LTP master: arm64 : fsetxattr02.c:214: open(mntpoint/fsetxattr02blk, 0, 00) failed: ENXIO

LTP master testing on Hikey (arm64) device reported new test case fsetxattr02 and fgetxattr02 failed with error ENXIO (No such device or address)

We have very limited failure information on the console. Is this test case in any special TMP DIR ?

# cd /opt/ltp
# mkdir -m 777 -p /ltp-tmp # on the top level ltp-tmp created which is ext4 fs.
# ./runltp -f syscalls -d /ltp-tmp

Test output log,
safe_macros.c:225: BROK: fsetxattr02.c:214:
open(mntpoint/fsetxattr02blk,0,00) failed: ENXIO safe_macros.c:225: BROK: fgetxattr02.c:244: open(fgetxattr02blk,0,00)
failed: ENXIO

Yangx fixed error "EACCES" this error is ENXIO (No such device or address)

Full log link,
https://lkft.validation.linaro.org/scheduler/job/420924#L3182

FYI,
LTP Version: 20180515-270-ge7bab6188

Best regards
Naresh Kamboju

Hello Naresh,

LKFT hikey builds are missing:

inaddy@hikey:/mountpoint$ zcat /proc/config.gz | grep -i BLK_DEV_RAM
# CONFIG_BLK_DEV_RAM is not set

if comparing to my debian arm64 lab:

inaddy@statx04bug:/mountpoint$ cat /boot/config-4.18.0 | grep -i BLK_DEV_RAM
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384

So, when the test tries to mkdev(1,3), the device "ramdisk" does not exist. As you can see in:

inaddy@statx04bug:/mountpoint$ sudo cat /proc/devices
Character devices:
...
Block devices:
  1 ramdisk
...

ramdisk block devices are showed in a working environment.

Without the ramdisk module, the test creates a block device node (major 1, minor 3) pointing to non existing device types (ramdisk for this particular test). I guess ramdisk module is mandatory for this test to succeed.

Not sure if there is a way, using LTP API, to enforce a module existing/being loaded, but BROK is definitely the correct error in this condition.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20180916/7cf30a7c/attachment.html>

Hi!

There is an in-flight patch set from Alexey see:

[PATCH v3 1/2] lib/tst_test.c: add 'needs_drivers' option with tst_check_drivers cmd

Cyril Hrubis
[email protected]

Great! I'll fix this error by using it then.
Thank you!

This test depends on CONFIG_BLK_DEV_RAM kernel config option. If not, then errors like:

safe_macros.c:225: BROK: fsetxattr02.c:214:
open(mntpoint/fsetxattr02blk,0,00) failed: ENXIO safe_macros.c:225:
BROK: fgetxattr02.c:244: open(fgetxattr02blk,0,00) failed: ENXIO

might happen. By using recent "needs_drivers" option we are able to mitigate this.

---
 testcases/kernel/syscalls/fsetxattr/fsetxattr02.c | 8 ++++++++
 1 file changed, 8 insertions(+)

index b0d4a84fb..89279c384 100644
@@ -58,6 +58,8 @@
 #define BLK      MNTPOINT"/fsetxattr02blk"
 #define SOCK     "fsetxattr02sock"
 
+#define DRVRAMDISK "brd"
+
 struct test_case {
 	char *fname;
 	int fd;

@@ -241,6 +243,11 @@ static void cleanup(void)
 	}
 }
 
+static const char *const needed_drivers[] = {
+	DRVRAMDISK,
+	NULL,
+};
+
 static struct tst_test test = {
 	.setup = setup,
 	.test = verify_fsetxattr,

@@ -249,6 +256,7 @@ static struct tst_test test = {
 	.needs_devfs = 1,
 	.mntpoint = MNTPOINT,
 	.needs_root = 1,
+	.needs_drivers = needed_drivers,
 };
 
 #else /* HAVE_SYS_XATTR_H */

2.19.0.rc2

Hi!

I find it a bit silly to define a macro for a string that is used exactly once. Why can't we just write "brd", in the needed_drivers?

Cyril Hrubis
[email protected]

I got it from from an existing test Cyril. I confess I thought the same =), was afraid of being an etiquette or something. Feel free to drop it, no hard feelings!

Hi!

There is still a lot of silly code in LTP, just send a patch if you see some :-).

Cyril Hrubis
[email protected]

Hi!
I got rid of the macro and pushed, thanks.

Cyril Hrubis
[email protected]