[PATCH] [UBI] 1/5 - UBI notifications, take two

[dmitry pervushin]

On Mon, 2008-12-15 at 16:04 +0200, Artem Bityutskiy wrote:
> Thanks for the patch, but I have some concerns. Please clarify some
> things.
> 
> 1. If X is subscribed to the notification, you assume that can X open
> UBI volumes from within the notification. At least I can see this in
> your "simple FTL". But this is recursion, ant it is very tricky. And I
> see problems related to this in your code. I may be mistaken, though.
> See below.
Thanks for reporting this. This is really a problem, and I'd suggest to
create additional mode in addition to
UBI_READONLY/UBI_READWRITE/UBI_EXCLUSIVE, say, UBI_OPEN_INTERNAL, to
increase reference count on the volume. 
> So you call notifiers from withing spin-locks. Are they really blocking
> notifiers? Note, if you call any UBI kernel API function from the
> notifier, you'll deadlock. E.g., if you call 'ubi_get_device_info()',
> you'll deadlock on 'ubi_devices_lock'. Did you test your code?
> 
> I guess you should prohibit recursion and pass full UBI device/volume
> information _inside_ the notifier. And the subsystems which work above
> UBI should never _open_ UBI volumes from within notifiers. E.g., the
> "simple FTL" stuff should open the UBI volume only when the
> corresponding FTL block device is opened, not in the notifier.
Although it is a good idea and it will save some time for notified
modules -- it won't help me. The block device created by ftl could be
opened immediately after creating, err.., actually, in the middle of
creating - e.g., to read partition table.

The ubi_enum_volumes could open the volume with the flag
UBI_OPEN_INTERNAL and thus release spinlock when calling notifiers.

Comments?
> -- 
> Best regards,
> Artem Bityutskiy (Битюцкий Артём)
>