Re: [PATCH] Btrfs: add a check of whether fs_info->fs_root is NULL in btrfs_async_reclaim_metadata_space()
On 2015/10/21 20:27, David Sterba wrote: On Wed, Oct 21, 2015 at 04:20:00PM +0900, Tsutomu Itoh wrote: Kernel panic occurred due to NULL pointer reference in can_overcommit(). Because btrfs_async_reclaim_metadata_space() passed NULL pointer to btrfs_calc_reclaim_metadata_size(). fs_info->fs_root is referred in btrfs_async_reclaim_metadata_space() when mount kicked kworker(btrfs_async_reclaim_metadata_space). But at this time, fs_info->fs_root had not been initialized yet, so NULL pointer passed to btrfs_calc_reclaim_metadata_size(). I don't think it's the right fix, the initialization sequence should take care of such situations. The fs_tree must exist at the time we reach the point where it crashed, the code expects it. OK. I will try to change initialization sequence. Thanks, Tsutomu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Btrfs: add a check of whether fs_info->fs_root is NULL in btrfs_async_reclaim_metadata_space()
Kernel panic occurred due to NULL pointer reference in can_overcommit(). Because btrfs_async_reclaim_metadata_space() passed NULL pointer to btrfs_calc_reclaim_metadata_size(). [ 3756.152833] BUG: unable to handle kernel NULL pointer dereference at 01f0 [ 3756.152882] IP: [] can_overcommit+0x21/0xf0 [btrfs] [ 3756.152936] PGD 0 [ 3756.152949] Oops: [#1] SMP [ 3756.152969] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_filter ebtable_broute bridge stp llc ebtable_nat ebtables ip6table_mangle ip6table_raw ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack coretemp kvm_intel kvm crc32 _pclmul iTCO_wdt iTCO_vendor_support microcode ipmi_si lpc_ich mfd_core pcspkr acpi_power_meter ipmi_msghandler i2c_i801 i7core_edac shpchp edac_core nfsd acpi_cpufreq auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel btrfs xor raid6_pq usb_storage mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ata_generic pps_core pata_acpi crc32c_intel [ 3756.153397] dca megaraid_sas i2c_algo_bit ata_piix i2c_core [ 3756.153433] CPU: 3 PID: 3004 Comm: kworker/u25:4 Tainted: G I 4.3.0-rc6 #1 [ 3756.153469] Hardware name: FUJITSU-SV PRIMERGY RX300 S6 /D2619, BIOS 6.00 Rev. 1.09.2619.N1 12/13/2010 [ 3756.153537] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] [ 3756.153571] task: 88023581a400 ti: 880234648000 task.ti: 880234648000 [ 3756.153604] RIP: 0010:[] [] can_overcommit+0x21/0xf0 [btrfs] [ 3756.153655] RSP: 0018:88023464bda8 EFLAGS: 00010282 [ 3756.153679] RAX: 0100 RBX: 880431f68c00 RCX: 0002 [ 3756.153711] RDX: 00c0 RSI: RDI: [ 3756.153742] RBP: 88023464bde0 R08: 0101 R09: 000c [ 3756.153773] R10: 81d10060 R11: 81d10050 R12: 880431f68c00 [ 3756.153804] R13: R14: 880035f67070 R15: 00c0 [ 3756.153836] FS: () GS:880237cc() knlGS: [ 3756.153871] CS: 0010 DS: ES: CR0: 8005003b [ 3756.153897] CR2: 01f0 CR3: 01c08000 CR4: 06e0 [ 3756.153929] Stack: [ 3756.153940] 8802 880237cd2940 880431f68c00 [ 3756.153979] 00c0 880035f67070 88023464be20 [ 3756.154016] a01e5404 880431f68c80 880234482240 8802378a1800 [ 3756.154054] Call Trace: [ 3756.154081] [] btrfs_async_reclaim_metadata_space+0xb4/0x210 [btrfs] [ 3756.154119] [] process_one_work+0x19e/0x3d0 [ 3756.154146] [] worker_thread+0x4e/0x450 [ 3756.154174] [] ? __schedule+0x2b9/0x930 [ 3756.154199] [] ? process_one_work+0x3d0/0x3d0 [ 3756.154227] [] ? process_one_work+0x3d0/0x3d0 [ 3756.154255] [] kthread+0xc9/0xe0 [ 3756.154279] [] ? kthread_worker_fn+0x160/0x160 [ 3756.154307] [] ret_from_fork+0x3f/0x70 [ 3756.154333] [] ? kthread_worker_fn+0x160/0x160 [ 3756.154361] Code: a5 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 f4 53 31 f6 49 89 fd 49 89 d7 48 83 ec 10 <4c> 8b b7 f0 01 00 00 89 4d cc 49 3b 7e 30 40 0f 95 c6 48 8d 74 [ 3756.156802] RIP [] can_overcommit+0x21/0xf0 [btrfs] [ 3756.157995] RSP [ 3756.159162] CR2: 01f0 fs_info->fs_root is referred in btrfs_async_reclaim_metadata_space() when mount kicked kworker(btrfs_async_reclaim_metadata_space). But at this time, fs_info->fs_root had not been initialized yet, so NULL pointer passed to btrfs_calc_reclaim_metadata_size(). PID: 3045 TASK: 8800bb06b000 CPU: 2 COMMAND: "mount" [exception RIP: queued_spin_lock_slowpath+350] RIP: 810be2de RSP: 8800b9fdb738 RFLAGS: 0202 RAX: 0101 RBX: 880431f68c00 RCX: 0001 RDX: 0101 RSI: 0001 RDI: 880431f68c00 RBP: 8800b9fdb738 R8: 0101 R9: R10: 4000 R11: 00018e58 R12: 0001 R13: 8800b9fdb7c0 R14: 8800bb06b000 R15: 0001 CS: 0010 SS: 0018 #0 [8800b9fdb740] _raw_spin_lock at 81694ff0 #1 [8800b9fdb750] reserve_metadata_bytes at a01e55cc [btrfs] #2 [8800b9fdb800] btrfs_block_rsv_add at a01e5a93 [btrfs] #3 [8800b9fdb828] btrfs_truncate_inode_items at a0202779 [btrfs] #4 [8800b9fdb920] btrfs_evict_inode at a02040ec [btrfs] #5 [8800b9fdb990] evict at 811ed6ea #6
Re: [PATCH] Btrfs: add a check of whether fs_info->fs_root is NULL in btrfs_async_reclaim_metadata_space()
On Wed, Oct 21, 2015 at 04:20:00PM +0900, Tsutomu Itoh wrote: > Kernel panic occurred due to NULL pointer reference in can_overcommit(). > Because btrfs_async_reclaim_metadata_space() passed NULL pointer to > btrfs_calc_reclaim_metadata_size(). > fs_info->fs_root is referred in btrfs_async_reclaim_metadata_space() > when mount kicked kworker(btrfs_async_reclaim_metadata_space). > > But at this time, fs_info->fs_root had not been initialized yet, > so NULL pointer passed to btrfs_calc_reclaim_metadata_size(). I don't think it's the right fix, the initialization sequence should take care of such situations. The fs_tree must exist at the time we reach the point where it crashed, the code expects it. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
