[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wqg0cy9d.fsf@xmission.com>
Date: Tue, 11 Mar 2014 12:48:30 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: David Miller <davem@...emloft.net>
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
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.
It does break kgdboe that was never merged.
> 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.
Eric
--
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