From: Artem Bityutskiy <dedekind@infradead.org>
To: dpervushin@gmail.com
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [UBI] 1/5 - UBI notifications, take two
Date: Thu, 18 Dec 2008 09:31:40 +0200 [thread overview]
Message-ID: <1229585500.17960.99.camel@sauron> (raw)
In-Reply-To: <1229543636.7900.53.camel@hp.diimka.lan>
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 (Битюцкий Артём)
next prev parent reply other threads:[~2008-12-18 7:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-15 11:13 [PATCH] [UBI] 1/5 - UBI notifications, take two dmitry pervushin
2008-12-15 14:04 ` Artem Bityutskiy
2008-12-17 19:53 ` dmitry pervushin
2008-12-18 7:31 ` Artem Bityutskiy [this message]
2008-12-18 11:07 ` dmitry pervushin
2008-12-18 11:11 ` Artem Bityutskiy
2008-12-18 11:14 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1229585500.17960.99.camel@sauron \
--to=dedekind@infradead.org \
--cc=dpervushin@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.