All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Alexander Aring <aahringo@redhat.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/5] fcntl40: test for owner values on classic posix lock
Date: Fri, 7 Jul 2023 10:14:04 +0200	[thread overview]
Message-ID: <20230707081404.GA571797@pevik> (raw)
In-Reply-To: <CAK-6q+hsZxurnnd2snKr12R5UwieCnWhvgr5_OoDKAXorHNhTA@mail.gmail.com>

> 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


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

  reply	other threads:[~2023-07-07  8:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30 20:37 [LTP] [PATCH 0/5] fcntl: add more testcases Alexander Aring
2023-05-30 20:37 ` [LTP] [PATCH 1/5] fcntl40: test for owner values on classic posix lock Alexander Aring
2023-06-21  9:03   ` Petr Vorel
2023-06-30 19:59     ` Alexander Aring
2023-07-02 19:18       ` Petr Vorel
2023-07-05 13:23         ` Alexander Aring
2023-07-07  8:14           ` Petr Vorel [this message]
2023-07-07 12:50             ` Alexander Aring
2023-07-07 13:17               ` Petr Vorel
2023-07-02 19:19       ` Petr Vorel
2023-05-30 20:37 ` [LTP] [PATCH 2/5] fcntl41: test for owner values on OFD posix locks Alexander Aring
2023-06-21  9:38   ` Petr Vorel
2023-06-30 20:00     ` Alexander Aring
2023-05-30 20:37 ` [LTP] [PATCH 3/5] fcntl42: test for F_SETLKW interruption case Alexander Aring
2023-05-30 20:37 ` [LTP] [PATCH 4/5] fcntl43: test for identical F_SETLKW lock requests Alexander Aring
2023-05-30 20:37 ` [LTP] [PATCH 5/5] fcntl44: test for kill child while others waiting Alexander Aring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230707081404.GA571797@pevik \
    --to=pvorel@suse.cz \
    --cc=aahringo@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.