Anton Altaparmakov wrote:
On Thu, 2006-07-27 at 19:18 +1000, Nick Piggin wrote:
Anton Altaparmakov wrote:
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?
I don't think NTFS has a problem either. It is a theoretical problem
No, I mean: *really* doesn't have a problem. If Andrew says ext2 doesn't
need i_mutex in reclaim, then I tend to believe him.
with an extremely small chance of being hit. I am happy to have such a
problem for now. There are more pressing problems to solve. The only
thing that needs to happen is for the messages to stop so people stop
complaining / getting worried about them...
I guess the memory deadlock issue is probably mostly theoretical, although
it is still nice to get them fixed. I'd imagine a deadlock condition -- if
one really exists -- could be hit without much problem though. Page reclaim
will readily get kicked from the write(2) path, and will potentially free
*lots* of stuff from there.
If it isn't a problem for you, I'd suspect it might be due to some other
conditions which happen to mean it is avoided. For example, the inode who's
i_mutex you are holding will have a raised refcount AFAIK, so it will not
get reclaimed and so may get around your problem.
This would be a valid solution IMO. It probably could do with documentation
to outline the issues, though.
--
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]
