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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox