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

[John Ferlan]

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.

John