Re: [Qemu-devel] [PATCH] s390-ccw: print carriage return with new lines

[Collin L. Walling]

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:  010
> The 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