On Fri, May 26, 2023 at 3:42 PM Damien Le Moal <dlemoal@xxxxxxxxxx> wrote: > > On 5/26/23 16:27, Murphy Zhou wrote: > > Hi Damien, > > > > Since these commits: > > > > scsi: block: Introduce ioprio hints > > scsi: block: ioprio: Clean up interface definition > > > > go into linux-next tree, ioprio_set can take the value of 8 > > as the PROCESS CLASS_BE ioprio parameter, returning > > success but actually it is setting to 0 due to the mask roundup. > > > > The LTP test case ioprio_set03[1] covers this boundary value > > testing, which starts to fail since then. > > > > This does not look as expected. Could you help to take a look? > > Before the patches, the ioprio level of 8 could indeed be set, but that was Before the patches, it can't be set to 8 because the check in ioprio_check_cap refused it. >= IOPRIO_NR_LEVELS Before the patches, the value can be greater than 8, so it takes effect. After the patches, the value is limited to [0..7], this check always passes. > actually totally meaningless since the kernel components that use the priority > level all are limited to the range [0..7]. And why the level value 8 could be > seen, the effective level would have been 0. So at least, with the changes, we > are not lying to the user... > > I am not sure what this ioprio_set03 test is trying to check. I guess it is trying to make sure boundary values do not cause uncertaining. The test case can be updated according to intended kernel changes. So does other user space applications that may depend on this, or there is none of them to worry about. Thanks, Murphy > > > > > Thanks, > > Murphy > > > > [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/ioprio/ioprio_set03.c > > -- > Damien Le Moal > Western Digital Research >
