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: <alpine.LFD.2.00.1012171725300.12146@localhost6.localdomain6>
Date:	Fri, 17 Dec 2010 17:32:46 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Jan Kiszka <jan.kiszka@...mens.com>
cc:	Jan Kiszka <jan.kiszka@....de>, Avi Kivity <avi@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kvm <kvm@...r.kernel.org>, Tom Lyon <pugs@...e.org>,
	Alex Williamson <alex.williamson@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v3 2/4] genirq: Inform handler about line sharing state

On Fri, 17 Dec 2010, Jan Kiszka wrote:
> Am 17.12.2010 16:25, Thomas Gleixner wrote:
> > Your aproach with disable_irq_nosync() is completely flawed, simply
> > because you try to pretend that your interrupt handler is done, while
> > it is not done at all. The threaded interrupt handler is done when
> > user space completes. Everything else is just hacking around the
> > problem and creates all that nasty transitional problems.
> 
> disable_irq_nosync is the pattern currently used in KVM, it's nothing
> new in fact.

That does not make it less flawed :)

> The approach looks interesting but requires separate code for
> non-PCI-2.3 devices, i.e. when we have no means to mask at device level.

Why? You can have the same code, you just can't request COND_ONESHOT
handlers for it, so it needs unshared ONESHOT or it won't work at all,
no matter what approach you chose. No device level mask, no sharing,
it's that simple.

> Further drawbacks - unless I missed something on first glance:
> 
> - prevents any future optimizations that would work without IRQ thread
>   ping-pong (ie. once we allow guest IRQ injection from hardirq context
>   for selected but typical setups)
> - two additional, though light-weight, context switches on each
>   interrupt completion

The drawback of these two points is way less than the horror which you
need to introduce to do the whole async handler disable, userspace
enable dance. Robust and simple solutions really a preferred over
complex and fragile horror which has a questionable runtime benefit.

> - continuous polling if user space decides to leave the interrupt
>   unhandled (e.g. because the virtual IRQ line is masked)
 
That should be a solvable problem.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