netdev
[Top] [All Lists]

Re: serious netpoll bug w/NAPI

To: Matt Mackall <mpm@xxxxxxxxxxx>
Subject: Re: serious netpoll bug w/NAPI
From: Jeff Moyer <jmoyer@xxxxxxxxxx>
Date: Wed, 16 Feb 2005 17:07:01 -0500
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20050216050722.GC3358@waste.org>
References: <20050208201634.03074349.davem@davemloft.net> <20050209183219.GA2366@waste.org> <20050209164658.409f8950.davem@davemloft.net> <20050210011104.GF2366@waste.org> <16914.31886.665975.522710@segfault.boston.redhat.com> <20050216050722.GC3358@waste.org>
Reply-to: jmoyer@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall <mpm@xxxxxxxxxxx> 
adds:

mpm> On Tue, Feb 15, 2005 at 05:49:50PM -0500, Jeff Moyer wrote:
>> ==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall <mpm@xxxxxxxxxxx> 
>> adds:
>> 
[snip]
>> 
>> Okay, I've only taken a quick glance at this, but I don't quite understand
>> why it's safe to take out the check for the per-cpu queue.  Realize that an
>> interrupt may have been serviced on another processor, and a NAPI poll may
>> have been scheduled there.

mpm> Because dev->np->poll_lock now serializes all access to ->poll (when
mpm> netpoll is enabled on said device).

>> Also, could you use the -p flag to diff when you generate your next patch?
>> It makes it *much* easier to review.

mpm> Hmm, somehow my QUILT_DIFF_OPTS got lost, thanks.

mpm> I've just now recovered my SMP+NAPI box, so I can take a stab at
mpm> actually testing this shortly.

I put together a patch against our kernel tree which implements essentially
the same logic as your patch, and it works great:  I was able to reproduce
the bug without the patch, and the patched kernel is running just fine.
Let me know when you have another version of your patch, and I will happily
test it in my environment.

Thanks,

Jeff

<Prev in Thread] Current Thread [Next in Thread>