0

If the answer is NO, that if root filesystem disk partition is lost for any reason, like dying hard drive or if booted via nfs rootfs and network is lost etc, if in these cases the kernel "no longer" has access to read or write to previously existing /proc/ files, then that's the answer, NO.

If the answer is YES, that the kernel still has access to already existing /proc/ because they are virtual and not really on any filesystem and so are still available after to kernel even after root "/" is lost, then how can I do the "equivalent" of:

"echo 1 > /proc/existingfile" but WITHOUT using call_usermodehelper but via some SYSCALL? where the "echo 1 >" can be replaced with some kernel SYSCALL so that "userland" is not relied upon because it won't be available in my scenario where root partition disappeared.

(UPDATE: In reply to a comment, perhaps SYSCALL was the wrong word, I don't care if SYSCALLS might be possible or impossible to call from inside kernel because they were made with user-space in mind. SysCall method is not the point, but I simply want to know of "any" possible method whereby I can trigger a "WRITE" to an existing /proc/file without the need of reading any input from "user-space".)

(UPDATE2: Would be nice if some Kernel authority can answer if the kernel still has access to read/write to a /proc/file even after the root "/" file system (let's say its rootfs over nfs) has become "unavailable". So far comments "contradict" on this issue, some say NO, others say YES, and others unsure etc.)

I do not want to simply cut to the chase and just do the action that putting a 1 into the existing file would have done based on kernel code. I want it to go through the usual vfs_write etc pathway "before" it does what echo 1 into /proc/existing file does. (I'm debugging some crashes/issues that's why I want it to go via this specific route.)

maybe related? Access /proc fs variable from other parts of Kernel code

htfree
  • 331
  • 1
  • 15
  • *but via some SYSCALL* That makes no sense. User-space programs use system calls to have the kernel to do something for them that the user space program can't do on its own. The kernel is the kernel - it doesn't need to use a system call to do that. – Andrew Henle Aug 05 '20 at 11:25
  • The files in `/proc` do not exist on disk. The kernel does not need the disk to access them except to resolve the path to `/proc`, and that information is probably cached. – Jonathan Leffler Aug 05 '20 at 13:03
  • /proc is only for userspace. It provides userspace access to kernel state. More generally, the kernel does not use filesystem services. It provides filesystem services. – stark Aug 05 '20 at 13:30
  • The root filesystem may need to be working enough to follow the path to the mountpoint /proc. – Ian Abbott Aug 05 '20 at 17:20
  • @AndrewHenle OK. Then perhaps I used the wrong word, I don't care the "methodology" but IF its possible from Kernel code to simply trigger a WRITE to /proc/somefile "without" user-space initiating the write. I realize its not "normal usage" scenario. – htfree Aug 05 '20 at 20:13
  • @JonathanLeffler Great thanks that's very helpful, and if so, it would indicate what I want to do is "technically" possible then. – htfree Aug 05 '20 at 20:16
  • @stark Yes I know but the question is not what it "does" but IF it can call/trigger in one place the very same services it "provides". If it creates the proc file via proc_create, why can't it write to it directly without need of input from user space. – htfree Aug 05 '20 at 20:18
  • @IanAbbott In my case the file created used "NULL" in the 3rd field of "proc_create", so its in the very root of proc. Also it seems that @ JonathanLeffler thinks that the path shouldn't be a problem. – htfree Aug 05 '20 at 20:22
  • 2
    Does intention of this question differ from your [previous one](https://stackoverflow.com/questions/63253217/linux-kernel-c-code-to-simulate-userland-writing-setting-a-value-to-proc-file)? "`echo 1 > /proc/existingfile` but WITHOUT using `call_usermodehelper` but via some SYSCALL?" - I already told you in the comment to your previous question, that kernel doesn't need to use `call_usermodehelper` for write a file. The kernel could open a file and write it using [corresponded functions](https://stackoverflow.com/questions/1184274/read-write-files-within-a-linux-kernel-module). – Tsyvarev Aug 06 '20 at 08:27
  • @Tsyvarev Thanks, actually yesterday I had already solved "part" of my problem and found a method similar to what you linked but without using filp_open but sys_open and vfs_write. So the answer to this question is YES its possible to write directly via vfs_write pathway at least while / available. On the other hand I still get the crash this way, versus via call_usermodehelper it doesn't crash. Might be related to some spin lock irq thing that's happening during get_user buffer transfer to kernel from user_space perhaps, been trying to find where that code is in the kernel but hard to follow. – htfree Aug 06 '20 at 17:23
  • @Tysvarev and sorry I guess i missed your comment on my other question. When i found the sys_open and vfs_write method I hadn't seen any response from you with the filp_open method etc. Perhaps method I'm using with sys_open is not really working correctly if that commenter is correct about 2.6.22 and above not able to use sys_open correctly. I will try the filp_open way and see. – htfree Aug 06 '20 at 17:29
  • The issue with writing to /proc from the kernel is that proc writes expect a userspace buffer and do copy_from_user. – stark Aug 10 '20 at 18:17

0 Answers0