On Mon, Oct 16, 2017 at 4:37 PM, Cyril Hrubis chrubis@suse.cz wrote:
First half of them are writers where each of these loops:
- lock region in a file with posix write lock
- write to the region
- unlock it
While the second half loops concurently (time and file offset vise):
- lock region with read ofd lock
- read the region, expects it to be consistent block vise
- unlock it
As far as I can tell this is supposed to be supported combination
I've read the fs/locks.c implementation now and agree this should be supported: posix locks and ofd locks are in the same namespace but considered having different owners by definition, so they will conflict and the reader/writer should block on each other.
I don't see any interesting patches in that area between linux-4.4 and current mainline, or anything relevant that went into stable/linux-4.4.y
What filesystem is this testcase running against, i.e. what is in TMPDIR (defaults to /tmp) and what is mounted under that directory? We are running this test in SUSE against several kernel versions since it was introduced in the git repository and we never seen a failure, we are running it mostly against Btrfs though.
I hope Naresh can clarify but I suspect it might be NFS, which is a bit of a special case here. When checking whether two locks have the same owner, we call this function in the kernel:
static int posix_same_owner(struct file_lock *fl1, struct file_lock *fl2) { if (fl1->fl_lmops && fl1->fl_lmops->lm_compare_owner) return fl2->fl_lmops == fl1->fl_lmops && fl1->fl_lmops->lm_compare_owner(fl1, fl2); return fl1->fl_owner == fl2->fl_owner; }
The last line is used on all file systems, except on NFS, which uses
static int nlmsvc_same_owner(struct file_lock *fl1, struct file_lock *fl2) { return fl1->fl_owner == fl2->fl_owner && fl1->fl_pid == fl2->fl_pid; }
so it only applies if both the owner and pid fields match. Not sure how that could cause problems though. Possibly if the fl1->fl_lmops pointer is different here?
Arnd