Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

2018-03-16 Thread Greg Kroah-Hartman 
On Fri, Mar 16, 2018 at 02:22:02PM +0100, David Sterba wrote:
> On Fri, Mar 16, 2018 at 01:30:49PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote:
> > > Greg Kroah-Hartman wrote...
> > > 
> > > > 4.14-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > 
> > > > commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream.
> > > (...)
> > > 
> > > > If the filesystem is always used on a same endian host, this will not
> > > > be a problem.
> > > 
> > > >From my observations I cannot quite subscribe to that.
> > > 
> > > On big-endian systems, this change intruduces severe corruption,
> > > resulting in complete loss of the data on the used block device.
> > > 
> > > Steps to reproduce (tested on ppc/powerpc and parisc/hppa):
> > > 
> > > # mkfs.btrfs $DEV
> > > # mount $DEV /mnt/tmp/
> > > # umount /mnt/tmp/
> > > 
> > > This simple umount corrupts the file system:
> > > 
> > > # mount $DEV /mnt/tmp/
> > > mount: /mnt/tmp: wrong fs type, bad option, bad superblock on $DEV, 
> > > missing codepage or helper program, or other error.
> > > 
> > > # dmesg:
> > > BTRFS critical (device ): unable to find logical 4294967296 length 
> > > 4096
> > > BTRFS critical (device ): unable to find logical 4294967296 length 
> > > 4096
> > > BTRFS critical (device ): unable to find logical 18102363734671360 
> > > length 16384
> > > BTRFS error (device ): failed to read chunk root
> > > BTRFS error (device ): open_ctree failed
> > > 
> > > Also fsck is of no help:
> > > 
> > > # btrfsck $DEV
> > > Couldn't map the block 18102363734671360
> > > No mapping for 18102363734671360-18102363734687744
> > > Couldn't map the block 18102363734671360
> > > bytenr mismatch, want=18102363734671360, have=0
> > > ERROR: cannot read chunk root
> > > ERROR: cannot open file system
> > > 
> > > 
> > > Trying mount or fsck on a little-endian system does not help either. So
> > > I consider the data on that device lost - luckily I use btrfs only for
> > > files where a backup exists all the time.
> > > 
> > > 
> > > Reverting that change restored the previous error-free behaviour. I
> > > didn't check HEAD, i.e. v4.16-rc5, since the upstream commt was the last
> > > that affected these files. Still I could give this a try if anybody
> > > wishes so.
> > 
> > That sucks.  Can you test Linus's tree to verify the problem is there?
> > I'll gladly revert this if Linus's tree also gets the revert, I don't
> > want you to hit this when you upgrade to a newer kernel.
> 
> I'll push a fix for the upcoming rc but I think it would be better to
> remove the broken patch from stable kernels ASAP, so I'd recommend to
> revert it now.

Now reverted, thanks.

greg k-h
--
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

Re: [PATCH 4.14 024/110] btrfs: use proper endianness accessors for super_copy

2018-03-16 Thread Greg Kroah-Hartman 
On Thu, Mar 15, 2018 at 07:55:42PM +0100, Christoph Biedl wrote:
> Greg Kroah-Hartman wrote...
> 
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> 
> > commit 3c181c12c431fe33b669410d663beb9cceefcd1b upstream.
> (...)
> 
> > If the filesystem is always used on a same endian host, this will not
> > be a problem.
> 
> >From my observations I cannot quite subscribe to that.
> 
> On big-endian systems, this change intruduces severe corruption,
> resulting in complete loss of the data on the used block device.
> 
> Steps to reproduce (tested on ppc/powerpc and parisc/hppa):
> 
> # mkfs.btrfs $DEV
> # mount $DEV /mnt/tmp/
> # umount /mnt/tmp/
> 
> This simple umount corrupts the file system:
> 
> # mount $DEV /mnt/tmp/
> mount: /mnt/tmp: wrong fs type, bad option, bad superblock on $DEV, missing 
> codepage or helper program, or other error.
> 
> # dmesg:
> BTRFS critical (device ): unable to find logical 4294967296 length 4096
> BTRFS critical (device ): unable to find logical 4294967296 length 4096
> BTRFS critical (device ): unable to find logical 18102363734671360 
> length 16384
> BTRFS error (device ): failed to read chunk root
> BTRFS error (device ): open_ctree failed
> 
> Also fsck is of no help:
> 
> # btrfsck $DEV
> Couldn't map the block 18102363734671360
> No mapping for 18102363734671360-18102363734687744
> Couldn't map the block 18102363734671360
> bytenr mismatch, want=18102363734671360, have=0
> ERROR: cannot read chunk root
> ERROR: cannot open file system
> 
> 
> Trying mount or fsck on a little-endian system does not help either. So
> I consider the data on that device lost - luckily I use btrfs only for
> files where a backup exists all the time.
> 
> 
> Reverting that change restored the previous error-free behaviour. I
> didn't check HEAD, i.e. v4.16-rc5, since the upstream commt was the last
> that affected these files. Still I could give this a try if anybody
> wishes so.

