On Tue, Oct 11, 2022 at 10:11:29PM +0530, manish.mishra wrote:
Thanks for review Jonathon, Daniel
On 11/10/22 9:56 pm, Daniel P. Berrangé wrote:
> On Tue, Oct 11, 2022 at 11:20:00AM -0500, Jonathon Jongsma wrote:
> > I believe that pidfd syscalls were introduced in kernel 5.2. Judging by our
> > CI build setup, the oldest distrubution that we support is Alma Linux 8,
> > which still has kernel version 4.18.
I did not know that, will it okay to put it in some condional check. Pidfd
is used anyway to remove a very small window race, more important one
is start time comparison. As these kind of issues can be very easily
reproducible if domain process dies when libvirt is dead and by time
libvirt comes pid is re-used. So atleast start time checking reduce race
window even for older kernel.
I presume you're seeing this on fairly old kernels ? On modern
kernels, pid_max is ~4 billion, instead of 64k, so the chances
of seeing PID reuse is tiny.
If the risk is primarily from the situation where libvirtd was
shutoff at the time QEMU stopped, then we ought to read
/proc/$PID/stat in qemuProcessReconnect() and entirely skip
any attempt to reconnect if we see the starttime has changed
while we were stopped. Of course needs to be skipped on non-Linux.
Also having an conditionally compiled pidfd check during the
kill() path would be a second safety net, for modern Linux.
> We need to support FreeBSD / macOS for the QEMU driver too,
which becomes
> the same problem.
Sorry Daniel i could not understand much of this, can you please give some
Libvirt targets multiple platforms, not merely Linux. the QEMU driver
is expected to run on Linux, FreeBSD and macOS, so cannot rely on
Linux specific functionality - that has to be conditionally built.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|