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

[Artem Bityutskiy <dedekind@infradead.org>]

On Wed, 2008-12-17 at 22:53 +0300, dmitry pervushin wrote:
> > 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.

You may introduce a "ubi_get_volume(struct ubi_info *ubi, int vol_id)"
function, similar to the existing "ubi_get_device(int ubi_num)"
function. However, it looks like you may just use UBI_READONLY instead.
It will not prevent the "notifyees" to open the volume in UBI_READWRITE
mode.

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