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
prev parent reply other threads:[~2026-08-14 6:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 11:25 [LTP] [PATCH 1/1] ima_setup.sh: Use tst_umount() Petr Vorel
2026-08-13 11:48 ` [LTP] " linuxtestproject.agent
2026-08-13 11:54 ` [LTP] [PATCH 1/1] " Andrea Cervesato via ltp
2026-08-14 1:18 ` Mimi Zohar
2026-08-14 6:01 ` Petr Vorel [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox