All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suresh Jayaraman <sjayaraman@suse.de>
To: trond.myklebust@netapp.com, David Howells <dhowells@redhat.com>
Cc: Linux NFS mailing list <linux-nfs@vger.kernel.org>
Subject: [RFC][PATCH] nfs: don't assume fscache_acquire_cookie will always succeed
Date: Wed, 20 Jan 2010 17:51:57 +0530	[thread overview]
Message-ID: <4B56F565.7080104@suse.de> (raw)

We seem to be assuming fscache_acquire_cookie will always succeed and will
obtain a valid cookie. But, under low memory conditions kmem_cache_alloc
could fail and that would leave nfsi->fscache being set to NULL.

This could lead to a possibility of a page with PG_fscache flag set but
cookie not set(i.e. NULL). This inconsistency could trigger a kernel BUG in
nfs_fscache_release_page() and other places as we do BUG_ON(!cookie), I think.

I'm aware that there are other places where we would need such checks, but
wanted to validate this patch before getting on to them.

Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
---

 fs/nfs/client.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index ee77713..7776e8a 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -155,6 +155,8 @@ static struct nfs_client *nfs_alloc_client(const struct nfs_client_initdata *cl_
 		clp->cl_machine_cred = cred;
 
 	nfs_fscache_get_client_cookie(clp);
+	if (!clp->fscache)
+		goto error_cleanup;
 
 	return clp;
 
-- 
Suresh Jayaraman

             reply	other threads:[~2010-01-20 12:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-20 12:21 Suresh Jayaraman [this message]
2010-01-20 21:35 ` [RFC][PATCH] nfs: don't assume fscache_acquire_cookie will always succeed Trond Myklebust
2010-01-21 11:07 ` David Howells
2010-01-21 11:41   ` Suresh Jayaraman
2010-01-22 12:52   ` Suresh Jayaraman
2010-01-23  3:48     ` David Howells

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=4B56F565.7080104@suse.de \
    --to=sjayaraman@suse.de \
    --cc=dhowells@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@netapp.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.