Re: [PATCH v5 4/6] xen/console: use memcpy() in console_init_ring()

[Jan Beulich <jbeulich@suse.com>]

On 05.02.2026 02:36, dmukhin@xen.org wrote:
> @@ -479,11 +479,23 @@ void __init console_init_ring(void)
>      opt_conring_size = PAGE_SIZE << order;
>  
>      nrspin_lock_irqsave(&console_lock, flags);
> -    for ( i = conringc ; i != conringp; i++ )
> -        ring[i & (opt_conring_size - 1)] = conring[i & (conring_size - 1)];
> +
> +    start = conringc & (conring_size - 1);
> +    size = min(conringp - conringc, conring_size);

Is this correct when the ring size actually shrinks? In such a case you want
to copy the tail of the ring if not all of the original contents fits in the
new one. But ...

> +    chunk = min(size, conring_size - start);
> +
> +    memcpy(&ring[0], &conring[start], chunk);

... you start at its head.

> +    if ( size > chunk )
> +        memcpy(&ring[chunk], &conring[0], size - chunk);
> +
> +    /* Data is moved to [0..size), re-position conring pointers. */
> +    conringc = 0;
> +    conringp = size;

Why this unrelated change, which the description also doesn't mention? Since
this is in an __init function, there's no race with read_console_ring(), but
a static analysis tool may still (validly) spot one. Yet then there's also
conring_flush(), which doesn't look to be using any locking either. Have you
excluded that this function can run in a racing manner?

Jan