[PATCH 0/2] s390/sclp: Resize for sclp-vt220 console

[PATCH 0/2] s390/sclp: Resize for sclp-vt220 console

[Maximilian Immanuel Brandtner]

This patch-set implements resize event handling for the sclp-vt220
console and refactors some of the surrounding code.

---
Testing:
- Tested on QEMU: commit 38879a667f with the following patches applied:
    [PATCH] s390x/sclpconsole: implement resizing for vt220 consoles
    [PATCH v7 00/12] virtio-console: notify about the terminal size
    (https://lore.kernel.org/qemu-devel/20260609-console-resize-v7-0-0c550fdcec15@gmail.com/)
 - Tested on linux-next (commit c1f49dea2b8f)

Maximilian Immanuel Brandtner (2):
  s390/sclp: Introduce dedicated sclp-vt220 event buffer type
  s390/sclp: Implement resize for sclp-vt220 console

 drivers/s390/char/sclp_vt220.c | 77 ++++++++++++++++++++++++++++------
 1 file changed, 65 insertions(+), 12 deletions(-)

-- 
2.54.0

[PATCH 1/2] s390/sclp: Introduce dedicated sclp-vt220 event buffer type

[Maximilian Immanuel Brandtner]

Introduce sclp-vt220 event buffer type to replace the
byte-manipulation behavior in the receiver function with well defined
primitives.

Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
---
 drivers/s390/char/sclp_vt220.c | 21 ++++++++++++---------
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c
index 62979adcb..6dd176049 100644
--- a/drivers/s390/char/sclp_vt220.c
+++ b/drivers/s390/char/sclp_vt220.c
@@ -52,6 +52,12 @@ struct sclp_vt220_sccb {
 	struct evbuf_header evbuf;
 };
 
+struct sclp_vt220_evbuf {
+	struct evbuf_header header;
+	char type;
+	char data[];
+} __packed;
+
 #define SCLP_VT220_MAX_CHARS_PER_BUFFER	(PAGE_SIZE - \
 					 sizeof(struct sclp_vt220_request) - \
 					 sizeof(struct sclp_vt220_sccb))
@@ -522,25 +528,22 @@ static void sclp_vt220_handle_input(const char *buffer, unsigned int count)
 /*
  * Called by the SCLP to report incoming event buffers.
  */
