Message-ID: <ac3eb2510909180758u2131ae0eo9030a97cdde75bc6@mail.gmail.com>
Date:	Fri, 18 Sep 2009 16:58:28 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartmann <greg@...ah.com>
Subject: Re: [PATCH] Remove broken by design and by implementation devtmpfs 
	maintenance disaster

On Fri, Sep 18, 2009 at 16:43, Arjan van de Ven <arjan@...radead.org> wrote:
> On Fri, 18 Sep 2009 16:32:18 +0200
> Kay Sievers <kay.sievers@...y.org> wrote:
>> On Fri, Sep 18, 2009 at 16:25, Arjan van de Ven <arjan@...radead.org>
>> wrote:
>> > On Fri, 18 Sep 2009 16:11:16 +0200
>> > Kay Sievers <kay.sievers@...y.org> wrote:
>> >
>> >> On Fri, Sep 18, 2009 at 16:09, Arjan van de Ven
>> >> <arjan@...radead.org> wrote:
>> >>
>> >> > frankly, modprobe should call the settle.
>> >>
>> >> We call modprobe from udev, and will have fun with such a solution.
>> >
>> > too bad you cut my next sentence which said that there needed to be
>> > a way to opt out of that.
>>
>> Too bad, bad we don't have control over all the udev rules out there
>> doing that, which will dead-lock then. And too bad that when udev
>> calls modprobe we still don't solve the races. Too bad that calling
>> "settle" waits for all events and you can never know when loading a
>> module what to wait for and what not. It's just not a close to a
>> solution that is doing any good. What's the point of all these weird
>> workarounds you are proposing? I think it's properly solved already.
>
> please chill out. your attitude is exactly why several folks are giving
> an allergic reaction. every other sentence for you is either extreme
> defensive or attacking, rather than constructive discussion.

Oh, sorry, I'm just very tired of getting hacks like this thrown at
me, to show that we don't need a synchronous device node handling. I
don't see how that solves the problem, but it causes many new ones.

> Lets be clear:
> 1) modprobe already does some serialization (right now on the kernel
>   side, but ideally we move that to modprobe binary so that we can skip
>   that when we can)

We only serialize symbol linking I guess, and that window got pretty
small in recent kernels.

> 2) udev today has a small design issue that is relatively easy to fix.
> Right now, the rules call modprobe manually, each and every one of
> them. What is needed is a MODPROBE += directive for these instead of
> the RUN += that is done today. This is not (just) for this issue here,
> but is essential to reduce the cost of udev. A big chunk of udev cost
> is in doing dozens and dozens of useless modprobe execs; the only way
> to solve this is by having a MODPROBE +=.
> (useless because the thing they modprobe doesn't exist)

That would help in which case? Which single event does do more than a
single modprobe call? What do you want to collect?

> 3) if we move synchronization for other things to modprobe, it might
> make sense to move the device node synchronization to it as well.
> Exactly for the scenario you described, to get a good, generic
> solution, that also makes sure that the permissions/ownership/etc of
> the device node is also the right one.

How do you know what to sync against, what to wait for? I'm pretty
sure the sync creation is much simpler and solves most of the problems
in the right way.

> (to answer your "we are perfect" dream:
> you solved the "modprobe loop; losetup" example.
> you did not solve the "modprobe i915 ; startx" example.
> )

Sure, it can not solve things where managed user ACLs are involved.

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/

Powered by blists - more mailing lists