61–66 of 66 posts
Earlier quoted context omitted.
Since when can you use a MAC as an unprivileged user on an arbitrary distro?
Parent is referring to https://en.m.wikipedia.org/wiki/Mandatory_access_control As opposed to https://en.m.wikipedia.org/wiki/Medium_access_control
Earlier quoted context omitted.
What are the big changes in 6? links welcome.
https://kernelnewbies.org/Linux_6.0#io_uring_features but only mentions zero copy and https://lwn.net/Articles/879724/ also https://www.phoronix.com/news/Linux-6.0-IO-Block-IO_uring
Earlier quoted context omitted.
> Current io_uring is not particularly prone to vulnerabilities The tech industry: launch early! Develop in public! Many eyes make all bugs shallow! Also the tech industry: we will never forgive you for that one segfault you had ten years ago.
Excuse me? Io_uring is by far the most often exploited syscall on modern day Linux. Most often exploited subsystem even. https://www.phoronix.com/news/Google-Restricting-IO_uring
How do the exploits for io_uring compare to the exploits for the rest of the kernel?
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=%22linux%20...
Earlier quoted context omitted.
Not at all; with io_uring, you can copy multiple files in parallel (and in fewer syscalls), which is a huge win for small files.
On a hard disk, copying multiple files in parallel is likely to make the copy run slower because it spends more time seeking back and forth between the files ( except for small files). Perhaps that isn't a problem with SSDs? It seems like you'd still end up with the data from the different files interleaved in the erase blocks currently being written instead of contiguous, which seems like it would slow down all subs…
Certainly not; it's likely to make it run faster, since you can use the elevator algorithm more efficiently instead of seeking back and forth between the files. You can easily measure this yourself by using comparing wcp, which uses io_uring, and GNU cp (remember to empty the cache between each run).
Earlier quoted context omitted.
On a hard disk, copying multiple files in parallel is likely to make the copy run slower because it spends more time seeking back and forth between the files ( except for small files). Perhaps that isn't a problem with SSDs? It seems like you'd still end up with the data from the different files interleaved in the erase blocks currently being written instead of contiguous, which seems like it would slow down all subs…
> On a hard disk, copying multiple files in parallel is likely to make the copy run slower because it spends more time seeking back and forth between the files (except for small files). Certainly not; it's likely to make it run faster, since you can use the elevator algorithm more efficiently instead of seeking back and forth between the files. You can easily measure this yourself by using comparing wcp, which uses i…
Earlier quoted context omitted.
Interesting, I didn't realize inotify didn't work with FUSE. Is this a flaw in the FUSE interface, or is it just a deficiency in certain FUSE filesystems?
I think the key problem is that mapping from FUSE requests to inotify events requires information that only the FUSE daemon has. For example, lets say you open a file with O_CREAT. Whether this should trigger IN_CREATE depends on whether the file already exists. The kernel doesn't know this, and so couldn't be responsible for generating the IN_CREATE event. Now, the FUSE daemon could generate the event, but correctly…