Kernel resources

Help
1

first i understood nothing from that ticket i stared at it for literally 10 minutes i guess and then i started small (Making sure you’re not a bot! ) this ticket says that Running “ulimit” in Bash returns invalid argument then i thought to let’s just know about this ulimit then i went to my wsl and typed man ulimit and in the manual pages it said use getrlimit and setrlimit instead then i read the manual pages for getrlimit it says the resource arguments must be one of those RLIMITS
which was mentioned in the ticket then i came to know across a fact that bash cannot access these limits, memory or hardware it just takes permission from the kernel and kernel is the actual boss here so it is clue that when we run ulimit in the bash it’s just “user” gateway to interact with the kernel

then i opened my editor and typed grep -rn “getrlimit” src/system (the path was mentioned in the component section of the ticket) to find where this getrlimit function lives the terminal has so many outputs of getrlimit then i eliminated one by one to find where this function is actually implemented rather than being used then i came across __user__getrlimit function i thought this could be our target as the name of this is user__getrlimit then i went to that function there i found that it is doing nothing but returning a value got from calling a function named common__getrlimit then i went to the implementation of the that function in which this RLIMIT_FSIZE case is not handled so we found the location of the problem now i don’t know what limit do i have to set the current and hard to ! this is another struggle finally from manual pages and from google knowledge i came up with RLIM_INFINITY

it took a lot of effort just to get to the location of the problem i don’t know how i am going to solve those bigger issues in the kernel when easy tickets are taking this much of efforts

can anyone who have an expertise in the kernel suggest me some resources so that i could work better with the kernel

or any tips in navigating to the exact problem location in the file system could really help me!!

2

Yeah, it will.

There’s a lot of background knowledge involved here in order to make that one an “easy” fix (as it’s called on the bug tracker). You have to know that ulimit is just the user-facing program for the kernel-enforced limits, and what backend function calls and constants it uses to do that.

It does sound like you learned a lot going through this, which is great. But it’ll probably feel like a huge effort each time until you have the background knowledge built up.

1 Like
3

You may want to use @nipos’ helpful code search instance to search the source tree: https://grok.nikisoft.one/opengrok/

We could definitely use some better onboarding documentation for kernel development. Here’s a few tips and tricks:

  • _kern_ functions and _user_ functions are counterparts: the former are the userland syscall trampolines, the latter are the syscall implementations in the kernel. So any time you see a _kern_... function invoked, you can go look for the corresponding _user_... function with the same name to find its “implementation”.
  • strace is your friend when debugging syscalls (or when you think things might be going wrong with syscalls.) It can save a lot of time in a debugger to read through an strace output and see what’s going on. (Its filtering mechanisms are very useful too.)
  • The source tree layout mirrors the filesystem layout, approximately. So you’ll find drivers on the filesystem in add-ons/kernel and subdirectories, and in the source tree at src/add-ons/kernel and subdirectories, and so on.
3 Likes