|
From: | Collin L. Walling |
Subject: | Re: [Qemu-devel] [PATCH] s390-ccw: print carriage return with new lines |
Date: | Wed, 25 Oct 2017 15:49:31 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 10/20/2017 07:37 AM, Halil Pasic wrote:
On 10/20/2017 12:25 PM, Christian Borntraeger wrote:From: "Collin L. Walling" <address@hidden> The sclp console in the s390 bios writes raw data, leading console emulators (such as virsh console) to treat a new line ('\n') as just a new line instead of as a Unix line feed. Because of this, output appears in a "stair case" pattern. Let's print \r\n on every occurrence of a new line in the string passed to write to amend this issue. This is in sync with the guest Linux code in drivers/s390/char/sclp_vt220.c which also does a line feed conversion in the console part of the driver. This fixes the s390-ccw and s390-netboot output like $ virsh start test --console Domain test started Connected to domain test Escape character is ^] Network boot starting... Using MAC address: 02:01:02:03:04:05 Requesting information via DHCP: 010The check for buffer overflow was not there previously, or? Maybe integrate that in the commit message too.
Good point.
Signed-off-by: Collin L. Walling <address@hidden> Signed-off-by: Christian Borntraeger <address@hidden> --- pc-bios/s390-ccw/s390-ccw.h | 3 +++ pc-bios/s390-ccw/sclp.c | 17 ++++++++++++++--- 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h index 25d4d21..a8bd204 100644 --- a/pc-bios/s390-ccw/s390-ccw.h +++ b/pc-bios/s390-ccw/s390-ccw.h @@ -33,6 +33,9 @@ typedef unsigned long long __u64; #ifndef EBUSY #define EBUSY 2 #endif +#ifndef EFBIG +#define EFBIG 3 +#endif #ifndef NULL #define NULL 0 #endif diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c index b1fc8ff..4795259 100644 --- a/pc-bios/s390-ccw/sclp.c +++ b/pc-bios/s390-ccw/sclp.c @@ -76,17 +76,28 @@ static int _strlen(const char *str) long write(int fd, const void *str, size_t len) { WriteEventData *sccb = (void *)_sccb; + const char *p; + size_t data_len = 0; if (fd != 1 && fd != 2) { return -EIO; } - sccb->h.length = sizeof(WriteEventData) + len; + for (p = str; *p; ++p) { + if (data_len > SCCB_DATA_LEN - 1) { + return -EFBIG; + }We could also do a partial write or do more that one sclp_service_call calls. I don't think EFBIG is entirely correct here. From the man page: """ EFBIG An attempt was made to write a file that exceeds the implementa- tion-defined maximum file size or the process’s file size limit, or to write at a position past the maximum allowed offset. """ That's not what we have here IMHO.
From my perspective, the error code was a tie between EFBIG (consider max sccb size as the maximum allowed offset) and ENOSPC: """ ENOSPC The device containing the file referred to by /fd/has no room for the data. """ (consider "the file" as the sccb data buffer) However, I extremely doubt we'll ever encounter an overflow from printing during the bios (why would we print something that large?) ... perhaps the check is redundant?
+ if (*p == '\n') { + sccb->data[data_len++] = '\r'; + } + sccb->data[data_len++] = *p; + } + + sccb->h.length = sizeof(WriteEventData) + data_len; sccb->h.function_code = SCLP_FC_NORMAL_WRITE; - sccb->ebh.length = sizeof(EventBufferHeader) + len; + sccb->ebh.length = sizeof(EventBufferHeader) + data_len; sccb->ebh.type = SCLP_EVENT_ASCII_CONSOLE_DATA; sccb->ebh.flags = 0; - memcpy(sccb->data, str, len); sclp_service_call(SCLP_CMD_WRITE_EVENT_DATA, sccb);Otherwise LGTM Halil
-- - Collin L Walling
[Prev in Thread] | Current Thread | [Next in Thread] |