Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Not knowing the /proc file system

admccartney.mur.at

Post reply on HN
Print view View original

41–50 of 111 posts

Re: Not knowing the /proc file system

#41

Post by aunderscored »

williamcotton wrote: post #32

This is running in a barebones Ubuntu container on my MacBook as BSDs don't use /proc: root@74c03a282fbe:/# ed a ls /proc/[0-9]/status | xargs -n 1 cat | awk '/^Name:/ { name = $2 } /^Pid:/ { pid = $2 } END { print "cmd: " name ", pid: " pid }' . w prc.sh 132 q root@74c03a282fbe:/# chmod +x ./prc.sh root@74c03a282fbe:/# hyperfine --warmup=100 "./prc.sh" Benchmark 1: ./prc.sh Time (mean ± σ): 2.2 ms ± 0.3 ms [User: 1.…

I think you may have convinced me to learn more awk with this. I'd have constructed something horrible with sed or so to do this. And this is just much cleaner

Re: Not knowing the /proc file system

#42

Post by MayeulC »

IggleSniggle wrote: post #22
dezgeg wrote: post #20

Earlier quoted context omitted.

Because for some reason many C programmers still insist on 80-character line length limit and 8-wide tab indentation, so something has to give to fit all on the screen

8-wide tab is still just 1 char of your 80 allotted. Just sayin'.

Nah, kernel coding style counts tabs as 8 characters for indentation purposes. It is also discouraged to nest conditional structures too deeply.

Here's the very opinionated documentation: https://www.kernel.org/doc/html/v6.5/process/coding-style.ht...

I also want to note that the 80 columns limit was bumped to 100, and is no longer strictly enforced: https://www.phoronix.com/news/Linux-Kernel-Deprecates-80-Col

Re: Not knowing the /proc file system

#43

Post by williamcotton »

aunderscored wrote: post #41
williamcotton wrote: post #32

This is running in a barebones Ubuntu container on my MacBook as BSDs don't use /proc: root@74c03a282fbe:/# ed a ls /proc/[0-9]/status | xargs -n 1 cat | awk '/^Name:/ { name = $2 } /^Pid:/ { pid = $2 } END { print "cmd: " name ", pid: " pid }' . w prc.sh 132 q root@74c03a282fbe:/# chmod +x ./prc.sh root@74c03a282fbe:/# hyperfine --warmup=100 "./prc.sh" Benchmark 1: ./prc.sh Time (mean ± σ): 2.2 ms ± 0.3 ms [User: 1.…

I think you may have convinced me to learn more awk with this. I'd have constructed something horrible with sed or so to do this. And this is just much cleaner

The AWK Programming Language, Second Edition was just released. I'd say it's an instant classic! CSV support is slowly rolling out... you can compile Kernighan's nawk from source right now, gawk has it in trunk I think, and GoAwk has had support and is now also following the --csv design decision made by Mr. Kernighan.

Re: Not knowing the /proc file system

#44

Post by MobiusHorizons »

mhitza wrote: post #5
dale_glass wrote: post #4

Earlier quoted context omitted.

Just inertia from the times where teletypes were a thing. As in, a mechanical printer that served as your console. When you have that as your interface you want to keep things terse. Even after that you had compilers with limits like 6 character names for a symbol. Those constraints went away, but names made to be comfortable for the users of teletypes and ancient compilers stuck around, and people made more of them…

> Just inertia from the times where teletypes were a thing. As in, a mechanical printer that served as your console. That's more than inertia, that seems to cross the threshold for ceremony. When was the last time that actual printers/teletypes were used, the 60s? The inwrtia part of it is people imitating what they already see on a project (cause why would you disrupt something as a newcomer on a project) and line l…

There are benefits to keeping code less far to the right on the line for easy reading. I review a fair bit of code these days, and I’ve never once wished someone used more characters for their variable names. Long variable names have a tendency to make the code they are part of wrap a lot and become hard to read. I think a lot of people think that a verbose variable name is always better, so they end up lazy and don’t try to figure out what makes the variable interesting in context.

