1/4 Fixes a bug that we were applying an incomplete string zstd.
2/4 Fixes a bug that the compression property gets reset to NULL after a
failed attempt to change the compression parameter on the object.
3/4 preparatory patch so that btrfs_set_prop_trans() can be merged with
btrfs_set_prop(
We let to pass zstd compression parameter even if its not fully written.
For example:
btrfs prop set /btrfs compression zst
btrfs prop get /btrfs compression
compression=zst
zlib and lzo are fine.
Fix it by using the expected number of char in strncmp().
Signed-off-by: Anand Jain
Revie
The compression property resets to NULL, instead of the old value if we
fail to set the new compression parameter.
btrfs prop get /btrfs compression
compression=lzo
btrfs prop set /btrfs compression zli
ERROR: failed to set compression for /btrfs: Invalid argument
btrfs prop get /btrfs compres
When an inode inherits property from its parent, we call btrfs_set_prop().
btrfs_set_prop() does an elaborate checks, which is not required in the
context of inheriting a property. Instead just open-code only the required
items from btrfs_set_prop() and then call btrfs_setxattr() directly. So
now t
When the property fails to pass the prop_handlers::validate() check, the
thread should exit with no changes in the kernel, but as we are starting
the transaction too early, we have just updated the generation even if
there is no change.
For example:
btrfs prop get /btrfs compression
compression=l
On 3/14/19 1:45 AM, David Sterba wrote:
On Wed, Mar 13, 2019 at 06:33:50PM +0800, Anand Jain wrote:
On 3/13/19 1:36 PM, Anand Jain wrote:
The compression property resets to NULL, instead of the old value if we
fail to set the new compression parameter.
btrfs prop get /btrfs compression
Sorry, fighting with this technology called "email" :)
Hopefully better wrapped outputs:
On 13. 03. 19 22:58, Jakub Husák wrote:
Hi,
I added another disk to my 3-disk raid5 and ran a balance command.
After few hours I looked to output of `fi usage` to see that no data
are being used on th
Hi,
I added another disk to my 3-disk raid5 and ran a balance command. After
few hours I looked to output of `fi usage` to see that no data are being
used on the new disk. I got the same result even when balancing my raid5
data or metadata.
Next I tried to convert my raid5 metadata to raid1
On Tue, Mar 12, 2019 at 03:18:47PM +0200, Nikolay Borisov wrote:
> If a an eb fails to be read for whatever reason - it's corrupted on disk
> and parent transid/key validations fail or IO for eb pages fail then
> this buffer must be removed from the buffer cache. Currently the code
> calls free_ext
On Wed, Mar 13, 2019 at 06:33:50PM +0800, Anand Jain wrote:
>
>
>
> On 3/13/19 1:36 PM, Anand Jain wrote:
> > The compression property resets to NULL, instead of the old value if we
> > fail to set the new compression parameter.
> >
> > btrfs prop get /btrfs compression
> >compression=lzo
>
On Wed, Mar 13, 2019 at 06:49:27PM +0800, Anand Jain wrote:
>
>
> On 3/13/19 6:33 PM, Anand Jain wrote:
> >
> >
> >
> > On 3/13/19 1:36 PM, Anand Jain wrote:
> >> The compression property resets to NULL, instead of the old value if we
> >> fail to set the new compression parameter.
> >>
> >> b
On Wed, Mar 13, 2019 at 04:49:54PM +0800, Anand Jain wrote:
>
>
> On 3/13/19 3:22 PM, Nikolay Borisov wrote:
> >
> >
> > On 13.03.19 г. 9:20 ч., Nikolay Borisov wrote:
> >>
> >>
> >> On 13.03.19 г. 7:36 ч., Anand Jain wrote:
> >>> The compression property resets to NULL, instead of the old valu
On Mon, Mar 11, 2019 at 09:55:38AM +0200, Nikolay Borisov wrote:
> Currently extent_readpages (called from btrfs_redpages) will always call
> __extent_readpages which tries to create contiguous range of pages and
> call __do_contiguous_readpages when such contiguous range is created.
>
> It turns
The read_locks are a simple counter to track locking balance and used to
assert tree locks. Add helpers to make it conditionally work only in
DEBUG builds. Will be used in followup patches.
Signed-off-by: David Sterba
---
fs/btrfs/locking.c | 25 ++---
1 file changed, 18 in
Add helpers for conditional DEBUG build to assert that the extent buffer
spinning_readers constraints are met. Will be used in followup patches.
Signed-off-by: David Sterba
---
fs/btrfs/locking.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/fs/btrfs/locking.c b/fs/btrfs/loc
Use the helpers where open coded. On non-debug builds, the warnings will
not trigger and extent_buffer::spining_writers become unused and can be
moved to the appropriate section, saving a few bytes.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 5 -
fs/btrfs/extent_io.h | 2 +-
fs
Use the helpers where open coded. On non-debug builds, the warnings will
not trigger and extent_buffer::spining_readers become unused and can be
moved to the appropriate section, saving a few bytes.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/extent_io.h | 2 +-
fs/bt
Use the helpers where open coded. On non-debug builds, the warnings will
not trigger and extent_buffer::read_locks become unused and can be
moved to the appropriate section, saving a few bytes.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/extent_io.h | 2 +-
fs/btrfs/l
The member is tracking simple status of the lock, we can use bool for
that and make some room for further space reduction in the structure.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/extent_io.h | 2 +-
fs/btrfs/locking.c | 6 +++---
3 files changed, 5 insertions(+),
The write_locks are a simple counter to track locking balance and used
to assert tree locks. Add helpers to make it conditionally work only in
DEBUG builds. Will be used in followup patches.
Signed-off-by: David Sterba
---
fs/btrfs/locking.c | 23 ++-
1 file changed, 18 ins
Use the helpers where open coded. On non-debug builds, the warnings will
not trigger and extent_buffer::write_locks become unused and can be
moved to the appropriate section, saving a few bytes.
Signed-off-by: David Sterba
---
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/extent_io.h | 3 +--
fs/btrfs/l
Add helpers for conditional DEBUG build to assert that the extent buffer
spinning_writers constraints are met. Will be used in followup patches.
Signed-off-by: David Sterba
---
fs/btrfs/locking.c | 24
1 file changed, 24 insertions(+)
diff --git a/fs/btrfs/locking.c b/f
The series moves several atomic counters under CONFIG_BTRFS_DEBUG. The
selected counters are not essential for the extent buffer locking to
work. There's some space saving (4x 4B at least) and the cachelines are
less stressed on non-debugging builds.
The final size is 264 from 280, getting to 256
On Tue, Mar 12, 2019 at 05:20:23PM +0200, Nikolay Borisov wrote:
> Here is the v4 of the compress path cleanups, this version incorporates
> feeback from v3, namely:
>
> * Use struct_size when calculating the size of the struct to allocated in
> cow_file_range_async
>
> * Reinstated the comme
On 2019/3/13 下午7:31, David Sterba wrote:
> On Tue, Mar 12, 2019 at 08:42:12AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2019/3/12 上午8:33, David Sterba wrote:
>>> On Mon, Feb 18, 2019 at 01:27:51PM +0800, Qu Wenruo wrote:
Signed-off-by: Qu Wenruo
Reviewed-by: Johannes Thumshirn
---
On Tue, Mar 12, 2019 at 08:42:12AM +0800, Qu Wenruo wrote:
>
>
> On 2019/3/12 上午8:33, David Sterba wrote:
> > On Mon, Feb 18, 2019 at 01:27:51PM +0800, Qu Wenruo wrote:
> >> Signed-off-by: Qu Wenruo
> >> Reviewed-by: Johannes Thumshirn
> >> ---
> >> fs/btrfs/extent_io.c | 10 --
> >> 1
On 3/13/19 6:33 PM, Anand Jain wrote:
On 3/13/19 1:36 PM, Anand Jain wrote:
The compression property resets to NULL, instead of the old value if we
fail to set the new compression parameter.
btrfs prop get /btrfs compression
compression=lzo
btrfs prop set /btrfs compression zli
ERRO
On 3/13/19 1:36 PM, Anand Jain wrote:
The compression property resets to NULL, instead of the old value if we
fail to set the new compression parameter.
btrfs prop get /btrfs compression
compression=lzo
btrfs prop set /btrfs compression zli
ERROR: failed to set compression for /btrfs:
On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> [BUG]
> When access a file on a crafted image, btrfs can crash in block layer:
>
> BUG: unable to handle kernel NULL pointer dereference at 0008
> PGD 136501067 P4D 136501067 PUD 124519067 PMD 0
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted
On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> There is a report in kernel bugzilla about mismatch file type in dir
> item and inode item.
>
> This inspires us to check inode mode in inode item.
>
> This patch will check the following members:
> - inode key objectid
> Should be ROOT_DIR_DIR or
On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> [BUG]
> When reading a file from a fuzzed image, kernel can panic like:
> BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum
> 0x98f94189 expected csum 0x mirror 1
> assertion failed: !memcmp_extent_buffer(b, &disk_key, of
On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> [BUG]
> For fuzzed image whose DEV_ITEM has invalid total_bytes as 0, then
> kernel will just panic:
> BUG: unable to handle kernel NULL pointer dereference at 0098
> #PF error: [normal kernel read fault]
> PGD 80022b2bd067 P4D 80
On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> We already have btrfs_check_chunk_valid() to verify each chunk before
> tree-checker.
>
> Merge that function into tree-checker, and update its error message to
> be more readable.
>
> Old error message would be something like:
> BTRFS error (devic
On 13.03.19 г. 10:55 ч., Qu Wenruo wrote:
> Btrfs-progs already has comprehensive type checker, to ensure there is
> only 0 (SINGLE profile) or 1 (DUP/RAID0/1/5/6/10) bit set for chunk
> profile bits.
>
> Do the same work for kernel.
>
> Reported-by: Yoon Jungyeon
> Link: https://bugzilla.ker
Just forgot the repo:
It can be fetched from github:
https://github.com/adam900710/linux/tree/tree_checker_enhancement
Which is based on my previous write time tree checker patchset.
Although the patchset itself can also be applied to v5.0-rc7 tag without
manual modification.
Thanks,
Qu
On 2019
[BUG]
When access a file on a crafted image, btrfs can crash in block layer:
BUG: unable to handle kernel NULL pointer dereference at 0008
PGD 136501067 P4D 136501067 PUD 124519067 PMD 0
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.0.0-rc8-default #252
RIP: 0010:end_bio_extent_readpage+
Btrfs-progs already has comprehensive type checker, to ensure there is
only 0 (SINGLE profile) or 1 (DUP/RAID0/1/5/6/10) bit set for chunk
profile bits.
Do the same work for kernel.
Reported-by: Yoon Jungyeon
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202765
Signed-off-by: Qu Wenruo
---
[BUG]
When reading a file from a fuzzed image, kernel can panic like:
BTRFS warning (device loop0): csum failed root 5 ino 270 off 0 csum
0x98f94189 expected csum 0x mirror 1
assertion failed: !memcmp_extent_buffer(b, &disk_key, offsetof(struct
btrfs_leaf, items[0].key), sizeof(disk_k
There is a report in kernel bugzilla about mismatch file type in dir
item and inode item.
This inspires us to check inode mode in inode item.
This patch will check the following members:
- inode key objectid
Should be ROOT_DIR_DIR or [256, (u64)-256] or FREE_INO.
- inode key offset
Should be
Thanks for the report from Yoon Jungyeon , we have
more fuzzed image to torture btrfs.
Those images exposed the following problems:
- Chunk check is not comprehensive nor early enough
Chunk item check lacks profile bits check (e.g RAID|DUP profile is
invalid).
And for certain fuzzed image,
We already have btrfs_check_chunk_valid() to verify each chunk before
tree-checker.
Merge that function into tree-checker, and update its error message to
be more readable.
Old error message would be something like:
BTRFS error (device dm-3): invalid chunk num_stipres: 0
New error message woul
[BUG]
For fuzzed image whose DEV_ITEM has invalid total_bytes as 0, then
kernel will just panic:
BUG: unable to handle kernel NULL pointer dereference at 0098
#PF error: [normal kernel read fault]
PGD 80022b2bd067 P4D 80022b2bd067 PUD 22b2bc067 PMD 0
Oops: [#1] SMP
On 3/13/19 3:22 PM, Nikolay Borisov wrote:
On 13.03.19 г. 9:20 ч., Nikolay Borisov wrote:
On 13.03.19 г. 7:36 ч., Anand Jain wrote:
The compression property resets to NULL, instead of the old value if we
fail to set the new compression parameter.
btrfs prop get /btrfs compression
com
On 13.03.19 г. 9:20 ч., Nikolay Borisov wrote:
>
>
> On 13.03.19 г. 7:36 ч., Anand Jain wrote:
>> The compression property resets to NULL, instead of the old value if we
>> fail to set the new compression parameter.
>>
>> btrfs prop get /btrfs compression
>> compression=lzo
>> btrfs prop set
On 13.03.19 г. 7:36 ч., Anand Jain wrote:
> The compression property resets to NULL, instead of the old value if we
> fail to set the new compression parameter.
>
> btrfs prop get /btrfs compression
> compression=lzo
> btrfs prop set /btrfs compression zli
> ERROR: failed to set compression
On 13.03.19 г. 7:36 ч., Anand Jain wrote:
> We let to pass zstd compression parameter even if its not fully written.
> For example:
> btrfs prop set /btrfs compression zst
> btrfs prop get /btrfs compression
> compression=zst
>
> zlib and lzo are fine.
>
> Fix it by using the expected
46 matches
Mail list logo
