[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhTzYQ3ZTnecZNQe7v5VTqSWsJeRCL+Qhwfk-nEuRQ-D5Q@mail.gmail.com>
Date: Fri, 21 Oct 2016 21:55:53 -0400
From: Paul Moore <paul@...l-moore.com>
To: David Miller <davem@...emloft.net>
Cc: rgb@...hat.com, xiyou.wangcong@...il.com,
Stephen Smalley <sds@...ho.nsa.gov>, netdev@...r.kernel.org,
e@...draz.com
Subject: Re: [Patch net] net: saving irq context for peernet2id()
On Fri, Oct 21, 2016 at 4:53 PM, Paul Moore <paul@...l-moore.com> wrote:
> On Fri, Oct 21, 2016 at 4:33 PM, David Miller <davem@...emloft.net> wrote:
>> From: Paul Moore <paul@...l-moore.com>
>> Date: Fri, 21 Oct 2016 16:15:00 -0400
>>
>>> However, that's not the case is it? Unless I missed something, the
>>> fix that Cong Wang is advocating (rework the audit multicast code), is
>>> a change that I have said I'm not going to accept during the -rc
>>> phase. It has been a few days now and no alternate fix has been
>>> proposed, I'll give it a few more hours ...
>>
>> It really is the right way to fix this though.
>>
>> Nothing should be emitting netlink messages, potentially en-masse
>> to a multicast group or broadcast, in hardware interrupt context.
>>
>> I know it's been said that only systemd receives these things, so
>> that point doesn't need to be remade again.
>
> I think it is also worth noting that this code has been doing it this
> way for some time now. I say this not to advocate that it is correct,
> only that there hasn't been a demonstrated problem until Cong Wang's
> patch.
>
>> We have many weeks until -final is released so I really don't
>> understand the reluctance at a slightly more involved fix in -rc2. In
>> fact this is the most optimal time to try it this way, as we'll have
>> the maximum amount of time for it to have exposure for testing before
>> -final.
>
> Well, I understand what you are trying to say, but the maximum amount
> of time for exposure/testing would be to put it in -next. The audit
> netlink code needs a rework, but introducing such a change in the -rc
> kernels is not something I'm going to do, especially when the change
> which triggered the regression is an optimization that can be easily
> reverted ... or fixed, but the only two options I've heard mentioned
> are the audit multicast rework and the revert; if someone has a third
> option I'm listening ...
It's the end of my day, and commitments over the weekend will limit
how much additional testing/work I can do so I went ahead and just
posted a simple revert to netdev, it should be in your inbox already.
Please fix this, either through a revert, or preferably some other fix
we haven't thought of yet, in time for -rc2.
Thanks.
--
paul moore
www.paul-moore.com
Powered by blists - more mailing lists