All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leo Liang <ycliang@andestech.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/1] cgroup/cgroup_regression_test: Fix umount failure
Date: Tue, 6 Jul 2021 11:27:48 +0800	[thread overview]
Message-ID: <20210706032748.GA16346@andestech.com> (raw)
In-Reply-To: <YNnJ18Q+cqb8zM5K@yuki>

Hi,

Sorry for the late response and thanks for all the replies and suggestions.

I am running on a rather new RISC-V platform (Andes/AE350) and with 5.4.0 off-tree kernel.
The umount in cgroup_regression_test mostly failed at test_2 and test_3, 
so it would show FAIL result (mount not successfully executed) at test_3 and test_5 (test_4 shows TCONF on my platform).

On Mon, Jun 28, 2021 at 03:08:39PM +0200, Cyril Hrubis wrote:
> Hi!
> > I would like a short comment close to the syncs. When I converted 
> > cpuset_regression_test.sh, I would have removed the sync in there, if 
> > there wouldn't have been any comment.
> > Most of the time syncs are not required and just added by paranoid 
> > developers, but if there is a real reason, I think it should be stated 
> > in a comment.
>
> Sounds reasonable to me, can we please add a comment there?

Hi Cyril and Joerg,

Sounds reasonable to me as well,
will send a v2 patch with comment.

> -- 
> Cyril Hrubis
> chrubis@suse.cz


> Agree with this. Are all these sync really needed? Or just some?

Hi Petr,

I've written a script containing only the following sequence
	" mount 'cgroup mntpoint' "
	" mkdir 'under cgroup mntpoint' "
	" rmdir 'under cgroup mntpoint' "
	" umount 'cgroup mntpoint' "
	" mount 'cgroup mntpoint' "
and it could trigger the fail.

But only bumped into the umount fail when doing test_2 and test_3 in the cgroup_regression_test.

I am adding syncs in every sub-tests that execute the above sequence now.
Should them be added only at the places where umount failure did occur ?

> Kind regards,
> Petr


> IMO, Even we call sync, this umount may fail because sync ensures 
> nothing.  Why not use tst_umount?

Hi Yang,

I think this might be a timing issue and a little delay could fix this problem. (e.g. 'sleep 1')
Using 'sync' here IMHO would be more descriptive and has a semantic meaning.

Speaking of tst_umount, do you mean to convert this test to C code ?

> Best Regards
> Yang Xu

Best regards,
Leo

  reply	other threads:[~2021-07-06  3:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28  3:30 [LTP] [PATCH 1/1] cgroup/cgroup_regression_test: Fix umount failure Leo Liang
2021-06-28  7:24 ` Richard Palethorpe
2021-06-28  7:36 ` Joerg Vehlow
2021-06-28  8:49   ` Petr Vorel
2021-06-28 13:08   ` Cyril Hrubis
2021-07-06  3:27     ` Leo Liang [this message]
2021-07-06  5:45       ` xuyang2018.jy
2021-07-12  7:28         ` Leo Liang
2021-06-29  7:01 ` xuyang2018.jy

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=20210706032748.GA16346@andestech.com \
    --to=ycliang@andestech.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.