| Message ID | 1675261833-2-1-git-send-email-lizhijian@fujitsu.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj | expand |
On 2/1/23 22:30, Li Zhijian wrote: > As the mention in commmit f7452a7e96c1 ("RDMA/rtrs-srv: fix memory leak by missing kobject free"), > it's intended to remove the kobject_del for srv_path->kobj. > > A kernel panic will be triggered by following script > ----------------------- > $ while true; > do > echo "sessname=foo path=ip:<ip address> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device > echo "normal" > /sys/block/rnbd0/rnbd/unmap_device > done > ----------------------- > The bisection pointed to commit 6af4609c18b3 ("RDMA/rtrs-srv: Fix several issues in rtrs_srv_destroy_path_files") > at last. > > rnbd_server L777: </dev/nvme0n1@foo>: Opened device 'nvme0n1' > general protection fault, probably for non-canonical address 0x765f766564753aea: 0000 [#1] PREEMPT SMP PTI > CPU: 0 PID: 3558 Comm: systemd-udevd Kdump: loaded Not tainted 6.1.0-rc3-roce-flush+ #51 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:kernfs_dop_revalidate+0x36/0x180 > Code: 00 00 41 55 41 54 55 53 48 8b 47 68 48 89 fb 48 85 c0 0f 84 db 00 00 00 48 8b a8 60 04 00 00 48 8b 45 30 48 85 c0 48 0f 44 c5 <4c> 8b 60 78 49 81 c4 d8 00 00 00 4c 89 e7 e8 b7 78 7b 00 8b 05 3d > RSP: 0018:ffffaf1700b67c78 EFLAGS: 00010206 > RAX: 765f766564753a72 RBX: ffff89e2830849c0 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff89e2830849c0 > RBP: ffff89e280361bd0 R08: 0000000000000000 R09: 0000000000000001 > R10: 0000000000000065 R11: 0000000000000000 R12: ffff89e2830849c0 > R13: ffff89e283084888 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f > FS: 00007f13fbce7b40(0000) GS:ffff89e2bbc00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00007f93e055d340 CR3: 0000000104664002 CR4: 00000000001706f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > lookup_fast+0x7b/0x100 > walk_component+0x21/0x160 > link_path_walk.part.0+0x24d/0x390 > path_openat+0xad/0x9a0 > do_filp_open+0xa9/0x150 > ? lock_release+0x13c/0x2e0 > ? _raw_spin_unlock+0x29/0x50 > ? alloc_fd+0x124/0x1f0 > do_sys_openat2+0x9b/0x160 > __x64_sys_openat+0x54/0xa0 > do_syscall_64+0x3b/0x90 > entry_SYSCALL_64_after_hwframe+0x63/0xcd > RIP: 0033:0x7f13fc9d701b > Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 54 24 28 64 48 2b 14 25 > RSP: 002b:00007ffddf242640 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 > RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f13fc9d701b > RDX: 0000000000080000 RSI: 00007ffddf2427c0 RDI: 00000000ffffff9c > RBP: 00007ffddf2427c0 R08: 00007f13fcc5b440 R09: 21b2131aa64b1ef2 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000080000 > R13: 00007ffddf2427c0 R14: 000055ed13be8db0 R15: 0000000000000000 > > Fixes: 6af4609c18b3 ("RDMA/rtrs-srv: Fix several issues in rtrs_srv_destroy_path_files") > Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> > --- > drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c > index da8e205ce331..7fe905424109 100644 > --- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c > +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c > @@ -313,7 +313,6 @@ void rtrs_srv_destroy_path_files(struct rtrs_srv_path *srv_path) > > if (srv_path->kobj.state_in_sysfs) { > sysfs_remove_group(&srv_path->kobj, &rtrs_srv_path_attr_group); > - kobject_del(&srv_path->kobj); > kobject_put(&srv_path->kobj); > } > Thanks for the fix, it would be better to comment that why kobject_del can't be called here. Anyway, Acked-by: Guoqing Jiang <guoqing.jiang@linux.dev> Thanks, Guoqing
Thanks your reviewing @Guoqing > Thanks for the fix, it would be better to comment that why kobject_del can't > be called here. commmit f7452a7e96c1 ("RDMA/rtrs-srv: fix memory leak by missing kobject free") memtioned a free_sess(), but i didn't get it exactly(no such function ?). So i have not sorted it out. And hold on，with below change， kernel gets another WARNING. I'm still working on it. [ 125.034407] ========================= [ 125.035490] WARNING: held lock freed! [ 125.036640] 6.2.0-rc6-roce-flush+ #53 Not tainted [ 125.038088] ------------------------- [ 125.039143] kworker/0:3/63 is freeing memory ffff90bd01eaa000-ffff90bd01eaa7ff, with a lock still held there! [ 125.041660] ffff90bd01eaa118 (&srv->paths_mutex){+.+.}-{3:3}, at: rtrs_srv_destroy_once_sysfs_root_folders.isra.0+0x24/0x60 [rtrs_server] [ 125.044600] 3 locks held by kworker/0:3/63: [ 125.046091] #0: ffff90bd05f8ed38 ((wq_completion)rtrs_server_wq){+.+.}-{0:0}, at: process_one_work+0x1f4/0x590 [ 125.048876] #1: ffff9ff4c085fe78 ((work_completion)(&srv_path->close_work)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x590 [ 125.051789] #2: ffff90bd01eaa118 (&srv->paths_mutex){+.+.}-{3:3}, at: rtrs_srv_destroy_once_sysfs_root_folders.isra.0+0x24/0x60 [rtrs_server] [ 125.055167] [ 125.055167] stack backtrace: [ 125.057979] CPU: 0 PID: 63 Comm: kworker/0:3 Kdump: loaded Not tainted 6.2.0-rc6-roce-flush+ #53 [ 125.060201] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 125.063156] Workqueue: rtrs_server_wq rtrs_srv_close_work [rtrs_server] [ 125.065031] Call Trace: [ 125.065905] <TASK> [ 125.066733] dump_stack_lvl+0x45/0x5d [ 125.068003] debug_check_no_locks_freed.cold+0x77/0x7c [ 125.069565] ? device_release+0x34/0x90 [ 125.070814] __kmem_cache_free+0x74/0x190 [ 125.072059] device_release+0x34/0x90 [ 125.073203] kobject_put+0x8b/0x1d0 [ 125.074385] rtrs_srv_destroy_once_sysfs_root_folders.isra.0+0x35/0x60 [rtrs_server] [ 125.076456] rtrs_srv_close_work+0x21/0x270 [rtrs_server] [ 125.078097] process_one_work+0x274/0x590 [ 125.079372] worker_thread+0x4f/0x3d0 [ 125.080508] ? __pfx_worker_thread+0x10/0x10 [ 125.081751] kthread+0xe7/0x110 [ 125.082778] ? __pfx_kthread+0x10/0x10 [ 125.083894] ret_from_fork+0x2c/0x50 [ 125.084991] </TASK> On 02/02/2023 09:41, Guoqing Jiang wrote: > > > On 2/1/23 22:30, Li Zhijian wrote: >> As the mention in commmit f7452a7e96c1 ("RDMA/rtrs-srv: fix memory leak by missing kobject free"), >> it's intended to remove the kobject_del for srv_path->kobj. >> >> A kernel panic will be triggered by following script >> ----------------------- >> $ while true; >> do >> echo "sessname=foo path=ip:<ip address> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device >> echo "normal" > /sys/block/rnbd0/rnbd/unmap_device >> done >> ----------------------- >> The bisection pointed to commit 6af4609c18b3 ("RDMA/rtrs-srv: Fix several issues in rtrs_srv_destroy_path_files") >> at last. >> >> rnbd_server L777: </dev/nvme0n1@foo>: Opened device 'nvme0n1' >> general protection fault, probably for non-canonical address 0x765f766564753aea: 0000 [#1] PREEMPT SMP PTI >> CPU: 0 PID: 3558 Comm: systemd-udevd Kdump: loaded Not tainted 6.1.0-rc3-roce-flush+ #51 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 >> RIP: 0010:kernfs_dop_revalidate+0x36/0x180 >> Code: 00 00 41 55 41 54 55 53 48 8b 47 68 48 89 fb 48 85 c0 0f 84 db 00 00 00 48 8b a8 60 04 00 00 48 8b 45 30 48 85 c0 48 0f 44 c5 <4c> 8b 60 78 49 81 c4 d8 00 00 00 4c 89 e7 e8 b7 78 7b 00 8b 05 3d >> RSP: 0018:ffffaf1700b67c78 EFLAGS: 00010206 >> RAX: 765f766564753a72 RBX: ffff89e2830849c0 RCX: 0000000000000000 >> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff89e2830849c0 >> RBP: ffff89e280361bd0 R08: 0000000000000000 R09: 0000000000000001 >> R10: 0000000000000065 R11: 0000000000000000 R12: ffff89e2830849c0 >> R13: ffff89e283084888 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f >> FS: 00007f13fbce7b40(0000) GS:ffff89e2bbc00000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 00007f93e055d340 CR3: 0000000104664002 CR4: 00000000001706f0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 >> Call Trace: >> <TASK> >> lookup_fast+0x7b/0x100 >> walk_component+0x21/0x160 >> link_path_walk.part.0+0x24d/0x390 >> path_openat+0xad/0x9a0 >> do_filp_open+0xa9/0x150 >> ? lock_release+0x13c/0x2e0 >> ? _raw_spin_unlock+0x29/0x50 >> ? alloc_fd+0x124/0x1f0 >> do_sys_openat2+0x9b/0x160 >> __x64_sys_openat+0x54/0xa0 >> do_syscall_64+0x3b/0x90 >> entry_SYSCALL_64_after_hwframe+0x63/0xcd >> RIP: 0033:0x7f13fc9d701b >> Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 54 24 28 64 48 2b 14 25 >> RSP: 002b:00007ffddf242640 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 >> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f13fc9d701b >> RDX: 0000000000080000 RSI: 00007ffddf2427c0 RDI: 00000000ffffff9c >> RBP: 00007ffddf2427c0 R08: 00007f13fcc5b440 R09: 21b2131aa64b1ef2 >> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000080000 >> R13: 00007ffddf2427c0 R14: 000055ed13be8db0 R15: 0000000000000000 >> >> Fixes: 6af4609c18b3 ("RDMA/rtrs-srv: Fix several issues in rtrs_srv_destroy_path_files") >> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> >> --- >> drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c >> index da8e205ce331..7fe905424109 100644 >> --- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c >> +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c >> @@ -313,7 +313,6 @@ void rtrs_srv_destroy_path_files(struct rtrs_srv_path *srv_path) >> if (srv_path->kobj.state_in_sysfs) { >> sysfs_remove_group(&srv_path->kobj, &rtrs_srv_path_attr_group); >> - kobject_del(&srv_path->kobj); >> kobject_put(&srv_path->kobj); >> } > > Thanks for the fix, it would be better to comment that why kobject_del can't > be called here. > > Anyway, Acked-by: Guoqing Jiang <guoqing.jiang@linux.dev> > > Thanks, > Guoqing
On 2/2/23 11:42, lizhijian@fujitsu.com wrote: > Thanks your reviewing @Guoqing > >> Thanks for the fix, it would be better to comment that why kobject_del can't >> be called here. > commmit f7452a7e96c1 ("RDMA/rtrs-srv: fix memory leak by missing kobject free") > memtioned a free_sess(), but i didn't get it exactly(no such function ?). So i have > not sorted it out. It was renamed to free_path I believe. > And hold on，with below change， kernel gets another WARNING. > I'm still working on it. > > [ 125.034407] ========================= > [ 125.035490] WARNING: held lock freed! > [ 125.036640] 6.2.0-rc6-roce-flush+ #53 Not tainted > [ 125.038088] ------------------------- > [ 125.039143] kworker/0:3/63 is freeing memory ffff90bd01eaa000-ffff90bd01eaa7ff, with a lock still held there! > [ 125.041660] ffff90bd01eaa118 (&srv->paths_mutex){+.+.}-{3:3}, at: rtrs_srv_destroy_once_sysfs_root_folders.isra.0+0x24/0x60 [rtrs_server] > [ 125.044600] 3 locks held by kworker/0:3/63: > [ 125.046091] #0: ffff90bd05f8ed38 ((wq_completion)rtrs_server_wq){+.+.}-{0:0}, at: process_one_work+0x1f4/0x590 > [ 125.048876] #1: ffff9ff4c085fe78 ((work_completion)(&srv_path->close_work)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x590 > [ 125.051789] #2: ffff90bd01eaa118 (&srv->paths_mutex){+.+.}-{3:3}, at: rtrs_srv_destroy_once_sysfs_root_folders.isra.0+0x24/0x60 [rtrs_server] > [ 125.055167] > [ 125.055167] stack backtrace: > [ 125.057979] CPU: 0 PID: 63 Comm: kworker/0:3 Kdump: loaded Not tainted 6.2.0-rc6-roce-flush+ #53 > [ 125.060201] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > [ 125.063156] Workqueue: rtrs_server_wq rtrs_srv_close_work [rtrs_server] > [ 125.065031] Call Trace: > [ 125.065905] <TASK> > [ 125.066733] dump_stack_lvl+0x45/0x5d > [ 125.068003] debug_check_no_locks_freed.cold+0x77/0x7c > [ 125.069565] ? device_release+0x34/0x90 > [ 125.070814] __kmem_cache_free+0x74/0x190 > [ 125.072059] device_release+0x34/0x90 > [ 125.073203] kobject_put+0x8b/0x1d0 > [ 125.074385] rtrs_srv_destroy_once_sysfs_root_folders.isra.0+0x35/0x60 [rtrs_server] > [ 125.076456] rtrs_srv_close_work+0x21/0x270 [rtrs_server] > [ 125.078097] process_one_work+0x274/0x590 > [ 125.079372] worker_thread+0x4f/0x3d0 > [ 125.080508] ? __pfx_worker_thread+0x10/0x10 > [ 125.081751] kthread+0xe7/0x110 > [ 125.082778] ? __pfx_kthread+0x10/0x10 > [ 125.083894] ret_from_fork+0x2c/0x50 > [ 125.084991] </TASK> Suppose it also happened during run your script, I guess it might be some racy conditions. $ while true; do echo "sessname=foo path=ip:<ip address> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device echo "normal" > /sys/block/rnbd0/rnbd/unmap_device done Or does it disappear after revert 6af4609c18b3? If so, we can revert it first. Thanks, Guoqing
On 02/02/2023 12:09, Guoqing Jiang wrote: >> > > Suppose it also happened during run your script, I guess it might be some > racy conditions. That's true > > $ while true; > do > echo "sessname=foo path=ip:<ip address> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device > echo "normal" > /sys/block/rnbd0/rnbd/unmap_device > done > > > Or does it disappear after revert 6af4609c18b3? If so, we can revert it > first. Well, everything goes well after i reverted 6af4609c18b3. Thanks Zhijian > > Thanks, > Guoqing
On 02/02/2023 15:25, lizhijian@fujitsu.com wrote: > > > On 02/02/2023 12:09, Guoqing Jiang wrote: >>> >> >> Suppose it also happened during run your script, I guess it might be some >> racy conditions. > That's true > > >> >> $ while true; >> do >> echo "sessname=foo path=ip:<ip address> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device >> echo "normal" > /sys/block/rnbd0/rnbd/unmap_device >> done >> >> >> Or does it disappear after revert 6af4609c18b3? If so, we can revert it >> first. > > Well, everything goes well after i reverted 6af4609c18b3. 6af4609c18b3 seems make senses, so i don't want to revert it entirely if possible. I have a update for this path like below, i am no longer get problem with this new update. index c76ba29da1e2..5adba0f754b6 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c @@ -312,9 +312,8 @@ void rtrs_srv_destroy_path_files(struct rtrs_srv_path *srv_path) if (srv_path->kobj.state_in_sysfs) { sysfs_remove_group(&srv_path->kobj, &rtrs_srv_path_attr_group); - kobject_del(&srv_path->kobj); kobject_put(&srv_path->kobj); + rtrs_srv_destroy_once_sysfs_root_folders(srv_path); } - rtrs_srv_destroy_once_sysfs_root_folders(srv_path); } > > Thanks > Zhijian >> >> Thanks, >> Guoqing
On 2/2/23 15:59, lizhijian@fujitsu.com wrote: > 6af4609c18b3 seems make senses, so i don't want to revert it entirely if possible. > > I have a update for this path like below, i am no longer get problem with this new update. > > index c76ba29da1e2..5adba0f754b6 100644 > --- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c > +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c > @@ -312,9 +312,8 @@ void rtrs_srv_destroy_path_files(struct rtrs_srv_path *srv_path) > > if (srv_path->kobj.state_in_sysfs) { > sysfs_remove_group(&srv_path->kobj, &rtrs_srv_path_attr_group); > - kobject_del(&srv_path->kobj); > kobject_put(&srv_path->kobj); > + rtrs_srv_destroy_once_sysfs_root_folders(srv_path); > } > > - rtrs_srv_destroy_once_sysfs_root_folders(srv_path); > } Hmm, I overlooked the kobject hierarchy
diff --git a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c index da8e205ce331..7fe905424109 100644 --- a/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c +++ b/drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c @@ -313,7 +313,6 @@ void rtrs_srv_destroy_path_files(struct rtrs_srv_path *srv_path) if (srv_path->kobj.state_in_sysfs) { sysfs_remove_group(&srv_path->kobj, &rtrs_srv_path_attr_group); - kobject_del(&srv_path->kobj); kobject_put(&srv_path->kobj); }
As the mention in commmit f7452a7e96c1 ("RDMA/rtrs-srv: fix memory leak by missing kobject free"), it's intended to remove the kobject_del for srv_path->kobj. A kernel panic will be triggered by following script ----------------------- $ while true; do echo "sessname=foo path=ip:<ip address> device_path=/dev/nvme0n1" > /sys/devices/virtual/rnbd-client/ctl/map_device echo "normal" > /sys/block/rnbd0/rnbd/unmap_device done ----------------------- The bisection pointed to commit 6af4609c18b3 ("RDMA/rtrs-srv: Fix several issues in rtrs_srv_destroy_path_files") at last. rnbd_server L777: </dev/nvme0n1@foo>: Opened device 'nvme0n1' general protection fault, probably for non-canonical address 0x765f766564753aea: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3558 Comm: systemd-udevd Kdump: loaded Not tainted 6.1.0-rc3-roce-flush+ #51 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:kernfs_dop_revalidate+0x36/0x180 Code: 00 00 41 55 41 54 55 53 48 8b 47 68 48 89 fb 48 85 c0 0f 84 db 00 00 00 48 8b a8 60 04 00 00 48 8b 45 30 48 85 c0 48 0f 44 c5 <4c> 8b 60 78 49 81 c4 d8 00 00 00 4c 89 e7 e8 b7 78 7b 00 8b 05 3d RSP: 0018:ffffaf1700b67c78 EFLAGS: 00010206 RAX: 765f766564753a72 RBX: ffff89e2830849c0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff89e2830849c0 RBP: ffff89e280361bd0 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000065 R11: 0000000000000000 R12: ffff89e2830849c0 R13: ffff89e283084888 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f13fbce7b40(0000) GS:ffff89e2bbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93e055d340 CR3: 0000000104664002 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> lookup_fast+0x7b/0x100 walk_component+0x21/0x160 link_path_walk.part.0+0x24d/0x390 path_openat+0xad/0x9a0 do_filp_open+0xa9/0x150 ? lock_release+0x13c/0x2e0 ? _raw_spin_unlock+0x29/0x50 ? alloc_fd+0x124/0x1f0 do_sys_openat2+0x9b/0x160 __x64_sys_openat+0x54/0xa0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f13fc9d701b Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 54 24 28 64 48 2b 14 25 RSP: 002b:00007ffddf242640 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f13fc9d701b RDX: 0000000000080000 RSI: 00007ffddf2427c0 RDI: 00000000ffffff9c RBP: 00007ffddf2427c0 R08: 00007f13fcc5b440 R09: 21b2131aa64b1ef2 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000080000 R13: 00007ffddf2427c0 R14: 000055ed13be8db0 R15: 0000000000000000 Fixes: 6af4609c18b3 ("RDMA/rtrs-srv: Fix several issues in rtrs_srv_destroy_path_files") Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> --- drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 1 - 1 file changed, 1 deletion(-)