Re: [PATCH 6/7] Btrfs: kill the btree_inode

On Friday, September 02, 2016 03:40:05 PM Josef Bacik wrote: Please find my comment inlined below, > In order to more efficiently support sub-page blocksizes we need to stop > allocating pages from pagecache for our metadata. Instead switch to using the > account_metadata* counters for making

Re: [PATCH] btrfs: fix false enospc error when truncating heavily reflinked file

Hi, On 09/07/2016 11:56 PM, Darrick J. Wong wrote: On Wed, Sep 07, 2016 at 08:17:38PM +0800, Wang Xiaoguang wrote: Below test script can reveal this bug: dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=100 dev=$(losetup --show -f fs.img) mkdir -p /mnt/mntpoint mkfs.btrfs

[PATCH v2] fstests: common: Enhance _exclude_scratch_mount_option to handle multiple options

Enhance _exclude_scratch_mount_option() function to normalize mount options. Now it can understand and extract real mount option from string like "-o opt1,opt2 -oopt3". And now we do word grep to handle mount options like noinode_cache and inode_cache. Finally, allow it to accept multiple

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

Hi Jeff, On Wed, Sep 07, 2016 at 10:25:54AM -0400, Jeff Mahoney wrote: > On 9/6/16 5:51 PM, Liu Bo wrote: > > Hi Filipe, > > > > On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote: > >> On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo wrote: > >>> This can only happen

Re: Security implications of btrfs receive?

On Wed, Sep 07, 2016 at 08:07:59PM +0200, Christoph Anton Mitterer wrote: > Even other multi-device containers (LVM, MD) don't at least corrupt > your data like it allegedly can happen with btrfs. LVM and MD also check sequence numbers and timestamps. You can't just guess the UUID, you need a

Hope to hear from you

Hello Dear, I'm Miss.Mariame  24yrs old female, from Benghazi – Libya seeking for your assistance regards to my situation since the death of my parents.My father of blessed memory by name late General Abdel Fattah Younes who was shot death by Islamist-linked militia within the anti-Gaddafi forces

Re: Security implications of btrfs receive?

On Wed, Sep 7, 2016 at 1:08 PM, Austin S. Hemmelgarn wrote: > I think I covered it already in the last thread on this, but the best way I > see to fix the whole auto-assembly issue is: > 1. Stop the damn auto-scanning of new devices on hot-plug. The scanning > should be

Re: Security implications of btrfs receive?

On 2016-09-07 14:07, Christoph Anton Mitterer wrote: On Wed, 2016-09-07 at 11:06 -0400, Austin S. Hemmelgarn wrote: This is an issue with any filesystem, Not really... any other filesystem I'd know (not sure about ZFS) keeps working when there are UUID collisions... or at least it won't cause

Re: Security implications of btrfs receive?

On Wed, 2016-09-07 at 11:06 -0400, Austin S. Hemmelgarn wrote: > This is an issue with any filesystem, Not really... any other filesystem I'd know (not sure about ZFS) keeps working when there are UUID collisions... or at least it won't cause arbitrary corruptions, which then in the end may even

Re: Security implications of btrfs receive?

On 2016-09-07 12:10, Graham Cobb wrote: On 07/09/16 16:20, Austin S. Hemmelgarn wrote: I should probably add to this that you shouldn't be accepting send/receive data streams from untrusted sources anyway. While it probably won't crash your system, it's not intended for use as something like a

Re: Security implications of btrfs receive?

On 07/09/16 16:06, Austin S. Hemmelgarn wrote: > It hasn't, because there's not any way it can be completely fixed. This > particular case is an excellent example of why it's so hard to fix. To > close this particular hole, BTRFS itself would have to become aware of > whether whoever is running

Re: Security implications of btrfs receive?

On 07/09/16 16:20, Austin S. Hemmelgarn wrote: > I should probably add to this that you shouldn't be accepting > send/receive data streams from untrusted sources anyway. While it > probably won't crash your system, it's not intended for use as something > like a network service. If you're

Re: [PATCH] btrfs: fix false enospc error when truncating heavily reflinked file

On Wed, Sep 07, 2016 at 08:17:38PM +0800, Wang Xiaoguang wrote: > Below test script can reveal this bug: > dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=100 > dev=$(losetup --show -f fs.img) > mkdir -p /mnt/mntpoint > mkfs.btrfs -f $dev > mount $dev /mnt/mntpoint > cd

Re: Security implications of btrfs receive?

