All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] runtest/fs: Don't read files in /dev indiscriminately
Date: Mon, 14 May 2018 09:28:29 +0200	[thread overview]
Message-ID: <87lgcmy9uq.fsf@rpws.prws.suse.cz> (raw)
In-Reply-To: <20180511173156.30197-1-punit.agrawal@arm.com>

Hello,

Punit Agrawal writes:

> read_all_dev attempts to read 1024 bytes from all devices in /dev. As
> nodes in /dev represent devices, any access can have side-effects -
> sometimes fatally so, e.g., accessing /dev/port on Juno R2 and AMD
> Seattle lead to synchronous external abort or SError (system error)
> interrupt depending on the access pattern.
>
> There isn't much the kernel can do about the aborts other than panic
> the system.
>
> The side-effects problem is also highlighted by the recent exclusion
> added for watchdog devices. See commit 4a41aa6b48c134e ("runtest/fs:
> filter /dev/watchdog* for read_all_dev by default").
>
> It would be better to replace indiscriminate reading of /dev files
> with tests targeting specific files in /dev which have defined known
> behaviour, e.g., /dev/null, /dev/urandom, etc.
>
> In the meanwhile, drop the indiscriminate reading of files in /dev.

Another solution might be to add an option which drops privileges before
running the test on /dev. An unprivileged user should not have access to files
like /dev/port, but will for /dev/null and /dev/urandom.

>
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: xuyang.jy@cn.fujitsu.com
> Cc: naresh.kamboju@linaro.org
> Cc: rpalethorpe@suse.com
> Cc: chrubis@suse.cz
> Cc: james.morse@arm.com
> ---
> Hi,
>
> The test leads to panic during nightly ltp runs on internal
> systems. Looking at the crash report from Naresh[0], it looks likely
> that he's facing the same problem.
>
> Please consider including in upcoming release.
>
> Thanks,
> Punit
>
> [0] http://lists.linux.it/pipermail/ltp/2018-May/007954.html
> ---
>  runtest/fs | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/runtest/fs b/runtest/fs
> index 42a9bfcbf..c7ed64fbf 100644
> --- a/runtest/fs
> +++ b/runtest/fs
> @@ -69,7 +69,6 @@ fs_di fs_di -d $TMPDIR
>  # Was not sure why it should reside in runtest/crashme and won´t get tested ever
>  proc01 proc01 -m 128
>
> -read_all_dev read_all -d /dev -e '/dev/watchdog?(0)' -q -r 10
>  read_all_proc read_all -d /proc -q -r 10
>  read_all_sys read_all -d /sys -q -r 10


--
Thank you,
Richard.

  reply	other threads:[~2018-05-14  7:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 17:31 [LTP] [PATCH] runtest/fs: Don't read files in /dev indiscriminately Punit Agrawal
2018-05-14  7:28 ` Richard Palethorpe [this message]
2018-05-14  8:53   ` Cyril Hrubis
2018-05-14  9:04     ` Richard Palethorpe
2018-05-14 10:07   ` Punit Agrawal

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=87lgcmy9uq.fsf@rpws.prws.suse.cz \
    --to=rpalethorpe@suse.de \
    --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.