From: Theodore Ts'o <tytso@mit.edu>
To: Li Xi <pkuelelixi@gmail.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
Andreas Dilger <adilger@dilger.ca>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] ext4: fix deadlock of i_data_sem in ext4_mark_inode_dirty()
Date: Thu, 4 Sep 2014 23:30:54 -0400 [thread overview]
Message-ID: <20140905033054.GE1971@thunk.org> (raw)
In-Reply-To: <CAPTn0cBcy+hHeC0oUk8eVrqHUTF8N05puKmZPBOKrafvaQHhxA@mail.gmail.com>
On Fri, Sep 05, 2014 at 10:29:16AM +0800, Li Xi wrote:
> On Fri, Sep 5, 2014 at 9:59 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> > On Thu, Sep 04, 2014 at 04:49:58PM +0800, Li Xi wrote:
> >> There are multiple places where ext4_mark_inode_dirty() is called holding
> >> write lock of EXT4_I(inode)->i_data_sem. However, if
> >> ext4_mark_inode_dirty() needs to expand inode size, this will cause
> >> deadlock when ext4_xattr_block_set() tries to get read lock of
> >> EXT4_I(inode)->i_data_sem.
> >
> > This was with inline data enabled, right?
> I hit this problem when starting a kernel with project quota support for ext4.
> The ext4 file system was not formated with project quota feature so it tried
> to extend the space for project ID. And this problem happened every time
> when the kernel was rebooted. Inline data was not enable on that file
> system. I am not sure whether this problem will happen under other
> circumstances. :)
I'm not understanding why expanding the inode size would result in
needing to call ext4_xattr_block_set. Was that becuse you were
storing the project quota in the xattr? I'm just trying to understand
the context.
Please also note that a recent set of patches (sent to the ext4 list
and in the ext4 git tree) has removed the need for taking i_data_sem
in xattr.c:
http://patchwork.ozlabs.org/patch/385347
http://patchwork.ozlabs.org/patch/385348
http://patchwork.ozlabs.org/patch/385346
(It's the 2/3 patch that removes taking i_data_sem read lock in xattr.c.)
Regards,
- Ted
next prev parent reply other threads:[~2014-09-05 3:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAPTn0cAPYMMDx-_RvL22Mf8YMcGib65YbiwfzDhCkEO7-OtHjw@mail.gmail.com>
2014-09-05 1:59 ` [PATCH] ext4: fix deadlock of i_data_sem in ext4_mark_inode_dirty() Theodore Ts'o
2014-09-05 2:29 ` Li Xi
2014-09-05 3:30 ` Theodore Ts'o [this message]
2014-09-05 4:44 ` Li Xi
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=20140905033054.GE1971@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=pkuelelixi@gmail.com \
/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.