Implement Filelock

[crafcat7]

Summary

I made functional implementations of F_SETLK, F_SETLKW, F_GETLK in fcntl to extend the capabilities of fcntl.
The way to implement this is to use a simple Hashtable implementation, using the path as the key to store the lock information context of a file, from which you can go to the lock, unlock, merge locks and other operations.

Impact

Implemented file locking functionality, extending the F_SETLK, F_SETLKW, F_GETLK implementations in fcntl.

Testing

Through a series of tests on file locks, its functionality aligns with Linux file locks

[jturnsek]

If underlying fs is on a MTD device, function call file_fcntl(filep, F_GETPATH, path) returns with ENOTTY in my case where MX25L device is used to serve littlefs fileystem.

[xiaoxiang781216]

If underlying fs is on a MTD device, function call file_fcntl(filep, F_GETPATH, path) returns with ENOTTY in my case where MX25L device is used to serve littlefs fileystem.

our littlefs fs wrapper implement F_GETPATH to return the file name

[crafcat7]

If underlying fs is on a MTD device, function call file_fcntl(filep, F_GETPATH, path) returns with ENOTTY in my case where MX25L device is used to serve littlefs fileystem.

Please try this change #11729. I will submit the LFS support GET PATH implementation to another PR.

[yamt]

using a path as a file id for locking seems broken by design. (consider rename.)
can you consider to use something more appropriate?
eg. a dedicated id for file locking, which is not changed by a rename.

[xiaoxiang781216]

but how to get id from the different file system?

[yamt]

add it to file_operations. or it can be fcntl/ioctl as F_GETPATH.

[xiaoxiang781216]

The problem is that many fs designed for RTOS doesn't define the unique id in file metadata, adding file_operations can't resolve this problem.

[xiaoxiang781216]

I don't object to utilize some unique id, but this approach need improve all file system implementation, which isn't a minor work. The current implementation of filelock work well in most case. If your case require handle rename correctly, feel free to improve the current implementation, thanks.

[yamt]

well, actually, i don't have a motivation to improve file locking.
i'm just unhappy with having the local littlefs patch.

[xiaoxiang781216]

If you don't use file lock, could skip the local patch safely.

[yamt]

If you don't use file lock, could skip the local patch safely.

it doesn't solve the maintenance problem.

if no one wants to work on a solution, i'd suggest to revert it.

[xiaoxiang781216]

If you don't use file lock, could skip the local patch safely.

it doesn't solve the maintenance problem.

if no one wants to work on a solution, i'd suggest to revert it.

This feature is used by other community member not us. It work fine, why do you want to revert it?

[yamt]

If you don't use file lock, could skip the local patch safely.

it doesn't solve the maintenance problem.
if no one wants to work on a solution, i'd suggest to revert it.

This feature is used by other community member not us. It work fine, why do you want to revert it?

because it's responsibility for the person adding a feature to find a maintainable implementation.

my suggestion is

• introduce an optional api to query filesystems file id usable for this purpose. say, F_GETIDFORLOCK
• adapt this PR to use F_GETIDFORLOCK. when a filesystem doesn't support it, probably fall back to F_GETPATH. or just bail out with ENOTSUP or such.
• revert F_GETPATH patch in littlefs because it seems unacceptable for the upstream.
• add necessary api to the upstream littlefs, probably something along the line with: Support get file path littlefs-project/littlefs#976 (comment). importantly we should provide something the upstream littlefs can accept.
• implement F_GETIDFORLOCK in our littlefs driver, based on the new api. i guess you can iterate all open files and find aliases, and assign/reuse the in-core file id accordingly.

alternatively, you can probably try to convince the littlefs author to accept the get file path patch. if it gets merged in the upstream, i have no big objection against having the patch in our tree for older littlefs versions in the meantime. i personally agree with his rationale of the rejection though.