That sucks.  Can you test Linus's tree to verify the problem is there?
I'll gladly revert this if Linus's tree also gets the revert, I don't
want you to hit this when you upgrade to a newer kernel.

thanks,

greg k-h
--
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 4.4 12/36] btrfs: Dont clear SGID when inheriting ACLs

2018-03-09 Thread Greg Kroah-Hartman 
4.4-stable 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: sta...@vger.kernel.org
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>
Signed-off-by: Nikolay Borisov <nbori...@suse.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 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 4.9 028/125] btrfs: Dont clear SGID when inheriting ACLs

2017-07-25 Thread Greg Kroah-Hartman 
4.9-stable 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>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 fs/btrfs/acl.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -78,12 +78,6 @@ static int __btrfs_set_acl(struct btrfs_
switch (type) {
case ACL_TYPE_ACCESS:
name = XATTR_NAME_POSIX_ACL_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))
@@ -119,6 +113,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 4.12 031/196] btrfs: Dont clear SGID when inheriting ACLs

2017-07-25 Thread Greg Kroah-Hartman 
4.12-stable 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>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 fs/btrfs/acl.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

--- a/fs/btrfs/acl.c
+++ b/fs/btrfs/acl.c
@@ -78,12 +78,6 @@ static int __btrfs_set_acl(struct btrfs_
switch (type) {
case ACL_TYPE_ACCESS:
name = XATTR_NAME_POSIX_ACL_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))
@@ -119,6 +113,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

Re: [PATCH 01/14] VFS: Don't use save/replace_mount_options if not using generic_show_options

2017-07-05 Thread Greg Kroah-Hartman 
On Wed, Jul 05, 2017 at 04:24:09PM +0100, David Howells wrote:
> btrfs, debugfs, reiserfs and tracefs call save_mount_options() and reiserfs
> calls replace_mount_options(), but they then implement their own
> ->show_options() methods and don't touch s_options, rendering the saved
> options unnecessary.  I'm trying to eliminate s_options to make it easier
> to implement a context-based mount where the mount options can be passed
> individually over a file descriptor.
> 
> Remove the calls to save/replace_mount_options() call in these cases.
> 
> Signed-off-by: David Howells <dhowe...@redhat.com>
> cc: Chris Mason <c...@fb.com>
> cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> cc: Steven Rostedt <rost...@goodmis.org>
> cc: linux-btrfs@vger.kernel.org
> cc: reiserfs-de...@vger.kernel.org

For debugfs:
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
--
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

Re: 3.2-rc4: scrubbing locks up the kernel, then hung tasks on boot

2012-03-19 Thread Greg Kroah-Hartman 
On Mon, Mar 19, 2012 at 09:31:24AM +0100, Martin Steigerwald wrote:
  formletter
  
  This is not the correct way to submit patches for inclusion in the
  stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
  for how to do this properly.
  
  /formletter
 
 What point of the rules do you refer to? Is it
 
  - It or an equivalent fix must already exist in Linus' tree (upstream).

Yes.

Without that, there's nothing I can do with this.

 Or do you want the patch quoted in the mail?
 
 Anyways its not yet in linus tree AFAIR and from my side it was a question 
 whether it should be included at all. I thought it might be good ccing you on 
 that question already.

