All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Carsten Otte <COTTE@de.ibm.com>
Cc: jfs-discussion@oss.lotus.com, reiserfs-dev@namesys.com,
	andrea@suse.de, sct@dcs.ed.ac.uk, linux-kernel@vger.kernel.org,
	mauelshagen@sistina.com, Holger Smolinski <HSmolinski@de.ibm.com>,
	Horst Hummel <Horst.Hummel@de.ibm.com>
Subject: Re: Design-Question: end_that_request_* and bh->b_end_io hooks
Date: Thu, 26 Jul 2001 08:40:04 +0200	[thread overview]
Message-ID: <20010726084004.E648@suse.de> (raw)
In-Reply-To: <OF3CC2BFB9.69086721-ONC1256A93.0059C650@de.ibm.com>
In-Reply-To: <OF3CC2BFB9.69086721-ONC1256A93.0059C650@de.ibm.com>

On Tue, Jul 24 2001, Carsten Otte wrote:
> Hi  Folks,
> 
> as you are deeper into block-devices & filesystems than me,
> here are my two simple questions in short:
> Is it legal for a filesystem (or whatever) to install a hook into
> bh->b_end_io
> which calls generic_make_request?

No, b_end_io might be called from irq context (IDE for instance) which
will break for __make_request (both the _irq spin locks and the schedule
on request slot empty).

You could do bh stacking and defer stuff like this to a thread, that's
probably the way to go.

> Do block drivers need or are they allowed to hold the io_request_lock or
> other (local) locks when calling end_that_request_*?

Yes they may, in fact they _must_ hold it for end_that_request_last.
Look at blkdev_release_request -- it meddles with the queue free and
pending lists and must be protected against reentrancy. 

-- 
Jens Axboe


      parent reply	other threads:[~2001-07-26  6:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-24 17:20 Design-Question: end_that_request_* and bh->b_end_io hooks Carsten Otte
2001-07-25 17:24 ` tpepper
2001-07-25 21:04 ` [Jfs-discussion] " Dave Kleikamp
2001-07-25 21:47   ` Dave Kleikamp
2001-07-26  6:40 ` Jens Axboe [this message]

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=20010726084004.E648@suse.de \
    --to=axboe@suse.de \
    --cc=COTTE@de.ibm.com \
    --cc=HSmolinski@de.ibm.com \
    --cc=Horst.Hummel@de.ibm.com \
    --cc=andrea@suse.de \
    --cc=jfs-discussion@oss.lotus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mauelshagen@sistina.com \
    --cc=reiserfs-dev@namesys.com \
    --cc=sct@dcs.ed.ac.uk \
    /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.