All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-integrity@vger.kernel.org, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/1] ima_setup.sh: Use tst_umount()
Date: Fri, 14 Aug 2026 08:01:02 +0200	[thread overview]
Message-ID: <20260814060102.GC261864@pevik> (raw)
In-Reply-To: <b901f8d94a9d6e3faf26a5e359ad8ec7e306c931.camel@linux.ibm.com>

Hi Mimi,

> Hi Petr,

> On Thu, 2026-08-13 at 13:25 +0200, Petr Vorel wrote:
> > Use standard test mechanism to detect problems during umount() caused by
> > GNOME's gvfsd-trash daemon. Although it will not solve the problem it at
> > least warn tester.

> > Reported-by: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>

> With this patch applied and after removing everything other than ima_violations
> from /opt/ltp/runtest/ima, I'm still seeing:

> ima_violations 1 TINFO: $TMPDIR is on tmpfs => run on loop device
> ima_violations 1 TINFO: booted with IMA policy: tcb
> ima_violations 1 TINFO: using log /var/log/audit/audit.log
> ima_violations 1 TINFO: verify open writers violation
> ima_violations 1 TPASS: 1 open_writers violation(s) added
> ima_violations 2 TINFO: verify ToMToU violation
> ima_violations 2 TPASS: 1 ToMToU violation(s) added
> ima_violations 3 TINFO: verify open_writers using mmapped files
> tst_kconfig.c:90: TINFO: Parsing kernel config '/lib/modules/7.1.5-
> 101.fc43.x86_64/build/.config'
> ima_violations 3 TBROK: tst_checkpoint wait 10000 0 failed
> umount: /tmp/LTP_ima_violations.1OEcI81NHB/mntpoint: target is busy.
> ima_violations 3 TINFO: umount(/tmp/LTP_ima_violations.1OEcI81NHB/mntpoint)
> failed, try 1 ...
> ima_violations 3 TINFO: Likely gvfsd-trash is probing newly mounted  fs, kill it
> to speed up tests.
> umount: /tmp/LTP_ima_violations.1OEcI81NHB/mntpoint: target is busy.
> ima_violations 3 TINFO: umount(/tmp/LTP_ima_violations.1OEcI81NHB/mntpoint)
> failed, try 2 ...

I wonder if the process on your machine is gvfsd-trash or something else.
Unfortunately what we can do is probably just an advice to user, killing any
userspace process is probably too aggressive. So the current isn't really a
workaround just kind of a hint.

> The message keeps repeating ...

Yeah, I wonder if trying 50x makes even sense, IMHO 5x would be enough.

FYI the current code in tst_test.sh:

tst_umount()
{
	local mntpoint="${1:-$TST_MNTPOINT}"
	local i=0

	[ -z "$mntpoint" ] && return

	if ! echo "$mntpoint" | grep -q ^/; then
		tst_brk TCONF "The '$mntpoint' is not an absolute path"
	fi

	if ! grep -q "${mntpoint%/}" /proc/mounts; then
		tst_res TINFO "The '$mntpoint' is not mounted, skipping umount"
		return
	fi

	while [ "$i" -lt 50 ]; do
		if umount "$mntpoint" > /dev/null; then
			return
		fi

		i=$((i+1))

		tst_res TINFO "umount($mntpoint) failed, try $i ..."
		tst_res TINFO "Likely gvfsd-trash is probing newly mounted "\
		              "fs, kill it to speed up tests."

		tst_sleep 100ms
	done

	tst_res TWARN "Failed to umount($mntpoint) after 50 retries"
}

Kind regards,
Petr

> Mimi


> > ---
> >  testcases/kernel/security/integrity/ima/tests/ima_setup.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)

> > diff --git a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
> > index 19f00532b1..054ab28611 100644
> > --- a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
> > +++ b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
> > @@ -313,7 +313,7 @@ ima_cleanup()
> >  	[ -n "$TST_CLEANUP_CALLER" ] && $TST_CLEANUP_CALLER

> >  	for dir in $UMOUNT; do
> > -		umount $dir
> > +		tst_umount $dir
> >  	done

> >  	if [ "$IMA_POLICY_LOADED" = 1 ]; then

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

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: ltp@lists.linux.it, linux-integrity@vger.kernel.org
Subject: Re: [PATCH 1/1] ima_setup.sh: Use tst_umount()
Date: Fri, 14 Aug 2026 08:01:02 +0200	[thread overview]
Message-ID: <20260814060102.GC261864@pevik> (raw)
In-Reply-To: <b901f8d94a9d6e3faf26a5e359ad8ec7e306c931.camel@linux.ibm.com>

Hi Mimi,

> Hi Petr,

