The 5.15 kernel has been released

Posted Nov 1, 2021 6:17 UTC (Mon) by developer122 (guest, #152928)
Parent article: The 5.15 kernel has been released

Mandatory locking seems like a really weird half-solution to a problem. Like they were very close to inventing the right solution, but because it was the 80's and everyone was making this shit up as they went along, they never quite settled on it.

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] (6 responses)

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]

> 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

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] (2 responses)

Dont count out tears of joy... Now there is only one locking system and the entire failure mode of advisory/mandatory lock interaction is dead.

The 5.15 kernel has been released

Posted Nov 1, 2021 21:16 UTC (Mon) by Anssi (subscriber, #52242) [Link] (1 responses)

There are still many advisory locking systems, e.g. BSD and POSIX locks:

https://gavv.github.io/articles/file-locks/
http://0pointer.de/blog/projects/locking
http://0pointer.de/blog/projects/locking2

The 5.15 kernel has been released

Posted Nov 1, 2021 21:53 UTC (Mon) by jhoblitt (subscriber, #77733) [Link]

I stand corrected. I thought for some reason there was a single system call that supported BSD and POSIX, style advisory locking.

https://github.com/torvalds/linux/blob/007b350a58754a93ca...
https://github.com/torvalds/linux/blob/007b350a58754a93ca...

I'm sure sooner or later there will be a 3rd linux specific set of system call(s) in order to have a [more] sane[-ish] solution.

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 19:24 UTC (Mon) by Wol (subscriber, #4433) [Link]

> There's nothing wrong with two programs opening the same file for writing at the same time.

Think databases. Or even filesystems. Do you really want somebody writing a file to have to lock the filesystem (after all, on nix it's just another file ...)

Cheers,
Wol

The 5.15 kernel has been released

Posted Nov 1, 2021 9:32 UTC (Mon) by atnot (subscriber, #124910) [Link] (1 responses)

Like a lot of Unix decisions that have not aged well, this is impossible because of fork(). You'd either have to allow duplicate writers anyway, or close them all on fork.

The 5.15 kernel has been released

Posted Nov 1, 2021 11:34 UTC (Mon) by josh (subscriber, #17465) [Link]

I think there's a useful third option there. If you open a file with a flag for a mandatory lock, then for as long as your file descriptor is open, nobody else can call open to get a file descriptor to that file. However, you can still fork, or dup2, or similar, to generate a copy of your file descriptor.

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 19:21 UTC (Mon) by Deleted user 129183 (guest, #129183) [Link]

> Mandatory locking seems like a really weird half-solution to a problem.

To be fair, Unix has been basically built on those weird half-solutions. And GNU/Linux is sometimes worse, because when the proprietary Unixes abandoned some earlier half-solutions already in the 80s or early 90s, GNU/Linux slavishly copied many of the earlier designs.