Victor Hsieh wrote on Tue, Jul 14, 2020:
> Please disregard this patch. I misunderstood the protocol and have
> found the actual problem in the hypervisor's 9P implementation. Sorry
> about the noise.
Ok, thanks for the notice.
Greg KH wrote on Wed, Jul 15, 2020:
> As Eric says, this is fine to
On Tue, Jul 14, 2020 at 01:54:01PM -0700, Eric Biggers wrote:
> On Tue, Jul 14, 2020 at 02:12:49PM +0200, Dominique Martinet wrote:
> >
> > > Fixes: 5643135a2846 ("fs/9p: This patch implements TLCREATE for 9p2000.L
> > > protocol.")
> > > Signed-off-by: Victor Hsieh
> > > Cc: sta...@vger.kernel.
Please disregard this patch. I misunderstood the protocol and have
found the actual problem in the hypervisor's 9P implementation. Sorry
about the noise.
On Tue, Jul 14, 2020 at 1:54 PM Eric Biggers wrote:
>
> On Tue, Jul 14, 2020 at 02:12:49PM +0200, Dominique Martinet wrote:
> >
> > > Fixes:
On Tue, Jul 14, 2020 at 02:12:49PM +0200, Dominique Martinet wrote:
>
> > Fixes: 5643135a2846 ("fs/9p: This patch implements TLCREATE for 9p2000.L
> > protocol.")
> > Signed-off-by: Victor Hsieh
> > Cc: sta...@vger.kernel.org
>
> (afaiu it is normally frowned upon for developers to add this cc
Victor Hsieh wrote on Mon, Jul 13, 2020:
> The fid parameter of TCREATE represents the directory that the file
This is not TCREATE, this is TLCREATE.
The fid represents the directory before the call, but on success
represents the file that has been created.
> should be created at. The current imp
The fid parameter of TCREATE represents the directory that the file
should be created at. The current implementation mistakenly passes a
locally created fid for the file. The correct file fid is usually
retrieved by another WALK call, which does happen right after.
The problem happens when a new c
6 matches
Mail list logo
