From: Andrzej Hajda <andrzej.hajda@intel.com>
To: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
igt-dev@lists.freedesktop.org
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>,
Karol Krol <karol.krol@intel.com>
Subject: Re: [igt-dev] [PATCH v2 i-g-t] runner: check disk limit at dumping kmsg
Date: Thu, 20 Apr 2023 15:03:32 +0200 [thread overview]
Message-ID: <5a2ff1e5-026c-c8e7-aa77-e003143c3ecd@intel.com> (raw)
In-Reply-To: <20230227142748.28811-1-kamil.konieczny@linux.intel.com>
Hi,
On 27.02.2023 15:27, Kamil Konieczny wrote:
> It was reported that kernel dumps can grow beyond disk limit size
> so add checks for it and report error if that happen.
>
> v2: return number of written bytes (Petri)
>
> Reported-by: Karol Krol <karol.krol@intel.com>
> Ref: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/129
> Cc: Petri Latvala <adrinael@adrinael.net>
> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
> Reviewed-by: Petri Latvala <adrinael@adrinael.net>
It looks correct, however the main issue is that logs cut are quite
often unusable, the vital info is usually at the end.
From my observation the long dmesg is usually a result of trace dump in
dmesg.
Limiting it in .config should help, currently it is:
CONFIG_GLOBAL_TRACE_BUF_SIZE=1441792
It seems huge since it is very compressed comparing to dmesg.
Anyway, going back to the subject:
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Regards
Andrzej
> ---
> runner/executor.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/runner/executor.c b/runner/executor.c
> index 597cd7f5..ae6cf1bb 100644
> --- a/runner/executor.c
> +++ b/runner/executor.c
> @@ -584,7 +584,7 @@ void close_outputs(int *fds)
> }
>
> /* Returns the number of bytes written to disk, or a negative number on error */
> -static long dump_dmesg(int kmsgfd, int outfd)
> +static long dump_dmesg(int kmsgfd, int outfd, size_t disk_limit)
> {
> /*
> * Write kernel messages to the log file until we reach
> @@ -599,12 +599,18 @@ static long dump_dmesg(int kmsgfd, int outfd)
> bool underflow_once = false;
> char cont;
> char buf[2048];
> - ssize_t r;
> + ssize_t r, disk_written;
> long written = 0;
>
> if (kmsgfd < 0)
> return 0;
>
> + disk_written = lseek(outfd, 0, SEEK_SET);
> + if (disk_written > disk_limit) {
> + errf("Error dumping kmsg: disk limit already exceeded\n");
> + return 0; /* number of written bytes */
> + }
> +
> comparefd = open("/dev/kmsg", O_RDONLY | O_NONBLOCK);
> if (comparefd < 0) {
> errf("Error opening another fd for /dev/kmsg\n");
> @@ -655,6 +661,13 @@ static long dump_dmesg(int kmsgfd, int outfd)
>
> write(outfd, buf, r);
> written += r;
> + disk_written += r;
> +
> + if (disk_written > disk_limit) {
> + close(comparefd);
> + errf("Error dumping kmsg: disk limit exceeded\n");
> + return written;
> + }
>
> if (comparefd < 0 && sscanf(buf, "%u,%llu,%llu,%c;",
> &flags, &seq, &usec, &cont) == 4) {
> @@ -890,6 +903,7 @@ static int monitor_output(pid_t child,
> unsigned long taints = 0;
> bool aborting = false;
> size_t disk_usage = 0;
> + const size_t mon_disk_limit = settings->disk_usage_limit ? : (~(size_t)0);
> bool socket_comms_used = false; /* whether the test actually uses comms */
> bool results_received = false; /* whether we already have test results that might need overriding if we detect an abort condition */
>
> @@ -1219,7 +1233,7 @@ static int monitor_output(pid_t child,
>
> time_last_activity = time_now;
>
> - dmesgwritten = dump_dmesg(kmsgfd, outputs[_F_DMESG]);
> + dmesgwritten = dump_dmesg(kmsgfd, outputs[_F_DMESG], mon_disk_limit);
> if (settings->sync)
> fdatasync(outputs[_F_DMESG]);
>
> @@ -1457,7 +1471,7 @@ static int monitor_output(pid_t child,
> asprintf(abortreason, "Child refuses to die, tainted 0x%lx.", taints);
> }
>
> - dump_dmesg(kmsgfd, outputs[_F_DMESG]);
> + dump_dmesg(kmsgfd, outputs[_F_DMESG], mon_disk_limit);
> if (settings->sync)
> fdatasync(outputs[_F_DMESG]);
>
> @@ -1483,7 +1497,7 @@ static int monitor_output(pid_t child,
> }
> }
>
> - dump_dmesg(kmsgfd, outputs[_F_DMESG]);
> + dump_dmesg(kmsgfd, outputs[_F_DMESG], mon_disk_limit);
> if (settings->sync)
> fdatasync(outputs[_F_DMESG]);
>
next prev parent reply other threads:[~2023-04-20 13:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 14:27 [igt-dev] [PATCH v2 i-g-t] runner: check disk limit at dumping kmsg Kamil Konieczny
2023-02-27 16:09 ` [igt-dev] ✓ Fi.CI.BAT: success for runner: check disk limit at dumping kmsg (rev2) Patchwork
2023-02-27 22:32 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2023-02-28 20:11 ` Kamil Konieczny
2023-03-03 10:49 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2023-03-05 9:11 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2023-03-06 17:46 ` Patchwork
2023-03-07 0:02 ` Patchwork
2023-03-07 11:41 ` Patchwork
2023-04-19 13:39 ` [igt-dev] ✗ Fi.CI.BAT: failure for runner: check disk limit at dumping kmsg (rev3) Patchwork
2023-04-19 17:40 ` Kamil Konieczny
2023-04-20 9:51 ` [igt-dev] ✗ Fi.CI.BAT: failure for runner: check disk limit at dumping kmsg (rev4) Patchwork
2023-04-20 18:58 ` Kamil Konieczny
2023-04-21 14:20 ` Yedireswarapu, SaiX Nandan
2023-04-20 13:03 ` Andrzej Hajda [this message]
2023-04-21 9:19 ` [igt-dev] ✗ Fi.CI.BAT: failure for runner: check disk limit at dumping kmsg (rev5) Patchwork
2023-04-21 13:51 ` Patchwork
2023-04-21 14:16 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2023-04-21 15:39 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2023-04-24 15:05 ` Kamil Konieczny
2023-04-25 8:31 ` Kamil Konieczny
2023-04-25 13:05 ` Yedireswarapu, SaiX Nandan
2023-04-25 12:53 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2023-04-25 12:53 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2023-04-25 18:37 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
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=5a2ff1e5-026c-c8e7-aa77-e003143c3ecd@intel.com \
--to=andrzej.hajda@intel.com \
--cc=arkadiusz.hiler@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=karol.krol@intel.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