Hello,
setting an invalid elevator without blk-mq results in an error:
# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
# echo foo > /sys/block/sda/queue/scheduler
-bash: echo: write error: Invalid argument
# dmesg
[ 328.767088] elevator: type foo not found
[ 328.767097] elevator: switch to foo
failed
With blk-mq no error is returned:
# cat /sys/block/sda/queue/scheduler
none
# echo foo > /sys/block/sda/queue/scheduler
# echo $?
0
block/elevator.c got
988 ssize_t elv_iosched_store(struct request_queue *q, const char *name,
989 size_t count)
990 {
991 int ret;
992
993 if (!q->elevator)
994 return count;
995
996 ret = __elevator_change(q, name);
and
952 static int __elevator_change(struct request_queue *q, const char *name)
953 {
954 char elevator_name[ELV_NAME_MAX];
955 struct elevator_type *e;
956
957 if (!q->elevator)
958 return -ENXIO;
959
960 strlcpy(elevator_name, name, sizeof(elevator_name));
961 e = elevator_get(strstrip(elevator_name), true);
962 if (!e) {
963 printk(KERN_ERR "elevator: type %s not found\n", elevator_name);
964 return -EINVAL;
965 }
So !q->elevator is checked in elv_iosched_store and __elevator_change.
Should elv_iosched_store return ENXIO or EINVAL or should __elevator_change
handle this?
Sebastian
On 12/30/2014 04:37 PM, Sebastian Herbszt wrote:
> Hello,
>
> setting an invalid elevator without blk-mq results in an error:
>
> # cat /sys/block/sda/queue/scheduler
> noop deadline [cfq]
> # echo foo > /sys/block/sda/queue/scheduler
> -bash: echo: write error: Invalid argument
> # dmesg
> [ 328.767088] elevator: type foo not found
> [ 328.767097] elevator: switch to foo
> failed
>
> With blk-mq no error is returned:
>
> # cat /sys/block/sda/queue/scheduler
> none
> # echo foo > /sys/block/sda/queue/scheduler
> # echo $?
> 0
>
>
> block/elevator.c got
>
> 988 ssize_t elv_iosched_store(struct request_queue *q, const char *name,
> 989 size_t count)
> 990 {
> 991 int ret;
> 992
> 993 if (!q->elevator)
> 994 return count;
> 995
> 996 ret = __elevator_change(q, name);
>
> and
>
> 952 static int __elevator_change(struct request_queue *q, const char *name)
> 953 {
> 954 char elevator_name[ELV_NAME_MAX];
> 955 struct elevator_type *e;
> 956
> 957 if (!q->elevator)
> 958 return -ENXIO;
> 959
> 960 strlcpy(elevator_name, name, sizeof(elevator_name));
> 961 e = elevator_get(strstrip(elevator_name), true);
> 962 if (!e) {
> 963 printk(KERN_ERR "elevator: type %s not found\n", elevator_name);
> 964 return -EINVAL;
> 965 }
>
>
> So !q->elevator is checked in elv_iosched_store and __elevator_change.
>
> Should elv_iosched_store return ENXIO or EINVAL or should __elevator_change
> handle this?
I agree the behavior is strange, but it actually matches what would
happen for a make_request_fn based driver in this or earlier kernels. So
there is a worry of changing the API if we modify it in general. The
safe change would be to have these two lines before the q->elevator check:
if (q->mq_ops)
return -EINVAL;
since that's new enough not to be a "real" API change. If we do that, we
could let it slide into the general !q->elevator case after a few revisions.
Or we can just leave it as-is. If you read back the value after writing
to it, it will always return "none".
--
Jens Axboe