From: Cyril Hrubis <chrubis@suse.cz>
To: Petr Vorel <pvorel@suse.cz>
Cc: Martin Doucha <martin.doucha@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] lib: tst_fd: Avoid tst_brk(TCONF, ...) on older distros
Date: Wed, 24 Jan 2024 16:19:24 +0100 [thread overview]
Message-ID: <ZbEqfGw9rbGzdDiD@yuki> (raw)
In-Reply-To: <20240124145632.GA307120@pevik>
Hi!
> Actually, the solution I posted [1] works on both old (affected) kernel and new
> one:
>
> - fd->fd = syscall(__NR_pidfd_open, getpid(), 0);
> + fd->fd = tst_syscall(__NR_pidfd_open, getpid(), 0);
> if (fd->fd < 0)
> tst_brk(TBROK | TERRNO, "pidfd_open()");
This cannot work on kenrel that does not implement pidfd_open. That's
what the code in tst_syscall() does:
#define tst_syscall(NR, ...) ({ \
intptr_t tst_ret; \
if (NR == __LTP__NR_INVALID_SYSCALL) { \
errno = ENOSYS; \
tst_ret = -1; \
} else { \
tst_ret = syscall(NR, ##__VA_ARGS__); \
} \
if (tst_ret == -1 && errno == ENOSYS) { \
TST_SYSCALL_BRK__(NR, #NR); \
} \
tst_ret; \
})
This means that either if the syscall number is undefined or if the
actuall syscall fails with ENOSYS we call tst_brk(TCONF, ...) or
tst_brkm(TCONF, ...) on old API.
> I guess we should merge your solution (otherwise we would need to change other
> cases to be consistent), but I'm a bit confused. Is it the reason why we use
> syscall() + tst_res(TCONF) instead of tst_syscall() + tst_brk(TBROK) that for
> some cases it's expected to fail, thus TBROK is not accepted? Again, I was blind
> when doing review.
The problem is that if kernel does not implement a particular syscall
the tst_syscall() calls tst_brk() which ends the tst_fd iteration in the
middle. The tst_fd iterator just loop over different types of file
descriptors, if you call tst_brk() anywhere the test ends before we
managed to finish the loop. We do not want that to happen because of
either syscall not implemented in older kernels or syscalls disabled by
CONFIG options.
That's why we have to call syscall() and do tst_res(TCONF, ...) when the
syscall had failed. The tst_fd_next() will just continue with next fd
type if we failed to produce a valid fd.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-01-24 15:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 12:58 [LTP] [PATCH] lib: tst_fd: Avoid tst_brk(TCONF, ...) on older distros Cyril Hrubis
2024-01-24 13:54 ` Martin Doucha
2024-01-24 14:10 ` Petr Vorel
2024-01-24 14:11 ` Cyril Hrubis
2024-01-24 14:22 ` Petr Vorel
2024-01-24 14:16 ` Petr Vorel
2024-01-24 14:21 ` Cyril Hrubis
2024-01-24 14:25 ` Petr Vorel
2024-01-24 14:36 ` Martin Doucha
2024-01-24 14:56 ` Petr Vorel
2024-01-24 15:19 ` Cyril Hrubis [this message]
2024-01-24 15:50 ` Petr Vorel
2024-01-24 16:57 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZbEqfGw9rbGzdDiD@yuki \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=martin.doucha@suse.com \
--cc=pvorel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox