From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
Cornelia Huck <cohuck@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
Bjoern Walk <bwalk@linux.vnet.ibm.com>,
David Hildenbrand <david@redhat.com>,
Pierre Morel <pmorel@linux.vnet.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>,
"Jason J . Herne" <jjherne@linux.vnet.ibm.com>,
"Collin L. Walling" <walling@linux.vnet.ibm.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] s390-ccw: print carriage return with new lines
Date: Fri, 20 Oct 2017 13:37:44 +0200 [thread overview]
Message-ID: <b04cf5cc-cfb4-1f36-1a8b-99a34933a75c@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171020102517.28385-1-borntraeger@de.ibm.com>
On 10/20/2017 12:25 PM, Christian Borntraeger wrote:
> From: "Collin L. Walling" <walling@linux.vnet.ibm.com>
>
> 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: 010
>
The check for buffer overflow was not there previously, or?
Maybe integrate that in the commit message too.
> Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> 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.
> + 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
next prev parent reply other threads:[~2017-10-20 11:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 10:25 [Qemu-devel] [PATCH] s390-ccw: print carriage return with new lines Christian Borntraeger
2017-10-20 10:30 ` Alexander Graf
2017-10-20 10:41 ` Christian Borntraeger
2017-10-20 11:02 ` Christian Borntraeger
2017-10-20 11:09 ` Alexander Graf
2017-10-20 11:18 ` Christian Borntraeger
2017-10-20 11:28 ` Thomas Huth
2017-10-20 13:48 ` Farhan Ali
2017-10-25 5:55 ` Christian Borntraeger
2017-10-20 11:31 ` Cornelia Huck
2017-10-20 12:27 ` Christian Borntraeger
2017-10-20 12:41 ` Cornelia Huck
2017-10-20 11:37 ` Halil Pasic [this message]
2017-10-25 19:49 ` Collin L. Walling
2017-10-25 22:24 ` Halil Pasic
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=b04cf5cc-cfb4-1f36-1a8b-99a34933a75c@linux.vnet.ibm.com \
--to=pasic@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=bwalk@linux.vnet.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=pmorel@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
--cc=walling@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).