On 2019/02/12 11:55, Jens Axboe wrote: > On 2/11/19 4:47 PM, Damien Le Moal wrote: >> When null_blk queue mode is specified together with modprobe/insmod, a >> check to prevent setting the nullb device queue mode to 1 (NULL_Q_RQ) is >> done. However, the same check is not performed when setting up a nullb >> device through configfs, resulting in a oops (NULL pointer dereference >> for the device request queue). >> >> Fix this problem by checking for an invalid queue mode value in >> null_validate_conf(), propagating -EINVAL to null_add_dev() if the queue >> mode is NULL_Q_RQ. While at it, also fix the propagation to user space >> of null_add_dev() return value when a nullb device is created through >> the power attribute of configfs. >> >> Finally, remove the "1=rq" value from the list of possible values of >> the queue_mode module argument to make it clear that this is no longer >> a valid setting. > > I actually left that in there on purpose, to avoid breaking test > scripts. It's not the perfect solution, but I viewed it as the > lesser of two evils. Maybe we're fine now, I think blktests has > been fixed a while back? > Yes, blktests is fine right now and not triggering the problem with a default config. Internally, blktests never tries to enable the rq=1 mode. I discovered this problem doing tests manually. -- Damien Le Moal Western Digital Research
