[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E01DDD5.8020707@redhat.com>
Date: Wed, 22 Jun 2011 08:19:33 -0400
From: Prarit Bhargava <prarit@...hat.com>
To: Florian Westphal <fw@...len.de>
CC: David Miller <davem@...emloft.net>, fbl@...hat.com,
netdev@...r.kernel.org, agospoda@...hat.com, nhorman@...hat.com,
lwoodman@...hat.com, john.haxby@...cle.com
Subject: Re: [PATCH]: Add Network Sysrq Support
On 06/22/2011 06:54 AM, Florian Westphal wrote:
> Prarit Bhargava <prarit@...hat.com> wrote:
>
> [ cc'd John Haxby, who worked on xt_SYSREQ ]
>
>
>> On 06/21/2011 06:58 PM, David Miller wrote:
>>
>>> From: Florian Westphal <fw@...len.de>
>>> Date: Wed, 22 Jun 2011 00:56:45 +0200
>>>
>>>> This is one of the reasons why I still think that
>>>> xt_SYSREQ would be the better solution, you get all
>>>> kinds of filtering features for free.
>>>>
>>>> You could even use crazy things like '-m time' to restrict
>>>> sysreq availability to working hours and whatnot.
>>>>
>>>>
>>> Agreed.
>>>
>> Using the netfilter xt-SYSRQ code seems to store the entered code and
>> execute it later after the system has returned to a normal state....
>> which is much too late to be useful.
>>
> The target handler of the kernel part invokes handle_sysrq(),
> I don't see any delaying/queueing?
>
Yeah ... It just occurred to me on the way into the office that I made a
mistake.
... What if the "slow down" I'm seeing is due to the network layer? ...
but why would ping work and the xt_SYSRQ not work?
Either way ... I have a feeling that I'm on to something,
P.
--
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