Re: [stable] btrfs name length fixes

2017-10-29 Thread Ben Hutchings 
On Mon, 2017-10-30 at 08:45 +0800, Qu Wenruo wrote:
> 
> On 2017年10月30日 08:19, Ben Hutchings wrote:
> > On Mon, 2017-10-30 at 07:59 +0800, Qu Wenruo wrote:
[...]
> > > These fixes will soon be replace by centralized tree-checker facilities.
> > 
> > Is that likely to be a small enough change to be reasonably backport-
> > able?
> 
> It depends.
> 
> Check the thread with the subject "[PATCH v3 0/5] Enhance tree block
> validation checker"
> 
> 
>  fs/btrfs/Makefile   |   2 +-
>  fs/btrfs/ctree.h|   4 +
>  fs/btrfs/disk-io.c  | 284 +---
>  fs/btrfs/tree-checker.c | 429
> 
>  4 files changed, 437 insertions(+), 282 deletions(-)
>  create mode 100644 fs/btrfs/tree-checker.c
> 

That looks like it would be too big for stable.

> Since it's centralized, most of the modification will be in
> tree-checker.c, and make the impact to existing code to minimal.
> 
> However that patchset is just the skeleton of the whole thing, name_len
> related code is not moved to tree-checker yet.
> 
> 
> On the other hand, the whole name_len patchset is just an enhanced
> validation checker, I'm not pretty sure if such thing should be back
> ported especially when it's just a whack-a-hole solution.

I see.  Thanks for the information.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



signature.asc
Description: This is a digitally signed message part

Re: [stable] btrfs name length fixes

2017-10-29 Thread Ben Hutchings 
On Mon, 2017-10-30 at 07:59 +0800, Qu Wenruo wrote:
> 
> On 2017年10月30日 01:15, Ben Hutchings wrote:
> > You recently made a number of fixes to validation and use of name
> > lengths in btrfs:
> > 
> > 286b92f43c0d btrfs: tree-log.c: Wrong printk information about namelen
> > 19c6dcbfa746 btrfs: Introduce btrfs_is_name_len_valid to avoid reading 
> > beyond boundary
> > e79a33270d05 btrfs: Check name_len with boundary in verify dir_item
> > 26a836cec2ea btrfs: Check name_len on add_inode_ref call path
> > 8ee8c2d62d5f btrfs: Verify dir_item in replay_xattr_deletes
> > 3c1d41844896 btrfs: Check name_len in btrfs_check_ref_name_override
> > 59b0a7f2c7c1 btrfs: Check name_len before read in iterate_dir_item
> > 488d7c456653 btrfs: Check name_len before reading btrfs_get_name
> > 64c7b01446f4 btrfs: Check name_len before in btrfs_del_root_ref
> > fbc326159a01 btrfs: Verify dir_item in iterate_object_props
> > 
> > The bugs these are fixing probably should also be fixed on the affected
> > stable branches.  Do you agree?  Can you provide any guidance about how
> > far back these fixes would be needed?
> 
> These fixes will soon be replace by centralized tree-checker facilities.

Is that likely to be a small enough change to be reasonably backport-
able?

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



signature.asc
Description: This is a digitally signed message part

[PATCH 3.2 24/74] btrfs: Don't clear SGID when inheriting ACLs

2017-10-09 Thread Ben Hutchings 
3.2.94-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara <j...@suse.cz>

commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream.

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.

Fix the problem by moving posix_acl_update_mode() out of
__btrfs_set_acl() into btrfs_set_acl(). That way the function will not be
called when inheriting ACLs which is what we want as it prevents SGID
bit clearing and the mode has been properly set by posix_acl_create()
anyway.

