tools/testing/selftests/arm64/gcs/gcs-stress.c
Source file repositories/reference/linux-study-clean/tools/testing/selftests/arm64/gcs/gcs-stress.c
File Facts
- System
- Linux kernel
- Corpus path
tools/testing/selftests/arm64/gcs/gcs-stress.c- Extension
.c- Size
- 11722 bytes
- Lines
- 531
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: implementation source
- Status
- source implementation candidate
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
errno.hgetopt.hpoll.hsignal.hstdbool.hstddef.hstdio.hstdlib.hstring.hunistd.hsys/auxv.hsys/epoll.hsys/prctl.hsys/types.hsys/uio.hsys/wait.hasm/hwcap.hkselftest.h
Detected Declarations
struct child_datafunction num_processorsfunction start_threadfunction child_output_readfunction child_outputfunction child_ticklefunction child_stopfunction child_cleanupfunction handle_child_signalfunction handle_exit_signalfunction drain_outputfunction main
Annotated Snippet
struct child_data {
char *name, *output;
pid_t pid;
int stdout;
bool output_seen;
bool exited;
int exit_status;
int exit_signal;
};
static int epoll_fd;
static struct child_data *children;
static struct epoll_event *evs;
static int tests;
static int num_children;
static bool terminate;
static int startup_pipe[2];
static int num_processors(void)
{
long nproc = sysconf(_SC_NPROCESSORS_CONF);
if (nproc < 0) {
perror("Unable to read number of processors\n");
exit(EXIT_FAILURE);
}
return nproc;
}
static void start_thread(struct child_data *child, int id)
{
int ret, pipefd[2], i;
struct epoll_event ev;
ret = pipe(pipefd);
if (ret != 0)
ksft_exit_fail_msg("Failed to create stdout pipe: %s (%d)\n",
strerror(errno), errno);
child->pid = fork();
if (child->pid == -1)
ksft_exit_fail_msg("fork() failed: %s (%d)\n",
strerror(errno), errno);
if (!child->pid) {
/*
* In child, replace stdout with the pipe, errors to
* stderr from here as kselftest prints to stdout.
*/
ret = dup2(pipefd[1], 1);
if (ret == -1) {
fprintf(stderr, "dup2() %d\n", errno);
exit(EXIT_FAILURE);
}
/*
* Duplicate the read side of the startup pipe to
* FD 3 so we can close everything else.
*/
ret = dup2(startup_pipe[0], 3);
if (ret == -1) {
fprintf(stderr, "dup2() %d\n", errno);
exit(EXIT_FAILURE);
}
/*
* Very dumb mechanism to clean open FDs other than
* stdio. We don't want O_CLOEXEC for the pipes...
*/
for (i = 4; i < 8192; i++)
close(i);
/*
* Read from the startup pipe, there should be no data
* and we should block until it is closed. We just
* carry on on error since this isn't super critical.
*/
ret = read(3, &i, sizeof(i));
if (ret < 0)
fprintf(stderr, "read(startp pipe) failed: %s (%d)\n",
strerror(errno), errno);
if (ret > 0)
fprintf(stderr, "%d bytes of data on startup pipe\n",
ret);
close(3);
ret = execl("gcs-stress-thread", "gcs-stress-thread", NULL);
fprintf(stderr, "execl(gcs-stress-thread) failed: %d (%s)\n",
errno, strerror(errno));
Annotation
- Immediate include surface: `errno.h`, `getopt.h`, `poll.h`, `signal.h`, `stdbool.h`, `stddef.h`, `stdio.h`, `stdlib.h`.
- Detected declarations: `struct child_data`, `function num_processors`, `function start_thread`, `function child_output_read`, `function child_output`, `function child_tickle`, `function child_stop`, `function child_cleanup`, `function handle_child_signal`, `function handle_exit_signal`.
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: source implementation candidate.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.