lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F6CB6E77-082D-442A-A3C9-F2D955E1D285@flyingcircus.io>
Date: Fri, 27 Jun 2025 10:19:34 +0200
From: Christian Theune <ct@...ingcircus.io>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: David Howells <dhowells@...hat.com>,
 Ryan Lahfa <ryan@...fa.xyz>,
 Antony Antony <antony.antony@...unet.com>,
 Antony Antony <antony@...nome.org>,
 Christian Brauner <brauner@...nel.org>,
 Eric Van Hensbergen <ericvh@...nel.org>,
 Latchesar Ionkov <lucho@...kov.net>,
 Christian Schoenebeck <linux_oss@...debyte.com>,
 Sedat Dilek <sedat.dilek@...il.com>,
 Maximilian Bosch <maximilian@...sch.me>,
 regressions@...ts.linux.dev,
 v9fs@...ts.linux.dev,
 netfs@...ts.linux.dev,
 linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] 9pfs issues on 6.12-rc1

Hi,

> On 27. Jun 2025, at 08:44, Dominique Martinet <asmadeus@...ewreck.org> wrote:
> 
> Hi all,
> 
> sorry for the slow reply; I wasn't in Cc of most of the mails back in
> October so this is a pain to navigate... Let me recap a bit:
> - stuff started failing in 6.12-rc1

yes, to my knowledge and interpretation of this thread.

> - David first posted "9p: Don't revert the I/O iterator after
> reading"[1], which fixed the bug, but then found a "better" fix as
> "iov_iter: Fix iov_iter_get_pages*() for folio_queue" [2] which was
> merged instead (so the first patch was not merged)
> 
> But it turns out the second patch is not enough (or causes another
> issue?), and the reverting it + applying first one works, is that
> correct?
> What happens if you keep [2] and just apply [1], does that still bug?

I tried that and the test that so far under all the variations reliably
crashed (or not) is not crashing in this case.

> (I've tried reading through the thread now and I don't even see what was
> the "bad" patch in the first place, although I assume it's ee4cdf7ba857
> ("netfs: Speed up buffered reading") -- was that confirmed?)

I was late to the party, to, so I’ll defer to the others.

> David, as you worked on this at the time it'd be great if you could have
> another look, I have no idea what made you try [1] in the first place
> but unless you think 9p is doing something wrong like double-reverting
> on error or something like that I'd like to understand a bit more what
> happens... Although given 6.12 is getting used more now it could make
> sense to just apply [1] first until we understand, and have a proper fix
> come second -- if someone can confirm we don't need to revert [2].

I guess I confirmed this. However, I’m just barely better than a monkey
here so I can’t tell whether this makes sense from the internal logic of
things.

To repeat, for safety: my test case worked with the situation you described and suggested:
[1] applied on top of 6.12.34 and *not* having [2] reverted.

Christian

-- 
Christian Theune · ct@...ingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · https://flyingcircus.io
Leipziger Str. 70/71 · 06108 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