Fixes: 073931017b49d9458aa351605b43a7e34598caef
CC: linux-btrfs@vger.kernel.org
CC: David Sterba <dste...@suse.com>
Signed-off-by: Jan Kara <j...@suse.cz>
Signed-off-by: David Sterba <dste...@suse.com>
[bwh: Backported to 3.2: move the call to posix_acl_update_mode() into
 btrfs_xattr_acl_set()]
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -117,12 +117,6 @@ static int btrfs_set_acl(struct btrfs_tr
switch (type) {
case ACL_TYPE_ACCESS:
name = POSIX_ACL_XATTR_ACCESS;
-   if (acl) {
-   ret = posix_acl_update_mode(inode, >i_mode, 
);
-   if (ret)
-   return ret;
-   }
-   ret = 0;
break;
case ACL_TYPE_DEFAULT:
if (!S_ISDIR(inode->i_mode))
@@ -161,11 +155,12 @@ static int btrfs_xattr_acl_set(struct de
 {
int ret;
struct posix_acl *acl = NULL;
+   struct inode *inode = dentry->d_inode;
 
-   if (!inode_owner_or_capable(dentry->d_inode))
+   if (!inode_owner_or_capable(inode))
return -EPERM;
 
-   if (!IS_POSIXACL(dentry->d_inode))
+   if (!IS_POSIXACL(inode))
return -EOPNOTSUPP;
 
if (value) {
@@ -180,7 +175,12 @@ static int btrfs_xattr_acl_set(struct de
}
}
 
-   ret = btrfs_set_acl(NULL, dentry->d_inode, acl, type);
+   if (type == ACL_TYPE_ACCESS && acl) {
+   ret = posix_acl_update_mode(inode, >i_mode, );
+   if (ret)
+   goto out;
+   }
+   ret = btrfs_set_acl(NULL, inode, acl, type);
 out:
posix_acl_release(acl);
 

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.16 075/192] btrfs: Don't clear SGID when inheriting ACLs

2017-10-09 Thread Ben Hutchings 
3.16.49-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara <j...@suse.cz>

commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream.

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.

Fix the problem by moving posix_acl_update_mode() out of
__btrfs_set_acl() into btrfs_set_acl(). That way the function will not be
called when inheriting ACLs which is what we want as it prevents SGID
bit clearing and the mode has been properly set by posix_acl_create()
anyway.

Fixes: 073931017b49d9458aa351605b43a7e34598caef
CC: linux-btrfs@vger.kernel.org
CC: David Sterba <dste...@suse.com>
Signed-off-by: Jan Kara <j...@suse.cz>
Signed-off-by: David Sterba <dste...@suse.com>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
 fs/btrfs/acl.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -82,12 +82,6 @@ static int __btrfs_set_acl(struct btrfs_
switch (type) {
case ACL_TYPE_ACCESS:
name = POSIX_ACL_XATTR_ACCESS;
-   if (acl) {
-   ret = posix_acl_update_mode(inode, >i_mode, 
);
-   if (ret)
-   return ret;
-   }
-   ret = 0;
break;
case ACL_TYPE_DEFAULT:
if (!S_ISDIR(inode->i_mode))
@@ -123,6 +117,13 @@ out:
 
 int btrfs_set_acl(struct inode *inode, struct posix_acl *acl, int type)
 {
+   int ret;
+
+   if (type == ACL_TYPE_ACCESS && acl) {
+   ret = posix_acl_update_mode(inode, >i_mode, );
+   if (ret)
+   return ret;
+   }
return __btrfs_set_acl(NULL, inode, acl, type);
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

2016-05-17 Thread Ben Hutchings 
This helps initramfs builders and other tools to find the full
dependencies of a module.

References: https://bugs.debian.org/819725
Signed-off-by: Ben Hutchings <b...@decadent.org.uk>
---
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -2456,3 +2456,4 @@ late_initcall(init_btrfs_fs);
 module_exit(exit_btrfs_fs)
 
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: crypto-crc32c");
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -1373,5 +1373,13 @@ MODULE_DESCRIPTION
 ("VFS to access servers complying with the SNIA CIFS Specification "
  "e.g. Samba and Windows");
 MODULE_VERSION(CIFS_VERSION);
+
+#ifdef CONFIG_CIFS_SMB2
+#define CIFS_SMB2_EXTRA_SOFTDEPS " crypto-aes crypto-cmac crypto-sha256"
+#else
+#define CIFS_SMB2_EXTRA_SOFTDEPS ""
+#endif
+MODULE_SOFTDEP("pre: crypto-arc4 crypto-des crypto-ecb crypto-hmac crypto-md4 
crypto-md5" CIFS_SMB2_EXTRA_SOFTDEPS);
+
 module_init(init_cifs)
 module_exit(exit_cifs)
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -566,3 +566,4 @@ static void __exit fscrypt_exit(void)
 module_exit(fscrypt_exit);
 
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: crypto-aes crypto-ecb");
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5441,5 +5441,13 @@ static void __exit ext4_exit_fs(void)
 MODULE_AUTHOR("Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, 
Theodore Ts'o and others");
 MODULE_DESCRIPTION("Fourth Extended Filesystem");
 MODULE_LICENSE("GPL");
+
+#ifdef CONFIG_EXT4_FS_ENCRYPTION
+#define EXT4_ENC_EXTRA_SOFTDEPS " crypto-aes crypto-ecb"
+#else
+#define EXT4_ENC_EXTRA_SOFTDEPS ""
+#endif
+MODULE_SOFTDEP("pre: crypto-crc32c" EXT4_ENC_EXTRA_SOFTDEPS);
+
 module_init(ext4_init_fs)
 module_exit(ext4_exit_fs)
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1742,3 +1742,4 @@ module_exit(exit_f2fs_fs)
 MODULE_AUTHOR("Samsung Electronics's Praesto Team");
 MODULE_DESCRIPTION("Flash Friendly File System");
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: crypto-crc32c");
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -2716,6 +2716,7 @@ static void __exit journal_exit(void)
 }
 
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: crypto-crc32c");
 module_init(journal_init);
 module_exit(journal_exit);
 
--- a/fs/nfsd/nfsctl.c
+++ b/fs/nfsd/nfsctl.c
@@ -1314,5 +1314,8 @@ static void __exit exit_nfsd(void)
 
 MODULE_AUTHOR("Olaf Kirch <o...@monad.swb.de>");
 MODULE_LICENSE("GPL");
+#ifdef CONFIG_NFSD_V4
+MODULE_SOFTDEP("pre: crypto-md5");
+#endif
 module_init(init_nfsd)
 module_exit(exit_nfsd)


signature.asc
Description: Digital signature

Re: [v3.10.y][v3.11.y][v3.12.y][v3.13.y][v3.14.y][PATCH 1/1][V2] ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined

2014-06-21 Thread Ben Hutchings 
On Fri, 2014-06-20 at 14:21 -0400, Joseph Salisbury wrote:
[...]
 I looked at this some more.   It seems like my v2 backport may be the
 most suitable for the releases mentioned in the subject line, but I'd
 like to get additional feedback.
 
 The lines added by commit a5065eb just get removed by commit b7a77235. 
 Also, if I apply commit a5065eb, it will also require a backport to pull
 in just a piece of code(Remove snd_printk() and add dev_dbg()) from
 another prior commit(0ba41d9).  No backport would be needed at all if I
 cherry-pick 0ba41d9, but that commit seems to have too may changes for a
 stable release.

Keep the changes squashed together if you like, but do include both
commit hashes and commit messages.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, reading IRC for the first time


signature.asc
Description: This is a digitally signed message part

Re: [v3.10.y][v3.11.y][v3.12.y][v3.13.y][v3.14.y][PATCH 1/1][V2] ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined

2014-06-18 Thread Ben Hutchings 
On Wed, 2014-06-18 at 14:32 -0400, Joseph Salisbury wrote:
 From: Sander Eikelenboom li...@eikelenboom.it
 
 BugLink: http://bugs.launchpad.net/bugs/1319457
 
 This (widely used) construction:
 
 if(printk_ratelimit())
   dev_dbg()
 
 Causes the ratelimiting to spam the kernel log with the callbacks suppressed
 message below, even while the dev_dbg it is supposed to rate limit wouldn't
 print anything because DEBUG is not defined for this device.
 
 [  533.803964] retire_playback_urb: 852 callbacks suppressed
 [  538.807930] retire_playback_urb: 852 callbacks suppressed
 [  543.811897] retire_playback_urb: 852 callbacks suppressed
 [  548.815745] retire_playback_urb: 852 callbacks suppressed
 [  553.819826] retire_playback_urb: 852 callbacks suppressed
 
 So use dev_dbg_ratelimited() instead of this construction.
 
 Signed-off-by: Sander Eikelenboom li...@eikelenboom.it
 Signed-off-by: Takashi Iwai ti...@suse.de
 (backported from commit b7a7723513dc89f83d6df13206df55d4dc26e825)
 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com

It looks like you have combined the commit identified here with the
preceding:

commit a5065eb6da55b226661456e6a7435f605df98111
Author: Tim Gardner tim.gard...@canonical.com
Date:   Wed Apr 9 11:30:44 2014 -0600

ALSA: usb-audio: Suppress repetitive debug messages from 
retire_playback_urb()

They should not be squashed together like this.

Ben.

 ---
  sound/usb/pcm.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
 index ca3256d..ede4b92 100644
 --- a/sound/usb/pcm.c
 +++ b/sound/usb/pcm.c
 @@ -1488,7 +1488,8 @@ static void retire_playback_urb(struct 
 snd_usb_substream *subs,
* on two reads of a counter updated every ms.
*/
   if (abs(est_delay - subs-last_delay) * 1000  runtime-rate * 2)
 - snd_printk(KERN_DEBUG delay: estimated %d, actual %d\n,
 + dev_dbg_ratelimited(subs-dev-dev,
 + delay: estimated %d, actual %d\n,
   est_delay, subs-last_delay);
  
   if (!subs-running) {

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


signature.asc
Description: This is a digitally signed message part

Re: Bug#736227: linux-headers-3.12-1-amd64: general protection fault when using aptitude

2014-01-22 Thread Ben Hutchings 
 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 
 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c 8b 5e 18 48 8d 
 [  322.371118] RIP  [812713e2] memcpy+0x12/0x110
 [  322.371154]  RSP 88009bf7f968
 [  322.378460] ---[ end trace 4d0836c03317ee9d ]---

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source


signature.asc
Description: This is a digitally signed message part

Re: btrfs: filenames collide with snapshot/subvolume names

2012-06-24 Thread Ben Hutchings 
On Thu, 2012-06-14 at 12:28 +0200, David Sterba wrote:
 On Thu, Jun 14, 2012 at 05:34:29AM +0100, Ben Hutchings wrote:
  ?? (Giorgos?) reports:
   Namely, being inside a snapshot directory, I can't create a file/directory
   with the name of the snapshot directory.
   
   For example, inside /mnt/aSnap, I can't create a file named 'aSnap', so 
   I'm
   filling this bug report.
  
  It seems that the snapshot directory is partially created before the
  snapshot is taken, so that the snapshot directory half-exists (can be
  looked up, but doesn't appear in listings) inside the snapshot itself.
 
 I think it's this one, not merged so far (author CCed)
 http://www.spinics.net/lists/linux-btrfs/msg15195.html

Thanks, that sounds like it addresses this.  I'll wait for that patch or
another fix to be applied, as I am not able to assess whether it's
reasonable.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be sure.


signature.asc
Description: This is a digitally signed message part

Re: btrfs: filenames collide with snapshot/subvolume names

2012-06-13 Thread Ben Hutchings 
Γιώργος (Giorgos?) reports:
 Namely, being inside a snapshot directory, I can't create a file/directory
 with the name of the snapshot directory.
 
 For example, inside /mnt/aSnap, I can't create a file named 'aSnap', so I'm
 filling this bug report.

It seems that the snapshot directory is partially created before the
snapshot is taken, so that the snapshot directory half-exists (can be
looked up, but doesn't appear in listings) inside the snapshot itself.

This doesn't seem to be the recommended way to organise subvolumes, but
it seems like it should at least result in a coherent filesystem within
each subvolume.

Ben.

 Below follows full reproduction of this behavior:
 
 aris tmp # dd if=/dev/zero of=FILE bs=4k seek=`echo 5*1024*1024 | bc` count=1
 1+0 records in
 1+0 records out
 4096 bytes (4.1 kB) copied, 1.8695e-05 s, 219 MB/s
 aris tmp # losetup /dev/loop0 FILE 
 aris tmp # losetup -a
 /dev/loop0: [fe01]:263872 (/tmp/FILE)
 aris tmp # mkfs.btrfs -Ltest /dev/loop0
 
 WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
 WARNING! - see http://btrfs.wiki.kernel.org before using
 
 fs created label test on /dev/loop0
 nodesize 4096 leafsize 4096 sectorsize 4096 size 20.00GB
 Btrfs Btrfs v0.19
 aris tmp # mount /dev/loop0 /mnt/
 aris tmp # cd /mnt
 aris mnt # ls -la
 total 8
 dr-xr-xr-x  1 root root0 Mar  8 12:07 .
 drwxr-xr-x 24 root root 4096 Mar  8 11:41 ..
 aris mnt # mkdir dir1
 aris mnt # mkdir dir2
 aris mnt # mkdir dir3
 aris mnt # l
 total 0
 drwxr-xr-x 1 root root 0 Mar  8 12:08 dir1
 drwxr-xr-x 1 root root 0 Mar  8 12:08 dir2
 drwxr-xr-x 1 root root 0 Mar  8 12:08 dir3
 aris mnt # btrfs subvolume snapshot /mnt/ /mnt/aSnap
 Create a snapshot of '/mnt/' in '/mnt/aSnap'
 aris mnt # cd /mnt/aSnap/
 aris aSnap # ls -la
 total 8
 dr-xr-xr-x 1 root root 34 Mar  8 12:08 .
 dr-xr-xr-x 1 root root 34 Mar  8 12:08 ..
 drwxr-xr-x 1 root root  0 Mar  8 12:08 dir1
 drwxr-xr-x 1 root root  0 Mar  8 12:08 dir2
 drwxr-xr-x 1 root root  0 Mar  8 12:08 dir3
 aris aSnap # date  aSnap
 bash: aSnap: Is a directory

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

2011-04-25 Thread Ben Hutchings 
On Mon, 2011-04-25 at 22:05 +0200, Maik Zumstrull wrote:
 Package: linux-image-2.6.39-rc4-686-pae
 Version: 2.6.39~rc4-1~experimental.1
 Severity: normal
 Tags: experimental
 
 By simply stressing the system with some I/O, I can make it crash within
 seconds. I'm not setting a higher severity because the bug is in an
 experimental file system in an experimental kernel.

I assume this doesn't happen in 2.6.38?

 Here's the important bits (by my guess) I have on screen from the kernel 
 panic:
 
 Bug at fs/btrfs/free-space-cache.c:1246
 Bug type: invalid opcode: 
 Kernel not tainted, running on an ASUSTek 1005HAG
 EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]

You will probably need to provide a more complete copy of the panic
message.  Let's see what the btrfs developers say.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

2011-04-25 Thread Ben Hutchings 
On Mon, 2011-04-25 at 15:05 -0600, cwillu wrote:
 On Mon, Apr 25, 2011 at 2:50 PM, Peter Stuge pe...@stuge.se wrote:
  Maik Zumstrull wrote:
   Bug at fs/btrfs/free-space-cache.c:1246
   Bug type: invalid opcode: 
   Kernel not tainted, running on an ASUSTek 1005HAG
   EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]
  
   You will probably need to provide a more complete copy of the panic
   message.
 
  I thought as much, but other than taking a picture of the screen, I
  don't know how.
 
  Take a picture and ideally transcribe it after reboot.
 
 Known issue;  josef sent a patch
 (http://permalink.gmane.org/gmane.comp.file-systems.btrfs/10261) that
 should fix it, or you can mount with clear_cache on each boot as a
 workaround.

This fix doesn't seem to be in your for-linux branch yet.  Please can
you ensure that this (or an alternate fix) is included in 2.6.39.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

[PATCH] btrfs: Require CAP_SYS_ADMIN for filesystem rebalance

2010-12-29 Thread Ben Hutchings 
Filesystem rebalancing (BTRFS_IOC_BALANCE) affects the entire
filesystem and may run uninterruptibly for a long time.  This does not
seem to be something that an unprivileged user should be able to do.

Reported-by: Aron Xu happyaron...@gmail.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 fs/btrfs/volumes.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index cc04dc1..2313e8b 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -22,6 +22,7 @@
 #include linux/blkdev.h
 #include linux/random.h
 #include linux/iocontext.h
+#include linux/capability.h
 #include asm/div64.h
 #include compat.h
 #include ctree.h
@@ -1905,6 +1906,9 @@ int btrfs_balance(struct btrfs_root *dev_root)
if (dev_root-fs_info-sb-s_flags  MS_RDONLY)
return -EROFS;
 
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+
mutex_lock(dev_root-fs_info-volume_mutex);
dev_root = dev_root-fs_info-dev_root;
 
-- 
1.7.2.3


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html