From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from e2i340.smtp2go.com (e2i340.smtp2go.com [103.2.141.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC5E11419A9 for ; Fri, 5 Dec 2025 12:09:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.2.141.84 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764936558; cv=none; b=UwVlIxaH2unnzxJSmu6Z96z83OAyb2yZUgMUNkdlPVtOLKiRZ0x0bYMQcNvfKR2ntlMOdaX3dS7Ha1q4C7wVeXDypcuu0JJ37ZUqU3koX5YW9c/M4MO2HrKAfqpF0lcSNnM1sXOpieGPz8NmhMaTBv6Uacqx/T1LHBdGrnrueDo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764936558; c=relaxed/simple; bh=LaOiU5bWnuebDcDGPmZl4kS1pqOs9u+qoKUghe2ucy4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hOa3T3NKiwhJbbWbBA9vEcz+xPJOr2r8As/Pq3qJRT5Tgb+Lrn7gutQf9BE9OGskfyB9nj208adVboQfHAlEDPUbC+abfU2I/SpbODvi/RnNkuFedDALIwOt3W1UsMNQjN0L+DW5Qrtbex1faakLfkA8sx69E0eWV3NWdfMIMYU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=triplefau.lt; spf=pass smtp.mailfrom=em510616.triplefau.lt; dkim=fail (0-bit key) header.d=smtpservice.net header.i=@smtpservice.net header.b=GRI9KXLF reason="unknown key version"; dkim=pass (2048-bit key) header.d=triplefau.lt header.i=@triplefau.lt header.b=O1idr3tH; arc=none smtp.client-ip=103.2.141.84 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=triplefau.lt Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=em510616.triplefau.lt Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="unknown key version" (0-bit key) header.d=smtpservice.net header.i=@smtpservice.net header.b="GRI9KXLF"; dkim=pass (2048-bit key) header.d=triplefau.lt header.i=@triplefau.lt header.b="O1idr3tH" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=maxzs0.a1-4.dyn; x=1764937456; h=Feedback-ID: X-Smtpcorp-Track:Message-ID:Subject:To:From:Date:Reply-To:Sender: List-Unsubscribe:List-Unsubscribe-Post; bh=nDQbuCR0xlv5qS7HgYyT3GoyUmABzZVoQRnEZkWUh3E=; b=GRI9KXLFY3KbvgYTGYZS4AypaE OnqHUjRuBPTBy7LkS3YeSjP4ed9Vu0NRwzKYk1KKf1vvow/WNY4K4c70KmsD4ghdmH5oVNSPDcap5 tPQ42jv4GCXVkI1A4CedBMrFT5XWd8FImFODZLwYGt7NRmEDZgBil2y9djP6jbS/N4lgBA5i2mYCy bCFG2rrRXV5aCbDvJ0KZHegIbSDDddoWOWRYSUJDf1v0acnrBMY9IQnHQ/cgClesAlQEXB9wusezs jTjONkpE/ts9WcpENwZXDLivAYonKOmiVbIbbKQANzmPspBl28pZ5d9HBSlgK9hTC5MxpiETXP7/j qqTGyaJA==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=triplefau.lt; i=@triplefau.lt; q=dns/txt; s=s510616; t=1764936556; h=from : subject : to : message-id : date; bh=nDQbuCR0xlv5qS7HgYyT3GoyUmABzZVoQRnEZkWUh3E=; b=O1idr3tHMAXGgBhagLpLkbyauBYeTNqrvgDbHFsD5hpF+0lJWQUnkQkMw9V3XX6RjySrc e6Mk5iDXAHBnDGW4s1wCzt54X2Al3rnoAhu2A1vQYA580DY+7hbZCWhp5sPt54dMir85HQu th3fC6SW1E3UBOz3jMmUtK/Txij1GQEEn4z+EZwJI6BNfZZDrSDVhVLNGvI2fs6rkR8Jtou je73XBpeaaD58r0yB4Viu6VHZZaCcAaqZTuvs8dO11SxXr6Dn16uIHWE3vhmqH97gpAFMPn SmSxuJakjO3Qay+SmERk8QRAXI/7B8yaZb2wGCT4nDhPwPq+CBbR+4GolL6Q== Received: from [10.139.162.187] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1vRUcA-TRk4wX-Kz; Fri, 05 Dec 2025 12:08:46 +0000 Received: from [10.12.239.196] (helo=localhost) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.98.1-S2G) (envelope-from ) id 1vRUcA-4o5NDgrjBW5-lSAe; Fri, 05 Dec 2025 12:08:46 +0000 Date: Fri, 5 Dec 2025 12:53:04 +0100 From: Remi Pommarel To: Dominique Martinet Cc: Eric Sandeen , v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, ericvh@kernel.org, lucho@ionkov.net, linux_oss@crudebyte.com, eadavis@qq.com Subject: Re: [PATCH V3 4/4] 9p: convert to the new mount API Message-ID: References: <20251010214222.1347785-1-sandeen@redhat.com> <20251010214222.1347785-5-sandeen@redhat.com> <13d4a021-908e-4dff-874d-d4cbdcdd71d4@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Smtpcorp-Track: pm781FhrtG3L.oaEJiOZ-_HhR.ihm_pQ0y_8c Feedback-ID: 510616m:510616apGKSTK:510616sykM-zowXn X-Report-Abuse: Please forward a copy of this message, including all headers, to On Thu, Dec 04, 2025 at 12:13:33AM +0900, Dominique Martinet wrote: > Eric Sandeen wrote on Tue, Dec 02, 2025 at 04:12:36PM -0600: > > Working on this, but something that confuses me about the current > > (not for-next) code: > > > > If I mount with "cache=loose" I see this in /proc/mounts: > > > > 127.0.0.1 /mnt 9p rw,relatime,uname=fsgqa,aname=/tmp/9,cache=f,access=user,trans=tcp 0 0 > > > > note the "cache=f" thanks to show_options printing "cache=%x" > > > > "mount -o cache=f" is rejected, though, because "f" is not a parseable > > number. > > > > Shouldn't it be printing "cache=0xf" instead of "cache=f?" > > Definitely should be! > > > (for some reason, though, in my test "remount -o,ro" does still work even with > > "cache=f" in /proc/mounts but that seems to be a side effect of mount.9p trying > > to use the new mount API when it shouldn't, or ...???) > > ... and Remi explicitly had cache=loose in his command line, so I'm also > surprised it worked... > > > I'll send my fix-up patch with a (maybe?) extra bugfix of printing > > "cache=0x%x" in show_options, and you can see what you think... it could > > be moved into a pure bugfix patch first if you agree. > > Thank you! I would have been happy to see both together but it does make > more sense separately, I've just tested and pushed both your patches to > -next > > > I also agree the other show_options look safe enough as they either > print a string or int. . . . > Ah, actually I spotted another one: > if (v9ses->debug) > seq_printf(m, ",debug=%x", v9ses->debug); > This needs to be prefixed by 0x as well -- Eric, do you mind if I amend > your patch 5 with that as well? > > > Remi - I did check rootfstype=9p as well and all seems fine but I'd > appreciate if you could test as well I just tried your 9p-next branch and the issue is gone for rootfstype=9p using cache=loose (I've also made sure that I reproduce the issue without the last two commits of your branch). So yes for me that fixes it, thanks for the patches. -- Remi