The 5.15 kernel has been released
source link: https://lwn.net/Articles/874493/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
The 5.15 kernel has been released
This release may have started out with some -Werror pain, but it calmed down fairly quickly and on the whole 5.15 was fair small and calm. Let's hope for more of the same - without Werror issues this time - for the upcoming merge window.
The code name for this release has been set to "Trick or Treat".
Significant features in this release include: the realtime preemption locking code, descriptorless files for io_uring, BPF timers, the removal of mandatory file-locking support, the ksmbd SMB filesystem server (but see this article), printk() indexing, the process_mrelease() system call, The DAMON memory-management optimization system, the ntfs3 filesystem implementation, and much more. See the KernelNewbies 5.15 page for more information.
(Log in to post comments)
The 5.15 kernel has been released
Posted Nov 1, 2021 6:17 UTC (Mon) by developer122 (subscriber, #152928) [Link]
Like, why not just track who has opened a file for reading or for writing as normal, and then throw and error if two programs both try to open a file for writing (or any of the other undesirable combinations)? I realize that tracking this with regular read() calls and other elements of the API we all eventually adopted isn't exactly straightforward, but this was literally the group of guys who got to make all that stuff up.
The 5.15 kernel has been released
Posted Nov 1, 2021 9:11 UTC (Mon) by anselm (subscriber, #2796) [Link]
why not just track who has opened a file for reading or for writing as normal, and then throw and error if two programs both try to open a file for writing (or any of the other undesirable combinations)?
There's nothing wrong with two programs opening the same file for writing at the same time. If one program changes only the beginning of the file and the other only the end, there is no conflict (think “fixed-length records”). The problems start when both programs try to write to the same region of the file at the same time, which is where locking comes in.
Having said that, mandatory file locking was something that Unix-like operating systems never really treated very well (the popularity of purportedly “stateless” file-sharing approaches like NFS didn't help, either). Today people tend to use advisory file locking instead, and while that has its own drawbacks, few people will be in tears about the demise of mandatory file locking in Linux.
The 5.15 kernel has been released
Posted Nov 1, 2021 11:31 UTC (Mon) by josh (subscriber, #17465) [Link]
That seems like a useful extension, but mandatory locking seems like it still would have been useful if limited to "only original file descriptor (and the copies its owner makes) at a time".
The 5.15 kernel has been released
Posted Nov 1, 2021 14:26 UTC (Mon) by jhoblitt (subscriber, #77733) [Link]
The 5.15 kernel has been released
Posted Nov 1, 2021 15:00 UTC (Mon) by hubcapsc (subscriber, #98078) [Link]
>> the popularity of purportedly “stateless” file-sharing approaches like NFS didn't help, either
About eight or ten years ago I wrote a native Orangefs Apache DAV module that supported
locking by setting and unsetting an extended attribute. It passed the DAV correctness testers (I think one of them's name was "cadaver").
If someone locked a file and then didn't unlock it, that was bad :) ...
At the time I figured if two programs tried to lock a file at the same time,
one would win and one would lose, and my lock code just fired off the
lock request without checking any return codes, then it checked to see
if it got the lock, and then returned success or failure back to the caller.
Ida know if this really addressed the race condition, but that's how it worked.
-Mike "by 'native' I mean using the Orangefs API, not the kernel module"
The 5.15 kernel has been released
Posted Nov 1, 2021 9:32 UTC (Mon) by atnot (subscriber, #124910) [Link]
The 5.15 kernel has been released
Posted Nov 1, 2021 11:34 UTC (Mon) by josh (subscriber, #17465) [Link]
That way, another process can't independently open the file, but you can still use multiple threads or processes to operate on it.
The 5.15 kernel has been released
Posted Nov 1, 2021 8:04 UTC (Mon) by ddevault (subscriber, #99589) [Link]
The 5.15 kernel has been released
Posted Nov 1, 2021 9:28 UTC (Mon) by sdalley (subscriber, #18550) [Link]
I've always been impressed by the general lucidity and helpfulness of the kernel release notes on kernelnewbies. Who do we have to thank for these good release summaries?
The 5.15 kernel has been released
Posted Nov 1, 2021 9:55 UTC (Mon) by ashkulz (subscriber, #102382) [Link]
It's Diego Calleja, as per https://kernelnewbies.org/Linux_5.15?action=info
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK