On Thu, Dec 9, 2021 at 2:40 PM Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > > Hi Murphy, > > Can you please share the kernel config file used for this test? > Is cachefilesd configured on this test setup? > > Regards, > Shyam > > On Wed, Dec 8, 2021 at 2:57 PM Murphy Zhou <jencce.kernel@xxxxxxxxx> wrote: > > > > Hi, > > > > A connectathon test triggers panic like below. The server is a smb > > share on the same server with the test client. > > > > > > [ 594.061343] Key type cifs.spnego registered > > [ 594.082337] Key type cifs.idmap registered > > [ 594.104961] CIFS: No dialect specified on mount. Default has > > changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), > > from CIFS (SMB1). To use the less secure SMB1 dialect to access old > > servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1) specify > > vers=1.0 on mount. > > [ 594.223460] CIFS: Attempting to mount \\hp-dl380pg8\testuser > > [ 594.287771] BUG: kernel NULL pointer dereference, address: 0000000000000000 > > [ 594.319712] #PF: supervisor write access in kernel mode > > [ 594.343627] #PF: error_code(0x0002) - not-present page > > [ 594.366791] PGD 0 P4D 0 > > [ 594.378172] Oops: 0002 [#1] PREEMPT SMP PTI > > [ 594.397047] CPU: 0 PID: 52196 Comm: mount.cifs Kdump: loaded > > Tainted: G I 5.16.0-rc4-next-20211206 #1 > > [ 594.445144] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/02/2014 > > [ 594.475201] RIP: 0010:cifs_fscache_get_inode_cookie+0x2f/0xb0 [cifs] > > [ 594.503934] Code: 53 48 89 fb 48 83 ec 20 65 48 8b 04 25 28 00 00 > > 00 48 89 44 24 18 48 8b 47 28 48 8b b8 88 03 00 00 e8 35 c6 fa ff 48 > > 8b 53 68 <48> 89 14 25 00 00 00 00 48 8b 53 70 89 14 25 10 00 00 00 48 > > 8b 53 > > [ 594.590004] RSP: 0018:ffffb93c4998fc10 EFLAGS: 00010282 > > [ 594.614861] RAX: ffff970743ab5000 RBX: ffff970411193168 RCX: 0000000000000000 > > [ 594.650920] RDX: 0000000061b01059 RSI: 00000000000041ed RDI: ffff970453924780 > > [ 594.686189] RBP: ffffb93c4998fce8 R08: ffff970411193168 R09: ffff970743ab1548 > > [ 594.718776] R10: 000000009f8bdc24 R11: 000000009053e561 R12: 000000000e1c25d9 > > [ 594.750925] R13: ffff970411193168 R14: ffff970743ab1000 R15: ffff970743ab5000 > > [ 594.783532] FS: 00007f2037080780(0000) GS:ffff97072f600000(0000) > > knlGS:0000000000000000 > > [ 594.820129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [ 594.846183] CR2: 0000000000000000 CR3: 0000000141820006 CR4: 00000000001706f0 > > [ 594.878376] Call Trace: > > [ 594.889469] <TASK> > > [ 594.898870] cifs_iget+0x14b/0x160 [cifs] > > [ 594.917781] cifs_get_inode_info+0x430/0x750 [cifs] > > [ 594.941267] ? __d_instantiate+0x34/0xf0 > > [ 594.960012] ? _raw_spin_unlock+0x16/0x30 > > [ 594.978111] ? d_instantiate+0x3e/0x60 > > [ 594.994982] cifs_root_iget+0x33b/0x4b0 [cifs] > > [ 595.015099] cifs_read_super+0x125/0x200 [cifs] > > [ 595.035596] cifs_smb3_do_mount+0x224/0x330 [cifs] > > [ 595.057009] smb3_get_tree+0x2d/0x50 [cifs] > > [ 595.076065] vfs_get_tree+0x25/0xb0 > > [ 595.092562] do_new_mount+0x176/0x310 > > [ 595.110929] __x64_sys_mount+0x103/0x140 > > [ 595.130439] do_syscall_64+0x3b/0x90 > > [ 595.147929] entry_SYSCALL_64_after_hwframe+0x44/0xae > > [ 595.172646] RIP: 0033:0x7f2037195c4e > > [ 595.188703] Code: 48 8b 0d dd 71 0e 00 f7 d8 64 89 01 48 83 c8 ff > > c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 > > 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d aa 71 0e 00 f7 d8 64 89 > > 01 48 > > [ 595.273644] RSP: 002b:00007fff27645a38 EFLAGS: 00000202 ORIG_RAX: > > 00000000000000a5 > > [ 595.307790] RAX: ffffffffffffffda RBX: 000055690a1bb910 RCX: 00007f2037195c4e > > [ 595.340187] RDX: 0000556908d5946b RSI: 0000556908d594b6 RDI: 00007fff27647fbe > > [ 595.372419] RBP: 000055690a1bb8f0 R08: 000055690a1bb910 R09: 0000000000000077 > > [ 595.404633] R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff27647fb3 > > [ 595.436882] R13: 00007f203729d000 R14: 00007f203729f70e R15: 00007fff27647fbe > > [ 595.468980] </TASK> > > [ 595.478769] Modules linked in: cifs cifs_arc4 cifs_md4 loop nfsv3 > > rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache netfs rpcrdma rdma_cm > > iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace rfkill sunrpc > > intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal > > intel_powerclamp mgag200 coretemp i2c_algo_bit kvm_intel > > drm_shmem_helper drm_kms_helper ipmi_ssif iTCO_wdt kvm > > iTCO_vendor_support acpi_ipmi syscopyarea irqbypass sysfillrect > > ipmi_si rapl intel_cstate ioatdma ipmi_devintf sysimgblt intel_uncore > > fb_sys_fops cec lpc_ich ipmi_msghandler acpi_power_meter pcspkr dca > > hpilo drm fuse xfs libcrc32c sr_mod cdrom sd_mod ata_generic t10_pi sg > > ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata serio_raw > > tg3 ghash_clmulni_intel hpsa hpwdt scsi_transport_sas dm_mirror > > dm_region_hash dm_log dm_mod > > [ 595.821049] CR2: 0000000000000000 > > > > -- > Regards, > Shyam This does not repro against a Windows server. My suspicion is that the recent change of location of cifs_fscache_get_super_cookie to cifs_root_iget caused this. We maybe trying to initialize the inode cookie when the super cookie is yet to be initialized. The bigger point here is that there seems to be a circular dependency: We need tcon->resource_id to setup the super cookie. This is populated using inode number of root directory. Getting this inode number needs opening of the root dir. Open causes inode cookie to be initialized, which trips when it sees that the super cookie is still NULL. Steve: Do you agree with this assessment? How do we fix this? Can we use some other value for resource_id, and not have to rely on the root inode number? How about tcon->tid? Or a combination of tcon->tid and ses->Suid? -- Regards, Shyam
