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

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

[Naresh Kamboju]

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

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

[Rafael Tinoco]

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.

On Sat, Sep 15, 2018 at 7:09 AM Naresh Kamboju <naresh.kamboju@linaro.org>
wrote:

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

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

[Cyril Hrubis]

Hi!
> 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.

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
chrubis@suse.cz

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

[Rafael David Tinoco]

On Mon, Sep 17, 2018 at 5:45 AM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > 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.
>
> 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

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

[LTP] [PATCH] syscalls/fsetxattr02.c: Fix missing ramdisk module error

[Rafael David Tinoco]

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.

Link: https://bugs.linaro.org/show_bug.cgi?id=4011
Signed-off-by: Rafael David Tinoco <rafael.tinoco@linaro.org>
---
 testcases/kernel/syscalls/fsetxattr/fsetxattr02.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/testcases/kernel/syscalls/fsetxattr/fsetxattr02.c b/testcases/kernel/syscalls/fsetxattr/fsetxattr02.c
index b0d4a84fb..89279c384 100644
--- a/testcases/kernel/syscalls/fsetxattr/fsetxattr02.c
+++ b/testcases/kernel/syscalls/fsetxattr/fsetxattr02.c
@@ -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

[LTP] [PATCH] syscalls/fsetxattr02.c: Fix missing ramdisk module error

[Cyril Hrubis]

Hi!
> +#define DRVRAMDISK "brd"

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
chrubis@suse.cz

[LTP] [PATCH] syscalls/fsetxattr02.c: Fix missing ramdisk module error

[Rafael David Tinoco]

On 10/9/18 11:17 AM, Cyril Hrubis wrote:
> Hi!
>> +#define DRVRAMDISK "brd"
> 
> 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?

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!

[LTP] [PATCH] syscalls/fsetxattr02.c: Fix missing ramdisk module error

[Cyril Hrubis]

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?
> 
> 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!

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

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] [PATCH] syscalls/fsetxattr02.c: Fix missing ramdisk module error

[Cyril Hrubis]

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

-- 
Cyril Hrubis
chrubis@suse.cz