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

Message-ID: <ac3eb2510904300934q4c36d6bdma9e610bfc0acb7bd@mail.gmail.com>
Date:	Thu, 30 Apr 2009 18:34:06 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	David Dillow <dave@...dillows.org>
Cc:	Michael Brown <mebrown@...haels-house.net>,
	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 Thu, Apr 30, 2009 at 17:18, David Dillow <dave@...dillows.org> wrote:
> On Wed, 2009-04-29 at 23:53 +0200, Kay Sievers wrote:
>> On Wed, Apr 29, 2009 at 23:28, Michael Brown <mebrown@...haels-house.net> wrote:
>> > 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.
>
> drivers/firmware/dell_rbu.c does this:
> req_firm_rc = request_firmware_nowait(THIS_MODULE,
>                                FW_ACTION_NOHOTPLUG, "dell_rbu",
>                                &rbu_device->dev, &context,
>                                callbackfn_rbu);
>
> I've not gone looking to verify, but FW_ACTION_NOHOTPLUG implies to me
> that udev never sees a uevent for it.

Ah, I see. Pretty weird idea to do that with polling, should be better
some key that tells udev to ignore the event, and you could listen to
the events yourself, instead of checking for them in sysfs at a
specific path and fixed name. But looks fine:
  if (uevent)
    dev_set_uevent_suppress(f_dev, 0);

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