-static void
-sclp_vt220_receiver_fn(struct evbuf_header *evbuf)
+static void sclp_vt220_receiver_fn(struct evbuf_header *evbuf)
 {
-	char *buffer;
+	struct sclp_vt220_evbuf *buffer;
 	unsigned int count;
 
-	buffer = (char *) ((addr_t) evbuf + sizeof(struct evbuf_header));
-	count = evbuf->length - sizeof(struct evbuf_header);
+	buffer = (struct sclp_vt220_evbuf *)evbuf;
+	count = evbuf->length - offsetof(struct sclp_vt220_evbuf, data);
 
-	switch (*buffer) {
+	switch (buffer->type) {
 	case SCLP_VT220_SESSION_ENDED:
 	case SCLP_VT220_SESSION_STARTED:
 		sclp_vt220_reset_session();
 		break;
 	case SCLP_VT220_SESSION_DATA:
 		/* Send input to line discipline */
-		buffer++;
-		count--;
-		sclp_vt220_handle_input(buffer, count);
+		sclp_vt220_handle_input(buffer->data, count);
 		tty_flip_buffer_push(&sclp_vt220_port);
 		break;
 	}
-- 
2.54.0

[PATCH 2/2] s390/sclp: Implement resize for sclp-vt220 console

[Maximilian Immanuel Brandtner]

Add support for sclp vt220 resize events to enable host-initiated
terminal resizing when using the sclp-vt220 console.

This allows QEMU to dynamically resize the console. On older kernel
versions, these events are safely ignored as the kernel drops events
with undefined tty codes.

Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
---
 drivers/s390/char/sclp_vt220.c | 56 ++++++++++++++++++++++++++++++++--
 1 file changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c
index 6dd176049..42b96b343 100644
--- a/drivers/s390/char/sclp_vt220.c
+++ b/drivers/s390/char/sclp_vt220.c
@@ -27,6 +27,7 @@
 #include <linux/init.h>
 #include <linux/reboot.h>
 #include <linux/slab.h>
+#include <linux/workqueue.h>
 
 #include <linux/uaccess.h>
 #include "sclp.h"
@@ -58,6 +59,11 @@ struct sclp_vt220_evbuf {
 	char data[];
 } __packed;
 
+struct sclp_vt220_resize_data_t {
+	u16 rows;
+	u16 cols;
+} __packed;
+
 #define SCLP_VT220_MAX_CHARS_PER_BUFFER	(PAGE_SIZE - \
 					 sizeof(struct sclp_vt220_request) - \
 					 sizeof(struct sclp_vt220_sccb))
@@ -98,6 +104,15 @@ static int __initdata sclp_vt220_init_count;
  * another buffer */
 static int sclp_vt220_flush_later;
 
+/* Work struct required for scheduling resize */
+static struct work_struct sclp_vt220_resize_work;
+
+/* Current vt220 terminal winsize */
+static struct winsize sclp_vt220_winsize = {
+	.ws_row = 24,
+	.ws_col = 80,
+};
+
 static void sclp_vt220_receiver_fn(struct evbuf_header *evbuf);
 static int __sclp_vt220_emit(struct sclp_vt220_request *request);
 static void sclp_vt220_emit_current(void);
@@ -477,6 +492,7 @@ sclp_vt220_write(struct tty_struct *tty, const u8 *buf, size_t count)
 #define SCLP_VT220_SESSION_ENDED	0x01
 #define	SCLP_VT220_SESSION_STARTED	0x80
 #define SCLP_VT220_SESSION_DATA		0x00
+#define SCLP_VT220_SESSION_RESIZE	0x08
 
 #ifdef CONFIG_MAGIC_SYSRQ
 
@@ -525,6 +541,35 @@ static void sclp_vt220_handle_input(const char *buffer, unsigned int count)
 
 #endif
 
+static void sclp_vt220_resize(struct work_struct *work)
+{
+	struct tty_struct *tty;
+	struct winsize ws;
+
+	spin_lock_irq(&sclp_vt220_lock);
+	ws = sclp_vt220_winsize;
+	spin_unlock_irq(&sclp_vt220_lock);
+
+	tty = tty_port_tty_get(&sclp_vt220_port);
+	if (!tty)
+		return;
+
+	tty_do_resize(tty, &ws);
+	tty_kref_put(tty);
+}
+
+static void sclp_vt220_resize_sched(void *buffer)
+{
+	struct sclp_vt220_resize_data_t *data = buffer;
+	unsigned long flags;
+
+	spin_lock_irqsave(&sclp_vt220_lock, flags);
+	sclp_vt220_winsize.ws_row = data->rows;
+	sclp_vt220_winsize.ws_col = data->cols;
+	schedule_work(&sclp_vt220_resize_work);
+	spin_unlock_irqrestore(&sclp_vt220_lock, flags);
+}
+
 /*
  * Called by the SCLP to report incoming event buffers.
  */
@@ -546,6 +591,9 @@ static void sclp_vt220_receiver_fn(struct evbuf_header *evbuf)
 		sclp_vt220_handle_input(buffer->data, count);
 		tty_flip_buffer_push(&sclp_vt220_port);
 		break;
+	case SCLP_VT220_SESSION_RESIZE:
+		sclp_vt220_resize_sched(buffer->data);
+		break;
 	}
 }
 
