On Thu, Apr 23, 2015 at 8:50 PM, Chris Mason wrote:
> On 04/23/2015 03:43 PM, Filipe David Manana wrote:
>> On Thu, Apr 23, 2015 at 4:48 PM, Filipe David Manana
>> wrote:
>>> On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason wrote:
On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana w
On Fri, Apr 24, 2015 at 8:16 AM, arnaud gaboury
wrote:
> On Fri, Apr 24, 2015 at 8:14 AM, arnaud gaboury
> wrote:
>> On Thu, Apr 23, 2015 at 7:37 PM, arnaud gaboury
>> wrote:
>>> On Thu, Apr 23, 2015 at 7:36 PM, Lennart Poettering
>>> wrote:
On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.g
On Fri, Apr 24, 2015 at 8:14 AM, arnaud gaboury
wrote:
> On Thu, Apr 23, 2015 at 7:37 PM, arnaud gaboury
> wrote:
>> On Thu, Apr 23, 2015 at 7:36 PM, Lennart Poettering
>> wrote:
>>> On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>>>
When in /var/lib/machines/poppy
On Thu, Apr 23, 2015 at 7:37 PM, arnaud gaboury
wrote:
> On Thu, Apr 23, 2015 at 7:36 PM, Lennart Poettering
> wrote:
>> On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>>
>>> When in /var/lib/machines/poppy:
>>>
>>> root@hortensia ➤➤ machines/poppy # btrfs subvolume list
Dan Merillat posted on Thu, 23 Apr 2015 12:47:29 -0400 as excerpted:
> Hopefully this is sufficiently paranoid, tested with PATH_MAX length
> symlinks, existing files, insufficient permissions, dangling symlinks. I
> think I got the coding style correct this time, I'll fix and resend if
> not.
>
- - posted on Thu, 23 Apr 2015 19:30:56 +0200 as excerpted:
> Hello,
>
> I had a 3 disk raid5 system with btrfs installed. Unfortunately one of
> the disks crashed. Now I cannot mount the system any more, not even with
> the degraded option. I suspect the failed disk to have a hw failure. I
> Thi
Martin Monperrus posted on Thu, 23 Apr 2015 20:05:16 +0200 as excerpted:
> # btrfs scrub status /
> scrub status for e11013b3-b244-4d1a-a9c7-3956db1a699c
> scrub started at Thu Apr 23 19:07:45 2015
> and finished after 372 seconds
> total bytes scrubbed: 167.13GiB with 13 errors
>
Old csum type check is wrong and can't catch csum_type 1(not supported).
Fix it to avoid hostile 0 division.
Reported-by: Lukas Lueg
Signed-off-by: Qu Wenruo
---
Changelog:
v2:
Fix existing codes other than adding new one.
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/disk-io.c | 4 ++--
2 files c
Although only RAID10 use sub_stripes, a hostile attack can modify chunk
tree and just add RAID10 bit to a single chunk.
Then btrfs_map_block will trigger a 0 division in kernel and destroy
everything.
Just add extra check when reading chunk from disk.
Reported-by: Lukas Lueg
Signed-off-by: Qu We
Original Message
Subject: Re: [PATCH] btrfs: Check superblock csum type to avoid 0
division or array overflow.
From: David Sterba
To: Qu Wenruo
Date: 2015年04月24日 00:16
On Thu, Apr 23, 2015 at 09:31:21AM +0800, Qu Wenruo wrote:
Current btrfs only support CRC32 checksum,
See also https://bugzilla.kernel.org/show_bug.cgi?id=97191
Running btrfs-progs v3.19.1
The btrfs-image attached to this bug causes the btrfs-userland tool to
overflow some data structures, leading to unallocated memory being
written to and read from. A segfault results shortly after. Reproduced
o
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.1
I've been running these through a longer set of load tests because my
commits change the free space cache writeout. It fixes commit
stalls on large filesystems (~20T space used and up) that
Hi,
This patch adds a 'du' subcommand to btrfs. 'btrfs fi du' will
calculate disk usage of the target files using fiemap. For individual
files, it will report a count of total bytes, and exclusive (not
shared) bytes. We also calculate a 'set shared' value which is
described below.
Each argument t
On 04/23/2015 03:43 PM, Filipe David Manana wrote:
> On Thu, Apr 23, 2015 at 4:48 PM, Filipe David Manana
> wrote:
>> On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason wrote:
>>> On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
>> Trying the current integration-4.1 branch, I r
On Thu, Apr 23, 2015 at 4:48 PM, Filipe David Manana wrote:
> On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason wrote:
>> On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
>>> >> Trying the current integration-4.1 branch, I ran into the following
>>> >> during xfstests/btrfs/049:
>>
On 04/23/2015 02:34 PM, Sasha Levin wrote:
> On 04/23/2015 02:24 PM, Josh Boyer wrote:
>> On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman
>> wrote:
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH
wrote:
>> On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
On Thu, 2 Ap
On 04/23/2015 02:24 PM, Josh Boyer wrote:
> On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman
> wrote:
>> > On Mon, Apr 13, 2015 at 12:58 PM, Greg KH
>> > wrote:
>>> >> On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
>>> On Thu, 2 Apr 2015 10:17:47 -0400
>>> Chris Mason wro
See also https://bugzilla.kernel.org/show_bug.cgi?id=97171
Running btrfs-progs v3.19.1
The btrfs-image attached to this bug causes the btrfs-userland tool to
use uninitialized memory and ultimately overwrite what seems to be
arbitrary memory locations, dying in the process. Reproduced on x86-64
a
On Thu, Apr 23, 2015 at 02:16:40PM -0400, Rich Freeman wrote:
> On Mon, Apr 13, 2015 at 12:58 PM, Greg KH wrote:
> > On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
> >> On Thu, 2 Apr 2015 10:17:47 -0400
> >> Chris Mason wrote:
> >>
> >> > Hi stable friends,
> >> >
> >> > Can you p
On Thu, Apr 23, 2015 at 2:16 PM, Rich Freeman
wrote:
> On Mon, Apr 13, 2015 at 12:58 PM, Greg KH wrote:
>> On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
>>> On Thu, 2 Apr 2015 10:17:47 -0400
>>> Chris Mason wrote:
>>>
>>> > Hi stable friends,
>>> >
>>> > Can you please backport
On Mon, Apr 13, 2015 at 12:58 PM, Greg KH wrote:
> On Mon, Apr 13, 2015 at 07:28:38PM +0500, Roman Mamedov wrote:
>> On Thu, 2 Apr 2015 10:17:47 -0400
>> Chris Mason wrote:
>>
>> > Hi stable friends,
>> >
>> > Can you please backport this one to 3.19.y. It fixes a bug introduced
>> > by:
>> >
>>
Hi,
More on my issue, I have "uncorrectable errors"
# btrfs scrub status /
scrub status for e11013b3-b244-4d1a-a9c7-3956db1a699c
scrub started at Thu Apr 23 19:07:45 2015 and finished after 372 seconds
total bytes scrubbed: 167.13GiB with 13 errors
error details: read=13
corrected
On 04/23/2015 12:34 PM, Holger Hoffstätte wrote:
> kmem_cache_destroy btrfs_transaction: Slab cache still has objects
Josef has a fix for this, but the fix was causing other problems. It's
not a new bug, but we'll get it fixed up.
-chris
--
To unsubscribe from this list: send the line "unsubscr
On Thu, Apr 23, 2015 at 7:36 PM, Lennart Poettering
wrote:
> On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>
>> When in /var/lib/machines/poppy:
>>
>> root@hortensia ➤➤ machines/poppy # btrfs subvolume list .
>> ID 266 gen 98 top level 5 path rootvol
>> ID 268 gen 100 to
On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> When in /var/lib/machines/poppy:
>
> root@hortensia ➤➤ machines/poppy # btrfs subvolume list .
> ID 266 gen 98 top level 5 path rootvol
> ID 268 gen 100 top level 5 path var
> ID 269 gen 101 top level 5 path etc
> ID 271 g
Hello,
I had a 3 disk raid5 system with btrfs installed. Unfortunately one of the disks
crashed. Now I cannot mount the system any more, not even with the degraded
option. I suspect the failed disk to have a hw failure. I Think part of the
problem might be that I configured the system to not only
On Thu, Apr 23, 2015 at 7:21 PM, arnaud gaboury
wrote:
> On Thu, Apr 23, 2015 at 7:12 PM, Lennart Poettering
> wrote:
>> On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>>
>>> On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
>>> wrote:
>>> > On Thu, 23.04.15 14:18, ar
On Thu, Apr 23, 2015 at 7:12 PM, Lennart Poettering
wrote:
> On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>
>> On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
>> wrote:
>> > On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>> >
>> >> > Pick
On Monday 20 Apr 2015 13:33:16 xuw2...@gmail.com wrote:
> From: George Wang
>
> PPC64 arch use such following IOC values "
> \#define _IOC_NONE 1U
> \#define _IOC_READ 2U
> \#define _IOC_WRITE 4U
> " comparing to the default IOC values "
> \#define _IOC_NONE 0U
> \#define _
On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
> wrote:
> > On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> >
> >> > Pick one:
> >> >
> >> > a) download the raw image and use that, but it wi
On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering
wrote:
> On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>
>> > Pick one:
>> >
>> > a) download the raw image and use that, but it will be a loopback file
>> > with its own file system inside
>> >
>> > or:
>> >
>> > b) do
Restore symlinks, optionally with owner/times.
Signed-off-by: Dan Merillat
---
Documentation/btrfs-restore.asciidoc | 3 +
cmds-restore.c | 140 ++-
2 files changed, 140 insertions(+), 3 deletions(-)
diff --git a/Documentation/btrfs-restor
Symlink restore needs this, but the cut&paste became
too complicated. Simplify everything.
Signed-off-by: Dan Merillat
---
cmds-restore.c | 53 ++---
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/cmds-restore.c b/cmds-restore.c
i
This was lost in the cleanup of 71a559
Signed-off-by: Dan Merillat
---
Documentation/btrfs-restore.asciidoc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/btrfs-restore.asciidoc
b/Documentation/btrfs-restore.asciidoc
index 20fc366..89e0c87 100644
--- a/Documentation/btrfs-
Hopefully this is sufficiently paranoid, tested with PATH_MAX length
symlinks, existing files, insufficient permissions, dangling symlinks.
I think I got the coding style correct this time, I'll fix and resend if
not.
Includes a trivial fix from my metadata patch, the documentation got
lost in th
On Wed, 22 Apr 2015 12:55:26 -0400, Chris Mason wrote:
> Great to hear. I recommend just using my for-linus-4.1 branch, since it
> has all the good things in one place.
Even with the latest patch for xfstests/049 I reproducibly get:
[ 405.052123]
=
On Thu, Apr 23, 2015 at 11:00:45AM +0800, Qu Wenruo wrote:
> Although only RAID10 use sub_stripes, a hostile attack can modify chunk
> tree and just add RAID10 bit to a single chunk.
> Then btrfs_map_block will trigger a 0 division in kernel and destroy
> everything.
>
> Just add extra check when
On Thu, Apr 23, 2015 at 09:31:21AM +0800, Qu Wenruo wrote:
> Current btrfs only support CRC32 checksum, and if csum_type is 1, we
> will get 0 csum size, causing 0 division later destroy the whole kernel.
> Or csum_type is later than 1, we will get data from other random memory
> causing more probl
On Thu, Apr 23, 2015 at 4:17 PM, Chris Mason wrote:
> On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
>> >> Trying the current integration-4.1 branch, I ran into the following
>> >> during xfstests/btrfs/049:
>> >>
>> >
>> > Ugh, I must not be waiting correctly in one of the i
On 20/04/2015 11:51, Marc Cousin wrote:
> On 31/03/2015 19:05, David Sterba wrote:
>> On Mon, Mar 30, 2015 at 05:09:52PM +0200, Marc Cousin wrote:
So it would be good to sample the active threads and see where it's
spending the time. It could be the somewhere in the rb-tree representing
>
On Thu, Apr 23, 2015 at 02:05:48PM +0100, Filipe David Manana wrote:
> >> Trying the current integration-4.1 branch, I ran into the following
> >> during xfstests/btrfs/049:
> >>
> >
> > Ugh, I must not be waiting correctly in one of the inode cache writeout
> > sections. But I've run 049 a whole
I've been hacking on https://github.com/csirac2/snazzer over the last
few months. It started out as a 20-line cron job, then a 50-line gist,
and now this thing that's obviously grown a little too much perhaps.
snazzer was initially written to help me maintain snapshots on a fleet
of VMs all using
On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> > Pick one:
> >
> > a) download the raw image and use that, but it will be a loopback file
> > with its own file system inside
> >
> > or:
> >
> > b) do the dnf/yum install root thing, and install it into a directory
> > tr
On Thu, 23 Apr 2015 14:43:40 +0100, Filipe Manana wrote:
> I don't think a lock followed by unlock without nothing in between (be
> it a spinlock, mutex, or any other kind of lock) will be seen by the
> compiler as a nop. Pretty sure I've seen this pattern being done in the
No, I didn't say they
On 04/23/2015 02:22 PM, Holger Hoffstätte wrote:
> On Thu, 23 Apr 2015 13:34:15 +0100, Filipe Manana wrote:
>
>> On 04/23/2015 01:16 PM, Holger Hoffstätte wrote:
>>> On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
>>>
There's a race between releasing extent buffers that are flagged
On Thu, 23 Apr 2015 13:34:15 +0100, Filipe Manana wrote:
> On 04/23/2015 01:16 PM, Holger Hoffstätte wrote:
>> On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
>>
>>> There's a race between releasing extent buffers that are flagged as stale
>>> and recycling them that makes us it the foll
On Thu, Apr 23, 2015 at 1:52 PM, Chris Mason wrote:
> On 04/23/2015 08:45 AM, Filipe David Manana wrote:
>> On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason wrote:
>>> On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
> On 04/13/2015
On 04/23/2015 08:52 AM, Chris Mason wrote:
> On 04/23/2015 08:45 AM, Filipe David Manana wrote:
>> On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason wrote:
>>> On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
> On 04/13/2015 09:52 PM,
On 04/23/2015 08:45 AM, Filipe David Manana wrote:
> On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason wrote:
>> On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
>>> On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
>>>
On 04/13/2015 09:52 PM, Chris Mason wrote:
> Large filesystems with l
On Wed, Apr 22, 2015 at 5:55 PM, Chris Mason wrote:
> On 04/22/2015 12:37 PM, Holger Hoffstätte wrote:
>> On Wed, 22 Apr 2015 18:09:18 +0200, Lutz Vieweg wrote:
>>
>>> On 04/13/2015 09:52 PM, Chris Mason wrote:
Large filesystems with lots of block groups can suffer long stalls during
com
On 04/23/2015 01:16 PM, Holger Hoffstätte wrote:
> On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
>
>> There's a race between releasing extent buffers that are flagged as stale
>> and recycling them that makes us it the following BUG_ON at
>> btrfs_release_extent_buffer_page:
>>
>>
On Thu, Apr 23, 2015 at 2:00 PM, Lennart Poettering
wrote:
> On Thu, 23.04.15 14:57, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
>> On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering
>> wrote:
>> > On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>> >
>> >> Not sure w
On Thu, Apr 23, 2015 at 1:50 PM, Lennart Poettering
wrote:
> On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>
>> Not sure what I did wrong, but I can't install/boot my nspawn container.
>> Here is my setup:
>>
>> Archlinux box- updated
>>
>> 1- created 3 btrfs subvol on /
On Thu, 23 Apr 2015 11:28:48 +0100, Filipe Manana wrote:
> There's a race between releasing extent buffers that are flagged as stale
> and recycling them that makes us it the following BUG_ON at
> btrfs_release_extent_buffer_page:
>
> BUG_ON(extent_buffer_under_io(eb))
>
> The BUG_ON is trig
On Thu, 23.04.15 14:57, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering
> wrote:
> > On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> >
> >> Not sure what I did wrong, but I can't install/boot my nspawn container.
> >>
On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering
wrote:
> On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
>
>> Not sure what I did wrong, but I can't install/boot my nspawn container.
>> Here is my setup:
>>
>> Archlinux box- updated
>>
>> 1- created 3 btrfs subvol on /
On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:
> Not sure what I did wrong, but I can't install/boot my nspawn container.
> Here is my setup:
>
> Archlinux box- updated
>
> 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage
> snapshots easily.
> no nest
Not sure what I did wrong, but I can't install/boot my nspawn container.
Here is my setup:
Archlinux box- updated
1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage
snapshots easily.
no nested subvol.
--
# btrfs subvolume list .
ID 266 gen
There's a race between releasing extent buffers that are flagged as stale
and recycling them that makes us it the following BUG_ON at
btrfs_release_extent_buffer_page:
BUG_ON(extent_buffer_under_io(eb))
The BUG_ON is triggered because the extent buffer has the flag
EXTENT_BUFFER_DIRTY set as
On Wed, Apr 22, 2015 at 12:53 PM, David Sterba wrote:
> Applied, thanks.
>
> In future patches, please stick to the coding style used in progs ([1]),
> I've fixed spacing around "=", comments and moved declarations before
> the statements.
>
> [1] https://www.kernel.org/doc/Documentation/CodingSty
60 matches
Mail list logo
