From: Shaohua Li <shaohua.li@intel.com>
To: Tiju Jacob <jacobtiju@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Multi-partition block layer behaviour
Date: Thu, 27 Oct 2011 08:42:41 +0800 [thread overview]
Message-ID: <1319676161.22361.148.camel@sli10-conroe> (raw)
In-Reply-To: <CADAg6uy7iDG1QxHd=5hX7J=9dYGLA+Ze1uE6WwF7Nfxc83T4hA@mail.gmail.com>
On Wed, 2011-10-26 at 18:10 +0800, Tiju Jacob wrote:
> >> 1. When an I/O request is made to the filesystem, process 'A' acquires
> >> a mutex FS lock and a mutex block driver lock.
> >>
> >> 2. Process 'B' tries to acquire the mutex FS lock, which is not
> >> available. Hence, it goes to sleep. Due to the new plugging mechanism,
> >> before going to sleep, shcedule() is invoked which disables preemption
> >> and the context becomes atomic. In schedule(), the newly added
> >> blk_flush_plug_list() is invoked which unplugs the block driver.
> >>
> >> 3) During unplug operation the block driver tries to acquire the mutex
> >> lock which fails, because the lock was held by process 'A'. Previous
> >> invocation of scheudle() in step 2 has already made the context as
> >> atomic, hence the error "Schedule while atomic" occured.
> > if blk_flush_plug_list() is called in schedule(), it will use
> > blk_run_queue_async
> > to unplug the queue. This runs in a workqueue. So how could this happen?
> >
>
> The call stack goes as follows:
>
> From schedule() it calls blk_schedule_flush_plug() and
> blk_flush_plug_list() gets invoked.
>
> In blk_flush_plug_list() queue_unplugged() does not get invoked. Hence
> blk_run_queue_async is not called.
> Instead __elv_add_request() is invoked with ELEVATOR_INSERT_SORT_MERGE
> flag and the flag gets reassigned to ELEVATOR_INSERT_BACK.
>
> In ELEVATOR_INSERT_BACK, __blk_run_queue() gets invoked and calls request_fn().
This doesn't make sense. why the flag is changed from
ELEVATOR_INSERT_SORT_MERGE to ELEVATOR_INSERT_BACK?
can you post a full log? or did your driver have something special?
next prev parent reply other threads:[~2011-10-27 0:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-26 5:12 Multi-partition block layer behaviour Tiju Jacob
2011-10-26 5:42 ` Shaohua Li
2011-10-26 10:10 ` Tiju Jacob
2011-10-27 0:42 ` Shaohua Li [this message]
2011-10-31 4:35 ` Tiju Jacob
2011-10-31 5:39 ` Shaohua Li
2011-10-31 6:14 ` Shaohua Li
2011-10-31 10:21 ` Tiju Jacob
2011-11-01 0:29 ` Shaohua Li
2011-11-03 11:18 ` Tiju Jacob
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=1319676161.22361.148.camel@sli10-conroe \
--to=shaohua.li@intel.com \
--cc=jacobtiju@gmail.com \
--cc=linux-kernel@vger.kernel.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.