From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Adrian Hunter <adrian.hunter@nokia.com>
Cc: "Bityutskiy Artem \(Nokia-D/Helsinki\)"
<Artem.Bityutskiy@nokia.com>,
David Woodhouse <David.Woodhouse@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
kosaki.motohiro@jp.fujitsu.com,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 4/7] nandsim: Don't use PF_MEMALLOC
Date: Tue, 24 Nov 2009 19:46:25 +0900 (JST) [thread overview]
Message-ID: <20091124194532.AFC2.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <4B0AEA33.3010306@nokia.com>
Hi
Thank you for this useful comments.
> > I vaguely remember Adrian (CCed) did this on purpose. This is for the
> > case when nandsim emulates NAND flash on top of a file. So there are 2
> > file-systems involved: one sits on top of nandsim (e.g. UBIFS) and the
> > other owns the file which nandsim uses (e.g., ext3).
> >
> > And I really cannot remember off the top of my head why he needed
> > PF_MEMALLOC, but I think Adrian wanted to prevent the direct reclaim
> > path to re-enter, say UBIFS, and cause deadlock. But I'd thing that all
> > the allocations in vfs_read()/vfs_write() should be GFP_NOFS, so that
> > should not be a probelm?
> >
>
> Yes it needs PF_MEMALLOC to prevent deadlock because there can be a
> file system on top of nandsim which, in this case, is on top of another
> file system.
>
> I do not see how mempools will help here.
>
> Please offer an alternative solution.
I have few questions.
Can you please explain more detail? Another stackable filesystam
(e.g. ecryptfs) don't have such problem. Why nandsim have its issue?
What lock cause deadlock?
next prev parent reply other threads:[~2009-11-24 10:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091117161551.3DD4.A69D9226@jp.fujitsu.com>
2009-11-17 7:18 ` [PATCH 3/7] mtd: Don't use PF_MEMALLOC KOSAKI Motohiro
2009-11-17 7:19 ` [PATCH 4/7] nandsim: " KOSAKI Motohiro
2009-11-23 15:00 ` Artem Bityutskiy
2009-11-23 20:01 ` Adrian Hunter
2009-11-24 10:46 ` KOSAKI Motohiro [this message]
2009-11-24 11:56 ` Adrian Hunter
2009-11-25 0:42 ` KOSAKI Motohiro
2009-11-25 7:13 ` Adrian Hunter
2009-11-25 7:18 ` KOSAKI Motohiro
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=20091124194532.AFC2.A69D9226@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=David.Woodhouse@intel.com \
--cc=adrian.hunter@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-mtd@lists.infradead.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