From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [Patch v2 41/42] btrfs: fix the use-after-free bug in writeback subpage helper
Date: Fri, 14 May 2021 03:06:56 +0530 [thread overview]
Message-ID: <20210513213656.2poyhssr4wzq65s4@riteshh-domain> (raw)
In-Reply-To: <20210513163316.ypvh3ppsrmxg7dit@riteshh-domain>
On 21/05/13 10:03PM, Ritesh Harjani wrote:
> On 21/05/12 12:39PM, Ritesh Harjani wrote:
> > On 21/05/12 09:49AM, Qu Wenruo wrote:
> > > Hi Ritesh,
> > >
> > > The patchset gets updated, and I am already running the tests, so far so
> > > good.
> > Sure, I have started the testing. Will update the results for both
> > 4k, 64k configs with "-g quick", "-g auto" options on PPC64.
>
> Hi Qu,
>
> I completed the testing of "4k" and "64k" configs with "-g quick" and "-g auto"
> groups on ppc64 machine. There were no crashes nor any related failures with
> your latest patch series. Also thanks a lot for getting this patch series ready
> and fixing all the reported failures :)
>
> Let me also know if you would like to me to test anything else too, will be
> happy to help. Feel free below tag for your full patch series:-
>
> Tested-by: Ritesh Harjani <riteshh@linux.ibm.com> [ppc64]
>
>
>
> FYI, I found this below lockdep warning from btrfs/112 with 64k config.
> This may not be related to your patch series though. But I thought I will report
> it to here anyways.
Hi Qu,
Please ignore below error. I could reproduce below on v5.13-rc1 too w/o your
patches, so this is not at all realted to bs < ps patch series. Will report this
seperately on mailing list.
-ritesh
>
> [ 756.021743] run fstests btrfs/112 at 2021-05-13 03:27:39
> [ 756.554974] BTRFS info (device vdd): disk space caching is enabled
> [ 756.555223] BTRFS info (device vdd): has skinny extents
> [ 757.062425] BTRFS: device fsid 453f3a16-65f2-4406-b666-1cb096966ad5 devid 1 transid 5 /dev/vdc scanned by mkfs.btrfs (29656)
> [ 757.111042] BTRFS info (device vdc): disk space caching is enabled
> [ 757.111309] BTRFS info (device vdc): has skinny extents
> [ 757.121898] BTRFS info (device vdc): checking UUID tree
>
> [ 757.373434] ======================================================
> [ 757.373557] WARNING: possible circular locking dependency detected
> [ 757.373670] 5.12.0-rc8-00161-g71a7ca634d59 #26 Not tainted
> [ 757.373751] ------------------------------------------------------
> [ 757.373851] cloner/29747 is trying to acquire lock:
> [ 757.373931] c00000002de71638 (sb_internal#2){.+.+}-{0:0}, at: clone_copy_inline_extent+0xe4/0x5a0
> [ 757.374130]
> but task is already holding lock:
> [ 757.374232] c000000036abc620 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x70/0x1d0
> [ 757.374389]
> which lock already depends on the new lock.
>
> [ 757.374507]
> the existing dependency chain (in reverse order) is:
> [ 757.374627]
> -> #1 (btrfs-tree-00){++++}-{3:3}:
> [ 757.374735] down_read_nested+0x68/0x200
> [ 757.374827] __btrfs_tree_read_lock+0x70/0x1d0
> [ 757.374908] btrfs_read_lock_root_node+0x88/0x200
> [ 757.374988] btrfs_search_slot+0x298/0xb70
> [ 757.375078] btrfs_set_inode_index+0xfc/0x260
> [ 757.375156] btrfs_new_inode+0x26c/0x950
> [ 757.375243] btrfs_create+0xf4/0x2b0
> [ 757.375303] lookup_open.isra.56+0x56c/0x690
> [ 757.375393] path_openat+0x418/0xd20
> [ 757.375455] do_filp_open+0x9c/0x130
> [ 757.375518] do_sys_openat2+0x2ec/0x430
> [ 757.375596] do_sys_open+0x90/0xc0
> [ 757.375657] system_call_exception+0x384/0x3d0
> [ 757.375750] system_call_common+0xec/0x278
> [ 757.375832]
> -> #0 (sb_internal#2){.+.+}-{0:0}:
> [ 757.375936] __lock_acquire+0x1e80/0x2c40
> [ 757.376017] lock_acquire+0x2b4/0x5b0
> [ 757.376078] start_transaction+0x3cc/0x950
> [ 757.376158] clone_copy_inline_extent+0xe4/0x5a0
> [ 757.376239] btrfs_clone+0x5fc/0x880
> [ 757.376299] btrfs_clone_files+0xd8/0x1c0
> [ 757.376376] btrfs_remap_file_range+0x3d8/0x590
> [ 757.376455] do_clone_file_range+0x10c/0x270
> [ 757.376542] vfs_clone_file_range+0x1b0/0x310
> [ 757.376621] ioctl_file_clone+0x90/0x130
> [ 757.376700] do_vfs_ioctl+0x984/0x1630
> [ 757.376781] sys_ioctl+0x6c/0x120
> [ 757.376843] system_call_exception+0x384/0x3d0
> [ 757.376924] system_call_common+0xec/0x278
> [ 757.377003]
> other info that might help us debug this:
>
> [ 757.377119] Possible unsafe locking scenario:
>
> [ 757.377216] CPU0 CPU1
> [ 757.377295] ---- ----
> [ 757.377372] lock(btrfs-tree-00);
> [ 757.377432] lock(sb_internal#2);
> [ 757.377530] lock(btrfs-tree-00);
> [ 757.377627] lock(sb_internal#2);
> [ 757.377689]
> *** DEADLOCK ***
>
> [ 757.377783] 6 locks held by cloner/29747:
> [ 757.377843] #0: c00000002de71448 (sb_writers#12){.+.+}-{0:0}, at: ioctl_file_clone+0x90/0x130
> [ 757.377990] #1: c000000010b87ce8 (&sb->s_type->i_mutex_key#15){++++}-{3:3}, at: lock_two_nondirectories+0x58/0xc0
> [ 757.378155] #2: c000000010b8d610 (&sb->s_type->i_mutex_key#15/4){+.+.}-{3:3}, at: lock_two_nondirectories+0x9c/0xc0
> [ 757.378322] #3: c000000010b8d4a0 (&ei->i_mmap_lock){++++}-{3:3}, at: btrfs_remap_file_range+0xd0/0x590
> [ 757.378463] #4: c000000010b87b78 (&ei->i_mmap_lock/1){+.+.}-{3:3}, at: btrfs_remap_file_range+0xe0/0x590
> [ 757.378605] #5: c000000036abc620 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x70/0x1d0
> [ 757.378745]
> stack backtrace:
> [ 757.378823] CPU: 0 PID: 29747 Comm: cloner Not tainted 5.12.0-rc8-00161-g71a7ca634d59 #26
> [ 757.378972] Call Trace:
> [ 757.379013] [c00000002de07200] [c000000000c12ea8] dump_stack+0xec/0x144 (unreliable)
> [ 757.379135] [c00000002de07240] [c0000000002775d8] print_circular_bug.isra.32+0x3a8/0x400
> [ 757.379269] [c00000002de072e0] [c000000000277774] check_noncircular+0x144/0x190
> [ 757.379389] [c00000002de073b0] [c00000000027c500] __lock_acquire+0x1e80/0x2c40
> [ 757.379509] [c00000002de074f0] [c00000000027dfd4] lock_acquire+0x2b4/0x5b0
> [ 757.379609] [c00000002de075e0] [c000000000a063cc] start_transaction+0x3cc/0x950
> [ 757.379726] [c00000002de07690] [c000000000aede64] clone_copy_inline_extent+0xe4/0x5a0
> [ 757.379842] [c00000002de077c0] [c000000000aee91c] btrfs_clone+0x5fc/0x880
> [ 757.379940] [c00000002de07990] [c000000000aeed58] btrfs_clone_files+0xd8/0x1c0
> [ 757.380056] [c00000002de07a00] [c000000000aef218] btrfs_remap_file_range+0x3d8/0x590
> [ 757.380172] [c00000002de07ae0] [c0000000005d481c] do_clone_file_range+0x10c/0x270
> [ 757.380289] [c00000002de07b40] [c0000000005d4b30] vfs_clone_file_range+0x1b0/0x310
> [ 757.380405] [c00000002de07bb0] [c000000000588a10] ioctl_file_clone+0x90/0x130
> [ 757.380523] [c00000002de07c10] [c000000000589434] do_vfs_ioctl+0x984/0x1630
> [ 757.380621] [c00000002de07d10] [c00000000058a14c] sys_ioctl+0x6c/0x120
> [ 757.380719] [c00000002de07d60] [c000000000039e64] system_call_exception+0x384/0x3d0
> [ 757.380836] [c00000002de07e10] [c00000000000d45c] system_call_common+0xec/0x278
> [ 757.380953] --- interrupt: c00 at 0x7ffff7e32990
> [ 757.381042] NIP: 00007ffff7e32990 LR: 00000001000010ec CTR: 0000000000000000
> [ 757.381157] REGS: c00000002de07e80 TRAP: 0c00 Not tainted (5.12.0-rc8-00161-g71a7ca634d59)
> [ 757.381289] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 28000244 XER: 00000000
> [ 757.381445] IRQMASK: 0
> GPR00: 0000000000000036 00007fffffffdec0 00007ffff7f27100 0000000000000004
> GPR04: 000000008020940d 00007fffffffdf40 0000000000000000 0000000000000000
> GPR08: 0000000000000004 0000000000000000 0000000000000000 0000000000000000
> GPR12: 0000000000000000 00007ffff7ffa940 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 000000009123683e 00007fffffffdf40 0000000000000000
> GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000004
> GPR28: 0000000100030260 0000000100030280 0000000000000003 000000000000005f
> [ 757.382382] NIP [00007ffff7e32990] 0x7ffff7e32990
> [ 757.382460] LR [00000001000010ec] 0x1000010ec
> [ 757.382537] --- interrupt: c00
> [ 757.787411] BTRFS: device fsid fd5f535c-f163-4a14-b9a5-c423b470fdd7 devid 1 transid 5 /dev/vdc scanned by mkfs.btrfs (29753)
> [ 757.829757] BTRFS info (device vdc): use zlib compression, level 3
> [ 757.829948] BTRFS info (device vdc): disk space caching is enabled
> [ 757.830051] BTRFS info (device vdc): has skinny extents
> [ 757.837338] BTRFS info (device vdc): checking UUID tree
> [ 758.421670] BTRFS: device fsid e2a0fa31-ad7e-47b9-879c-309e8e2b3583 devid 1 transid 5 /dev/vdc scanned by mkfs.btrfs (29850)
> [ 758.456197] BTRFS info (device vdc): disk space caching is enabled
> [ 758.456306] BTRFS info (device vdc): has skinny extents
> [ 758.502055] BTRFS info (device vdc): checking UUID tree
> [ 759.067243] BTRFS: device fsid b66a7909-8293-4467-9ec7-217007bc1023 devid 1 transid 5 /dev/vdc scanned by mkfs.btrfs (29947)
> [ 759.099884] BTRFS info (device vdc): use zlib compression, level 3
> [ 759.100112] BTRFS info (device vdc): disk space caching is enabled
> [ 759.100222] BTRFS info (device vdc): has skinny extents
> [ 759.108120] BTRFS info (device vdc): checking UUID tree
>
>
>
> -ritesh
>
> >
> > >
> > > The new head is:
> > > commit cb81da05e7899b8196c3c5e0b122798da3b94af0
> > > Author: Qu Wenruo <wqu@suse.com>
> > > Date: Mon May 3 08:19:27 2021 +0800
> > >
> > > btrfs: remove io_failure_record::in_validation
> > >
> > > I may have some minor change the to commit messages and comments
> > > preparing for the next submit, but the code shouldn't change any more.
> > >
> > >
> > > Just one note, thanks to your report on btrfs/028, I even find a data
> > > corruption bug in relocation code.
> > Nice :)
> >
> > > Kudos (and of-course Reported-by tags) to you!
> > Thanks!
> >
> > >
> > > New changes since v2 patchset:
> > >
> > > - Fix metadata read path ASSERT() when last eb is already dereferred
> > > - Fix read repair related bugs
> > > * fix possible hang due to unreleased sectors after read error
> > > * fix double accounting in btrfs_subpage::readers
> > >
> > > - Fix false alert when relocating data extent without csum
> > > This is really a false alert, the expected csum is always 0x00
> > >
> > > - Fix a data corruption when relocating certain data extents layout
> > > This is a real corruption, both relocation and scrub will report
> > > error.
> > Thanks for the detailed info.
> >
> > >
> > > Thanks and happy testing!
> > Thanks for the quick replies and all your work in supporting bs < ps.
> > This is definitely very useful for Power platform too!!
> >
> > -ritesh
next prev parent reply other threads:[~2021-05-13 21:37 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 23:03 [Patch v2 00/42] btrfs: add data write support for subpage Qu Wenruo
2021-04-27 23:03 ` [Patch v2 01/42] btrfs: scrub: fix subpage scrub repair error caused by hardcoded PAGE_SIZE Qu Wenruo
2021-05-13 22:57 ` David Sterba
2021-05-13 23:32 ` Qu Wenruo
2021-04-27 23:03 ` [Patch v2 02/42] btrfs: make free space cache size consistent across different PAGE_SIZE Qu Wenruo
2021-04-27 23:03 ` [Patch v2 03/42] btrfs: remove the unused parameter @len for btrfs_bio_fits_in_stripe() Qu Wenruo
2021-05-13 22:58 ` David Sterba
2021-05-13 23:07 ` David Sterba
2021-04-27 23:03 ` [Patch v2 04/42] btrfs: allow btrfs_bio_fits_in_stripe() to accept bio without any page Qu Wenruo
2021-04-27 23:03 ` [Patch v2 05/42] btrfs: refactor submit_extent_page() to make bio and its flag tracing easier Qu Wenruo
2021-05-13 23:03 ` David Sterba
2021-05-21 11:06 ` Johannes Thumshirn
2021-05-21 11:26 ` Qu Wenruo
2021-05-21 13:30 ` David Sterba
2021-04-27 23:03 ` [Patch v2 06/42] btrfs: make subpage metadata write path to call its own endio functions Qu Wenruo
2021-04-27 23:03 ` [Patch v2 07/42] btrfs: pass btrfs_inode into btrfs_writepage_endio_finish_ordered() Qu Wenruo
2021-05-13 23:06 ` David Sterba
2021-05-13 23:35 ` Qu Wenruo
2021-05-21 14:27 ` Josef Bacik
2021-05-21 20:22 ` David Sterba
2021-05-22 0:24 ` Qu Wenruo
2021-05-23 7:40 ` Qu Wenruo
2021-05-23 13:43 ` Josef Bacik
2021-05-23 13:50 ` Qu Wenruo
2021-05-23 14:08 ` Josef Bacik
2021-04-27 23:03 ` [Patch v2 08/42] btrfs: make Private2 lifespan more consistent Qu Wenruo
2021-04-27 23:03 ` [Patch v2 09/42] btrfs: refactor how we finish ordered extent io for endio functions Qu Wenruo
2021-05-13 23:11 ` David Sterba
2021-04-27 23:03 ` [Patch v2 10/42] btrfs: update the comments in btrfs_invalidatepage() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 11/42] btrfs: introduce btrfs_lookup_first_ordered_range() Qu Wenruo
2021-05-13 23:13 ` David Sterba
2021-04-27 23:03 ` [Patch v2 12/42] btrfs: refactor btrfs_invalidatepage() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 13/42] btrfs: rename PagePrivate2 to PageOrdered inside btrfs Qu Wenruo
2021-04-27 23:03 ` [Patch v2 14/42] btrfs: pass bytenr directly to __process_pages_contig() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 15/42] btrfs: refactor the page status update into process_one_page() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 16/42] btrfs: provide btrfs_page_clamp_*() helpers Qu Wenruo
2021-04-27 23:03 ` [Patch v2 17/42] btrfs: only require sector size alignment for end_bio_extent_writepage() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 18/42] btrfs: make btrfs_dirty_pages() to be subpage compatible Qu Wenruo
2021-04-27 23:03 ` [Patch v2 19/42] btrfs: make __process_pages_contig() to handle subpage dirty/error/writeback status Qu Wenruo
2021-04-27 23:03 ` [Patch v2 20/42] btrfs: make end_bio_extent_writepage() to be subpage compatible Qu Wenruo
2021-04-27 23:03 ` [Patch v2 21/42] btrfs: make process_one_page() to handle subpage locking Qu Wenruo
2021-04-27 23:03 ` [Patch v2 22/42] btrfs: introduce helpers for subpage ordered status Qu Wenruo
2021-04-27 23:03 ` [Patch v2 23/42] btrfs: make page Ordered bit to be subpage compatible Qu Wenruo
2021-04-27 23:03 ` [Patch v2 24/42] btrfs: update locked page dirty/writeback/error bits in __process_pages_contig Qu Wenruo
2021-04-27 23:03 ` [Patch v2 25/42] btrfs: prevent extent_clear_unlock_delalloc() to unlock page not locked by __process_pages_contig() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 26/42] btrfs: make btrfs_set_range_writeback() subpage compatible Qu Wenruo
2021-04-27 23:03 ` [Patch v2 27/42] btrfs: make __extent_writepage_io() only submit dirty range for subpage Qu Wenruo
2021-04-27 23:03 ` [Patch v2 28/42] btrfs: make btrfs_truncate_block() to be subpage compatible Qu Wenruo
2021-04-27 23:03 ` [Patch v2 29/42] btrfs: make btrfs_page_mkwrite() " Qu Wenruo
2021-04-27 23:03 ` [Patch v2 30/42] btrfs: reflink: make copy_inline_to_page() " Qu Wenruo
2021-04-27 23:03 ` [Patch v2 31/42] btrfs: fix the filemap_range_has_page() call in btrfs_punch_hole_lock_range() Qu Wenruo
2021-04-27 23:03 ` [Patch v2 32/42] btrfs: don't clear page extent mapped if we're not invalidating the full page Qu Wenruo
2021-04-27 23:03 ` [Patch v2 33/42] btrfs: extract relocation page read and dirty part into its own function Qu Wenruo
2021-04-27 23:03 ` [Patch v2 34/42] btrfs: make relocate_one_page() to handle subpage case Qu Wenruo
2021-04-27 23:03 ` [Patch v2 35/42] btrfs: fix wild subpage writeback which does not have ordered extent Qu Wenruo
2021-04-27 23:03 ` [Patch v2 36/42] btrfs: disable inline extent creation for subpage Qu Wenruo
2021-05-04 4:28 ` Qu Wenruo
2021-04-27 23:03 ` [Patch v2 37/42] btrfs: skip validation for subpage read repair Qu Wenruo
2021-04-27 23:03 ` [Patch v2 38/42] btrfs: allow submit_extent_page() to do bio split for subpage Qu Wenruo
2021-04-27 23:03 ` [Patch v2 39/42] btrfs: reject raid5/6 fs " Qu Wenruo
2021-04-28 14:22 ` Neal Gompa
2021-04-28 23:11 ` Qu Wenruo
2021-05-12 22:04 ` David Sterba
2021-04-27 23:03 ` [Patch v2 40/42] btrfs: fix a crash caused by race between prepare_pages() and btrfs_releasepage() Qu Wenruo
2021-04-28 10:56 ` Filipe Manana
2021-04-27 23:03 ` [Patch v2 41/42] btrfs: fix the use-after-free bug in writeback subpage helper Qu Wenruo
2021-05-06 23:46 ` Qu Wenruo
2021-05-07 4:57 ` Ritesh Harjani
2021-05-07 5:14 ` Qu Wenruo
2021-05-10 8:38 ` Qu Wenruo
2021-05-10 12:29 ` Ritesh Harjani
2021-05-10 13:10 ` Qu Wenruo
2021-05-11 10:48 ` Ritesh Harjani
2021-05-11 11:15 ` Qu Wenruo
2021-05-12 1:49 ` Qu Wenruo
2021-05-12 7:09 ` Ritesh Harjani
2021-05-13 16:33 ` Ritesh Harjani
2021-05-13 21:36 ` Ritesh Harjani [this message]
2021-05-13 23:41 ` Qu Wenruo
2021-05-14 15:08 ` Ritesh Harjani
2021-05-14 17:53 ` Ritesh Harjani
2021-05-14 22:22 ` Qu Wenruo
2021-05-15 9:59 ` Ritesh Harjani
2021-05-15 10:15 ` Qu Wenruo
2021-05-25 4:43 ` Ritesh Harjani
2021-05-25 5:52 ` Qu Wenruo
2021-05-25 6:14 ` Qu Wenruo
2021-05-25 9:23 ` Ritesh Harjani
2021-05-25 9:45 ` Qu Wenruo
2021-05-25 9:49 ` Qu Wenruo
2021-05-25 10:20 ` Ritesh Harjani
2021-05-25 11:41 ` Qu Wenruo
2021-05-25 13:02 ` Ritesh Harjani
2021-05-26 5:29 ` Ritesh Harjani
2021-05-26 5:58 ` Qu Wenruo
2021-05-26 13:45 ` Ritesh Harjani
2021-05-28 8:26 ` Qu Wenruo
2021-05-28 8:59 ` Ritesh Harjani
2021-05-28 10:25 ` Qu Wenruo
2021-05-30 1:50 ` Qu Wenruo
2021-04-27 23:03 ` [Patch v2 42/42] btrfs: allow read-write for 4K sectorsize on 64K page size systems Qu Wenruo
2021-05-12 22:18 ` [Patch v2 00/42] btrfs: add data write support for subpage David Sterba
2021-05-12 23:48 ` Qu Wenruo
2021-05-13 2:21 ` Qu Wenruo
2021-05-13 22:54 ` David Sterba
2021-05-14 1:41 ` Qu Wenruo
2021-05-14 2:26 ` riteshh
2021-05-14 10:28 ` riteshh
2021-05-14 11:28 ` David Sterba
2021-05-14 14:38 ` riteshh
2021-05-14 11:30 ` David Sterba
2021-05-14 22:25 ` David Sterba
2021-05-14 22:45 ` Qu Wenruo
2021-05-14 23:05 ` David Sterba
2021-05-14 23:17 ` Qu Wenruo
2021-05-17 13:22 ` David Sterba
2021-05-17 23:20 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210513213656.2poyhssr4wzq65s4@riteshh-domain \
--to=riteshh@linux.ibm.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.