On Mon, 2012-07-02 at 11:17 -0400, Jeff Layton wrote:
> nfs: broaden the cases where we use a non-blocking commit in releasepage
>
> Currently, we just do a non-blocking commit when called from kswapd, but
> that still gives us some cases where we end up blocking after recursing
> back into the filesystem. Instead, turn that check into a check for
> PF_MEMALLOC so that we never block when trying to free memory in order to
> satisfy an allocation.
>
> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
> ---
> fs/nfs/file.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> index 9075769..61d3670 100644
> --- a/fs/nfs/file.c
> +++ b/fs/nfs/file.c
> @@ -466,8 +466,8 @@ static int nfs_release_page(struct page *page, gfp_t gfp)
> !(current->flags & PF_FSTRANS)) {
> int how = FLUSH_SYNC;
>
> - /* Don't let kswapd deadlock waiting for OOM RPC calls */
> - if (current_is_kswapd())
> + /* Don't block if we're freeing for a memory allocation */
> + if (current->flags & PF_MEMALLOC)
> how = 0;
> nfs_commit_inode(mapping->host, how);
> }
Umm... So which process will actually call nfs_release_page() with
GFP_KERNEL, but without the PF_MEMALLOC flag being set?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
