[v2,1/3] tst: Extend cross-test-ssh.sh to specify if target date can be altered

Message ID 20210206175709.4691-1-lukma@denx.de
State Superseded
Delegated to: Adhemerval Zanella Netto
Headers
Series [v2,1/3] tst: Extend cross-test-ssh.sh to specify if target date can be altered |

Commit Message

Lukasz Majewski Feb. 6, 2021, 5:57 p.m. UTC
  This code adds new flag - '--allow-time-setting' to cross-test-ssh.sh
script to indicate if it is allowed to alter the date on the system
on which tests are executed. This change is supposed to be used with
test systems, which use virtual machines for testing.

The GLIBC_TEST_ALLOW_TIME_SETTING env variable is exported to the
remote environment on which the eligible test is run and brings no
functional change when it is not.

Changes for v2:
- Utilize flock to provide serialization of cross-test-ssh.sh script
  execution.
- Add entry to manual/install.texi about --allow-time-setting flag
  usage.
---
 manual/install.texi       |  2 ++
 scripts/cross-test-ssh.sh | 22 +++++++++++++++++++++-
 2 files changed, 23 insertions(+), 1 deletion(-)
  

Comments

Joseph Myers Feb. 8, 2021, 10:09 p.m. UTC | #1
On Sat, 6 Feb 2021, Lukasz Majewski wrote:

> This code adds new flag - '--allow-time-setting' to cross-test-ssh.sh
> script to indicate if it is allowed to alter the date on the system
> on which tests are executed. This change is supposed to be used with
> test systems, which use virtual machines for testing.
> 
> The GLIBC_TEST_ALLOW_TIME_SETTING env variable is exported to the
> remote environment on which the eligible test is run and brings no
> functional change when it is not.

I think there are two separate features here, both of which should be 
documented.  The ability to run tests that set the time should not be 
limited to when cross-test-ssh.sh is used; someone might want to write 
their own test wrapper supporting that feature (there's no requirement to 
use the provided test wrapper, writing your own is fully supported), or 
might want to run tests with setting time enabled for native testing (for 
example, if they have a build and test environment that creates a virtual 
machine to run "make check" natively on it and then destroys that virtual 
machine afterwards).

So at least two things should be documented:

* If you set GLIBC_TEST_ALLOW_TIME_SETTING in the environment in which 
tests are run *and* run the tests with appropriate privileges to be able 
to use clock_settime, then such tests will be run, but this will not by 
itself provide any locking against conflicting tests running in parallel 
so you should also either test in series or use a test wrapper that 
provides such locking.

* In the case of using cross-test-ssh.sh, you can pass the 
--allow-time-setting option to automate both setting 
GLIBC_TEST_ALLOW_TIME_SETTING and doing the locking.
  
Lukasz Majewski Feb. 10, 2021, 9:09 a.m. UTC | #2
Hi Joseph,

> On Sat, 6 Feb 2021, Lukasz Majewski wrote:
> 
> > This code adds new flag - '--allow-time-setting' to
> > cross-test-ssh.sh script to indicate if it is allowed to alter the
> > date on the system on which tests are executed. This change is
> > supposed to be used with test systems, which use virtual machines
> > for testing.
> > 
> > The GLIBC_TEST_ALLOW_TIME_SETTING env variable is exported to the
> > remote environment on which the eligible test is run and brings no
> > functional change when it is not.  
> 
> I think there are two separate features here, both of which should be 
> documented.  The ability to run tests that set the time should not be 
> limited to when cross-test-ssh.sh is used; someone might want to
> write their own test wrapper supporting that feature (there's no
> requirement to use the provided test wrapper, writing your own is
> fully supported), or might want to run tests with setting time
> enabled for native testing (for example, if they have a build and
> test environment that creates a virtual machine to run "make check"
> natively on it and then destroys that virtual machine afterwards).
> 

Thanks for the description.

> So at least two things should be documented:
> 
> * If you set GLIBC_TEST_ALLOW_TIME_SETTING in the environment in
> which tests are run *and* run the tests with appropriate privileges
> to be able to use clock_settime, then such tests will be run, but
> this will not by itself provide any locking against conflicting tests
> running in parallel so you should also either test in series or use a
> test wrapper that provides such locking.
> 
> * In the case of using cross-test-ssh.sh, you can pass the 
> --allow-time-setting option to automate both setting 
> GLIBC_TEST_ALLOW_TIME_SETTING and doing the locking.
> 

I will include information from above text to the install.texi.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
  

Patch

diff --git a/manual/install.texi b/manual/install.texi
index 419576f49c..2c8e49d31e 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -379,6 +379,8 @@  directory and @var{hostname} is the host name of a system that can run
 the newly built binaries of @theglibc{}.  The source and build
 directories must be visible at the same locations on both the build
 system and @var{hostname}.
+It is also possible to execute tests on the target machine, when passing
+@option{--allow-time-setting} flag, which would require setting date.
 
 In general, when testing @theglibc{}, @samp{test-wrapper} may be set
 to the name and arguments of any program to run newly built binaries.
diff --git a/scripts/cross-test-ssh.sh b/scripts/cross-test-ssh.sh
index 6d8fbcdfd2..c4b112aa1d 100755
--- a/scripts/cross-test-ssh.sh
+++ b/scripts/cross-test-ssh.sh
@@ -22,7 +22,7 @@ 
 
 progname="$(basename $0)"
 
-usage="usage: ${progname} [--ssh SSH] HOST COMMAND ..."
+usage="usage: ${progname} [--ssh SSH][--allow-time-setting] HOST COMMAND ..."
 help="Run a glibc test COMMAND on the remote machine HOST, via ssh,
 preserving the current working directory, and respecting quoting.
 
@@ -32,6 +32,11 @@  instead of ordinary 'ssh'.
 If the '--timeoutfactor FACTOR' flag is present, set TIMEOUTFACTOR on
 the remote machine to the specified FACTOR.
 
+If the '--allow-time-setting' flag is present, set
+GLIBC_TEST_ALLOW_TIME_SETTING on the remote machine to inform that
+time can be safely adjusted when e.g. tests are run in a virtual
+machine.
+
 To use this to run glibc tests, invoke the tests as follows:
 
   $ make test-wrapper='ABSPATH/cross-test-ssh.sh HOST' tests
@@ -81,6 +86,10 @@  while [ $# -gt 0 ]; do
       timeoutfactor="$1"
       ;;
 
+    "--allow-time-setting")
+      settimeallowed="1"
+      ;;
+
     "--help")
       echo "$usage"
       echo "$help"
@@ -127,6 +136,17 @@  if [ "$timeoutfactor" ]; then
 ${command}"
 fi
 
+# Add command to set the info that time on target can be adjusted,
+# if required.
+# Serialize execution of this script on host to prevent from unintended
+# change of target time.
+FLOCK_PATH="/var/lock/clock_settime"
+if [ "$settimeallowed" ]; then
+  exec 99<>${FLOCK_PATH}
+  flock 99 || { echo "Cannot lock ${FLOCK_PATH}"; exit 1; }
+  command="export GLIBC_TEST_ALLOW_TIME_SETTING=1 ${command}"
+fi
+
 # HOST's sshd simply concatenates its arguments with spaces and
 # passes them to some shell.  We want to force the use of /bin/sh,
 # so we need to re-quote the whole command to ensure it appears as