Re: [libvirt] [RFC PATCH 2/2] qemu: Force capabilities cache read if libvirtd date is different

On 20.05.2015 19:35, John Ferlan wrote: > > > On 05/20/2015 10:22 AM, Ján Tomko wrote: >> s/read/refresh/ in the commit message? >> >> On Wed, May 20, 2015 at 08:52:57AM -0400, John Ferlan wrote: >>> https://bugzilla.redhat.com/show_bug.cgi?id=1195882 >>> >>> Original commit id 'cbde3589' indicates that the cache file would be >>> discarded if either the QEMU binary or libvirtd 'ctime' changes; however, >>> the code only discarded if the QEMU binary time didn't match or if the >>> new libvirtd ctime was later than what created the cache file. >>> >>> This could lead to issues with respect to how the order of libvirtd images >>> is created for maintenance or patch branches where if someone had a libvirtd >>> created on 'date x' that was created from (a) backported patch(es) followed >>> by a subsequent install of the primary release which would have 'date y' >>> where if 'date x' was greater than 'date y', then features in a primary >>> release branch may not be available. >> >> I can see how here can be two daemons with different ctimes on the same >> system during development, so ACK to the change. > > But they'd use different cache paths, right? > >> >> However, when you install the daemon (even from an older package), ctime >> should only move forward, so I'm sceptical about its relevance to the >> referenced bug. > > Perhaps that my misinterpretation or misunderstanding of ctime - > certainly in a different OS I used to work on many years ago - ctime was > when the image was created by a build and not when the inode or file > change time as I (now) read... > > So hmmm... that blows my theory to shreds - unless you account for that > window of time during an install where files are being replaced while > libvirtd is still running an older release. As Dan notes in my 1/2 > removing the cache in between would be racey. So would it also be racey > if something caused a cache read, code finds updated libvirtd, asks qemu > for current capabilities, gets answer, creates file based on current (or > old) understanding... Then when libvirtd restarts it finds a ctime of > itself, doesn't update the cache, and of course doesn't have the latest > bits. How about computing a hash of the qemu binary, and if hashes do not equal recompile the cache?