Re: kern.boottime drift after boot?

[RVP]

On Thu, 12 Oct 2023, Simon Burge wrote:


Assuming of course that the boot_id is generated after interrupts
are enabled and some jitter has been processed :).



That's almost certainly the case: that UUID is only generated when
userspace first reads it (and there aren't any kernel-consumers of
that UUID that I'm aware of). See: proc_do_uuid():

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/char/random.c?h=v6.5.7#n1609

The file was put in to support server-farms where you push an update
to a bunch of machines, command them to reboot, then check if the
machines have actually rebooted for the updates to "take". But,
as abs@ just scoped out, it can have other uses too...

-RVP

Re: Notes on kern/57133

[Brian Buhrow]

Hello.  As a followup on this bug I now know what's causing the panic 
to get triggered.
The issue is that if a request gets requeued requeud, resid gets set to 0, 
which causes the
KASSERT to fire.  So the question is, is it always the case that if a request 
gets requeued,
resid gets set to 0, or is that only in certain cases?  A related question is 
has it always
been the case that resid gets reset to 0 on a requeue, but the mpii(4) driver 
didn't used to
check for this condition?  Or, is the resetting of resid to 0 a new phenomenon? 
 Note that I
did a search of all the scsi/atapi drivers in the tree and I couldn't find 
another instance
where this check is done.  So, I'm inclined to think this check is relatively 
new and it's just
that no one has run into it before.
While it would be interesting to know why these particular requests are getting 
requeued, and
I'll try to figure that out, if it is true that resid gets set to 0 on requeue, 
then this check
is just wrong in the mpii(4) driver.

Any thoughts from anyone?

-Brian