On 05.02.2026 02:36, [email protected] 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
