public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: "Peter T. Breuer" <ptb@it.uc3m.es>
Cc: Pavel Machek <pavel@suse.cz>,
	Steve Whitehouse <Steve@ChyGwyn.com>,
	linux kernel <linux-kernel@vger.kernel.org>,
	alan@lxorguk.ukuu.org.uk, chen_xiangping@emc.com
Subject: Re: Kernel deadlock using nbd over acenic driver
Date: Wed, 29 May 2002 15:24:54 +0200	[thread overview]
Message-ID: <20020529132454.GO17674@suse.de> (raw)
In-Reply-To: <20020529112137.GA397@elf.ucw.cz> <200205291210.g4TCAgh32404@oboe.it.uc3m.es>

On Wed, May 29 2002, Peter T. Breuer wrote:
> "A month of sundays ago Pavel Machek wrote:"
> > > > Init routine is called from insmod context or at kernel bootup (from pid==1).
> > > 
> > > That's nitpicking!  
> > 
> > I did not want to be nitpicking. init() really is considered process
> 
> Well, OK.
> 
> > context, and it looks to me like unplug is *blocking* operation so it
> > really needs proceess context.
> 
> unplug unsets the plugged flag and calls the request function. The
> question is whether the request function is allowed to block. I argue
> that it is not, on several grounds:
> 
>     1) it's also - and principally - been called from various task
>     queues, which aren't really associated with a process context, and
>     certainly not with the process context that set the task

It's called from tq_disk only, which is in process context. So at least
on that ground lets say that it is at least not technically illegal to
block.

>     2) blocking is really bad news depending on how we got to the
>     request function, which is not a really predictable thing, since
>       i) it can change with every kernel version
>       ii) it depends on what somebody else does

I don't agree with that. You get there from an unplug, which happens
from process context as already established. If you get there from other
places, it means that you are calling your request_fn from elsewhere in
your driver (typically recalling request_fn from isr or bottom half to
queue more I/O), and in that case it's your own responsibility.

>    3) if we block against memory for buffers, in particular, the 
>    the system is now very likely to be dead, since VM just went
>    synchronous.

Of course that is a tricky area. You shouldn't be doing memory
allocations inside the request_fn, that's just bad design, period.

The one reason why blocking inside the request_fn is bad, is that it
prevents the following queues on the tq_disk list from being run. And
subsequent tq_disk runs will not unplug them, since run_task_queue()
clears the list prior to starting.

-- 
Jens Axboe


  reply	other threads:[~2002-05-29 13:26 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-16 22:54 Kernel deadlock using nbd over acenic driver Peter T. Breuer
2002-05-17  8:44 ` Steven Whitehouse
2002-05-23 13:21   ` Peter T. Breuer
2002-05-24 10:11     ` Steven Whitehouse
2002-05-24 11:43       ` Peter T. Breuer
2002-05-24 13:28         ` Steven Whitehouse
2002-05-24 15:54           ` Peter T. Breuer
2002-05-27 13:04             ` Steven Whitehouse
2002-05-27 19:51               ` Peter T. Breuer
2002-05-27 13:44         ` Pavel Machek
2002-05-29 10:51           ` Peter T. Breuer
2002-05-29 11:21             ` Pavel Machek
2002-05-29 12:10               ` Peter T. Breuer
2002-05-29 13:24                 ` Jens Axboe [this message]
2002-06-01 21:13       ` Peter T. Breuer
2002-06-05  8:48         ` Steven Whitehouse
2002-06-02  6:39           ` Pavel Machek
     [not found] <3CE40A77.22C74DC1@zip.com.au>
2002-05-16 20:28 ` Peter T. Breuer
  -- strict thread matches above, loose matches on Subject: below --
2002-05-16 13:18 chen, xiangping
2002-05-15 21:43 Peter T. Breuer
2002-05-16  8:33 ` Steven Whitehouse
2002-05-15 17:43 Peter T. Breuer
2002-05-15 19:43 ` Steven Whitehouse
2002-05-16  5:15   ` Peter T. Breuer
2002-05-16  8:04     ` Steven Whitehouse
2002-05-16  8:49       ` Peter T. Breuer
2002-05-15 16:01 Peter T. Breuer
2002-05-14 17:42 chen, xiangping
2002-05-14 17:36 chen, xiangping
2002-05-14 18:02 ` Alan Cox
2002-05-14 16:07 chen, xiangping
2002-05-14 16:32 ` Steven Whitehouse
2002-05-14 16:48 ` Alan Cox
2002-05-15 22:31 ` Oliver Xymoron
2002-05-16  5:10   ` Peter T. Breuer
2002-05-16  5:19     ` Peter T. Breuer
2002-05-16 14:29       ` Oliver Xymoron
2002-05-16 15:35         ` Peter T. Breuer
2002-05-16 16:22           ` Oliver Xymoron
2002-05-16 16:45             ` Peter T. Breuer
2002-05-16 16:35               ` Steven Whitehouse
2002-05-17  7:01                 ` Peter T. Breuer
2002-05-17  9:26                   ` Steven Whitehouse
2002-05-14 15:05 chen, xiangping
2002-05-14 15:11 ` Jes Sorensen
2002-05-10 15:39 chen, xiangping
2002-05-10 15:02 chen, xiangping
2002-05-10 15:11 ` Steven Whitehouse
2002-05-14 14:58 ` Jes Sorensen
2002-05-06 15:05 chen, xiangping
2002-05-07  8:15 ` Steven Whitehouse
2002-05-06  2:26 chen, xiangping
2002-05-06  8:45 ` Steven Whitehouse

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=20020529132454.GO17674@suse.de \
    --to=axboe@suse.de \
    --cc=Steve@ChyGwyn.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=chen_xiangping@emc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=ptb@it.uc3m.es \
    /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