* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 4:08 ` [PATCH] null_blk: fix queue mode Oops for membacked Chaitanya Kulkarni
@ 2023-04-12 7:57 ` Damien Le Moal
2023-04-12 8:09 ` Chaitanya Kulkarni
2023-04-12 9:17 ` Nitesh Shetty
2023-04-13 3:24 ` Ming Lei
2 siblings, 1 reply; 8+ messages in thread
From: Damien Le Moal @ 2023-04-12 7:57 UTC (permalink / raw)
To: Chaitanya Kulkarni, linux-block
Cc: axboe, johannes.thumshirn, bvanassche, vincent.fu,
shinichiro.kawasaki, error27
On 4/12/23 13:08, Chaitanya Kulkarni wrote:
> Make sure to check device queue mode in the null_validate_conf()
> and return error for NULL_Q_RQ as we don't allow legacy I/O path,
> without this patch we get OOPs when queue mode is set to 1 from
> configfs, following are repro steps :-
Looks OK but the patch title is a little odd as I do not see what memory backing
has to do with checking the correctness of queue_mode. So what about something like:
null_blk: Always check queue mode setting from configfs
for the patch title ?
With that fixed,
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 7:57 ` Damien Le Moal
@ 2023-04-12 8:09 ` Chaitanya Kulkarni
0 siblings, 0 replies; 8+ messages in thread
From: Chaitanya Kulkarni @ 2023-04-12 8:09 UTC (permalink / raw)
To: Damien Le Moal, Chaitanya Kulkarni, linux-block@vger.kernel.org
Cc: axboe@kernel.dk, johannes.thumshirn@wdc.com, bvanassche@acm.org,
vincent.fu@samsung.com, shinichiro.kawasaki@wdc.com,
error27@gmail.com
On 4/12/23 00:57, Damien Le Moal wrote:
> On 4/12/23 13:08, Chaitanya Kulkarni wrote:
>> Make sure to check device queue mode in the null_validate_conf()
>> and return error for NULL_Q_RQ as we don't allow legacy I/O path,
>> without this patch we get OOPs when queue mode is set to 1 from
>> configfs, following are repro steps :-
> Looks OK but the patch title is a little odd as I do not see what memory backing
> has to do with checking the correctness of queue_mode. So what about something like:
>
> null_blk: Always check queue mode setting from configfs
agree..
> for the patch title ?
>
> With that fixed,
>
> Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
>
>
>
will send a v2 with that fix with your review tag, thanks for the
review.
-ck
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 4:08 ` [PATCH] null_blk: fix queue mode Oops for membacked Chaitanya Kulkarni
2023-04-12 7:57 ` Damien Le Moal
@ 2023-04-12 9:17 ` Nitesh Shetty
2023-04-12 9:43 ` Damien Le Moal
2023-04-13 1:30 ` Chaitanya Kulkarni
2023-04-13 3:24 ` Ming Lei
2 siblings, 2 replies; 8+ messages in thread
From: Nitesh Shetty @ 2023-04-12 9:17 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: linux-block, axboe, dlemoal, johannes.thumshirn, bvanassche,
vincent.fu, shinichiro.kawasaki, error27
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
On 23/04/11 09:08PM, Chaitanya Kulkarni wrote:
>Make sure to check device queue mode in the null_validate_conf()
>and return error for NULL_Q_RQ as we don't allow legacy I/O path,
Can't we do away with NULL_Q_RQ defination itself ?
I mean, since I see in code we are not using NULL_Q_RQ anywhere,
if we can remove NULL_Q_RQ defination from enum in null_blk.h,
we can remove your suggested check, as well as check in null_init.
--Nitesh Shetty
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 9:17 ` Nitesh Shetty
@ 2023-04-12 9:43 ` Damien Le Moal
2023-04-12 10:29 ` Nitesh Shetty
2023-04-13 1:30 ` Chaitanya Kulkarni
1 sibling, 1 reply; 8+ messages in thread
From: Damien Le Moal @ 2023-04-12 9:43 UTC (permalink / raw)
To: Nitesh Shetty, Chaitanya Kulkarni
Cc: linux-block, axboe, johannes.thumshirn, bvanassche, vincent.fu,
shinichiro.kawasaki, error27
On 4/12/23 18:17, Nitesh Shetty wrote:
> On 23/04/11 09:08PM, Chaitanya Kulkarni wrote:
>> Make sure to check device queue mode in the null_validate_conf()
>> and return error for NULL_Q_RQ as we don't allow legacy I/O path,
>
> Can't we do away with NULL_Q_RQ defination itself ?
> I mean, since I see in code we are not using NULL_Q_RQ anywhere,
> if we can remove NULL_Q_RQ defination from enum in null_blk.h,
> we can remove your suggested check, as well as check in null_init.
I think it is being kept around to avoid reusing this value to not confuse old
scripts.
>
> --Nitesh Shetty
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 9:43 ` Damien Le Moal
@ 2023-04-12 10:29 ` Nitesh Shetty
0 siblings, 0 replies; 8+ messages in thread
From: Nitesh Shetty @ 2023-04-12 10:29 UTC (permalink / raw)
To: Damien Le Moal
Cc: Chaitanya Kulkarni, linux-block, axboe, johannes.thumshirn,
bvanassche, vincent.fu, shinichiro.kawasaki, error27
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
On 23/04/12 06:43PM, Damien Le Moal wrote:
>On 4/12/23 18:17, Nitesh Shetty wrote:
>> On 23/04/11 09:08PM, Chaitanya Kulkarni wrote:
>>> Make sure to check device queue mode in the null_validate_conf()
>>> and return error for NULL_Q_RQ as we don't allow legacy I/O path,
>>
>> Can't we do away with NULL_Q_RQ defination itself ?
>> I mean, since I see in code we are not using NULL_Q_RQ anywhere,
>> if we can remove NULL_Q_RQ defination from enum in null_blk.h,
>> we can remove your suggested check, as well as check in null_init.
>
>I think it is being kept around to avoid reusing this value to not confuse old
>scripts.
>
got it.
Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com>
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 9:17 ` Nitesh Shetty
2023-04-12 9:43 ` Damien Le Moal
@ 2023-04-13 1:30 ` Chaitanya Kulkarni
1 sibling, 0 replies; 8+ messages in thread
From: Chaitanya Kulkarni @ 2023-04-13 1:30 UTC (permalink / raw)
To: Nitesh Shetty
Cc: linux-block@vger.kernel.org, axboe@kernel.dk, dlemoal@kernel.org,
johannes.thumshirn@wdc.com, bvanassche@acm.org,
vincent.fu@samsung.com, Chaitanya Kulkarni,
shinichiro.kawasaki@wdc.com, error27@gmail.com
On 4/12/23 02:17, Nitesh Shetty wrote:
> On 23/04/11 09:08PM, Chaitanya Kulkarni wrote:
>> Make sure to check device queue mode in the null_validate_conf()
>> and return error for NULL_Q_RQ as we don't allow legacy I/O path,
>
> Can't we do away with NULL_Q_RQ defination itself ?
> I mean, since I see in code we are not using NULL_Q_RQ anywhere,
> if we can remove NULL_Q_RQ defination from enum in null_blk.h,
> we can remove your suggested check, as well as check in null_init.
>
> --Nitesh Shetty
>
Please don't do that.
-ck
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] null_blk: fix queue mode Oops for membacked
2023-04-12 4:08 ` [PATCH] null_blk: fix queue mode Oops for membacked Chaitanya Kulkarni
2023-04-12 7:57 ` Damien Le Moal
2023-04-12 9:17 ` Nitesh Shetty
@ 2023-04-13 3:24 ` Ming Lei
2 siblings, 0 replies; 8+ messages in thread
From: Ming Lei @ 2023-04-13 3:24 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: linux-block, axboe, dlemoal, johannes.thumshirn, bvanassche,
vincent.fu, shinichiro.kawasaki, error27
On Wed, Apr 12, 2023 at 12:11 PM Chaitanya Kulkarni <kch@nvidia.com> wrote:
>
> Make sure to check device queue mode in the null_validate_conf()
> and return error for NULL_Q_RQ as we don't allow legacy I/O path,
> without this patch we get OOPs when queue mode is set to 1 from
> configfs, following are repro steps :-
>
> modprobe null_blk nr_devices=0
> mkdir config/nullb/nullb0
> echo 1 > config/nullb/nullb0/memory_backed
> echo 4096 > config/nullb/nullb0/blocksize
> echo 20480 > config/nullb/nullb0/size
> echo 1 > config/nullb/nullb0/queue_mode
> echo 1 > config/nullb/nullb0/power
>
> Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)
> due to oops @ 0xffffffffc041c329
> CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]
> Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20
> RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246
> RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00
> RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000
> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002
> R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740
> FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0
> DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a
> DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Call Trace:
> <TASK>
> nullb_device_power_store+0xd1/0x120 [null_blk]
> configfs_write_iter+0xb4/0x120
> vfs_write+0x2ba/0x3c0
> ksys_write+0x5f/0xe0
> do_syscall_64+0x3b/0x90
> entry_SYSCALL_64_after_hwframe+0x72/0xdc
> RIP: 0033:0x7fd4460c57a7
> Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
> RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7
> RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001
> RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0
> R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002
> R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700
> </TASK>
>
> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread