From: Roland Dreier <roland@digitalvampire.org>
To: unlisted-recipients:; (no To-header on input)
Cc: adilger@sun.com, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: ext4 lockdep report re possible reclaim deadlock on jbd2_handle
Date: Sun, 05 Jul 2009 12:10:00 -0700 [thread overview]
Message-ID: <87ocrzndyv.fsf@shaolin.home.digitalvampire.org> (raw)
In-Reply-To: <20090705124333.GA6757@mit.edu> (Theodore Tso's message of "Sun, 5 Jul 2009 08:43:33 -0400")
> What seems to be happening here is the ecryptfs is holding the file
> open, because of the upper dentry reference. So that's not a normal
> thing, and maybe that's why most people haven't noticed the problem;
> they're not doing enough with ecryptfs to trigger things.
Makes sense -- yes, I should have mentioned that I am using the Ubuntu
"$HOME on ecryptfs" feature; and also I had to fix 3 lockdep warnings
with ecryptfs before I hit this one. Still haven't caught the issue
with my own module code that I'm actually trying to debug :)
> How easily can you reproduce the lockdep warning? Does this patch
> (not tested; sorry, am in the Berkshires for the July 4th holiday)
> make it go away?
It's not very reproducible, I don't think; although I've just been
running with lockdep for about a week or so, and as I said I had to
work through 3 ecryptfs false positives before I got to this. I think
I triggered this while building a new kernel, and I haven't done that
since, so it may be reproducible, but I'm not sure.
In any case, I'd be surprised if:
- page = grab_cache_page(mapping, from >> PAGE_CACHE_SHIFT);
+ page = find_or_create_page(mapping, from >> PAGE_CACHE_SHIFT,
+ mapping_gfp_mask(mapping) & ~__GFP_FS);
doesn't get rid of the warning, and it looks like a good fix, although
I wonder if for a real upstream patch we wouldn't want to add a new
grab_cache_page()-like wrapper that does the "& ~__GFP_FS" --
grab_cache_page_nowait() isn't quite what's wanted here I don't think,
but something like that.
Anyway, I'll add this patch to my kernel and let you know if anything
ext4-related pops up.
Thanks,
Roland
--
Roland Dreier <roland@digitalvampire.org> GPG Key: 1024D/E0EEFAC0
Fingerprint: A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0
Sending >500KB attachments is forbidden by the Geneva Convention.
Your country may be at risk if you fail to comply.
prev parent reply other threads:[~2009-07-05 19:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-04 21:49 ext4 lockdep report re possible reclaim deadlock on jbd2_handle Roland Dreier
2009-07-05 12:43 ` Theodore Tso
2009-07-05 19:10 ` Roland Dreier [this message]
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=87ocrzndyv.fsf@shaolin.home.digitalvampire.org \
--to=roland@digitalvampire.org \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--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