lkml.org 
[lkml]   [2011]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Multi-partition block layer behaviour
From
Date
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?




\
 
 \ /
  Last update: 2011-10-27 02:37    [W:1.706 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site