All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Jones <davej@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>,
	viro@zeniv.linux.org.uk,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: suppress page allocation failure warnings from sys_listxattr
Date: Wed, 28 Mar 2012 18:10:23 -0700	[thread overview]
Message-ID: <20120328181023.274401d1.akpm@linux-foundation.org> (raw)
In-Reply-To: <20120329005442.GB16008@redhat.com>

On Wed, 28 Mar 2012 20:54:42 -0400 Dave Jones <davej@redhat.com> wrote:

> On Wed, Mar 28, 2012 at 04:47:20PM -0700, Andrew Morton wrote:
>  > On Wed, 28 Mar 2012 15:39:51 +1100
>  > Dave Chinner <david@fromorbit.com> wrote:
>  > 
>  > > > Well, the unusual thing was that I was fuzzing system calls for a few hours.
>  > > > 
>  > > > My fuzzing tool was able to trigger these very easily after an hour or two
>  > > > of uptime and memory had fragmented a little, so yeah, quite trivial.
>  > > 
>  > > We've recently been seeing reports of xfsdump trigging a similar
>  > > allocation failures in the XFS attr code when we are doing hundreds
>  > > of thousands of attribute lookups to back them up.
>  > > 
>  > > ad650f5 xfs: fallback to vmalloc for large buffers in xfs_attrmulti_attr_get
>  > > 
>  > > I think that falling back to vmalloc here is much better solution
>  > > than failing to retreive the attribute - it will work no matter how
>  > > fragmented memory gets. That means we don't get incomplete
>  > > backups occurring after days or months of uptime and successful
>  > > backups...
>  > 
>  > Yup.  How does the below look?
> 
> Don't see anything immediately wrong with it.
> Any thoughts on what to do about the similar problem in setxattr ? (memdup_user)
> 

I can't think of anything clever.

The dumb approach:

From: Andrew Morton <akpm@linux-foundation.org>
Subject: fs/xattr.c:setxattr(): improve handling of allocation failures

This allocation can be as large as 64k.

- Add __GFP_NOWARN so that a falied kmalloc() is silent

- Fall back to vmalloc() if the kmalloc() failed

Cc: Dave Chinner <david@fromorbit.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: David Rientjes <rientjes@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 fs/xattr.c |   21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff -puN fs/xattr.c~fs-xattrc-setxattr-improve-handling-of-allocation-failures fs/xattr.c
--- a/fs/xattr.c~fs-xattrc-setxattr-improve-handling-of-allocation-failures
+++ a/fs/xattr.c
@@ -320,6 +320,7 @@ setxattr(struct dentry *d, const char __
 {
 	int error;
 	void *kvalue = NULL;
+	void *vvalue = NULL;	/* If non-NULL, we used vmalloc() */
 	char kname[XATTR_NAME_MAX + 1];
 
 	if (flags & ~(XATTR_CREATE|XATTR_REPLACE))
@@ -334,13 +335,25 @@ setxattr(struct dentry *d, const char __
 	if (size) {
 		if (size > XATTR_SIZE_MAX)
 			return -E2BIG;
-		kvalue = memdup_user(value, size);
-		if (IS_ERR(kvalue))
-			return PTR_ERR(kvalue);
+		kvalue = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
+		if (!kvalue) {
+			vvalue = vmalloc(size);
+			if (!vvalue)
+				return -ENOMEM;
+			kvalue = vvalue;
+		}
+		if (copy_from_user(kvalue, value, size)) {
+			error = -EFAULT;
+			goto out;
+		}
 	}
 
 	error = vfs_setxattr(d, kname, kvalue, size, flags);
-	kfree(kvalue);
+out:
+	if (vvalue)
+		vfree(vvalue);
+	else
+		kfree(kvalue);
 	return error;
 }
 
_


  reply	other threads:[~2012-03-29  1:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-13 18:22 suppress page allocation failure warnings from sys_listxattr Dave Jones
2012-03-13 21:33 ` Colin Walters
2012-03-27 22:51 ` Andrew Morton
2012-03-28  0:15   ` Dave Jones
2012-03-28  0:26     ` Andrew Morton
2012-03-28  7:13       ` David Rientjes
2012-03-28  4:39     ` Dave Chinner
2012-03-28 23:47       ` Andrew Morton
2012-03-29  0:54         ` Dave Jones
2012-03-29  1:10           ` Andrew Morton [this message]
2012-03-29  1:28             ` Joe Perches
2012-03-29  1:46               ` Andrew Morton
2012-03-29  1:50                 ` Dave Jones
2012-03-29  2:02                   ` Andrew Morton
2012-03-29  2:08                     ` Dave Jones
2012-03-29  2:28                       ` Andrew Morton
2012-03-29  3:00                         ` Dave Jones
2012-03-29 21:09                           ` Andrew Morton
2012-03-29 21:13                             ` Dave Jones
2012-03-29  5:35                 ` Dave Chinner

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=20120328181023.274401d1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=david@fromorbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.