On 18.07.19 г. 14:16 ч., Filipe Manana wrote:
> On Thu, Jul 18, 2019 at 6:50 AM Qu Wenruo wrote:
>>
>> [BUG]
>> The following script can easily cause unexpected ENOSPC:
>> umount $dev &> /dev/null
>> umount $mnt &> /dev/null
>>
>> mkfs.btrfs -b 1G -m single -d single $dev -f > /dev/null
>
On 18.07.19 г. 8:48 ч., Qu Wenruo wrote:
> [BUG]
> The following script can easily cause unexpected ENOSPC:
> umount $dev &> /dev/null
> umount $mnt &> /dev/null
>
> mkfs.btrfs -b 1G -m single -d single $dev -f > /dev/null
>
> mount $dev $mnt -o enospc_debug
>
> for i in $(seq -w 0
On 17.07.19 г. 20:39 ч., Andrei Borzenkov wrote:
> 17.07.2019 14:19, Nikolay Borisov пишет:
>>
>> This is really odd... So this indeed seems to be a userspace problem.
>
>
> Of course it is user space problem.
>
> commit 0a0a03554aaf56a6e7245e74fa7d8b3c53f1
It's unlikely in-band dedupe is going to land so just remove any
leftovers - dedupe.h header as well as the 'dedupe' parameter to
btrfs_set_extent_delalloc.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/dedupe.h| 12
meter from that function as well.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 6 +++---
fs/btrfs/extent_io.h | 6 +++---
fs/btrfs/inode.c | 48 ++--
3 files changed, 25 insertions(+), 35 deletions(-)
diff --git a/fs/btrfs/extent_
This label is only executed if compress_file_range fails to create an
inline extent. So move its code in the semantically related inline
extent handling branch. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 18 --
1 file changed, 8 insertions
compress_file_range returns a void, yet uses a function parameter as a
return value. Make that more idiomatic by simply returning the number
of compressed extents directly. Also track such extents in more aptly
named variables. No functional changes
Signed-off-by: Nikolay Borisov
---
fs/btrfs
On 17.07.19 г. 13:29 ч., Andrei Borzenkov wrote:
> On Wed, Jul 17, 2019 at 1:14 PM Nikolay Borisov wrote:
>>
>>
>>
>> On 17.07.19 г. 12:11 ч., Ulli Horlacher wrote:
>>> On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
>>>>
>>>>
>
On 17.07.19 г. 12:11 ч., Ulli Horlacher wrote:
> On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
>>
>>
>> On 17.07.19 3. 2:24 G., Ulli Horlacher wrote:
>>
>>> I thought, I can recognize a snapshot when it has a Parent UUID, but this
>>> is
On 17.07.19 г. 2:24 ч., Ulli Horlacher wrote:
> I thought, I can recognize a snapshot when it has a Parent UUID, but this
> is not true for snapshots of toplevel subvolumes:
As you have asked this before - in my testing this is not true. Looking
at the code it also seems snapshots get a parent
On 16.07.19 г. 4:26 ч., Qu Wenruo wrote:
>
>
> On 2019/7/15 下午11:09, Nikolay Borisov wrote:
>>
>>
>> On 15.07.19 г. 17:42 ч., Anand Jain wrote:
>>> To help debug device scan issues, add verbose option to btrfs device scan.
>>>
>>> Signed-o
On 15.07.19 г. 17:42 ч., Anand Jain wrote:
> To help debug device scan issues, add verbose option to btrfs device scan.
>
> Signed-off-by: Anand Jain
I fail to see what this patch helps for. We get the path in case of
errors, in case of success what good could the path be ?
> ---
> cmds/de
call free_extent_map(), not just in the error case.
>
> Fixes: 5f1411265e16 ("btrfs: Introduce btrfs_io_geometry infrastructure")
> Signed-off-by: Johannes Thumshirn
My bad:
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/volumes.c | 10 +++---
> 1 file changed,
On 15.07.19 г. 10:19 ч., Игорь Наумов wrote:
>
> Hello,
>
> using Ubuntu server 18.04.2 btrfs on /
>
> 10 absolutely identical servers (Dell M630), with the same configuration,
> updated 2/10 and encountered this problem on both.
> After upgrading kernel from version 4.15.0-36-generic # 39
On 10.07.19 г. 22:28 ч., Tejun Heo wrote:
> From: Chris Mason
>
> The btrfs writepages function collects a large range of pages flagged
> for delayed allocation, and then sends them down through the COW code
> for processing. When compression is on, we allocate one async_cow
nit: The code no
On 10.07.19 г. 22:28 ч., Tejun Heo wrote:
> From: Chris Mason
>
> Now that we're not using btrfs_schedule_bio() anymore, delete all the
> code that supported it.
>
> Signed-off-by: Chris Mason
> Reviewed-by: Josef Bacik
Reviewed-by: Nikolay Borisov
> --
submission,
> and doesn't fit well with the modern blkmq IO stack. So, this commit stops
> using btrfs_schedule_bio(). We may need to adjust the number of async
> helper threads for crcs and compression, but long term it's a better
> path.
>
> Signed-off-by: Chris Mason
> Reviewed-by: Josef Bacik
Reviewed-by: Nikolay Borisov
On 10.07.19 г. 15:02 ч., Qu Wenruo wrote:
>
>
> On 2019/7/10 下午7:19, Nikolay Borisov wrote:
>>
>>
> [...]
>>> +static int check_cross_tree_key_order(struct extent_buffer *left,
>>> + struct extent_buffer *right)
t().
>
> Now we check if the key order of the right most key of the left node is
> larger than the left most key of the right node.
>
> By this we don't need to call the full tree-check, while still keeps the
> key order correct as key order in each node is already checked
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> [BUG]
> With crafted image, btrfs can panic at insert_inline_extent_backref():
> kernel BUG at fs/btrfs/extent-tree.c:1857!
> invalid opcode: [#1] SMP PTI
> CPU: 0 PID: 1117 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
> RIP: 0010:inser
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> [BUG]
> With crafted image, btrfs will panic at btree operations:
> kernel BUG at fs/btrfs/ctree.c:3894!
> invalid opcode: [#1] SMP PTI
> CPU: 0 PID: 1138 Comm: btrfs-transacti Not tainted 5.0.0-rc8+ #9
> RIP: 0010:__push_leaf_left+0x6b6/0
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> __btrfs_free_extent() is one of the best cases to show how optimization
> could make a function hard to read.
>
> In fact __btrfs_free_extent() is only doing two major works:
> 1. Reduce the refs number of an extent backref
>Either it's an inlined
On 10.07.19 г. 11:02 ч., Qu Wenruo wrote:
> Although we have start, len check for extent buffer reader/write (e.g.
> read_extent_buffer()), those checks has its limitations:
> - No overflow check
> Values like start = 1024 len = -1024 can still pass the basic
>(start + len) > eb->len check
bviously wrong compared to original commit.
I concur, it's indeed wrongly backported so:
Reviewed-by: Nikolay Borisov
>
> fs/btrfs/backref.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> index d826fbaf7d50..e4d5e6eae409
On 8.07.19 г. 15:50 ч., Qu Wenruo wrote:
>
>
> On 2019/7/8 下午6:43, Nikolay Borisov wrote:
>>
>>
>> On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
>>> In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
>>> However under a lot of
eed to exhaust both delayed refs and dirty blocks.
>
> This patch will call btrfs_write_dirty_block_groups() and
> btrfs_run_delayed_refs() in a loop until both delayed refs and dirty
> blocks are exhausted. Much like what we do in commit_cowonly_roots() in
> kernel.
>
> Also, t
On 8.07.19 г. 10:33 ч., Qu Wenruo wrote:
> In write_one_cache_group() we always do COW to update BLOCK_GROUP_ITEM.
> However under a lot of cases, the cache->item is not changed at all.
>
> E.g:
> Transaction 123, block group [1M, 1M + 16M)
>
> tree block 1M + 0 get freed
> tree block 1M + 16K
iters. So improve this by adding such a wakeup
> call after marking that initial range as free space.
>
> Fixes: a47d6b70e28040 ("Btrfs: setup free ino caching in a more asynchronous
> way")
> Signed-off-by: Filipe Manana
Reviewed-by: Nikolay Borisov
> ---
> fs
caching thread: print an error
> message, disable inode caching and make the wakers fallback to non-caching
> mode behaviour (calling btrfs_find_free_objectid()).
>
> Fixes: 581bb050941b4f ("Btrfs: Cache free inode numbers in memory")
> Signed-off-by: Filipe Manana
Reviewed
caching thread: print an error
> message, disable inode caching and make the wakers fallback to non-caching
> mode behaviour (calling btrfs_find_free_objectid()).
>
> Fixes: 581bb050941b4f ("Btrfs: Cache free inode numbers in memory")
> Signed-off-by: Filipe Manana
Reviewed-
On 5.07.19 г. 17:32 ч., Filipe Manana wrote:
> Nikolay,
>
> The bytes_may_use counter gets decremented once the extent is allocated.
> If we were leaking it, we would see a trace when unmounting the
> filesystem, and I certainly wouldn't send this patch trading a few
> warnings for another one
On 7.07.19 г. 10:37 ч., Andrei Borzenkov wrote:
> 07.07.2019 9:43, Nikolay Borisov пишет:
>>
>>
>> On 6.07.19 г. 23:43 ч., Ulli Horlacher wrote:
>>> On Sat 2019-07-06 (19:57), Nikolay Borisov wrote:
>>>
>>>>> And how can I see wheth
On 6.07.19 г. 23:43 ч., Ulli Horlacher wrote:
> On Sat 2019-07-06 (19:57), Nikolay Borisov wrote:
>
>>> And how can I see whether /test/tmp/xx/ss1 is a snapshot at all?
>>> Do all snapshots have a "Parent UUID" and regular subvolumes not?
>>
>
On 6.07.19 г. 18:53 ч., Ulli Horlacher wrote:
> Is there a standard way to find the path of the subvolume parent of a
> snapshot?
>
> For example:
>
> root@xerus:/test# btrfs sub list /test
> ID 269 gen 9818 top level 5 path tux/test
> ID 1026 gen 9804 top level 1011 path tmp/xx/ss1
> ID 1027
On 5.07.19 г. 17:23 ч., Filipe Manana wrote:
> On Fri, Jul 5, 2019 at 3:09 PM Nikolay Borisov wrote:
>>
>>
>>
>> On 5.07.19 г. 13:42 ч., Filipe Manana wrote:
>>> On Fri, Jul 5, 2019 at 11:01 AM Nikolay Borisov wrote:
>>>>
>>>>
sh. Fix this by waking them
> up and have them fallback to a call to btrfs_find_free_objectid().
>
> Fixes: e60efa84252c05 ("Btrfs: avoid triggering bug_on() when we fail to
> start inode caching task")
> Signed-off-by: Filipe Manana
Reviewed-by: Nikolay Bori
On 5.07.19 г. 13:42 ч., Filipe Manana wrote:
> On Fri, Jul 5, 2019 at 11:01 AM Nikolay Borisov wrote:
>>
>>
>>
>> On 4.07.19 г. 18:24 ч., fdman...@kernel.org wrote:
>>> From: Filipe Manana
>>>
>>> If we failed to allocate the data extent
On 4.07.19 г. 18:24 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If we failed to allocate the data extent(s) for the inode space cache, we
> were bailing out without releasing the previously reserved metadata. This
> was triggering the following warnings when unmounting a filesyste
ll right after setting the cache state to
> BTRFS_CACHE_FINISHED, at start_caching(), when we are able to load the
> cache from disk.
>
> Fixes: 82d5902d9c681b ("Btrfs: Support reading/writing on disk free ino
> cache")
> Signed-off-by: Filipe Manana
Reviewed-by: Ni
On 5.07.19 г. 10:26 ч., Qu Wenruo wrote:
> [BUG]
> On aarch64 with 64k page size, mkfs.btrfs -s option doesn't work:
> $ mkfs.btrfs -s 4096 ~/10G.img -f
> btrfs-progs v5.1.1
> See http://btrfs.wiki.kernel.org for more information.
>
> Label: (null)
> UUID:
5911c8fe05c5 ("btrfs: fiemap: preallocate ulists for
> btrfs_check_shared")
> Signed-off-by: Colin Ian King
Reviewed-by: Nikolay Borisov
> ---
> V2: move the btrfs_free_path to the out_free_ulist label as suggested by
> David Sterba as the correct fix.
> V3:
Simplify the code by removing variables that don't bring any real value
as well as simplifying the checks when buidling the candidate list of
devices. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/super.c | 30 ++
1 file changed, 10 inser
so there's no noticeable delay caused by that.
Signed-off-by: Nikolay Borisov
---
Hello Greg,
Please merge the following backport of upstream commit
debd1c065d2037919a7da67baf55cc683fee09f0
to 5.1 stable branch.
fs/btrfs/dev-replace.c | 26 +-
fs/btrfs/volumes.c
so there's no noticeable delay caused by that.
Signed-off-by: Nikolay Borisov
---
Hello Greg,
Please merge the following backport of upstream commit
debd1c065d2037919a7da67baf55cc683fee09f0
to 4.9 stable branch.
fs/btrfs/dev-replace.c | 29 +++--
fs/btrfs/volume
so there's no noticeable delay caused by that.
Signed-off-by: Nikolay Borisov
---
Hello Greg,
Please merge the following backport of upstream commit
debd1c065d2037919a7da67baf55cc683fee09f0
to 4.14.y stable branch.
fs/btrfs/dev-replace.c | 29 +++--
fs/btrfs/volume
so there's no noticeable delay caused by that.
Signed-off-by: Nikolay Borisov
---
Hello Greg,
Please merge the following backport of upstream commit
debd1c065d2037919a7da67baf55cc683fee09f0
to 4.19 stable branch.
fs/btrfs/dev-replace.c | 26 +-
fs/btrfs/volumes.c |
so there's no noticeable delay caused by that.
Signed-off-by: Nikolay Borisov
---
Hello Greg,
Please merge the following backport of upstream commit
debd1c065d2037919a7da67baf55cc683fee09f0
to 4.4.y stable branch.
fs/btrfs/dev-replace.c | 29 +++--
fs/btrfs/volume
Return "0" on
> line 316
>
> Signed-off-by: Hariprasad Kelam
Reviewed-by: Nikolay Borisov
compress_file_range returns a void, yet uses a function parameter as a
return value. Make that more idiomatic by simply returning the number
of compressed extents directly. Also track such extents in more aptly
named variables. No functional changes
Signed-off-by: Nikolay Borisov
---
fs/btrfs
This label is only executed if compress_file_range fails to create an
inline extent. So move its code in the semantically related inline
extent handling branch. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 18 --
1 file changed, 8 insertions
On 27.06.19 г. 20:00 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Move the code that is responsible for dropping extents in a range out of
> btrfs_punch_hole() into a new helper function, btrfs_punch_hole_range(),
> so that later it can be used by the reflinking (extent cloning and
On 26.06.19 г. 6:03 ч., Goldwyn Rodrigues wrote:
> On 21:04 25/06, Filipe Manana wrote:
>> On Tue, Jun 25, 2019 at 8:58 PM Goldwyn Rodrigues wrote:
>>>
>>> On 9:05 24/06, Christoph Hellwig wrote:
On Fri, Jun 21, 2019 at 02:28:25PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrig
On 25.06.19 г. 5:49 ч., Chris Murphy wrote:
> False alarm, not a new issue at all!
>
> I have a different system on kernel 5.1.11 using Btrfs as root with
> persistent systemd-journald storage, and compress=zstd. And I never
> have problems with it, so I never run btrfs check on it, until now.
On 19.06.19 г. 20:47 ч., Josef Bacik wrote:
> block_rsv_release_bytes() is the internal to the block_rsv code, and
> shouldn't be called directly by anything else. Switch all users to the
> exported helpers.
>
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/extent-tree.c | 14 ++
>
On 19.06.19 г. 20:47 ч., Josef Bacik wrote:
> This works for all callers already, but if we wanted to use the helper
> for the global_block_rsv it would end up trying to refill itself. Fix
> the logic to be able to be used no matter which block rsv is passed in
> to this helper.
>
> Signed-off
> other
> space reservation code that is specific to delayed_refs, inodes, etc. But I
> wanted to start with this to make sure we're all onboard with this approach
> before I do other things.
>
> The diffstat for the whole series is the following
Looks good,
Reviewed-b
gt; the first condition is true, can_overcommit() is not
> called.
>
> Signed-off-by: Goldwyn Rodrigues
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/extent-tree.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/fs/btrfs/extent-tr
d,
so just remove it.
Signed-off-by: Nikolay Borisov
---
check/main.c | 69
1 file changed, 69 deletions(-)
diff --git a/check/main.c b/check/main.c
index 731c21d364d7..05ba9819c58e 100644
--- a/check/main.c
+++ b/check/main.c
@@ -4385,36 +
Commit ba23855cdc89 ("btrfs-progs: send: use splice syscall instead of
read/write to transfer buffer") changed the send implementation to use
splice(). The old read/write implementation hasn't be used for at least
3 years, it's time to remove it.
Signed-off-by: Nikolay Boris
Just a couple of patches that remove unneeded code. The first one does away
with an always true if construct and the rest remove code which has been #if 0
for quite some time.
Nikolay Borisov (4):
btrfs-progs: Remove redundant if
btrfs-progs: Remove commented code
btrfs: Remove old send
'pin' is always true in __free_extent so there is no point in checking
it. Just remove the if and unindent the code.
Signed-off-by: Nikolay Borisov
---
extent-tree.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/extent-tree.c b/extent-tr
This piece of code has been commented since 2009, given the number of
changes that have happened it's unlikely it could be made to work or
is needed at all. Just delete it.
Signed-off-by: Nikolay Borisov
---
extent-tree.c | 257 --
1 file ch
On 18.06.19 г. 21:00 ч., David Sterba wrote:
> Minimum stripe count matches the minimum devices required for a given
> profile. The open coded assignments match the raid_attr table.
>
> What's changed here is the meaning for RAID5/6. Previously their
> min_stripes would be 1, while newly it's de
On 18.06.19 г. 21:00 ч., David Sterba wrote:
> The block device is passed around for the only purpose to set it in new
> bios. Move the assignment one level up. This is a preparatory patch for
> further bdev cleanups.
>
> Signed-off-by: David Sterba
Reviewed-by: Nikolay Boris
On 18.06.19 г. 21:00 ч., David Sterba wrote:
> Special case for DUP can be replaced by lookup to the attribute table,
> where the dev_stripes is the right coefficient.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/super.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
On 18.06.19 г. 21:00 ч., David Sterba wrote:
> Print the error messages using the helpers that also print the
> filesystem identification.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/extent_io.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrf
ore likely to be doing the final iput
> at unlink time, and thus will get the IO charged to the caller and get
> throttled appropriately without affecting the main workload.
>
> Signed-off-by: Josef Bacik
That looks a lot nicer and the explanation is sufficient.
Reviewed-by: Nikolay B
On 25.05.19 г. 2:32 ч., Qu Wenruo wrote:
> [BUG]
> There is a bug report of unexpected ENOSPC from btrfs-convert.
> https://github.com/kdave/btrfs-progs/issues/123#
>
> After some debug, even when we have enough unallocated space, we still
> hit ENOSPC at btrfs_reserve_extent().
>
> [CAUSE]
>
kfree();
> }
>
> This will not free the memory for the last user, but for refs >= 2.
> Causing both use-after-free and memory leak for any offline write
> operation.
>
> [FIX]
> Fix the (--ref->refs) condition to (--ref->refs == 0) to fix the
> bac
On 19.06.19 г. 3:35 ч., Goldwyn Rodrigues wrote:
> Simplification.
> No point passing the tree variable when it can be evaluated
> from inode.
>
> Signed-off-by: Goldwyn Rodrigues
The patch is good, however, there are several calls to find_
lock_delalloc_range in btrfs tests so you'd need to
On 18.06.19 г. 17:15 ч., David Sterba wrote:
> We don't use the plain key for any on-disk operations so there's no
> requirement for the member order. As the offset is a u64 that should be
> on an 8byte aligned address, this can generate ineffective code on
> strict alignment architectures and c
No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 22 +++---
fs/btrfs/volumes.c | 71 ++
2 files changed, 21 insertions(+), 72 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 7126493d8d8c..253e
ather than a single struct
is a deliberate choice so as not to bloat the stack.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/volumes.c | 119 +
fs/btrfs/volumes.h | 2 +
2 files changed, 121 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs
On 8.06.19 г. 19:06 ч., Paul E. McKenney wrote:
> On Sat, Jun 08, 2019 at 06:44:17PM +0300, Nikolay Borisov wrote:
>> On 8.06.19 г. 18:13 ч., Paul E. McKenney wrote:
>>> On Fri, Jun 07, 2019 at 02:59:34PM +0300, Nikolay Borisov wrote:
>>>> On 7.06.19 г. 13
On 8.06.19 г. 18:13 ч., Paul E. McKenney wrote:
> On Fri, Jun 07, 2019 at 02:59:34PM +0300, Nikolay Borisov wrote:
>>
>>
>> On 7.06.19 г. 13:52 ч., Paul E. McKenney wrote:
>>> On Thu, Jun 06, 2019 at 04:52:18PM +0300, Nikolay Borisov wrote:
>>>> A (D
On 7.06.19 г. 13:52 ч., Paul E. McKenney wrote:
> On Thu, Jun 06, 2019 at 04:52:18PM +0300, Nikolay Borisov wrote:
>> A (D)ouble (R)eader (W)riter lock is a locking primitive that allows
>> to have multiple readers or multiple writers but not multiple readers
>> a
and vice-versa. Current implementation
actually favors Readers (that is snapshot creaters) to writers (nocow
writers of the filesystem).
Signed-off-by: Nikolay Borisov
---
fs/btrfs/Makefile | 2 +-
fs/btrfs/drw_lock.c | 71 +
fs/btrfs/drw_lock.h | 23
antees of the locking scheme and whether there is some silent
breakage lurking.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 10 +++---
fs/btrfs/disk-io.c | 39 +++
fs/btrfs/extent-tree.c | 35 ---
fs/btrfs/f
about the technical
details and invariants that the lock provide.
I have also CC'ed a copule of the maintainer of linux memory model since my
patches just factor out the code and I would really like someone proficient
enough in the usage/semantics of memory barries to review it as well.
Ni
; with strncmp() and a length of 3.
> strncmp() read past the 'lz' when looking for the 'o' and thus caused an
> out-of-bounds read.
>
> Introduce a new check 'btrfs_compress_is_valid_type()' which not only
> checks the user-supplied value against known compression types, but also
> employs checks for too short values.
>
> Fixes: 272e5326c783 ("btrfs: prop: fix vanished compression property after
> failed set")
> Reported-by: Nikolay Borisov
> Signed-off-by: Johannes Thumshirn
>
Reviewed-by: Nikolay Borisov
On 6.06.19 г. 10:49 ч., Naohiro Aota wrote:
> xattr value is not NULL-terminated string. When you specify "lz" as the
> property value, strncmp("lzo", value, 3) will try to read one byte after
> the value buffer, causing the following OOB access. Fix this out-of-bound
> by explicitly check the r
; with strncmp() and a length of 3.
> strncmp() read past the 'lz' when looking for the 'o' and thus caused an
> out-of-bounds read.
>
> Introduce a new check 'btrfs_compress_is_valid_type()' which not only
> checks the user-supplied value against known compression t
On 5.06.19 г. 14:53 ч., Qu Wenruo wrote:
>
>
> On 2019/6/5 下午7:16, Nikolay Borisov wrote:
>>
>>
>> On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
>>> If a filesystem doesn't map its logical address space (normally the
>>> bytenr/blocknr r
The function has a lot of return values and specific conventions making
it cumbersome to understand what's returned. Have a go at documenting
its parameters and return values.
Signed-off-by: Nikolay Borisov
---
* Document 'tree' argument to silence error (Johaness)
* Document tha
On 5.06.19 г. 12:14 ч., Qu Wenruo wrote:
>
>
> On 2019/6/3 下午6:06, Nikolay Borisov wrote:
>> Currently the first megabyte on a device housing a btrfs filesystem is
>> exempt from allocation and trimming. Currently this is not a problem
>> since 'start&#
On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
> If a filesystem doesn't map its logical address space (normally the
> bytenr/blocknr returned by fiemap) directly to its devices(s), the
> following assumptions used in the test case is no longer true:
> - trim range start beyond the end of fs should fai
| 2 ++
> fs/btrfs/raid56.c | 4 ++--
> fs/btrfs/tests/extent-map-tests.c | 22 ++
> 5 files changed, 32 insertions(+), 7 deletions(-)
>
For the whole series :
Reviewed-by: Nikolay Borisov
e semantics and Patch 4 change
the semantics).
This has been fully tested with xfstest and no regressions were found.
Nikolay Borisov (4):
btrfs: Document __etree_search
btrfs: Always trim all unallocated space in btrfs_trim_free_extents
btrfs: Skip first megabyte on device when trimming
the function is called. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index d8c5febf7636..5a11e4988243 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/ext
into btrfs_issue_discard,
which in turn leads to wrap-around when aligning the passed range and
results in wrong regions being discarded which leads to data corruption.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 28 +++-
1 file changed, 3 insertions(+), 25 dele
The function has a lot of return values and specific conventions making
it cumbersome to understand what's returned. Have a go at documenting
its parameters and return values.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 16
1 file changed, 16 insertions(+)
first_clear_extent_bit
since they were missing up until now.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 51 +++---
fs/btrfs/tests/extent-io-tests.c | 89
2 files changed, 134 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/e
'bbio_ret' parameter.
This patch refactors all callers that require just the mapping length
by switching them to using btrfs_io_geometry instead of calling
btrfs_map_block with a special NULL value for 'bbio_ret'. No functional
change.
Signed-off-by: Nikolay Borisov
Signed-off-by: Nikolay Borisov
---
fs/btrfs/volumes.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index a7121d72388f..7c1ddf35b7d4 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -23,6 +23,15 @@ struct btrfs_pending_bios
Signed-off-by: Nikolay Borisov
---
fs/btrfs/volumes.c | 98 ++
fs/btrfs/volumes.h | 2 +
2 files changed, 100 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 776f5c7ca7c5..b130f465ca6d 100644
--- a/fs/btrfs/volumes.c
+++ b/fs
t the "address calculation
mechanics" into a separate function. To reduce the number of variables having
to pass also introduce a struct with the same name that holds all the output
values.
Nikolay Borisov (3):
btrfs: Introduce struct btrfs_io_geometry
btrfs: Introduce btrfs_io_geomet
On 31.05.19 г. 19:03 ч., David Sterba wrote:
> On Fri, May 31, 2019 at 06:01:14PM +0300, Nikolay Borisov wrote:
>> ---
>> fs/btrfs/volumes.c | 98 ++
>> fs/btrfs/volumes.h | 2 +
>> 2 files changed, 100 insertions(+)
Presently btrfs_map_block is used not only to do everything necessary
to map a bio to the underlying allocation profile but it's also used to
identify how much data could be written based on btrfs' stripe logic
without actually submitting anything. This is achieved by passing NULL
for 'bbio_ret' pa
---
fs/btrfs/volumes.c | 98 ++
fs/btrfs/volumes.h | 2 +
2 files changed, 100 insertions(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 776f5c7ca7c5..b130f465ca6d 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -5907,6 +5907
On 30.05.19 г. 19:31 ч., David Sterba wrote:
> The write_locks is either 0 or 1 and always updated under the lock,
> so we don't need the atomic_t semantics.
>
> Signed-off-by: David Sterba
Generally looks good, though my remark for patch2 remains.
Reviewed-by: Nikolay Bori
401 - 500 of 2813 matches
Mail list logo
