[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZnCviUrk5iQGrE4x@codewreck.org>
Date: Tue, 18 Jun 2024 06:50:01 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Christian Kastner <ckk@...ian.org>
Cc: David Howells <dhowells@...hat.com>,
Andrea Righi <andrea.righi@...onical.com>,
Eric Van Hensbergen <ericvh@...nel.org>,
linux-afs@...ts.infradead.org, linux-cifs@...r.kernel.org,
v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Luca Boccassi <bluca@...ian.org>, TJ <linux@....tj>,
Emanuele Rocca <ema@...ian.org>
Subject: Re: [PATCH v5 40/40] 9p: Use netfslib read/write_iter
Christian Kastner wrote on Mon, Jun 17, 2024 at 07:10:56PM +0200:
> On 2024-05-31 17:06, Emanuele Rocca wrote:
> > Meanwhile TJ (in CC) has been doing a lot of further investigation and
> > opened https://bugzilla.kernel.org/show_bug.cgi?id=218916.
>
> just to loop back to the MLs: in the referenced bug, TJ posted an
> analysis and and added a patch that fixed the issue for multiple testers.
Thanks for the mail, one of these days I'll try to understand how to
make bugzilla automatically put me in cc of all the 9p bugs..
Analysis and tentative fix are of great help! Looks like we now
understand what's wrong -- if I understand the description correctly we
know the correct size (files aren't modified in the background, just
other threads within the VM, right?); and the problem is that the netfs
IO reverts the size back to an incorrect value when it completes?
If so then the fix looks odd to me, the problem ought to be fixed at the
netfs/9p interface level, I don't see why an unbuffered read should
update the size metadata when it's done...
David, what do you think?
--
Dominique Martinet | Asmadeus
Powered by blists - more mailing lists