On 2016-09-07 07:58, Austin S. Hemmelgarn wrote: On 2016-09-06 13:20, Graham Cobb wrote: Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: On 2016-09-05 05:59, Graham Cobb wrote: Does the "path" argument of btrfs-receive mean that *all* operations

Re: Security implications of btrfs receive?

On 2016-09-07 10:41, Christoph Anton Mitterer wrote: On Tue, 2016-09-06 at 18:20 +0100, Graham Cobb wrote: they know the UUID of the subvolume? Unfortunately, btrfs seems to be pretty problematic when anyone knows your UUIDs... This is an issue with any filesystem, it is just a bigger issue

Re: [PATCH v12.2 01/15] btrfs: expand btrfs_set_extent_delalloc() and its friends to support in-band dedupe and subpage size patchset

On Tue, Aug 09, 2016 at 09:19:08AM +0800, Qu Wenruo wrote: > Hi David and Chandan, > > I see the expansion of cow_file_range() function got merged into 4.8 > window, while this patch is still not merged yet, is there anything > wrong with this patch? Now added to the 4.9 queue, sorry for the

Re: Security implications of btrfs receive?

On 2016-09-07 10:44, Christoph Anton Mitterer wrote: On Wed, 2016-09-07 at 07:58 -0400, Austin S. Hemmelgarn wrote: if you want proper security you should be using a real container system Won't these probably use the same filesystems? That depends on how it's set up. Most container software

Re: Security implications of btrfs receive?

On Wed, 2016-09-07 at 07:58 -0400, Austin S. Hemmelgarn wrote: > if you want proper security you should > be  > using a real container system Won't these probably use the same filesystems? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature

Re: Security implications of btrfs receive?

On Tue, 2016-09-06 at 18:20 +0100, Graham Cobb wrote: > they know the UUID of the subvolume? Unfortunately, btrfs seems to be pretty problematic when anyone knows your UUIDs... Look for my thread "attacking btrfs filesystems via UUID collisions?" in the list archives. From accidental corruptions

Re: kworker threads may be working saner now instead of using 100% of a CPU core for minutes (Re: Still not production ready)

Am Mittwoch, 7. September 2016, 11:53:04 CEST schrieb Christian Rohmann: > On 03/20/2016 12:24 PM, Martin Steigerwald wrote: > >> btrfs kworker thread uses up 100% of a Sandybridge core for minutes on > >> > >> > random write into big file > >> > https://bugzilla.kernel.org/show_bug.cgi?id=90401

Re: [PATCH] Btrfs: fix BUG_ON in btrfs_mark_buffer_dirty

On 9/6/16 5:51 PM, Liu Bo wrote: > Hi Filipe, > > On Mon, Sep 05, 2016 at 04:28:09PM +0100, Filipe Manana wrote: >> On Fri, Sep 2, 2016 at 8:35 PM, Liu Bo wrote: >>> This can only happen with CONFIG_BTRFS_FS_CHECK_INTEGRITY=y. >>> >>> Commit 1ba98d0 ("Btrfs: detect

[PATCH] btrfs: fix false enospc error when truncating heavily reflinked file

Below test script can reveal this bug: dd if=/dev/zero of=fs.img bs=$((1024*1024)) count=100 dev=$(losetup --show -f fs.img) mkdir -p /mnt/mntpoint mkfs.btrfs -f $dev mount $dev /mnt/mntpoint cd /mnt/mntpoint echo "workdir is: /mnt/mntpoint" blocksize=$((128 *

Re: Security implications of btrfs receive?

On 2016-09-06 13:20, Graham Cobb wrote: Thanks to Austin and Duncan for their replies. On 06/09/16 13:15, Austin S. Hemmelgarn wrote: On 2016-09-05 05:59, Graham Cobb wrote: Does the "path" argument of btrfs-receive mean that *all* operations are confined to that path? For example, if a UUID

Re: kworker threads may be working saner now instead of using 100% of a CPU core for minutes (Re: Still not production ready)

On 03/20/2016 12:24 PM, Martin Steigerwald wrote: >> btrfs kworker thread uses up 100% of a Sandybridge core for minutes on >> > random write into big file >> > https://bugzilla.kernel.org/show_bug.cgi?id=90401 > I think I saw this up to kernel 4.3. I think I didn´t see this with 4.4 > anymore

[PATCH] btrfs: Fix handling of -ENOENT from btrfs_uuid_iter_rem

btrfs_uuid_iter_rem is able to return -ENOENT, however this condition is not handled in btrfs_uuid_tree_iterate which can lead to calling btrfs_next_item with freed path argument, leading to a null pointer dereference. Fix it by redoing the search but with an incremented objectid so we don't loop