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

[Petr Vorel <pvorel@suse.cz>]

> Hi,

> On Fri, Jul 7, 2023 at 4:14 AM Petr Vorel <pvorel@suse.cz> wrote:

> > > 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},


> Can I override this setting by some ENV because I actually want to run
> it on a different filesystem which is using VFS posix lock
> implementation, because as I said I want to compare the results.

Sure, there is LTP_DEV_FS_TYPE. But the point is to write test which will be
useful for the default scenario.

Kind regards,
Petr

> - Alex


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp