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 o
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 a
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
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 * 1024
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 corruption when non-root leaf h
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
>
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 t
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
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 de
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 d
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 wi
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
a
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 /
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 sending
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 a
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
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 be
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
a
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 done on mount or invoking
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
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 UUI
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 with CONFIG_BTRFS_FS_CHECK
When we're not able to get enough space through splitting leaf,
we'd create a new sibling leaf instead, and it's possible that we return
a zero-nritem sibling leaf and mark it dirty before it's in a consistent
state. With CONFIG_BTRFS_FS_CHECK_INTEGRITY=y, the integrity check of
check_leaf will r
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 options
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
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 su
On Thu, Sep 08, 2016 at 10:52:21AM +0800, Qu Wenruo wrote:
> 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 noino
27 matches
Mail list logo