linux-kernel - Re: Class device namespaces

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:	Wed, 29 Apr 2009 23:53:58 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Michael Brown <mebrown@...haels-house.net>
Cc:	Doug Warzecha <Douglas_Warzecha@...l.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Matt Domsch <Matt_Domsch@...l.com>
Subject: Re: Class device namespaces

On Wed, Apr 29, 2009 at 23:28, Michael Brown <mebrown@...haels-house.net> wrote:
> On Wed, Apr 29, 2009 at 2:10 PM, Kay Sievers <kay.sievers@...y.org> wrote:
>> Udev runs exactly at the time you create the device, and is not
>> unlikely faster than your polling, at least not predictable slower.
>> And it will cancel all requests which can not be fulfilled by udev
>> itself.
>>
>> I strongly recommend switching to a different solution, you can not
>> use the firmware_class interface on any udev system, the interface is
>> already taken, and it's a single-user interface the way it is
>> implemented today. That it seems to work for you, is pure luck, I
>> guess. :)
>
> Is there a safe/easy way to tell udev that we will handle a particular
> request?

No, not with the current interface.

> I cant say that I've ever seen any problems due to udev
> cancelling a firmware request.  In fact, if I manually trigger a
> request using "echo" from the cmdline, I dont see udev take any action
> with the dell_rbu device. eg (Fedora 10, udev-127-5.fc10):

If you run:
  udevmonitor --udev --env
at the same time, what does it say?

> I dont see any of the behaviour that you have talked about. If I let
> it sit there for hours, it will stay at that state. It only closes up
> the request_firmware() request when I echo 0 > loading.

Udev will run in the moment this sysfs device is created, and it
should trigger the removal of the device, if it does not find the
requested firmware file.

> At this point, we have had this interface in the upstream kernel.org
> kernel since 2.6.14 and have a pretty huge legacy codebase that relies
> on this behaviour. We need to make sure that the current behaviour
> remains.

If we are talking about the same thing, which I'm not really sure
anymore, then you can not be sure that this will work in the future.
You can not reliably take over requests for the firmware class with
custom tools while udev is running.

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