@@ -557,9 +605,9 @@ sclp_vt220_open(struct tty_struct *tty, struct file *filp)
 {
 	if (tty->count == 1) {
 		tty_port_tty_set(&sclp_vt220_port, tty);
-		if (!tty->winsize.ws_row && !tty->winsize.ws_col) {
-			tty->winsize.ws_row = 24;
-			tty->winsize.ws_col = 80;
+		if (tty->winsize.ws_row != sclp_vt220_winsize.ws_row ||
+		    tty->winsize.ws_col != sclp_vt220_winsize.ws_col) {
+			schedule_work(&sclp_vt220_resize_work);
 		}
 	}
 	return 0;
@@ -754,6 +802,8 @@ static int __init sclp_vt220_tty_init(void)
 	rc = tty_register_driver(driver);
 	if (rc)
 		goto out_init;
+
+	INIT_WORK(&sclp_vt220_resize_work, sclp_vt220_resize);
 	rc = sclp_register(&sclp_vt220_register_input);
 	if (rc)
 		goto out_reg;
-- 
2.54.0

Re: [PATCH 0/2] s390/sclp: Resize for sclp-vt220 console

[Maximilian Immanuel Brandtner]

For the QEMU Patch see: [PATCH] s390x/sclpconsole: implement resizing
for vt220 consoles (https://lore.kernel.org/qemu-
devel/20260921121641.1354712-1-maxbr@linux.ibm.com/T/#u)

Re: [PATCH 1/2] s390/sclp: Introduce dedicated sclp-vt220 event buffer type

[sashiko-bot]

> Introduce sclp-vt220 event buffer type to replace the
> byte-manipulation behavior in the receiver function with well defined
> primitives.
> 
> Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921121619.1354611-1-maxbr@linux.ibm.com?part=1

Re: [PATCH 2/2] s390/sclp: Implement resize for sclp-vt220 console

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] tty: UAPI breakage due to asynchronous winsize initialization in open()
- [High] s390/sclp: out-of-bounds read in SCLP_VT220_SESSION_RESIZE parsing
- [Medium] s390/sclp: data race when reading shared terminal dimensions
--

commit 13e18fecbfc8440743cc8dff7c08364db9a637bf
Author: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>

s390/sclp: Implement resize for sclp-vt220 console

This patch adds support for sclp vt220 resize events to enable host-initiated
terminal resizing when using the sclp-vt220 console. This allows QEMU to
dynamically resize the console.

> diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c
> index 7c168a66e4afe..d140617846a2d 100644
> --- a/drivers/s390/char/sclp_vt220.c
> +++ b/drivers/s390/char/sclp_vt220.c

[ ... ]

> @@ -543,6 +588,9 @@ static void sclp_vt220_receiver_fn(struct evbuf_header *evbuf)
>  	case SCLP_VT220_SESSION_DATA:
>  		/* Send input to line discipline */
>  		sclp_vt220_handle_input(buffer->data, count);
>  		tty_flip_buffer_push(&sclp_vt220_port);
>  		break;
> +	case SCLP_VT220_SESSION_RESIZE:
> +		sclp_vt220_resize_sched(buffer->data);

[Severity: High]
If the hypervisor sends an SCLP_VT220_SESSION_RESIZE event with an
evbuf->length smaller than expected, is there a risk of reading out of bounds
when the data is accessed?

This path delegates to sclp_vt220_resize_sched() without verifying if
evbuf->length is large enough to contain the 4-byte resize payload. Since the
event length is controlled by the hypervisor, could this result in an
out-of-bounds memory read when sclp_vt220_resize_sched() reads the rows and
cols fields?

> +		break;
>  	}
>  }
>  
> @@ -554,9 +602,9 @@ sclp_vt220_open(struct tty_struct *tty, struct file *filp)
>  {
>  	if (tty->count == 1) {
>  		tty_port_tty_set(&sclp_vt220_port, tty);
> -		if (!tty->winsize.ws_row && !tty->winsize.ws_col) {
> -			tty->winsize.ws_row = 24;
> -			tty->winsize.ws_col = 80;
> +		if (tty->winsize.ws_row != sclp_vt220_winsize.ws_row ||
> +		    tty->winsize.ws_col != sclp_vt220_winsize.ws_col) {

[Severity: Medium]
Is it safe to read sclp_vt220_winsize here without synchronization?

The global sclp_vt220_winsize state is updated under sclp_vt220_lock in
sclp_vt220_resize_sched(). A concurrent resize interrupt could theoretically
result in a torn read here, mixing old and new terminal dimensions.

> +			schedule_work(&sclp_vt220_resize_work);

[Severity: High]
Does this replace a safe synchronous initialization with an asynchronous one,
exposing uninitialized dimensions to userspace?

Because workqueues execute asynchronously, the open() syscall can return to
userspace before the worker thread executes tty_do_resize() to populate
tty->winsize. If an application immediately queries the terminal size with
ioctl(TIOCGWINSZ), wouldn't it read 0x0 instead of the actual dimensions?

>  		}
>  	}
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921121619.1354611-1-maxbr@linux.ibm.com?part=2

Re: [PATCH 2/2] s390/sclp: Implement resize for sclp-vt220 console

[Maximilian Immanuel Brandtner]

On Mon, 2026-09-21 at 12:28 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider:
> - [High] tty: UAPI breakage due to asynchronous winsize
> initialization in open()
> - [High] s390/sclp: out-of-bounds read in SCLP_VT220_SESSION_RESIZE
> parsing
> - [Medium] s390/sclp: data race when reading shared terminal
> dimensions
> --
> 
> commit 13e18fecbfc8440743cc8dff7c08364db9a637bf
> Author: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
> 
> s390/sclp: Implement resize for sclp-vt220 console
> 
> This patch adds support for sclp vt220 resize events to enable host-
> initiated
> terminal resizing when using the sclp-vt220 console. This allows QEMU
> to
> dynamically resize the console.
> 
> > diff --git a/drivers/s390/char/sclp_vt220.c
> > b/drivers/s390/char/sclp_vt220.c
> > index 7c168a66e4afe..d140617846a2d 100644
> > --- a/drivers/s390/char/sclp_vt220.c
> > +++ b/drivers/s390/char/sclp_vt220.c
> 
> [ ... ]
> 
> > @@ -543,6 +588,9 @@ static void sclp_vt220_receiver_fn(struct
> > evbuf_header *evbuf)
> >  	case SCLP_VT220_SESSION_DATA:
> >  		/* Send input to line discipline */
> >  		sclp_vt220_handle_input(buffer->data, count);
> >  		tty_flip_buffer_push(&sclp_vt220_port);
> >  		break;
> > +	case SCLP_VT220_SESSION_RESIZE:
> > +		sclp_vt220_resize_sched(buffer->data);
> 
> [Severity: High]
> If the hypervisor sends an SCLP_VT220_SESSION_RESIZE event with an
> evbuf->length smaller than expected, is there a risk of reading out
> of bounds
> when the data is accessed?
> 
> This path delegates to sclp_vt220_resize_sched() without verifying if
> evbuf->length is large enough to contain the 4-byte resize payload.
> Since the
> event length is controlled by the hypervisor, could this result in an
> out-of-bounds memory read when sclp_vt220_resize_sched() reads the
> rows and
> cols fields?

Yes, but a guest needs to trust the hypervisor or firmware anyways to
provide it with correct data, so I don't see the point in verifying
data from a trusted source. (Eg what if the hypervisor implemented
load/store instructions incorrectly -- at that point there is nothing
the guest can do to operate correctly.) I could add a check here, but I
don't see the point in it.

> 
> > +		break;
> >  	}
> >  }
> >  
> > @@ -554,9 +602,9 @@ sclp_vt220_open(struct tty_struct *tty, struct
> > file *filp)
> >  {
> >  	if (tty->count == 1) {
> >  		tty_port_tty_set(&sclp_vt220_port, tty);
> > -		if (!tty->winsize.ws_row && !tty->winsize.ws_col)
> > {
> > -			tty->winsize.ws_row = 24;
> > -			tty->winsize.ws_col = 80;
> > +		if (tty->winsize.ws_row !=
> > sclp_vt220_winsize.ws_row ||
> > +		    tty->winsize.ws_col !=
> > sclp_vt220_winsize.ws_col) {
> 
> [Severity: Medium]
> Is it safe to read sclp_vt220_winsize here without synchronization?
> 
> The global sclp_vt220_winsize state is updated under sclp_vt220_lock
> in
> sclp_vt220_resize_sched(). A concurrent resize interrupt could
> theoretically
> result in a torn read here, mixing old and new terminal dimensions.

There can only be one open sclp console at a time. When opening an sclp
console there shouldn't already be stuff going on with the tty that
could mess with this. Even if this were the case though the tty is
locked by a mutex so it can't be locked in the interrupt context.
Furthermore, this behavior was already present prior to this commit so
even if it were an issue, which I don't believe it to be, it wouldn't
be an issue of this patch-set.

> 
> > +			schedule_work(&sclp_vt220_resize_work);
> 
> [Severity: High]
> Does this replace a safe synchronous initialization with an
> asynchronous one,
> exposing uninitialized dimensions to userspace?
> 
> Because workqueues execute asynchronously, the open() syscall can
> return to
> userspace before the worker thread executes tty_do_resize() to
> populate
> tty->winsize. If an application immediately queries the terminal size
> with
> ioctl(TIOCGWINSZ), wouldn't it read 0x0 instead of the actual
> dimensions?

True, but I don't consider that to be that much of a risk. There are
situations where a 0x0 terminal size can occur (though unless done
explicitly it's usually considered bad behavior) so applications need
to deal with that anyways. Most applications just fall back to 24x80
(the default). You can't assume that sclp_vt220_winsize is necessarily
24x80 once you open the console for a second time. That said in the
case of opening sclp_vt220_open().

> 
> >  		}
> >  	}
> >  	return 0;

Also you can't have your pie and eat it too. In suggestion 2 you doubt
whether you can change the window size synchronously and in suggestion
3 you mention that if you change the window size asynchronously and the
tty / application running in the tty are up really quickly and query
the winsize quickly enough they might receive an outdated result. Pick
your poison. You can't have both.

What I could see as a possible change would be removing the equality
check on tty->winsize altogether and scheduling the work
unconditionally, elliminating suggestion 2, but accepting the transient
false winsize value (which I doubt btw to ever be relevant in real
use).

Re: [PATCH 2/2] s390/sclp: Implement resize for sclp-vt220 console

[Christian Borntraeger]

Am 21.09.26 um 14:54 schrieb Maximilian Immanuel Brandtner:
> On Mon, 2026-09-21 at 12:28 +0000, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 3 potential
>> issue(s) to consider:
>> - [High] tty: UAPI breakage due to asynchronous winsize
>> initialization in open()
>> - [High] s390/sclp: out-of-bounds read in SCLP_VT220_SESSION_RESIZE
>> parsing
>> - [Medium] s390/sclp: data race when reading shared terminal
>> dimensions
>> --
>>
>> commit 13e18fecbfc8440743cc8dff7c08364db9a637bf
>> Author: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
>>
>> s390/sclp: Implement resize for sclp-vt220 console
>>
>> This patch adds support for sclp vt220 resize events to enable host-
>> initiated
>> terminal resizing when using the sclp-vt220 console. This allows QEMU
>> to
>> dynamically resize the console.
>>
>>> diff --git a/drivers/s390/char/sclp_vt220.c
>>> b/drivers/s390/char/sclp_vt220.c
>>> index 7c168a66e4afe..d140617846a2d 100644
>>> --- a/drivers/s390/char/sclp_vt220.c
>>> +++ b/drivers/s390/char/sclp_vt220.c
>>
>> [ ... ]
>>
>>> @@ -543,6 +588,9 @@ static void sclp_vt220_receiver_fn(struct
>>> evbuf_header *evbuf)
>>>   	case SCLP_VT220_SESSION_DATA:
>>>   		/* Send input to line discipline */
>>>   		sclp_vt220_handle_input(buffer->data, count);
>>>   		tty_flip_buffer_push(&sclp_vt220_port);
>>>   		break;
>>> +	case SCLP_VT220_SESSION_RESIZE:
>>> +		sclp_vt220_resize_sched(buffer->data);
>>
>> [Severity: High]
>> If the hypervisor sends an SCLP_VT220_SESSION_RESIZE event with an
>> evbuf->length smaller than expected, is there a risk of reading out
>> of bounds
>> when the data is accessed?
>>
>> This path delegates to sclp_vt220_resize_sched() without verifying if
>> evbuf->length is large enough to contain the 4-byte resize payload.
>> Since the
>> event length is controlled by the hypervisor, could this result in an
>> out-of-bounds memory read when sclp_vt220_resize_sched() reads the
>> rows and
>> cols fields?
> 
> Yes, but a guest needs to trust the hypervisor or firmware anyways to
> provide it with correct data, so I don't see the point in verifying
> data from a trusted source. (Eg what if the hypervisor implemented
> load/store instructions incorrectly -- at that point there is nothing
> the guest can do to operate correctly.) I could add a check here, but I
> don't see the point in it.

There is a point for secure execution / confidential computing. Lets validate
the data.