[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: <>
References: <> <> <> <> <> <>
Reply-to: jmoyer@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
==> Regarding Re: serious netpoll bug w/NAPI; Matt Mackall <mpm@xxxxxxxxxxx> 

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:
>> 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.



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