[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB9v_DG7e8vDE+4PDwuOR2DYG1FEvUM1fxa+e4a=swwTYGJ9nQ@mail.gmail.com>
Date: Mon, 4 Jul 2011 15:48:31 +0400
From: Alexey Zaytsev <alexey.zaytsev@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, netdev@...r.kernel.org,
Gary Zambrano <zambrano@...adcom.com>,
bugme-daemon@...zilla.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Pekka Pietikainen <pp@...oulu.fi>,
Florian Schirmer <jolt@...box.org>,
Felix Fietkau <nbd@...nwrt.org>, Michael Buesch <mb@...sch.de>
Subject: Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
On Sun, Jul 3, 2011 at 19:46, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le dimanche 03 juillet 2011 à 01:25 +0400, Alexey Zaytsev a écrit :
>> On Fri, Jul 1, 2011 at 10:01, Alexey Zaytsev <alexey.zaytsev@...il.com> wrote:
>> > On Thu, Jun 30, 2011 at 01:51, Andrew Morton <akpm@...ux-foundation.org> wrote:
>> >>
>> >> (switched to email. Please respond via emailed reply-to-all, not via the
>> >> bugzilla web interface).
>> >>
>> >> On Thu, 23 Jun 2011 17:33:54 GMT
>> >> bugzilla-daemon@...zilla.kernel.org wrote:
>> >>
>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=38102
>> >>>
>> >>> Summary: BUG kmalloc-2048: Poison overwritten
>> >>> Product: Drivers
>> >>> Version: 2.5
>> >>> Kernel Version: 3.0.0-rc4
>> >>
>> >> Looks like a 2.6.38->2.6.39 regression, perhaps a memory scribble in b44.
>> >
>> > Actually, not sure about the version. 39 was the first one I've been
>> > using in the scenario. Checking older versions now.
>> > And git-log does not show a lot of changes to the b44 driver, so it
>> > might be something unrelated.
>> >
>>
>> I've checked back as far as 2.6.27, and the problem is still there.
>> I've also looked through the allocation-related code, and it seemed
>> sane. I'm not sure I understand the 1GB dma workaround, but this path
>> is never hit in my case. So adding the driver authors to CC. This
>> could be something different, but I've been unable to reproduce using
>> an other machine with an rtl8139 nic.
>
> Hmm, looking at b44 code, I believe there is a race there.
>
> Could you try following patch ?
>
This might fix a potential problem, but unfortunately did not help here.
There is an other place that looks suspicious to me:
812 struct sk_buff *copy_skb;
813
814 b44_recycle_rx(bp, cons, bp->rx_prod);
815 copy_skb = netdev_alloc_skb(bp->dev, len + 2);
816 if (copy_skb == NULL)
817 goto drop_it_no_recycle;
818
819 skb_reserve(copy_skb, 2);
820 skb_put(copy_skb, len);
821 /* DMA sync done above, copy just the
actual packet */
822 skb_copy_from_linear_data_offset(skb,
RX_PKT_OFFSET,
823
copy_skb->data, len);
824 skb = copy_skb;
The skb is reinserted into the ring before its data is copied, it
seems. But this can't be the cause of my problem, as it would lead to
data corruption at most, not a write-after-free.
And an other question. Why so we have the logic to work-around the 1Gb
DMA limit instead of just setting the dma mask?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists