[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <544EA39A.1080005@windriver.com>
Date: Mon, 27 Oct 2014 13:57:14 -0600
From: Chris Friesen <chris.friesen@...driver.com>
To: Austin Schuh <austin@...oton-tech.com>, <pavel@...linux.ru>
CC: "J. Bruce Fields" <bfields@...ldses.org>,
<linux-ext4@...r.kernel.org>, <tytso@....edu>,
<adilger.kernel@...ger.ca>,
rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: RT/ext4/jbd2 circular dependency
On 10/23/2014 11:54 AM, Chris Friesen wrote:
> Basically it looks like we have a circular dependency involving the
> inode->i_data_sem rt_mutex, the PG_writeback bit, and the BJ_Shadow list. It
> goes something like this:
>
> jbd2_journal_commit_transaction:
> 1) set page for writeback (set PG_writeback bit)
> 2) put jbd2 journal head on BJ_Shadow list
> 3) sleep on PG_writeback bit waiting for page writeback complete
>
> ext4_da_writepages:
> 1) ext4_map_blocks() acquires inode->i_data_sem for writing
> 2) do_get_write_access() sleeps waiting for jbd2 journal head to come off
> the BJ_Shadow list
>
> At this point the flush code can't run because it can't acquire
> inode->i_data_sem for reading, so the page will never get written out.
> Deadlock.
Just curious...would we expect lockdep to detect this sort of thing? I
wasn't sure if the introduction of the two wait queues would cause
complications.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists