linux-kernel - Re: suppress page allocation failure warnings from sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20120328164720.d1aea752.akpm@linux-foundation.org>
Date:	Wed, 28 Mar 2012 16:47:20 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	Dave Jones <davej@...hat.com>, viro@...iv.linux.org.uk,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	David Rientjes <rientjes@...gle.com>
Subject: Re: suppress page allocation failure warnings from sys_listxattr

On Wed, 28 Mar 2012 15:39:51 +1100
Dave Chinner <david@...morbit.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?

This patch needs more Davids.


From: Andrew Morton <akpm@...ux-foundation.org>
Subject: fs/xattr.c:listxattr(): fall back to vmalloc() if kmalloc() failed

This allocation can be as large as 64k.  As David points out, "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".

Cc: Dave Chinner <david@...morbit.com>
Cc: Dave Jones <davej@...emonkey.org.uk>
Cc: David Rientjes <rientjes@...gle.com>
Cc: Al Viro <viro@...iv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 fs/xattr.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff -puN fs/xattr.c~fs-xattrc-listxattr-fall-back-to-vmalloc-if-kmalloc-failed fs/xattr.c
--- a/fs/xattr.c~fs-xattrc-listxattr-fall-back-to-vmalloc-if-kmalloc-failed
+++ a/fs/xattr.c
@@ -492,13 +492,18 @@ listxattr(struct dentry *d, char __user 
 {
 	ssize_t error;
 	char *klist = NULL;
+	char *vlist = NULL;	/* If non-NULL, we used vmalloc() */
 
 	if (size) {
 		if (size > XATTR_LIST_MAX)
 			size = XATTR_LIST_MAX;
 		klist = kmalloc(size, __GFP_NOWARN | GFP_KERNEL);
-		if (!klist)
-			return -ENOMEM;
+		if (!klist) {
+			vlist = vmalloc(size);
+			if (!vlist)
+				return -ENOMEM;
+			klist = vlist;
+		}
 	}
 
 	error = vfs_listxattr(d, klist, size);
@@ -510,7 +515,10 @@ listxattr(struct dentry *d, char __user 
 		   than XATTR_LIST_MAX bytes. Not possible. */
 		error = -E2BIG;
 	}
-	kfree(klist);
+	if (vlist)
+		vfree(vlist);
+	else
+		kfree(klist);
 	return error;
 }
 
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/