Re: [Qemu-devel] [RFC] qid path collision issues in 9pfs

[Greg Kurz]

On Thu, 25 Jan 2018 17:08:40 +0100
Veaceslav Falico <address@hidden> wrote:

> On 1/25/2018 3:46 PM, Veaceslav Falico wrote:
[...]
> > 
> > I've reproduced it today without fscache:
> > 
> > host:
> > mount -o bind /tmp/mounted t1
> > mount -o bind /tmp/mounted t2
> > 
> > guest:
> > / # tail -f t1/file &
> > / # 321
> > 
> > / # cat t2/file
> > 321
> > / #
> > 
> > host:
> > mv t1/file t1/file_moved
> > 
> > guest:
> > / # cat t2/file
> > cat: can't open 't2/file': No such file or directory
> > / # mount | grep fscache
> > / #  
> 
> Sorry, disregard this test case, it's operating normally -
> when we move the t1/file, we also move the t2/file, as they're
> the same directory... Sorry, it's a brainfart after a long
> discussion about the issue :).
> 

No problem :)

> So, it's still not reproducible without (fs)cache guest-side.
> 
> 
> Anyway, the question below still stands - is the guest
> allowed to re-use the FIDs for the files with same QIDs?
> 

AFAIU FIDs have a 1:1 relation to either a path in the file hierarchy or
to an open file. I don't think they can be re-used.

> > 
> > Also, per internal discussions, we're not sure if the guest side
> > is allowed to reuse the FIDs opened previously for same QID.paths.
> > 
> > QEMU holds FID.path for each FID, which contains the actual FS path,
> > i.e. "/path/to/file". 
> > 
> > So, if we (guest) have two "identical" (per QID.path and RFC) files
> > (f1 and f2), though in different directories (host and guest), and 
> > we've accessed f1 once (FID 10, for example) - are we allowed to
> > re-use FID 10 for f2, if f1's QID.path == f2's QID.path ?
> >   
> >>  
> >>>  
> >>>>
> >>>> Thanks,
> >>>> Eduard.
> >>>>     
> >>>>>    
> >>>>>>>    
> >>>>>>>> With our proof of concept patch, the issues caused by qid path 
> >>>>>>>> collisions go away, so it can be seen as an interim solution of 
> >>>>>>>> sorts. However, the chance of collisions is not eliminated, we are 
> >>>>>>>> just replacing the current strategy, which is almost guaranteed to 
> >>>>>>>> cause collisions in certain use cases, with one that makes them more 
> >>>>>>>> rare. We think that a virtio feature flag for longer qid paths is 
> >>>>>>>> the only way to eliminate these issues completely.
> >>>>>>>>
> >>>>>>>> This is the extent that we were able to analyze the issue from our 
> >>>>>>>> side, we would like to hear if there are some better ideas, or which 
> >>>>>>>> approach would be more appropriate for upstream.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>    
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> -- 
> >>>>>>> Greg
> >>>>>>>    
> >>>>>>    
> >>>>>    
> >>>>
> >>>> .
> >>>>     
> >>>
> >>>  
> >>
> >> .
> >>  
> >   
> 
>