linux-kernel - [PATCH 0/1] UIO: Add a write() function to enable/disable interrupts

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-next>] [day] [month] [year] [list]

Date:	Thu, 22 May 2008 21:22:52 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	linux-kernel@...r.kernel.org
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	Jan Altenberg <jan.altenberg@...utronix.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Uwe Kleine-KÃ¶nig <Uwe.Kleine-Koenig@...i.com>,
	Magnus Damm <magnus.damm@...il.com>
Subject: [PATCH 0/1] UIO: Add a write() function to enable/disable
	interrupts

At the moment, I've got two examples of hardware where the UIO interrupt
handling has problems:

1) A PCI card with several internal interrupt sources that can activate
the single IRQ line of the card. The card's PCI bridge has an irq
acknowledge register that can be mapped to userspace, but setting a bit
in it would be a read-modify-write operation which is racy from
userspace.

2) An FPGA that has several internal interrupt sources OR'ed to one
interrupt line that is connected to a GPIO of an ARM processor. The chip
only has a single IRQ register where different bits show the status of
the different interrupt sources. To acknowledge an IRQ, I have to clear
the respective bit, which would leave the userspace part of the driver
with a cleared register, unable to determine the source of the
interrupt. My only chance is to disable the GPIO interrupt, but this
leads to the problem that userspace cannot turn it on again.

The patch that I'll send in response to this mail solves these problems by
adding a write() function for /dev/uioX. Userspace can write a 32-bit
int value to /dev/uioX. This value will usually be 0 or 1 to disable or
enable the device's interrupts. The kernel part of the driver can
implement an irqcontrol() hook that is called by the UIO core.

Magnus Damm also ran into this problem when developing a generic UIO
platform handler and came up with a different solution:

http://lkml.org/lkml/2008/5/21/60

However, extending the UIO specs by adding a write function seems to be
a more generic approach. It allows enabling _and_ disabling of
interrupts. For devices that don't need this functionality, nothing
changes. They can simply ignore the new irqcontrol() pointer, and UIO
behaves as it always did. My patch is completely compatible with
existing UIO drivers, no changes to drivers are required.

Thanks to Jan Altenberg for testing this, and to Magnus Damm for telling
me that I'm not the only one who has these problems ;-)

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/