lkml.org 
[lkml]   [2008]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: potential regression in ext[34] call to __page_symlink()?
On Tue, Oct 28, 2008 at 08:11:48PM -0400, Mike Snitzer wrote:
> The gfp_mask that is passed to __page_symlink() is being completely
> dropped on the floor. Historically this mask was at least used by
> ext3 and ext4 to avoid recursing back into the FS from within a
> journal transaction; Kirill fixed that issue with this commit:
> 0adb25d2e71ab047423d6fc63d5d184590d0a66f
>
> I'm quite naive when it comes to Nick's relatively new (>= 2.6.24) AOP
> pagecache_write_{begin,end} code that motivated __page_symlink to
> change with this commit:
> afddba49d18f346e5cc2938b6ed7c512db18ca68
>
> Nick's change clearly did away with using the explicitly passed
> gfp_mask in __page_symlink().
> So at a minimum it would seem __page_symlink() now has an unused
> parameter that should be removed.
>
> But a more serious concern would be: have ext[34]_symlink() regressed
> to being susceptible to the bug that Kirill fixed some time ago?

Yeah, I think this would be a potential problem for ext3/4. Looks
like pagemap_write_begin() should take a gfp_mask argument, and then
pass it down through to __grab_cache_page(), which should then call
__page_cache_alloc() instead of _page_cache_alloc(). Then
__page_symlink() can actually pass in its gfp_mask to
pagemap_write_begin().

Nick, do you agree?

- Ted


\
 
 \ /
  Last update: 2008-10-29 03:43    [W:0.042 / U:0.740 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site