Re: Not knowing the /proc file system

#45

Post by __david__ »

Someone wrote: post #23
Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions AFAIK, as that StackOverflow page also says, that’s not guaranteed to be possible. https://man7.org/linux/man-pages/man2/read.2.html : “RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number…

Your best bet is to pass the maximum supported number for count to the call (SSIZE_MAX in POSIX, 0x7ffff000 on Linux, and hope that the call returns all bytes.

And then just hope your read buffer doesn’t overrun? Because 2GB is a lot of buffer to allocate for a read…

Re: Not knowing the /proc file system

#46

Post by marcosdumay »

Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

> The Linux kernel has no standard mechanism for delivering a variable-sized result from a system call.

Maybe we can expand the userspace networking interfaces, and make a fully featured messaging system. Some day Linux may even reach feature parity with L4!

Re: Not knowing the /proc file system

#47

Post by Someone »

dezgeg wrote: post #37
Someone wrote: post #23

Earlier quoted context omitted.

> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions AFAIK, as that StackOverflow page also says, that’s not guaranteed to be possible. https://man7.org/linux/man-pages/man2/read.2.html : “RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number…

In practice signals don't seem to be a problem for (most?) proc files as the seq_file infrastructure doesn't bother to check for pending signals and terminate the read if so. Naturally, only source reading will answer whether the proc file you're interested in is vulnerable to this or not.

> Naturally, only source reading will answer whether the proc file you're interested in is vulnerable to this or not.

At the moment. To be sure, you also have to keep track of changes to that source code to look for regressions, and have a mechanism to update all your deployed code if there is a regression there.

It could require multiple attempts at reading, and still doesn’t ensure progress, but I think /proc would be a lot more reliable if file contents included a good checksum.

Re: Not knowing the /proc file system

#48

Post by o11c »

Galanwe wrote: post #8
Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

I generally agree with your comment, especially coming from OpenBSD where /proc does not exist, for reasons you mentioned, as well as a purely practical one: let's not pressure the VFS for no reason. I think the biggest issue with /proc at the moment is that it leaks in core Linux components, and getting rid of it is becoming impossible. Some years ago I worked on adding `$ORIGIN` rpath support in OpenBSD and looked…

> Some years ago I worked on adding `$ORIGIN` rpath support in OpenBSD and looked at how Linux did it. Mind you, the dynamic linker (ldlinux.so) grabs the running executable path from /proc...

`getauxval(AT_EXECFN)` is "better" but there are weird edge cases with `fexecve` where you only get `AT_EXECFD`, even ignoring the inevitable TOCTOU.

Re: Not knowing the /proc file system

#49

Post by o11c »

Someone wrote: post #23
Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

> If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions AFAIK, as that StackOverflow page also says, that’s not guaranteed to be possible. https://man7.org/linux/man-pages/man2/read.2.html : “RETURN VALUE On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number…

There are several special file types where the return value of `read` is guaranteed more than the general case.

For example, `timerfd_create`'s returned FD guarantees that `read` will always return exactly 8.

Re: Not knowing the /proc file system

#50

Post by chasil »

Animats wrote: post #6

The Linux /proc "file system" is kernel to user space communication hammered into the wrong form because "everything is a file". /proc is a system call with a fake file system API, and this matters. The sample code won't work reliably, because it assumes that the "files" won't change while being read. If you read /proc, you must "read" each file with one unbuffered kernel read to be free of race conditions. See [1].…

I believe that the /proc filesystem first appeared commercially in Solaris, and was then adopted and expanded in Linux.

I got an SDF account recently, and was surprised to find it in NetBSD. OpenBSD has great resistance to it.

...looking at the wiki, many more kernels implement /proc:

"Many Unix-like operating systems support the proc filesystem, including Solaris, IRIX, Tru64 UNIX, BSD, Linux, IBM AIX, QNX, and Plan 9 from Bell Labs."

https://en.wikipedia.org/wiki/Procfs

Post reply on HN