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

[Alexander Aring]

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.

- Alex