linux-kernel - Re: [PATCH] uio_pdrv: Unique IRQ Mode

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: <20080610090158.GC4611@local>
Date:	Tue, 10 Jun 2008 11:01:59 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Uwe Kleine-König <Uwe.Kleine-Koenig@...i.com>
Cc:	"Hans J. Koch" <hjk@...utronix.de>,
	Magnus Damm <magnus.damm@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"lethal@...ux-sh.org" <lethal@...ux-sh.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH] uio_pdrv: Unique IRQ Mode

On Tue, Jun 10, 2008 at 08:11:21AM +0200, Uwe Kleine-König wrote:
> > >
> > > IMHO it should be asserted that irqs are on before waiting for the irq
> > > in poll and read.  So I suggest to call irqcontrol(ON) before doing so.
> > > This should allow to work with that kind of hardware, right?
> > 
> > Yes. But userspace can simply write() a 1 to /dev/uioX to achieve the
> > same result. This would clearly show what's happening. Remember, this is
> > only needed for certain (broken) hardware. If we hide some automagic irq
> > enabling in the kernel, it'll become less obvious and might even have
> > some bad side effects. I want to avoid this kind of trickery, especially
> > as it is not needed. Userspace should use write() to control irqs. It's
> > like this with any normal UIO driver, and we shouldn't have a different
> > handling in uio_pdrv.
> > Think of a chip that's directly connected to the bus on some embedded
> > board. You use uio_pdrv to handle it. Then the very same chip appears on
> > a PCI card in a normal PC. You write a normal UIO driver for it. The
> > userspace part of both drivers could be exactly the same. But if
> > uio_pdrv automagically reenabled the irq, we would need different
> > handling in userspace, without reasons obvious to the user.

> Note that my intention is to enable irqs in uio.c, not uio_pdrv.c.

Forget it. We won't have some crap that automagically enables irqs in
read() and poll(), neither with irq_enable() nor with irqcontrol(). It's
not a clean solution. We now have a clean solution how userspace can
enable interrupts by using write(), and this (together with uio_pdrv)
can handle all cases we were talking about.

You keep arguing about code that neither introduces new features nor
offers any other advantages. I'm really tired of that.

Thanks,
Hans

--
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/