[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140311.160931.1395978386605601765.davem@davemloft.net>
Date: Tue, 11 Mar 2014 16:09:31 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ebiederm@...ssion.com
Cc: eric.dumazet@...il.com, netdev@...r.kernel.org,
xiyou.wangcong@...il.com, mpm@...enic.com, satyam.sharma@...il.com
Subject: Re: [RFC PATCH 0/2] remove netpoll rx support
From: ebiederm@...ssion.com (Eric W. Biederman)
Date: Tue, 11 Mar 2014 12:48:30 -0700
> David Miller <davem@...emloft.net> writes:
>
>> From: ebiederm@...ssion.com (Eric W. Biederman)
>> Date: Tue, 11 Mar 2014 01:43:10 -0700
>>
>>> Furthermore netpoll by it's design depends on the ability to receive
>>> packets in netpoll_poll_dev. It is a capability I don't think we have
>>> ever used in the mainline kernel but it is a capability that is there
>>> deliberately. Which means if we want netpoll to not mess with the rx
>>> path we need to change netpoll.
>>
>> This breaks kdump, and any other users of netpoll_rx() et al.
>
> It does not break kdump. (kdump starts a new kernel to do it's work).
>
> It does break the ancient lkcd netdump that was never merged, and has
> been abandoned (to the best of my knowledge). crash dumps proved
> entirely too fragile to perform from a broken kernel.
I feel like I've mixed this up in the past, multiple times, thanks
for the sanity check.
>> Make the zero budget depend upon us being invoked from hardware
>> irq context, or something like that.
>
> Good enough. I will respin my driver patches based on the assumption
> that netpoll will be changed in this way. There are no dependencies
> for the drivers, I just need to remove my rx path changes.
>
> We can have the conversation about how to change netpoll in parallel.
Sounds great.
--
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