Re: [BUG?] possible recursive locking detected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Anton Altaparmakov wrote:
On Thu, 2006-07-27 at 00:38 -0700, Andrew Morton wrote:

On Thu, 27 Jul 2006 08:15:27 +0100
Anton Altaparmakov <[email protected]> wrote:


I'm surprised ext2 is allocating with __GFP_FS set, though. Would that
cause any problem?

That is an ext2 bug IMO.

There is no bug.

What there is is an ill-defined set of rules.  If we want to tighten these
rules we have a choice between


I beg to differ.  It is a bug.  You cannot reenter the file system when
the file system is trying to allocate memory.  Otherwise you can never
allocate memory with any locks held or you are bound to introduce an
A->B B->A deadlock somewhere.

I don't think it is a bug in general. It really depends on the allocation:

- If it is a path that might be required in order to writeout a page, then
yes GFP_NOFS is going to help prevent deadlocks.

- If it is a path where you'll take the same locks as page reclaim requires,
then again GFP_NOFS is required.

For NTFS case, it seems like holding i_mutex on the write path falls foul
of the second problem. But I agree with Andrew that this is a critical case
where we do have to enter the fs. GFP_NOFS is too big a hammer to use.

I guess you'd have to change NTFS to do something sane privately, or come
up with a nice general solution that doesn't harm the common filesystems
that apparently don't have a problem here... can you just add GFP_NOFS to
NTFS's mapping_gfp_mask to start with?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux