2023-02-01 14:31:03

by Zhijian Li (Fujitsu)

[permalink] [raw]
Subject: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for 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 <[email protected]>
---
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);
}

--
1.8.3.1



2023-02-02 01:47:26

by Guoqing Jiang

[permalink] [raw]
Subject: Re: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj



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 <[email protected]>
> ---
> 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 <[email protected]>

Thanks,
Guoqing

2023-02-02 03:46:33

by Zhijian Li (Fujitsu)

[permalink] [raw]
Subject: Re: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj


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 <[email protected]>
>> ---
>>   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 <[email protected]>
>
> Thanks,
> Guoqing

2023-02-02 04:09:54

by Guoqing Jiang

[permalink] [raw]
Subject: Re: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj



On 2/2/23 11:42, [email protected] 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

2023-02-02 07:29:32

by Zhijian Li (Fujitsu)

[permalink] [raw]
Subject: Re: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj



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

2023-02-02 08:00:00

by Zhijian Li (Fujitsu)

[permalink] [raw]
Subject: Re: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj



On 02/02/2023 15:25, [email protected] 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

2023-02-02 08:21:02

by Guoqing Jiang

[permalink] [raw]
Subject: Re: [PATCH RFC] RDMA/rtrs: Don't call kobject_del for srv_path->kobj



On 2/2/23 15:59, [email protected] 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 ????.

       err = kobject_init_and_add(&srv_path->kobj, &ktype,
srv->kobj_paths,
"%s", str);

Pls send a formal patch, and feel free to add my Acked-by.

Thanks,
Guoqing