Bugzilla – Bug 1217465
LTP: ioprio_set with invalid value "IOPRIO_CLASS_BE prio 8" return ok instead of error
Last modified: 2024-04-19 07:30:19 UTC
openQA test in scenario sle-15-SP6-Online-x86_64-ltp_syscalls@64bit fails in [ioprio_set03](https://openqa.suse.de/tests/12838610/modules/ioprio_set03/steps/7) LTP log: ioprio_set03.c:40: TFAIL: ioprio_set IOPRIO_CLASS_BE prio 8 should not work Test description: ret = syscall(__NR_ioprio_set,IOPRIO_WHO_PROCESS, 0,IOPRIO_PRIO_VALUE(IOPRIO_CLASS_BE, 8))); Expect ret is -1 but actually not. NOTE: 15sp5 no this issue. In openqa i found Power and x86 has this issue.
More explaination for test code: # define IOPRIO_PRIO_VALUE(class, data) (((class) << IOPRIO_CLASS_SHIFT) | data) Comments in kernel: * Helper functions for setting/querying io priorities of processes. The * system calls closely mimmick getpriority/setpriority, see the man page for * those. The prio argument is a composite of prio class and prio data, where * the data argument has meaning within that class. The standard scheduling * classes have 8 distinct prio levels, with 0 being the highest prio and 7 * being the lowest. * * IOW, setting BE scheduling class with prio 2 is done ala: * * unsigned int prio = (IOPRIO_CLASS_BE << IOPRIO_CLASS_SHIFT) | 2; * * ioprio_set(PRIO_PROCESS, pid, prio);
Submit fix on latest kernel: https://lkml.org/lkml/2023/11/23/1269
As indicated in the mail thread, this fix is not correct. The correct fix is commit 01584c1e2337 ("scsi: block: Improve ioprio value validity checks") which introduces IOPRIO_BAD_VALUE() macro for that. And for ltp, the commits are: 6b7f448fe392 ("ioprio: Use IOPRIO_PRIO_NUM to check prio range") 7c84fa710f75 ("ioprio: use ioprio.h kernel header if it exists")
(In reply to Hannes Reinecke from comment #3) > As indicated in the mail thread, this fix is not correct. > The correct fix is commit 01584c1e2337 ("scsi: block: Improve ioprio value > validity checks") which introduces IOPRIO_BAD_VALUE() macro for that. > > And for ltp, the commits are: > 6b7f448fe392 ("ioprio: Use IOPRIO_PRIO_NUM to check prio range") > 7c84fa710f75 ("ioprio: use ioprio.h kernel header if it exists") So i guess should we merge 01584c1e2337 ("scsi: block: Improve ioprio value validity checks") to fix current LTP failure in openqa?
Wei Gao, perhaps you can ping Hannes directly on this on SLACK and move the but to resolved?
(In reply to Radoslav Tzvetkov from comment #5) > Wei Gao, perhaps you can ping Hannes directly on this on SLACK and move the > but to resolved? Got it. Will ping.
(In reply to WEI GAO from comment #4) > (In reply to Hannes Reinecke from comment #3) > > As indicated in the mail thread, this fix is not correct. > > The correct fix is commit 01584c1e2337 ("scsi: block: Improve ioprio value > > validity checks") which introduces IOPRIO_BAD_VALUE() macro for that. > > > > And for ltp, the commits are: > > 6b7f448fe392 ("ioprio: Use IOPRIO_PRIO_NUM to check prio range") > > 7c84fa710f75 ("ioprio: use ioprio.h kernel header if it exists") > > So i guess should we merge 01584c1e2337 ("scsi: block: Improve ioprio value > validity checks") to fix current LTP failure in openqa? Yes please, do that.
The kernel backport of the commit 01584c1e233740519d0e11aa20daa323d26bf598 has been already included since beta1.
i.e. kernel-default-6.4.0-150600.2 already contained the backport.
So I don't think there is nothing left to be done for the kernel. The remaining would be the fixes in LTP side.
https://openqa.suse.de/tests/13319851#step/ioprio_set03/7 still show failed result. Manual check: I download latest LTP into 47.2 build and test, the result still failed. Kernel: Name : kernel-default Version : 6.4.0 Release : 150600.4.16 Architecture: x86_64 Install Date: Tue Jan 23 09:56:06 2024 Group : System/Kernel Size : 197013398 License : GPL-2.0-only Signature : RSA/SHA256, Fri Jan 19 12:24:34 2024, Key ID 70af9e8139db7c82 Source RPM : kernel-default-6.4.0-150600.4.16.nosrc.rpm Build Date : Fri Jan 19 12:15:32 2024 Build Host : h01-ch5b Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC <https://www.suse.com/> URL : https://www.kernel.org/ Summary : The Standard Kernel Description : The standard kernel for both uniprocessor and multiprocessor systems. Source Timestamp: 2023-11-23 09:48:45 +0000 GIT Revision: 428d2af242ddc7ff8721b201f2c54686e038255c GIT Branch: SLE15-SP6 Distribution: SUSE Linux Enterprise 15 LTP latest: commit 9062824a70b8da74aa5b1db08710d0018b48072e (HEAD -> master, origin/master, origin/HEAD) Author: Amir Goldstein <amir73il@gmail.com> Date: Tue Nov 21 12:52:47 2023 +0200 fanotify16: Fix test failure on FUSE
The tested kernel is very old, unfortunately the kernel package hasn't been updated in beta2. Just to be sure, please retest with SLE15-SP6 KOTD.
(In reply to Takashi Iwai from comment #13) > The tested kernel is very old, unfortunately the kernel package hasn't been > updated in beta2. Just to be sure, please retest with SLE15-SP6 KOTD. Latest KOTD openqa result still show failed: https://openqa.suse.de/tests/13372228#step/ioprio_set03/7 But if you check TW result is OK: https://openqa.opensuse.org/tests/3896346#step/ioprio_set03/6
OK, then it implies that we still miss something in the latest SLE15-SP6 kernel. I toss to Hannes again.
1)rpm -qf /usr/include/linux/ioprio.h <<<<< This one still old without change linux-glibc-devel-6.4-150600.1.38.x86_64 2)rpm -qf /usr/src/linux-6.4.0-150600.5/include/uapi/linux/ioprio.h <<<<< This one contain the update kernel-devel-6.4.0-150600.5.1.noarch I suppose kernel side has done it's work but glibc side maybe need extra update? LTP will default select 1) so we still encounter issue in openqa.
Hmm. Who's maintaining that? Andreas?
osc maintainer linux-glibc-devel
(In reply to Andreas Schwab from comment #18) > osc maintainer linux-glibc-devel The result depends on the API :) But IBS leaves it to kernel-devs, so we need to take care of it. The SP6 package linux-glibc-devel contains the headers generated from only vanilla 6.4 kernel without no patches at all, so it's waaay behind the SLE15-SP6 kernel code. I updated the package now with the backport of uapi headers. Since the way we build the package doesn't allow to apply the kernel patches cleanly, I created a big diff patch against the expanded headers to 6.4 base. The references have been added manually, although it could be scripted somehow. Let's hope that this will be accepted (and doesn't break things badly).
Latest result show ok now. https://openqa.suse.de/tests/13547748#step/ioprio_set03/7
See last comments
A SR mentioning this bug was successfully integrated into Build 58.1. Please, if needed, set it to RESOLVED FIXED for QE to verify it.