It's nice, yes, but note that you sent this to me directly, didn't cc:
the proper stable mailing list so that others who maintain other stable
trees also didn't get the notice, and again, there's really nothing that
the stable maintainers can do about this at the moment.

But, if this does go to Linus's tree, then sta...@vger.kernel.org would
be very interested in knowing about it.

thanks,

greg k-h
--
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

Re: 3.2-rc4: scrubbing locks up the kernel, then hung tasks on boot

2012-03-17 Thread Greg Kroah-Hartman 
On Sat, Mar 17, 2012 at 10:43:25AM +0100, Martin Steigerwald wrote:
 Hi Greg, Chris, Arne, hi everyone,
 
 Am Freitag, 16. März 2012 schrieb Martin Steigerwald:
  Am Donnerstag, 15. März 2012 schrieb Chris Mason:
   On Thu, Mar 15, 2012 at 06:32:19PM +0100, Martin Steigerwald wrote:
Am Samstag, 25. Februar 2012 schrieb Arne Jansen:
 On 02/24/12 16:51, Martin Steigerwald wrote:
  Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
  Am Samstag, 21. Januar 2012 schrieb Martin Steigerwald:
  I still have this with 3.2.0-1-pae - which is a debian kernel
  based on 3.2.1.
  
  When I do btrfs scrub start / the machine locks immediately
  up hard.
  
  Then usually on next boot it stops on space_cache enabled
  message, but not  the one for /, but the one for /home which
  is mounted later.
  
  […]
  
  I now tested scrubbing /home which is a different BTRFS
  filesystem on the same machine.
  
  Then the scrub is started, scrub status tells me so, but
  nothing happens, no block in/out activity in vmstat, no CPU
  related activity in top.
  
  btrfs scrub cancel then hangs, but not the complete machine,
  only the process.
  
  I had this once on my T520 with the internal Intel SSD 320 as
  well. The other time it worked.
  
  Well maybe that is due to BTRFS doing something else on my T23
  now:
  
  deepdance:~  ps aux | grep ino-cache | grep -v grep
  root  1992  5.5  0.0  0 0 ?D12:15  
  0:09 [btrfs- ino-cache]
  
  […]
  
  At least it doesn´t lock up hard, so there might really be
  something strange with /.
  
  FWIW a btrfs filesystem balance / does work. After this a btrfs
  scrub start / still locks the kernel.
 
 Hi Martin,
 
 I just sent 2 patches to the list. Could you please test if these
 fix your problem with scrub?

I didn´t yet test it but I tried the first balance then scrub stuff
   
again:
   Looks like you're on a 32 bit machine.  The current for-linus branch
   has an important fix for scrub on 32 bit that should solve this.
  
  So finally - the machine did make-kpkg over night and complained about
  missing Documentation lguest, then I switched off lots from distro
  default config and just did the usual make stuff - I was able to scrub
  both partitions on that ThinkPad T23:
  
  deepdance:~ btrfs scrub status /
  scrub status for 2bf5b1dc-1d89-4f0d-a561-1a5551a27275
  scrub started at Fri Mar 16 11:56:12 2012 and finished after
  741 seconds total bytes scrubbed: 9.62GB with 0 errors
  
  deepdance:~ btrfs scrub status /home
  scrub status for a600de65-e1ab-4cbf-b150-bbaeaf9fa98d
  scrub started at Fri Mar 16 12:00:31 2012 and finished after
  1708 seconds total bytes scrubbed: 36.63GB with 0 errors
  
  Thanks a lot for fixing this.
  
  Tested-by: Martin Steigerwald mar...@lichtvoll.de
 […]
 
 Would that patch
 
 Btrfs: fix casting error in scrub reada code
 
 http://git.kernel.org/?p=linux/kernel/git/mason/linux-
 btrfs.git;a=commit;h=a175423c831ea582c06784d1e172d2ce1d79923a
 
 (sorry for line break. KMail insists on it even when I disable line breaks 
 due to the minus sign in the URL.)
 
 that I tested above be something for stable?

formletter

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

/formletter
--
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