[LTP] [PATCH 1/5] fcntl40: test for owner values on classic posix lock

[Petr Vorel]

> Hi,

> On Sun, Jul 2, 2023 at 3:18 PM Petr Vorel <pvorel@suse.cz> wrote:

> > Hi Alex,

> > ...
> > > > > + * [Description]
> > > > > + * Tests gfs2 dlm posix op queue handling in the kernel.
> > > > > + * It is recommended to run watch -n 0.1 "dlm_tool plocks $LS"
> > > > > + * aside to monitor dlm plock handling.
> > > > > + *
> > > > > + * [How to use it]
> > > > > + * Call it with TMPDIR=/mnt ./fcntl40 where TMPDIR is a gfs2 mountpoint.
> > > > I wonder if we could check for GFS2_MAGIC (we'd need to add it to
> > > > include/tst_fs.h => 0x01161970) and quit the test with tst_brk(TCONF) if TMPDIR
> > > > is not on gfs2.

> > > > ATM we don't have any helper in struct tst_test, which would do it.


> > > I will mention that gfs2 is only an example here. It becomes
> > > interesting when a file system implements its own .lock() callback OR
> > > if somebody wants to test file system core, when a filesystem does not
> > > implement its own .lock().

> > I see .lock is implemented in 9p, afs, ceph, cifs, ocfs2, orangefs, even NFS.
> > "file system core": do you mean VFS? Because that would be more usable than the
> > filesystems above (which are quite exotic).


> It depends here what they are doing in .lock() - If they just call
> locks_lock_file_wait() or similar helpers depending on the call, then
> they don't do much different than what vfs is doing.
> In case of gfs2/ocfs it is very special, it redirects their calls to
> DLM and DLM has its own whole posix implementation behind it. We only
> call locks_lock_file_wait() to keep the Linux bookkeeping in
> /proc/locks.

> What I am doing here is mostly trusting the Linux implementation and
> comparing results from e.g. tmpfs with GFS2 and I found issues.

> For now I trust the Linux implementation and check if we have a
> different result here. I need to be very careful here because
> GFS2/OCFS2 are cluster filesystems and the fcntl() interface was never
> made for cluster filesystems. However I currently only test "one node"
> locking and this should deliver the same results as tmpfs, etc.

Thanks for info.  I'm still not sure if this is useful only for gfs2/ocfs
and we should prepare block device with gfs2 or ocfs and test filesystem on it.
Or if it would be useful to test other filesystem implementation. In this latter
case we usually use .all_filesystems (we don't have proper docs for
.all_filesystems, the closest is [1]) and test is then run on various common
filesystems (see fs_type_whitelist[] in lib/tst_supported_fs_types.c), but in
that case gfs2 would be skipped (it's not a common filesystem).

In case preparing block device with gfs2 something like this might work:

static struct tst_test test = {
	...
	.dev_fs_type = "gfs2",
	.format_device = 1,
	.dev_fs_opts = (const char *const []){ "-t", "mycluster:mygfs2", "-p", "lock_dlm", "-j" , "2" , NULL},

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/wiki/C-Test-API#113-filesystem-type-detection-and-skiplist

> - Alex