From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
igt-dev@lists.freedesktop.org
Cc: Krzysztof Karas <krzysztof.karas@intel.com>
Subject: Re: [PATCH i-g-t v2 1/4] runner/executor: Check for error at writing dmesg dump
Date: Wed, 27 Nov 2024 07:09:51 +0100 [thread overview]
Message-ID: <18615b3c-b8a9-4ac2-8ecf-5b03a84b1ac5@linux.intel.com> (raw)
In-Reply-To: <20241120183208.146299-2-kamil.konieczny@linux.intel.com>
Hi,
I think that the handling of expected errors such as handling of
EINTR, and partial reads can be improved. I would argue to either
ignore the errors or handle them properly. Anything in between is
likely just creating problem for future selves. Here is my
proposal:
do
w = write(outfd, buf, r);
while (w == -1 && errno == EINTR);
if (w < r) {
if (w > 0) {
ssize_t total_written = w;
while (total_written < r) {
ssize_t w_partial = write(outfd, buf + total_written, r - total_written);
if (w_partial > 0)
total_written += w_partial;
else if (w_partial == -1 && errno == EINTR)
continue; /* Retry */
else {
long err = (w_partial == -1) ? -errno : -1;
errf("Write error while processing dmesg, errno=%d (%ld bytes written out of %ld)\n", errno, total_written, r);
if (comparefd >= 0)
close(comparefd);
return err;
}
}
} else {
/* Write comnpletely failed */
errf("Write error while processing dmesg, errno=%d\n", errno);
if (comparefd >= 0)
close(comparefd);
return errno;
}
}
written += r;
Notice that the expected errors are expected to fail more than
once, and that I tried to organize the code in way that feels
"to me" easier to follow by nesting if (w < r) and if (w > 0).
Also notice that it can block due to EINTR for ever.
While I compile tested this code, I wrote it to ask you what do
we really want to do?
0 - Forget about write errors until we face issues in real world?
1 - Get arbitrary about which write errors we want to deal with?
2 - Make an effort to make a bullet proof error checking for write?
As I mentioned earlier, I am slightly more inclined to do nothing,
but if that is off limits, I see no other path than 2.
Thanks,
Peter
On 20.11.2024 19:32, Kamil Konieczny wrote:
> In processing kernel dmesg there are checks for error at reading
> so add also one for writing.
>
> Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
> ---
> runner/executor.c | 29 ++++++++++++++++++++++++++---
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/runner/executor.c b/runner/executor.c
> index ac73e1dde..e4d1fc323 100644
> --- a/runner/executor.c
> +++ b/runner/executor.c
> @@ -600,7 +600,7 @@ static long dump_dmesg(int kmsgfd, int outfd)
> bool underflow_once = false;
> char cont;
> char buf[2048];
> - ssize_t r;
> + ssize_t r, w;
> long written = 0;
>
> if (kmsgfd < 0)
> @@ -654,9 +654,32 @@ static long dump_dmesg(int kmsgfd, int outfd)
> return written;
> }
>
> - write(outfd, buf, r);
> - written += r;
> + w = write(outfd, buf, r);
> + if (w < r) {
> + if (w == -1 && errno == EINTR)
> + w = write(outfd, buf, r);
> +
> + if (w < r && w >= 0)
> + w += write(outfd, buf + w, r - w);
> +
> + if (w < r) {
> + long err = -errno;
> +
> + if (err) {
> + errf("Write error while processing dmesg, errno=%d %ld < %ld\n", errno, w, r);
> + } else {
> + errf("Cannot write dmesg chunk: %ld < %ld\n", w, r);
> + err = -1;
> + }
>
> + if (comparefd >= 0)
> + close(comparefd);
> +
> + return err;
> + }
> + }
> +
> + written += r;
> if (comparefd < 0 && sscanf(buf, "%u,%llu,%llu,%c;",
> &flags, &seq, &usec, &cont) == 4) {
> /*
next prev parent reply other threads:[~2024-11-27 6:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 18:32 [PATCH i-g-t v2 0/4] runner: Allow limits at dumping dmesg Kamil Konieczny
2024-11-20 18:32 ` [PATCH i-g-t v2 1/4] runner/executor: Check for error at writing dmesg dump Kamil Konieczny
2024-11-27 6:09 ` Peter Senna Tschudin [this message]
2024-11-27 15:05 ` [i-g-t,v2,1/4] " Ryszard Knop
2024-11-29 19:31 ` [i-g-t, v2, 1/4] " Kamil Konieczny
2024-11-20 18:32 ` [PATCH i-g-t v2 2/4] runner/executor: Limit reading dmesg to chunks Kamil Konieczny
2024-11-27 15:12 ` [i-g-t,v2,2/4] " Ryszard Knop
2024-11-29 19:24 ` Kamil Konieczny
2024-11-20 18:32 ` [PATCH i-g-t v2 3/4] runner/executor: Fix error handling at terminating test Kamil Konieczny
2024-11-27 14:32 ` [i-g-t,v2,3/4] " Ryszard Knop
2024-11-20 18:32 ` [PATCH i-g-t v2 4/4] runner/executor: Inform about terminating Kamil Konieczny
2024-11-27 14:32 ` [i-g-t,v2,4/4] " Ryszard Knop
2024-11-20 19:52 ` ✓ Fi.CI.BAT: success for runner: Allow limits at dumping dmesg (rev2) Patchwork
2024-11-21 4:39 ` ✗ Xe.CI.Full: failure " Patchwork
2024-11-23 23:06 ` ✗ i915.CI.Full: " Patchwork
2024-11-26 11:54 ` [PATCH i-g-t v2 0/4] runner: Allow limits at dumping dmesg Sokolowski, Jan
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=18615b3c-b8a9-4ac2-8ecf-5b03a84b1ac5@linux.intel.com \
--to=peter.senna@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=kamil.konieczny@linux.intel.com \
--cc=krzysztof.karas@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