All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH v2] ioctl10: fix the sscanf() call to handle 64-bit inode on 32-bit arch
@ 2026-06-26 18:20 Jeff Layton via ltp
  2026-06-26 19:49 ` [LTP] " linuxtestproject.agent
  0 siblings, 1 reply; 2+ messages in thread
From: Jeff Layton via ltp @ 2026-06-26 18:20 UTC (permalink / raw)
  To: Linux Test Project; +Cc: Mark Brown, Jeff Layton

This test started failing recently on arm32, when we switched the
kernel to displaying the full 64-bit inode number in the maps file.
Change the testcase to allow for a full 64-bit inode number on all
arches. The value it's compared to is already 64-bits, so widening
this field is all that is necessary.

Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Changes in v2:
- Use SCNu64 instead of %llu in the sscanf() format string
- Link to v1: https://lore.kernel.org/r/20260626-master-v1-1-e4fcb95b232d@kernel.org
---
 testcases/kernel/syscalls/ioctl/ioctl10.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/testcases/kernel/syscalls/ioctl/ioctl10.c b/testcases/kernel/syscalls/ioctl/ioctl10.c
index b668c9e93889..8a4f8ae405e6 100644
--- a/testcases/kernel/syscalls/ioctl/ioctl10.c
+++ b/testcases/kernel/syscalls/ioctl/ioctl10.c
@@ -17,6 +17,7 @@
 
 #include "config.h"
 #include <stdlib.h>
+#include <inttypes.h>
 #include <sys/ioctl.h>
 #include <errno.h>
 #include <fnmatch.h>
@@ -35,7 +36,7 @@ struct map_entry {
 	unsigned long vm_pgoff;
 	unsigned int vm_major;
 	unsigned int vm_minor;
-	unsigned long vm_inode;
+	uint64_t vm_inode;
 	char vm_name[256];
 	unsigned int vm_flags;
 };
@@ -68,7 +69,7 @@ static void parse_maps_file(const char *filename, const char *keyword, struct ma
 
 	while (fgets(line, sizeof(line), fp) != NULL) {
 		if (fnmatch(keyword, line, 0) == 0) {
-			if (sscanf(line, "%lx-%lx %s %lx %x:%x %lu %s",
+			if (sscanf(line, "%lx-%lx %s %lx %x:%x %" SCNu64 " %s",
 						&entry->vm_start, &entry->vm_end, entry->vm_flags_str,
 						&entry->vm_pgoff, &entry->vm_major, &entry->vm_minor,
 						&entry->vm_inode, entry->vm_name) < 7)

---
base-commit: 534222c4f3908e9642f913399e37a66fdd266bbe
change-id: 20260626-master-55d29494ba06

Best regards,
-- 
Jeff Layton <jlayton@kernel.org>


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [LTP] ioctl10: fix the sscanf() call to handle 64-bit inode on 32-bit arch
  2026-06-26 18:20 [LTP] [PATCH v2] ioctl10: fix the sscanf() call to handle 64-bit inode on 32-bit arch Jeff Layton via ltp
@ 2026-06-26 19:49 ` linuxtestproject.agent
  0 siblings, 0 replies; 2+ messages in thread
From: linuxtestproject.agent @ 2026-06-26 19:49 UTC (permalink / raw)
  To: Jeff Layton; +Cc: ltp

Hi Jeff,

On Fri, 26 Jun 2026, Jeff Layton wrote:
> ioctl10: fix the sscanf() call to handle 64-bit inode on 32-bit arch

Verdict - Reviewed

Pre-existing issue (not introduced by this patch):

> 	SAFE_CLOSE(fd);

SAFE_CLOSE(fd) inside verify_ioctl() closes the fd opened in setup()
and sets it to -1. When run with -i N (multiple iterations),
subsequent iterations pass fd=-1 to ioctl(), causing EBADF. The fd
should only be closed in cleanup().

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-06-26 19:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-26 18:20 [LTP] [PATCH v2] ioctl10: fix the sscanf() call to handle 64-bit inode on 32-bit arch Jeff Layton via ltp
2026-06-26 19:49 ` [LTP] " linuxtestproject.agent

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.