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]
Date:	Thu, 25 Mar 2010 09:54:50 +0100
From:	Giel van Schijndel <me@...tis.eu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Hans de Goede <hdegoede@...hat.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	Laurens Leemans <laurens@...nips.com>,
	lm-sensors@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/4] [RFC] hwmon: f71882fg: Add watchdog API for
 F71808E and F71889

On Wed, Mar 24, 2010 at 03:51:51PM +0000, Alan Cox wrote:
>> hold on the SIO port range. This would thus interfere with the
>> operation of the f71882fg driver. I.e. it would prevent the device
>> probing stage from working, thus preventing it from loading *after*
>> my in-development watchdog driver.
> 
> There are two ways to deal with that really
> 
> ... snip ...
>
> 2. Fix the kernel request_resource stuff to support a sleeping non
> exclusive resource so request/free of regions can be used as a resource
> semaphore by co-operative devices.
> 
> #2 is actually not hard but when I did the patch originally it then
> wasn't needed by the driver I had in mind for other reasons.
> 
> See http://groups.google.com/group/linux.kernel/msg/1425fc2aad32e6ea
> 
> Maybe its worth resurrecting ?

In this particular case I most definitely think it's worth resurrecting.
Using your patch (I had to change the IORESOURCE_MUXED constant's value
though) I can completely solve the I/O sharing issue for the f71882fg +
watchdog case with only a single line modification to the f71882fg
driver.

One question regarding your patch though: how will it function when
driver (A) locks an I/O region using request_region() then driver (B)
comes along and tries to lock it using request_muxed_region()? One
problem I imagine might occur is that driver (A)'s 'struct resource'
doesn't have the IORESOURCE_MUXED flags set, thus simply won't wake up
driver (B) on the 'muxed_resource_wait' queue.

-- 
Met vriendelijke groet,
With kind regards,
Giel van Schijndel

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