linux-kernel - Re: [GIT PULL] KVM fixes for 3.5-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50016C44.5000607@web.de>
Date:	Sat, 14 Jul 2012 14:55:32 +0200
From:	Jan Kiszka <jan.kiszka@....de>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	KVM list <kvm@...r.kernel.org>
Subject: Re: [GIT PULL] KVM fixes for 3.5-rc6

On 2012-07-14 14:33, Thomas Gleixner wrote:
> On Sat, 14 Jul 2012, Jan Kiszka wrote:
>> On 2012-07-14 13:16, Thomas Gleixner wrote:
>>> On Sat, 14 Jul 2012, Jan Kiszka wrote:
>>>> On 2012-07-14 04:25, Thomas Gleixner wrote:
>>>> This patch here is a workaround to unbreak devices assignment in 3.5
>>>> after the IRQ layer changes without regressing noticeable /wrt overhead.
>>>
>>> Yeah, workaround and regression are the proper marketing buzzwords to
>>> excuse mindless hackery.
>>>
>>> It took me a minute to figure out that there is no reason at all to
>>> use a threaded interrupt handler for MSI and MSIX.
>>
>> Thomas, we also explained to you in the cited thread that your simple
>> approach for this doesn't work as is. We will have a proper solution
>> soon, but it takes a bit more than a minute - at least us.
> 
> And I explained to you in that very thread that the proper solution to
> avoid the "overhead" of finalize_oneshot is exaclty the patch I sent
> to Linus yesterday:
> 
>> The only way we can avoid that, is that we get a hint from the
>> underlying irq chip/ handler setup with an extra flag to tell the
>> core, that it's safe to avoid the ONESHOT/finalize magic.
> 
> So now it took a full month of ignorance to come up with the
> mindboggling solution of working around the core change with a private
> hack instead of sitting down and doing what was said to be the correct
> solution.

We sat down and tried to avoid the core problem of our use case: IRQ
threading. That we now have to fall back to something else is
unfortunate and was surely not planned.

However, if you push your patch for 3.5, I'm sure Avi will happily drop
the disliked workaround and replace it with ordinary IRQF_ONESHOT tagging.

Jan


Download attachment "signature.asc" of type "application/pgp-signature" (263 bytes)