> On Thu, 2026-08-13 at 13:25 +0200, Petr Vorel wrote:
> > Use standard test mechanism to detect problems during umount() caused by
> > GNOME's gvfsd-trash daemon. Although it will not solve the problem it at
> > least warn tester.

> > Reported-by: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: Petr Vorel <pvorel@suse.cz>

> With this patch applied and after removing everything other than ima_violations
> from /opt/ltp/runtest/ima, I'm still seeing:

> ima_violations 1 TINFO: $TMPDIR is on tmpfs => run on loop device
> ima_violations 1 TINFO: booted with IMA policy: tcb
> ima_violations 1 TINFO: using log /var/log/audit/audit.log
> ima_violations 1 TINFO: verify open writers violation
> ima_violations 1 TPASS: 1 open_writers violation(s) added
> ima_violations 2 TINFO: verify ToMToU violation
> ima_violations 2 TPASS: 1 ToMToU violation(s) added
> ima_violations 3 TINFO: verify open_writers using mmapped files
> tst_kconfig.c:90: TINFO: Parsing kernel config '/lib/modules/7.1.5-
> 101.fc43.x86_64/build/.config'
> ima_violations 3 TBROK: tst_checkpoint wait 10000 0 failed
> umount: /tmp/LTP_ima_violations.1OEcI81NHB/mntpoint: target is busy.
> ima_violations 3 TINFO: umount(/tmp/LTP_ima_violations.1OEcI81NHB/mntpoint)
> failed, try 1 ...
> ima_violations 3 TINFO: Likely gvfsd-trash is probing newly mounted  fs, kill it
> to speed up tests.
> umount: /tmp/LTP_ima_violations.1OEcI81NHB/mntpoint: target is busy.
> ima_violations 3 TINFO: umount(/tmp/LTP_ima_violations.1OEcI81NHB/mntpoint)
> failed, try 2 ...

I wonder if the process on your machine is gvfsd-trash or something else.
Unfortunately what we can do is probably just an advice to user, killing any
userspace process is probably too aggressive. So the current isn't really a
workaround just kind of a hint.

> The message keeps repeating ...

Yeah, I wonder if trying 50x makes even sense, IMHO 5x would be enough.

FYI the current code in tst_test.sh:

tst_umount()
{
	local mntpoint="${1:-$TST_MNTPOINT}"
	local i=0

	[ -z "$mntpoint" ] && return

	if ! echo "$mntpoint" | grep -q ^/; then
		tst_brk TCONF "The '$mntpoint' is not an absolute path"
	fi

	if ! grep -q "${mntpoint%/}" /proc/mounts; then
		tst_res TINFO "The '$mntpoint' is not mounted, skipping umount"
		return
	fi

	while [ "$i" -lt 50 ]; do
		if umount "$mntpoint" > /dev/null; then
			return
		fi

		i=$((i+1))

		tst_res TINFO "umount($mntpoint) failed, try $i ..."
		tst_res TINFO "Likely gvfsd-trash is probing newly mounted "\
		              "fs, kill it to speed up tests."

		tst_sleep 100ms
	done

	tst_res TWARN "Failed to umount($mntpoint) after 50 retries"
}

Kind regards,
Petr

> Mimi


> > ---
> >  testcases/kernel/security/integrity/ima/tests/ima_setup.sh | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)

> > diff --git a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
> > index 19f00532b1..054ab28611 100644
> > --- a/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
> > +++ b/testcases/kernel/security/integrity/ima/tests/ima_setup.sh
> > @@ -313,7 +313,7 @@ ima_cleanup()
> >  	[ -n "$TST_CLEANUP_CALLER" ] && $TST_CLEANUP_CALLER

> >  	for dir in $UMOUNT; do
> > -		umount $dir
> > +		tst_umount $dir
> >  	done

> >  	if [ "$IMA_POLICY_LOADED" = 1 ]; then

  reply	other threads:[~2026-08-14  6:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 11:25 [PATCH 1/1] ima_setup.sh: Use tst_umount() Petr Vorel
2026-08-13 11:25 ` [LTP] " Petr Vorel
2026-08-13 11:48 ` [LTP] " linuxtestproject.agent
2026-08-13 11:54 ` [LTP] [PATCH 1/1] " Andrea Cervesato
2026-08-13 11:54   ` Andrea Cervesato via ltp
2026-08-14  1:18 ` Mimi Zohar
2026-08-14  1:18   ` Mimi Zohar
2026-08-14  6:01   ` Petr Vorel [this message]
2026-08-14  6:01     ` Petr Vorel
2026-09-22 17:22     ` [LTP] " Petr Vorel
2026-09-22 17:22       ` Petr Vorel

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=20260814060102.GC261864@pevik \
    --to=pvorel@suse.cz \
    --cc=linux-integrity@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=zohar@linux.ibm.com \
    /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.