[lkml]   [2005]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] forcedeth: fix random memory scribbling bug
Jeff Garzik wrote:

> Manfred Spraul wrote:
>> Two critical bugs were found in forcedeth 0.47:
>> - TSO doesn't work.
>> - pci_map_single() for the rx buffers is called with size==0. This
>> bug is critical, it causes random memory corruptions on systems with
>> an iommu.
>> Below is a minimal fix for both bugs, for inclusion into 2.6.15.
>> TSO will be fixed properly in the next version.
>> Tested on x86-64.
>> Signed-Off-By: Manfred Spraul <>
> 1) Why does forcedeth require a non-standard calculation for each
> pci_map_single() call?
- skb->len is the wrong thing (tm), since it's 0 until skb_put().
- I have not found a field that contains the actual size of the data
area of an skb.
- the results must be identical for map and unmap.
- I could recalculate the size of the allocation from np->rx_buf_sz, but
I don't like that. Right now it would work, but it's too subtile that
changing rx_buf_sz while there are outstanding rx buffers results in a
iommu memory leak.
Therefore I decided to calculate the mapping size with "skb->end -
skb->data": The size of the mapping for an skb is calculated by looking
at fields in the skb, no knowledge about driver fields.

> 2) I have requested multiple times that you avoid MIME...
It's the first time that you complain about Content-Transfer-Encoding:
7bit attachments.

> 3) Why disable TSO completely? It sounds like it should default to
> off, then permit enabling via ethtool.
The bugfix is in 0.49 - it's just a bit larger, I would consider it for

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-12-24 17:11    [W:0.039 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site