From: Qu Wenruo <wqu@suse.com>
To: Johannes Thumshirn <jth@kernel.org>, linux-btrfs@vger.kernel.org
Cc: Boris Burkov <boris@bur.io>, Christoph Hellwig <hch@lst.de>,
David Sterba <dsterba@suse.com>,
Josef Bacik <josef@toxicpanda.com>,
Johannes Thumshirn <johannes.thumshirn@wdc.com>
Subject: Re: [PATCH v2 0/5] btrfs: use the super_block as bdev holder
Date: Thu, 12 Jun 2025 07:36:37 +0930 [thread overview]
Message-ID: <69982e5e-96d3-4e60-891c-ade4474253cc@suse.com> (raw)
In-Reply-To: <9093e0d6-d33e-4c4b-814f-9134d568f395@suse.com>
在 2025/6/12 07:19, Qu Wenruo 写道:
>
>
> 在 2025/6/11 19:32, Johannes Thumshirn 写道:
>> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>>
>> This is a series I've picked up from Christoph, it changes the
>> block_device's bdev holder from fs_type to the super block.
>>
>> As the re-base was non trivial, I opted to drop Boris' Reviewed-by tags.
>>
>> Here's the original cover letter:
>> Hi all,
>>
>> this series contains the btrfs parts of the "remove get_super" from June
>> that managed to get lost.
>>
>> I've dropped all the reviews from back then as the rebase against the new
>> mount API conversion led to a lot of non-trivial conflicts.
>>
>> Josef kindly ran it through the CI farm and provided a fixup based on
>> that.
>
> Unfortunately it crashed immediately on btrfs/001:
>
> [ 23.878153] BTRFS info (device dm-0): using free-space-tree
> [ 23.891318] BUG: kernel NULL pointer dereference, address:
> 00000000000006f0
> [ 23.894047] #PF: supervisor read access in kernel mode
> [ 23.896010] #PF: error_code(0x0000) - not-present page
> [ 23.897982] PGD 0 P4D 0
> [ 23.899016] Oops: Oops: 0000 [#1] SMP NOPTI
> [ 23.900738] CPU: 9 UID: 0 PID: 768 Comm: mount Not tainted 6.16.0-
> rc1-custom+ #253 PREEMPT(full)
> [ 23.904288] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> unknown 02/02/2022
> [ 23.907696] RIP: 0010:btrfs_get_tree+0x29c/0x670 [btrfs]
This is at the line "if (fs_info->fs_devices)", so at this stage fs_info
is NULL already.
And it's again back to the original comment on the 2nd patch, why we
need to close the devices at btrfs_reconfigure_for_mount().
Thanks,
Qu
> [ 23.910090] Code: 89 83 50 02 00 00 e9 b0 fe ff ff 48 c7 c7 a0 4c 6f
> a0 48 89 04 24 e8 63 6d 67 e1 8b 2c 24 e9 e9 fe ff ff 49 8b ae 80 00 00
> 00 <48> 8b bd f0 06 00 00 48 85 ff 74 10 e8 03 c6 05 00 48 c7 85 f0 06
> [ 23.917698] RSP: 0018:ffffc90002663e00 EFLAGS: 00010246
> [ 23.919769] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
> 0000000000000000
> [ 23.922817] RDX: 7fffffffffffffff RSI: 0000000000000000 RDI:
> ffffffff835d9d80
> [ 23.925869] RBP: 0000000000000000 R08: 0000000000000005 R09:
> ffff888101ba6000
> [ 23.928916] R10: 00000000000000c8 R11: ffff88810a8fe280 R12:
> ffff888109932d80
> [ 23.932083] R13: ffff8881061ef640 R14: ffff888104dab840 R15:
> ffff888109932d80
> [ 23.935160] FS: 00007f9aa721ab80(0000) GS:ffff8882f4762000(0000)
> knlGS:0000000000000000
> [ 23.938582] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 23.941060] CR2: 00000000000006f0 CR3: 0000000128bc2000 CR4:
> 00000000000006f0
> [ 23.944122] Call Trace:
> [ 23.945228] <TASK>
> [ 23.946189] ? fscontext_read+0x118/0x130
> [ 23.947947] vfs_get_tree+0x29/0xd0
> [ 23.949507] vfs_cmd_create+0x57/0xd0
> [ 23.951131] __do_sys_fsconfig+0x4b6/0x650
> [ 23.952891] do_syscall_64+0x54/0x1d0
> [ 23.954522] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 23.956703] RIP: 0033:0x7f9aa736fefe
> [ 23.958313] Code: 73 01 c3 48 8b 0d 12 be 0c 00 f7 d8 64 89 01 48 83
> c8 ff c3 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 49 89 ca b8 af 01 00 00 0f
> 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e2 bd 0c 00 f7 d8 64 89 01 48
> [ 23.966225] RSP: 002b:00007ffe79405e18 EFLAGS: 00000246 ORIG_RAX:
> 00000000000001af
> [ 23.969431] RAX: ffffffffffffffda RBX: 000055f970791430 RCX:
> 00007f9aa736fefe
> [ 23.972466] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
> 0000000000000003
> [ 23.975485] RBP: 00007ffe79405e50 R08: 0000000000000000 R09:
> 0000000000000000
> [ 23.978527] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00007f9aa7499980
> [ 23.981535] R13: 0000000000000000 R14: 000055f970792720 R15:
> 00007f9aa748e8e0
> [ 23.984548] </TASK>
> [ 23.985537] Modules linked in: crc32c_cryptoapi vfat fat btrfs
> blake2b_generic xor zstd_compress iTCO_wdt iTCO_vendor_support psmouse
> pcspkr lpc_ich i2c_i801 i2c_smbus joydev intel_agp intel_gtt mousedev
> agpgart raid6_pq drm fuse loop qemu_fw_cfg ext4 crc16 mbcache jbd2
> dm_mod virtio_net net_failover virtio_rng failover virtio_balloon
> virtio_console virtio_blk rng_core virtio_scsi virtio_pci serio_raw
> usbhid virtio_pci_legacy_dev virtio_pci_modern_dev
> [ 24.002094] Dumping ftrace buffer:
> [ 24.003601] (ftrace buffer empty)
> [ 24.005188] CR2: 00000000000006f0
> [ 24.006735] ---[ end trace 0000000000000000 ]---
> [ 25.685915] RIP: 0010:btrfs_get_tree+0x29c/0x670 [btrfs]
> [ 25.688118] Code: 89 83 50 02 00 00 e9 b0 fe ff ff 48 c7 c7 a0 4c 6f
> a0 48 89 04 24 e8 63 6d 67 e1 8b 2c 24 e9 e9 fe ff ff 49 8b ae 80 00 00
> 00 <48> 8b bd f0 06 00 00 48 85 ff 74 10 e8 03 c6 05 00 48 c7 85 f0 06
> [ 25.695103] RSP: 0018:ffffc90002663e00 EFLAGS: 00010246
> [ 25.697125] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
> 0000000000000000
> [ 25.699813] RDX: 7fffffffffffffff RSI: 0000000000000000 RDI:
> ffffffff835d9d80
> [ 25.702464] RBP: 0000000000000000 R08: 0000000000000005 R09:
> ffff888101ba6000
> [ 25.705185] R10: 00000000000000c8 R11: ffff88810a8fe280 R12:
> ffff888109932d80
> [ 25.708000] R13: ffff8881061ef640 R14: ffff888104dab840 R15:
> ffff888109932d80
> [ 25.710720] FS: 00007f9aa721ab80(0000) GS:ffff8882f4762000(0000)
> knlGS:0000000000000000
> [ 25.713772] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 25.716003] CR2: 00000000000006f0 CR3: 0000000128bc2000 CR4:
> 00000000000006f0
> [ 25.718657] Kernel panic - not syncing: Fatal exception
> [ 25.721077] Dumping ftrace buffer:
> [ 25.722398] (ftrace buffer empty)
> [ 25.723775] Kernel Offset: disabled
> [ 27.228888] Rebooting in 5 seconds..>
>>
>>
>> Link to rebase v1:
>> https://lore.kernel.org/linux-btrfs/20240214-hch-device-open-v1-0-
>> b153428b4f72@wdc.com/
>>
>> Link to original posting:
>> https://lore.kernel.org/linux-btrfs/
>> b083ae24-2273-479f-8c9e-96cb9ef083b8@wdc.com/
>>
>> Christoph Hellwig (5):
>> btrfs: always open the device read-only in btrfs_scan_one_device
>> btrfs: call btrfs_close_devices from ->kill_sb
>> btrfs: split btrfs_fs_devices.opened
>> btrfs: open block devices after superblock creation
>> btrfs: use the super_block as holder when mounting file systems
>>
>> fs/btrfs/disk-io.c | 4 +--
>> fs/btrfs/super.c | 70 +++++++++++++++++++++++++++-------------------
>> fs/btrfs/volumes.c | 62 ++++++++++++++++++++--------------------
>> fs/btrfs/volumes.h | 8 ++++--
>> 4 files changed, 80 insertions(+), 64 deletions(-)
>>
>
>
next prev parent reply other threads:[~2025-06-11 22:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-11 10:02 [PATCH v2 0/5] btrfs: use the super_block as bdev holder Johannes Thumshirn
2025-06-11 10:02 ` [PATCH v2 1/5] btrfs: always open the device read-only in btrfs_scan_one_device Johannes Thumshirn
2025-06-11 21:28 ` Qu Wenruo
2025-06-11 10:03 ` [PATCH v2 2/5] btrfs: call btrfs_close_devices from ->kill_sb Johannes Thumshirn
2025-06-11 21:37 ` Qu Wenruo
2025-06-11 10:03 ` [PATCH v2 3/5] btrfs: split btrfs_fs_devices.opened Johannes Thumshirn
2025-06-11 21:44 ` Qu Wenruo
2025-06-16 10:26 ` Qu Wenruo
2025-06-16 22:37 ` Qu Wenruo
2025-06-11 10:03 ` [PATCH v2 4/5] btrfs: open block devices after superblock creation Johannes Thumshirn
2025-06-11 10:03 ` [PATCH v2 5/5] btrfs: use the super_block as holder when mounting file systems Johannes Thumshirn
2025-06-11 21:49 ` [PATCH v2 0/5] btrfs: use the super_block as bdev holder Qu Wenruo
2025-06-11 22:06 ` Qu Wenruo [this message]
2025-06-12 12:15 ` Johannes Thumshirn
2025-06-12 22:21 ` Qu Wenruo
2025-06-13 5:59 ` hch
2025-06-13 8:01 ` Qu Wenruo
2025-06-13 8:14 ` Johannes Thumshirn
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=69982e5e-96d3-4e60-891c-ade4474253cc@suse.com \
--to=wqu@suse.com \
--cc=boris@bur.io \
--cc=dsterba@suse.com \
--cc=hch@lst.de \
--cc=johannes.thumshirn@wdc.com \
--cc=josef@toxicpanda.com \
--cc=jth@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox