public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
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(-)
>>
> 
> 


  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