public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v6] syscalls/fcntl36: add tests for OFD locks
Date: Tue, 29 Aug 2017 16:27:48 +0200	[thread overview]
Message-ID: <20170829142748.GA18897@rei.lan> (raw)
In-Reply-To: <1503560908-21618-1-git-send-email-xzhou@redhat.com>

Hi!
> +} tcases[] = {
> +
> +	{fn_ofd_r,   fn_ofd_w,
> +		NULL, NULL, "OFD read  locks vs OFD   write locks"},
> +	{fn_ofd_w,   fn_posix_w,
> +		NULL, NULL, "OFD write locks vs POSIX write locks"},
> +	{fn_ofd_r,   fn_posix_w,
> +		NULL, NULL, "OFD read  locks vs POSIX write locks"},
> +	{fn_posix_r, fn_ofd_w,
> +		NULL, NULL, "OFD write locks vs POSIX read  locks"},
> +	{fn_ofd_w,   fn_ofd_w,
> +		NULL, NULL, "OFD write locks vs OFD   write locks"},
> +
> +	{fn_ofd_r,   fn_ofd_w,   fn_posix_w,
> +		      NULL, "OFD   r/w locks vs POSIX write locks"},
> +	{fn_posix_r, fn_ofd_w,   fn_posix_w,
> +		      NULL, "POSIX r/w locks vs OFD   write locks"},
> +	{fn_ofd_r,   fn_posix_r, fn_ofd_w,
> +		      NULL, "OFD   r/w locks vs POSIX read locks"},
> +	{fn_ofd_r,   fn_posix_r, fn_posix_w,
> +		      NULL, "POSIX r/w locks vs OFD   read locks"},
> +
> +	{fn_ofd_r,   fn_posix_r, fn_posix_w, fn_ofd_w,
> +			    "OFD   r/w locks vs POSIX r/w locks"},

The cases that concurently run posix read vs. posix write locks
unfortunately does not work, since posix locks are process based we
cannot have more than one lock on a file region per process (threads are
counted as single process as well) and conflicting locks are converted
i.e. the last two will fail with wrongly read data in the fn_posix_r
funciton in a case that posix read and posix write locks were held
concurently (which happens for me and the test fails on my testing
machine).

We can run as many threads with ofd locks as we want, since these are
based on open file descriptors and we can add exactly one posix lock
thread to the mix as well but no more than that.

Moreover I think that we may need a pthread_barrier before we close the
file descriptors in the test functions since the posix locks are dropped
when any file descriptor asociated with the file is closed, since if we
run more than two threads and ofd thread closes the fd, the posix thread
looses it's lock and the remaining ofd thread(s) run concurently, it's
unlikely that something like this would happen, but it's possible.

> +};
> +
> +static void tests(unsigned int i)
> +{
> +	test_fn(tcases[i].fn0, tcases[i].fn1,
> +		tcases[i].fn2, tcases[i].fn3, tcases[i].desc);
> +}
> +
> +static struct tst_test test = {
> +	.min_kver = "3.15",
> +	.needs_tmpdir = 1,
> +	.test = tests,
> +	.tcnt = ARRAY_SIZE(tcases),
> +	.setup = setup
> +};
> -- 
> 1.8.3.1
> 

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2017-08-29 14:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-11  3:14 [LTP] [PATCH] syscalls/fcntl36: add tests for OFD locks Xiong Zhou
2017-08-14 16:02 ` Cyril Hrubis
2017-08-21 11:17   ` [LTP] [PATCH v2] " Xiong Zhou
2017-08-21 16:00     ` Cyril Hrubis
2017-08-22  8:35       ` [LTP] [PATCH v3] " Xiong Zhou
2017-08-22 14:23         ` Cyril Hrubis
2017-08-23  4:15           ` Xiong Zhou
2017-08-23  8:40             ` Cyril Hrubis
2017-08-23  9:42               ` [LTP] [PATCH v4] " Xiong Zhou
2017-08-23  9:53             ` [LTP] [PATCH v3] " Cyril Hrubis
2017-08-23 13:15               ` [LTP] [PATCH v5] " Xiong Zhou
2017-08-23 13:35                 ` Cyril Hrubis
2017-08-24  7:48                   ` [LTP] [PATCH v6] " Xiong Zhou
2017-08-29 14:27                     ` Cyril Hrubis [this message]
2017-09-01  3:00                       ` [LTP] [PATCH v7] " Xiong Zhou
2017-09-05 12:06                         ` Cyril Hrubis
2017-09-05 13:13                           ` Xiong Zhou

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=20170829142748.GA18897@rei.lan \
    --to=chrubis@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox