Hi Josef,
This commit added the following code in find_free_extent:
ret = do_chunk_alloc(trans, root, flags,
CHUNK_ALLOC_FORCE);
+
+ /*
+* If we can't allocate a new chunk we've alrea
On Wed, Mar 6, 2019 at 10:15 PM Josef Bacik wrote:
>
> When Filipe added the recursive directory logging stuff he specifically
> didn't take the directory i_mutex for the children directories that we
> need to log because of lockdep. This is generally fine, but can lead to
> this WARN_ON() trippi
btrfs_num_copies really only needs to be called once, so move it out of
the verification loop in read_tree_block().
Signed-off-by: Qu Wenruo
---
disk-io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/disk-io.c b/disk-io.c
index 369592eb7b5c..1736d4a1f94b 100644
--- a/disk-
[BUG]
If the first copy of a tree block is corrupted but the other copy is
good, btrfs-progs will report the error twice:
checksum verify failed on 30556160 found 42A2DA71 wanted
checksum verify failed on 30556160 found 42A2DA71 wanted
While kernel only report it once, just a
Signed-off-by: Qu Wenruo
---
check/main.c| 12 ++--
check/mode-lowmem.c | 8
ctree.c | 32
ctree.h | 8
4 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/check/main.c b/check/main.c
index 7
[BUG]
If the first copy of a tree block has a bad key order, but the second
copy is completely good, then "btrfs ins dump-tree -b " fails to
print anything past the bad key:
leaf 29786112 items 47 free space 983 generation 20 owner EXTENT_TREE
leaf 29786112 flags 0x1(WRITTEN) backref revision 1
On Wed, Mar 06, 2019 at 02:19:04PM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/perf_tree_lock
> Which is based on v5.0-rc7 tag.
>
> Although we have ftrace/perf to do various performance analyse, under most
> case the granularity i
On 2019/3/7 下午10:02, David Sterba wrote:
> On Wed, Mar 06, 2019 at 02:19:04PM +0800, Qu Wenruo wrote:
>> This patchset can be fetched from github:
>> https://github.com/adam900710/linux/tree/perf_tree_lock
>> Which is based on v5.0-rc7 tag.
>>
>> Although we have ftrace/perf to do various perform
As readahead is an optimization, all errors are usually filtered out,
but still properly handled when the real read call is done. The commit
5e9d398240b2 added REQ_RAHEAD to readpages() because that's only used
for readahead (despite what one would expect from the callback name).
This causes a flo
On Wed, Mar 06, 2019 at 05:13:04PM -0500, Josef Bacik wrote:
> When Filipe added the recursive directory logging stuff he specifically
> didn't take the directory i_mutex for the children directories that we
> need to log because of lockdep. This is generally fine, but can lead to
> this WARN_ON()
On Thu, Mar 07, 2019 at 10:18:49PM +0800, Qu Wenruo wrote:
> > Well, most of that is answered by 'figure out how to use tracepoints and
> > perf for that'.
> >
> > If there were not a whole substystem, actively maintained and
> > documented, implementing something like that might help, but that's
Since commit c40a3d38aff4 ("Btrfs: Compute and look up csums based on
sectorsized blocks") we do a kmap_atomic() on the contents of a bvec.
kmap_atomic() in turn does a preempt_disable() and pagefault_disable(),
so we shouldn't map the data for too long. Reduce the time the bvec's
page is mapped t
On Fri, Mar 01, 2019 at 10:47:57AM +0800, Qu Wenruo wrote:
> - Allow NULL fs_info for TP_fast_assign_fsid()
> There is extent bits operation in selftest which is too deep to pass
> fs_info. And since it's in selftest, it shouldn't trigger trace
> events.
> But to be safe, we still need to c
When building with -Wsometimes-uninitialized, Clang warns:
fs/btrfs/uuid-tree.c:129:13: warning: variable 'eb' is used uninitialized
whenever 'if' condition is false [-Wsometimes-uninitialized]
fs/btrfs/uuid-tree.c:129:13: warning: variable 'offset' is used uninitialized
whenever 'if' condition
On Fri, Mar 01, 2019 at 10:47:59AM +0800, Qu Wenruo wrote:
> +enum {
> + IO_TREE_FS_INFO_FREED_EXTENTS0,
> + IO_TREE_FS_INFO_FREED_EXTENTS1,
> + IO_TREE_INODE_IO_TREE,
> + IO_TREE_INODE_IO_FAILURE_TREE,
> + IO_TREE_RELOC_BLOCKS,
> + IO_TREE_TRANSACTION_DIRTY_PAGES,
> + I
On Fri, Mar 01, 2019 at 10:48:00AM +0800, Qu Wenruo wrote:
> +#define show_extent_io_tree_owner(owner) \
> + __print_symbolic(owner, \
> + { IO_TREE_FS_INFO_FREED_EXTENTS0, "FREED_EXTENTS0" }, \
On Thu, Mar 07, 2019 at 05:14:00PM +0100, Johannes Thumshirn wrote:
> Since commit c40a3d38aff4 ("Btrfs: Compute and look up csums based on
> sectorsized blocks") we do a kmap_atomic() on the contents of a bvec.
>
> kmap_atomic() in turn does a preempt_disable() and pagefault_disable(),
> so we sh
The pull request you sent on Mon, 4 Mar 2019 20:20:53 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
> for-5.1-part1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b1e243957e9b3ba8e820fb8583bdf18e7c737aa2
Thank you!
--
Deet-doot-dot, I
On Thu, Mar 07, 2019 at 09:35:15AM -0700, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, Clang warns:
>
> fs/btrfs/uuid-tree.c:129:13: warning: variable 'eb' is used uninitialized
> whenever 'if' condition is false [-Wsometimes-uninitialized]
> fs/btrfs/uuid-tree.c:129:1
On Thu, Mar 7, 2019 at 9:54 AM David Sterba wrote:
>
> On Thu, Mar 07, 2019 at 09:35:15AM -0700, Nathan Chancellor wrote:
> > When building with -Wsometimes-uninitialized, Clang warns:
> >
> > fs/btrfs/uuid-tree.c:129:13: warning: variable 'eb' is used uninitialized
> > whenever 'if' condition is
On Mon, Mar 04, 2019 at 04:34:39PM +0100, Christoph Anton Mitterer wrote:
> Hey.
>
>
> Thanks for your elaborate explanations :-)
>
>
> On Fri, 2019-02-15 at 00:40 -0500, Zygo Blaxell wrote:
> > The problem occurs only on reads. Data that is written to disk will
> > be OK, and can be read corr
Hi Amir,
> I went back to look at similar fsync tests by Filipe:
> generic/{106,107,335,336,341,342,343,348,498,501,502,509,510,512}
>
> I found some alleged subtle mistakes about SOMC assumptions.
>
> generic/336 does:
> touch $SCRATCH_MNT/a/foo
> ln $SCRATCH_MNT/a/foo $SCRATCH_MNT/b/foo_link
> t
On 2019/3/8 上午12:32, David Sterba wrote:
> On Fri, Mar 01, 2019 at 10:47:57AM +0800, Qu Wenruo wrote:
>> - Allow NULL fs_info for TP_fast_assign_fsid()
>> There is extent bits operation in selftest which is too deep to pass
>> fs_info. And since it's in selftest, it shouldn't trigger trace
>>
On Thu, Mar 07, 2019 at 09:52:03AM +0200, Amir Goldstein wrote:
> On Wed, Mar 6, 2019 at 11:48 PM Dave Chinner wrote:
> >
> > On Wed, Mar 06, 2019 at 09:51:23AM +0200, Amir Goldstein wrote:
> > > On Wed, Mar 6, 2019 at 12:33 AM Dave Chinner wrote:
> > > > > So the reason this is working is becaus
On Thu, Mar 07, 2019 at 05:19:51PM -0600, Jayashree Mohan wrote:
> Hi Amir,
>
> > I went back to look at similar fsync tests by Filipe:
> > generic/{106,107,335,336,341,342,343,348,498,501,502,509,510,512}
> >
> > I found some alleged subtle mistakes about SOMC assumptions.
> >
> > generic/336 doe
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 a special crafted image, kernel can cause NULL pointer dereference like:
BUG: unable to handle kernel NULL pointer dereference at 0024
#PF error: [normal kernel read fault]
Oops: [#1] SMP PTI
CPU: 0 PID: 146 Comm: kworker/u2:4 Not tainted 5.0.0-rc8+ #9
Workqueue
[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
This patchset can be fetched from:
https://github.com/adam900710/linux/tree/tree_checker_enhancement
The base branch write_time_tree_checker, the base commit is:
commit cb3ba69132a83d5e87f243dece5db09a022b0be7
(github/write_time_tree_checker, write_time_tree_checker)
Author: Qu Wenruo
Date: Th
29 matches
Mail list logo
