From: Cyril Hrubis <chrubis@suse.cz>
To: Jan Stancek <jstancek@redhat.com>
Cc: ltp-list@lists.sourceforge.net, liwan@redhat.com
Subject: Re: [LTP] [PATCH] runltp: export initialized LTP_DEV
Date: Tue, 20 Jan 2015 15:07:04 +0100 [thread overview]
Message-ID: <20150120140704.GA15452@rei> (raw)
In-Reply-To: <8593d893c637eadbac85711428be570e2636ef38.1421761305.git.jstancek@redhat.com>
> commit 5c7c3fb219957484db92111d423e4e2553fb580b removed initialization
> of empty LTP_DEV from setup(), but it also caused that LTP_DEV
> is no longer exported when it's initialized in set_block_device().
>
> This causes every test to attempt to get loop device on its own,
> which is not necessary and it also makes tests sporadically fail with EBUSY:
> creat06 9 TBROK : tst_device.c:156: ioctl(/dev/loop1, LOOP_CLR_FD, 0) failed: EBUSY
> creat06 10 TBROK : tst_device.c:156: Remaining cases broken
>
> The cause of EBUSY is unknown. Cyril suggested it might be gvfsd-trash,
> however I don't have such process and still get the failures sporadically.
The EBUSY I've seen was from umount() rather that from ioctl() and was
caused by stat() from gvfsd-trash. I'm sure of it.
In that case one of the testcases fails to umount the device as:
acct01 0 TWARN : acct01.c:225: umount device:/dev/loop1 failed: errno=EBUSY(16): Device or resource busy
I've never seen EBUSY from the ioctl() that removes the loop device,
that looks like a kernel bug to me.
> This patch restores behavior from ltp-20140828, where LTP_DEV is exported
> and tst_acquire_device() will use that instead of trying to acquire/release
> loopdev on its own.
That wouldn't do because that breaks the exectuion when device was not
passed to runltp. What about exporting it but only when it's non-empty?
--
Cyril Hrubis
chrubis@suse.cz
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next parent reply other threads:[~2015-01-20 14:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8593d893c637eadbac85711428be570e2636ef38.1421761305.git.jstancek@redhat.com>
2015-01-20 14:07 ` Cyril Hrubis [this message]
2015-01-20 14:25 ` [LTP] [PATCH] runltp: export initialized LTP_DEV Cyril Hrubis
2015-01-20 14:44 ` Cyril Hrubis
[not found] ` <1705158126.11277852.1421766771922.JavaMail.zimbra@redhat.com>
2015-01-20 15:20 ` Cyril Hrubis
[not found] ` <54BF77F1.4050007@redhat.com>
2015-01-21 10:36 ` Cyril Hrubis
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=20150120140704.GA15452@rei \
--to=chrubis@suse.cz \
--cc=jstancek@redhat.com \
--cc=liwan@redhat.com \
--cc=ltp-list@lists.sourceforge.net \
/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.