- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

(no subject)
by Daniel Sept. 1, 2025

Sept. 1, 2025

1 0

Where is getname () defined
by Vulturus Aug. 31, 2025

Aug. 31, 2025

Dear kernelnewbies subscribers, I was reading the kernel source tree in an attempt to understand how the chroot syscall workes. (I was using the linux-6.17-rc3 tarball from kernel.org.) At line 1429 of the fs/open.c file, inside the definition of the do_sys_openat2() function getname() is called. I am having trouble finding its definition. In particular, $ grep -rn 'getname' fs doesn't return a line like 'struct file *getname (args)' or similar, as I would expect. Can someone point me to the file/line where getname() is defined? Thank you, Vulturus

4 3

FPGA based system controller
by Patryk Aug. 28, 2025

Aug. 28, 2025

Hi, I have an FPGA-based system controller connected over I2C to SoC running Linux. It currently exposes only one function (besides purely information things like sw version): selecting the boot source (via a register that takes effect after reboot). However in the future it will probably handle more functionalities like peripherals reset controller and interrupt controller. I'm wondering how I should approach this? My initial thought was that I could put the driver in the mfd that would load sub drivers but since it only has currently one functionality does it even make sense? The other thing is - how should I approach handling boot source selection? The simplest solution is by providing appropriate sysfs entries (e.g. syscon_bootsrc), allowing me to write the next boot source, but I'm wondering if there is any similar driver that I could reuse? I thought about reboot-mode but as the name suggests it's rather about mode (bootloader, recovery) selection than boot source selection. Thanks for guidance, Patryk

1 0

Re: git: list of my complaints about future graft removal
by Bagas Sanjaya Aug. 20, 2025

Aug. 20, 2025

On Tue, Aug 19, 2025 at 05:57:08PM +0400, Askar Safin wrote: > * As well as I understand, "git clone --depth=1" rely on grafts, too. > I hope "git clone --depth=1" will continue to work. So shallow clones should use git-replace(1) under the hood (both on initial clone, deepening with --shallow-since and --unshallow), right? Thanks. -- An old man doll... just what I always wanted! - Clara

1 0

Exchanging data between CPU and FPGA through shared DDR
by Patryk Aug. 19, 2025

Aug. 19, 2025

Hi, I'm working on a SoC where both the CPU and an FPGA have access to the same DDR memory. I need to exchange data between them. One idea I have is to reserve a portion of DDR via the device tree (reserved-memory node), so that the kernel will not use it, and then use ioremap (or similar) to expose that region to user space so an application can communicate with the FPGA. Is this the right approach, or is there a more recommended mechanism in the kernel for CPU - FPGA data exchange using shared DDR? Best regards Patryk

1 0

a little testing help from my friends
by jim.cromie＠gmail.com Aug. 3, 2025

Aug. 3, 2025

hello Kernelnewbies since folks periodically ask how to contribute to linux, let me humbly propose that you clone this, https://github.com/jimc/linux/tree/dd-classmap-fix-v4g build it, run it inside virtme-ng (a favorite tool), test it using the tools/testing/selftests script. its what Ive posted to LKML for consideration, here. https://lore.kernel.org/lkml/20250803035816.603405-1-jim.cromie@gmail.com/T… your help in testing this patchset may reduce GregKH's evaluation workload enough that he merges this in this cycle.

1 0

Linux Device Performance Analyses - Where are my cylces?
by Lucas Tanure Aug. 1, 2025

Aug. 1, 2025

Hey there, I'm a kernel developer working on an Android device with a 5.10 kernel. I'm trying to improve performance, and to do that, I need to figure out exactly where the CPU is spending its time. Our vendor provides a generic Android BSP, so the system is likely running many unnecessary processes for things like GPS and phone calls that my device doesn't even need. Since I don't have a good handle on all these processes, I want to create a detailed breakdown of all the tasks, workqueues, IRQs, kernel threads, softIRQs, and tasklets running and measure the CPU time each one is using. To do this, I've been using kernel traces with the following events: task:task_newtask sched:sched_process_fork sched:sched_process_exec sched:sched_process_exit sched:sched_switch irq:irq_handler_entry irq:irq_handler_exit irq:softirq_entry irq:softirq_exit workqueue:workqueue_execute_start workqueue:workqueue_execute_end syscalls:sys_enter_execve syscalls:sys_exit_execve syscalls:sys_enter_execveat syscalls:sys_exit_execveat However, the trace logs don't provide the full picture. For example, when a new process is executed, the logs don't specify the script being run. The sched_switch event tells me which PID is being executed, but multiple processes can originate from the same binary, so it's hard to distinguish them. To solve this, I've developed a patch for the do_execveat_common function to log all new processes along with their full command lines. I plan to use this patch with a Python script to parse the logs and generate a report on CPU usage. My main questions are: - Is my patch correct? When I log the new process, do current->pid and argv refer to the same new process? - It feels like logging new processes with their command lines is a fundamental requirement for this kind of analysis. Am I missing a better or more standard way of doing this? - I don't want to reinvent the wheel, so if there's a better way to analyze kernel performance on a device, I'd love to hear about it. After looking into other methods like eBPF and kprobes, I found that this patch is the most straightforward way to get the information I need. Any insights would be greatly appreciated! Thanks Lucas Tanure diff --git a/fs/exec.c b/fs/exec.c index 6e1f8628ab9c..ab797ba0571c 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -513,6 +513,49 @@ static int bprm_stack_limits(struct linux_binprm *bprm) return 0; } +static char* str_cmdline(int argc, struct user_arg_ptr argv, struct linux_binprm *bprm) +{ + char *buf = (char *)get_zeroed_page(GFP_KERNEL); + ssize_t pos = 0; + int arg; + + for (arg = 0; arg < argc; arg++) { + const char __user *str; + int len; + + str = get_user_arg_ptr(argv, arg); + if (IS_ERR(str)) + goto free_page; + + // this includes a final null. + len = strnlen_user(str, MAX_ARG_STRLEN); + if (!len) + goto free_page; + + if (!valid_arg_len(bprm, len)) + goto free_page; + + if (pos + len >= PAGE_SIZE) + break; // Return the command line up to a page + + len -= 1; // Don't copy the final null. + if (copy_from_user(buf+pos, str, len)) + goto free_page; + + pos += len; + + if (arg < argc - 1) + buf[pos++] = ' '; + } + + return buf; + +free_page: + free_page((unsigned long)buf); + + return NULL; +} + /* * 'copy_strings()' copies argument/environment strings from the old * processes's memory to the new process's stack. The call to get_user_pages() @@ -1874,6 +1917,7 @@ static int do_execveat_common(int fd, struct filename *filename, { struct linux_binprm *bprm; int retval; + char *cmdline; if (IS_ERR(filename)) return PTR_ERR(filename); @@ -1943,6 +1987,15 @@ static int do_execveat_common(int fd, struct filename *filename, bprm->argc = 1; } + cmdline = str_cmdline(bprm->argc, argv, bprm); + pr_info("%s pid: %d, comm: %s # filename: %s # cmdline: %s\n", __func__, + current->pid, + current->comm, + bprm->filename, + cmdline ? cmdline : "NULL"); + if (cmdline) + free_page((unsigned long)cmdline); + retval = bprm_execve(bprm, fd, filename, flags); out_free: free_bprm(bprm);

2 1

Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis
by Raka Gunarto July 25, 2025

July 25, 2025

Hi everyone, I'm a really new contributor and I sent off this RFC to LKML <https://lore.kernel.org/lkml/20250723140129.276874-1-rakagunarto@gmail.com/…>, when I probably should have floated the idea here first. In any case, I've pasted my RFC patch below and I would really like any feedback / suggestions on the idea. Thanks, Raka ---------- Forwarded message --------- From: Raka Gunarto <rakagunarto(a)gmail.com> Date: Wed, Jul 23, 2025 at 3:01 PM Subject: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis To: <linux-kernel(a)vger.kernel.org> Cc: Raka Gunarto <rakagunarto(a)gmail.com> This proposed patch introduces a new macro ASSUME_NONNULL to suppress false positives of null pointer dereference warnings during static analysis. The patch only includes the macro definition for Clang so far, as I could not silence GCC's static analyzer false positives without ensuring that it wouldn't affect the emitted code. I tested this patch and use of the macro successfully eliminates false positives when used properly and does not affect final code generation. I am new to contributing to the kernel, so I apologise in advance for any mistakes. I welcome all feedback or suggestions for improvement. Rationale: - Use of this optional macro can silence false positives which may reduce patches that fix false positives (such as AI generated patches). - Clear documentation of a non null assumption for other developers - Signal to reviewers to subject patches that use this macro to additional scrutiny, and require justification on why there isn't a null check in the code instead. Motivation: While running Clang's static analyzer on the Linux kernel, I encountered hundreds of false positives related to null pointer dereferences. One such example is in mm/slub.c, where the static analyzer incorrectly reports a potential null pointer dereference on line 3169. n is non-null at that point, but it is non obvious to the static analyzer (and to humans) that get_node() will always return a non-null pointer. Since it is in a performance crtical context, adding a null check would be undesirable (I think). A macro like this can be used to signal the pointer is invariably non-null, without adding a runtime check. Raka Gunarto (1): compiler_types.h: introduce ASSUME_NONNULL macro for static analysis include/linux/compiler-clang.h | 10 ++++++++++ include/linux/compiler_types.h | 5 +++++ 2 files changed, 15 insertions(+) -- 2.43.0

5 7

Intoduction
by Samiksha Palav July 15, 2025

July 15, 2025

Hi everyone, I’m Samiksha (a.k.a. Shdwcodr), an undergrad BCA student from India with a relentless drive to get deep into the Linux kernel. I've recently begun my journey contributing to the kernel, focusing on staging drivers, learning the kernel development workflow, and understanding the culture of patch submission and review. Over the past few days, I’ve: - Set up a local kernel build and testing workflow. - Sent out my first real patch (not a dummy), with more lined up. - Subscribed to key mailing lists and joined IRC channels to stay in the loop. - Started tracking patch feedback and diving into `scripts/checkpatch.pl`, git send-email, and the entire mailing list-based workflow. My short-term goal is to get multiple patches accepted into staging by early 2025, and long-term I’m aiming for the **LFX Kernel Mentorship Program in 2026**. I’ll be lurking, learning, and asking questions when stuck. Thanks in advance to everyone who shares knowledge and guidance — it means a lot to newcomers like me. Looking forward to learning from you all and giving back as I grow. Cheers, Samiksha (Shdwcodr) [GitLab/GitHub link if you want to include one]

7 10

Introduction
by Samiksha Palav July 10, 2025

July 10, 2025

Hi everyone, I’m Samiksha (a.k.a. Shdwcodr), an undergrad BCA student from India with a relentless drive to get deep into the Linux kernel. I've recently begun my journey contributing to the kernel, focusing on staging drivers, learning the kernel development workflow, and understanding the culture of patch submission and review. Over the past few days, I’ve: - Set up a local kernel build and testing workflow. - Sent out my first real patch (not a dummy), with more lined up. - Subscribed to key mailing lists and joined IRC channels to stay in the loop. - Started tracking patch feedback and diving into `scripts/checkpatch.pl`, git send-email, and the entire mailing list-based workflow. My short-term goal is to get multiple patches accepted into staging by early 2025, and long-term I’m aiming for the **LFX Kernel Mentorship Program in 2026**. I’ll be lurking, learning, and asking questions when stuck. Thanks in advance to everyone who shares knowledge and guidance — it means a lot to newcomers like me. Looking forward to learning from you all and giving back as I grow. Cheers, Samiksha (Shdwcodr)

1 0