Re: How to properly wait for udev?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 27.11.23 21:32, Richard Weinberger (richard.weinberger@xxxxxxxxx) wrote:

> On Mon, Nov 27, 2023 at 9:29 AM Lennart Poettering
> <lennart@xxxxxxxxxxxxxx> wrote:
> > If they conceptually should be considered block device equivalents, we
> > might want to extend the udev logic to such UBI devices too.  Patches
> > welcome.
>
> Why doesn't udev flock() every device it is probing?
> Or asked differently, why is this feature opt-in instead of opt-out?

Some software really doesn't like it if we take BSD locks on their
devices, hence we don't take it blanket everywhere. And what's more
important even: for various devices it simply isn't safe to just
willy-nilly even open them (tape drivers and things, which might start
to pull in a tape if we do). For others we might not be able to even
open thing at all with the wrong flags (for example, because they are
output only).

Bock devices have relatively well defined semantics, there it's
generally safe to do this, hence we do.

Hence, it might be safe for UBI, but for the general case it might
not be.

That said, would BSD locking even address your issue? If you devices
are exclusive access things and we first open() them and then flock()
them, then that's not atomic. So if your test cases open the devices,
then flock() them you might still get into conflict udev because it
just open()ed the device, but didn#t get to call flock() yet.

Doesn't UBI have something like O_EXCL-behaviour that grants true
exclusive access?

Lennart

--
Lennart Poettering, Berlin