public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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 13:11:43 +0200	[thread overview]
Message-ID: <1229598703.17960.104.camel@sauron> (raw)
In-Reply-To: <1229598476.7900.62.camel@hp.diimka.lan>

On Thu, 2008-12-18 at 14:07 +0300, dmitry pervushin wrote:
> On Thu, 2008-12-18 at 09:31 +0200, Artem Bityutskiy wrote:
> > 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.
> But will prevent opening in UBI_EXCLUSIVE. OK, get_volume/put_volume
> looks as the right way to go.

It will prevent exlusive, as well as get/put must prevent exclusive, so
there should be no difference for you at all. Exclusive is used when the
module is removed or re-sized, and there must be zero users if these
operations are performed.

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

  reply	other threads:[~2008-12-18 11:11 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
2008-12-18 11:07       ` dmitry pervushin
2008-12-18 11:11         ` Artem Bityutskiy [this message]
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=1229598703.17960.104.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox