fcntl locks, SEEK_END, and l_start
15 views
Skip to first unread message
Felipe Gasper
Jun 29, 2022, 9:53:44 AM6/29/22
to lib...@googlegroups.com
Hello,
libnfs.h defines struct nfs4_flock’s l_start as uint64_t. But l_whence is allowed to be SEEK_END.
When l_whence==SEEK_END, the implementation (nfs4_fcntl_stat_cb) seems to do a stat64, then set the lock type to SEEK_SET, with l_start = nfs_size + l_start. But this seems apt to make the lock size *exceed* the file’s size, since l_start is always nonnegative.
Should l_start be int64_t instead of uint64_t? This would make it match off_t and thus allow negative offsets, which seems to be the intent.
A secondary question: in the SEEK_END case, does the caller have to ensure that *arg persists after nfs_fcntl_async returns? It looks like the same data structure gets referenced after the stat64 finishes; I had previously assumed that I could discard that data structure right away.
Thank you!
cheers,
-Felipe Gasper
libnfs.h defines struct nfs4_flock’s l_start as uint64_t. But l_whence is allowed to be SEEK_END.
When l_whence==SEEK_END, the implementation (nfs4_fcntl_stat_cb) seems to do a stat64, then set the lock type to SEEK_SET, with l_start = nfs_size + l_start. But this seems apt to make the lock size *exceed* the file’s size, since l_start is always nonnegative.
Should l_start be int64_t instead of uint64_t? This would make it match off_t and thus allow negative offsets, which seems to be the intent.
A secondary question: in the SEEK_END case, does the caller have to ensure that *arg persists after nfs_fcntl_async returns? It looks like the same data structure gets referenced after the stat64 finishes; I had previously assumed that I could discard that data structure right away.
Thank you!
cheers,
-Felipe Gasper
Reply all
Reply to author
Forward
0 new messages