From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6991639B4A6 for ; Thu, 16 Apr 2026 09:18:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776331098; cv=none; b=lDkOM+eEFT5LxpfayAgFm67Tu2Eu/Hk4gch2tZK0YnsxLZ4Tapx9ergl543OQ10ymoKyP8WnBG5r5rmtv0A56I9PBlZzOx7iS/O1fKnzoyfdQrmqpQuwL/AFxdyc1NMidNv1lzx469vsrPFRCzPMAGG//EUtjNdti5tJxwxOBIA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776331098; c=relaxed/simple; bh=xRvxm8qG7RvcSNR6TnRYUMXS6QVlm2Lz0dsVOitMLK8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=K+vFEAjv/uP1ITvpEodqBiKcPDW5MK5+Swvc1mI0f+OhbJtHz//Qpsswhc84/R14vXMW/Em5Lu9Ve4zsk/m1qde4E2EWPy4VWI3j0+uevOR7/auTZmOkdXwOOFa7Gbwh2Wrwy3XpNYEfl3qC3kiClNuzR5pg/z6Y0LuuM3sXy3I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Ur8NAfH1; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Ur8NAfH1" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4887ca8e529so3108765e9.0 for ; Thu, 16 Apr 2026 02:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776331095; x=1776935895; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=IuZQZL889ZnDbuNbGRRXjZqQbzzmhhDBl+7CF09awAs=; b=Ur8NAfH1rsFVL+TWh7pqseZth7mIrQYVbTNgm0pDhpggyAdE/LGrv2qcaxaIjiaCvU wAe0iJUnAwsTtxh+QZwAnHeHYb6uO6aZ+OqlvBNkV6KI2n1ZSC6zHh7+dMd41zZsEaT0 NBpktNfVht+ZSr4XZ3LzQNGRz+Sj4mgrnn9YjKg5bcFCFECtC5EDpWpxfsZCPBT0whu2 oJv33VDySmQqC4RXnNMi37WPFw5QXQDnsFc4hO5QAIoTgn6WV4pnL3zT/7NKsgGYcKfn 21HoFb/UkADtgBwFMXRoYMvOTzFsCeS9Tme+LlMWX/YDUCs1dZyItyH7HqlVLiT7o92F eIWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776331095; x=1776935895; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=IuZQZL889ZnDbuNbGRRXjZqQbzzmhhDBl+7CF09awAs=; b=cSOOuta29L4sXA/6drb0E6jjPikzhV9Wtv+nerx/9qFWUr14j3uKLz7ZJMuSfWpjxU Qkxgy/GSxYeeX744ptGqDj2woM2ncWHWaOIEUSd5ADM5LGOEgSStRMaAoFFJqegTqTsh mugC7Kkhuii/H+eDEyDfqofEWDtZYG1NkCaHOEW5tJ1aKBdLG/He1GtTbqL5D2+TfZXs Oq1bcCoTBzolQmpCrQuWJFZXRpHE1KAydPSWIigV/mETPySpGsAYvmjTm3PsxPAuTlQ3 6KUbRjWKtjKH8gCLvDSpVYD6Kn/kfGMqRreXnGMZGpXWU7JWyNpWSysSo/VNJW9zgN8o XUBg== X-Forwarded-Encrypted: i=1; AFNElJ8ep4Ia2hQo49BYBXbmmYVJoZCzx3vWf3kge9Lkg14G1QTGOwFx4iVEbSo9IRFFlo35huVAoHzQKH3ZsKs=@vger.kernel.org X-Gm-Message-State: AOJu0YzVR+Q0jTGfkFe0vH0HeN/lNICV5WFZM6DC0VqC3IDNseQCpvrW ayyKxGSTNUtmEmg3GlzvoMfeK7kXZREEooUIZOqBTN9zkFs5kFjDznMb X-Gm-Gg: AeBDietrUbDMmX2j3793kurtLaWfviqUU4r7MwNfIWwHO8wDh/LcyzgzYe+E0f1cNC7 BxwhWhYl0kyttBeb16OVKCP1RQ1i5U0gW8KPjQTUy3nT8WQlJw9u63Knm4OD1Y0kMe9/3TrY5Fe X07fF4sFJcTg5nSl0m0WfTVCRcciWDvxdvMdK75ZBGL34jVxmjKP/oAK5Hya1dYy3m0jaGDZ6NQ liM+JfKPJvGJk4mrUnY7tiPNegIi1pMDYN9rjdcZJyj2MpF53x7wZrN2FeXxvRjuSQ8eONEvoT/ 8v9KYuUatMUsTy/nhlGnoai1LDpMOJ3KzajvRWeEGQdTlio5UCz7dxgcmnB43DlQwhfukBtkiq7 EA3+Pyal30tB09PooT0k957C0ezlpbonDtb7D7aDEcraWlrgkkLNNOIsRuJLrpkN935m7TLstgp I4nnmSGZIzDpW/f6qvRMnavb59amubC1pvWHAZ1mUhmE3rvmCVmESLYU7JBGeA1sbl X-Received: by 2002:a05:600c:1e28:b0:488:9c3b:ff40 with SMTP id 5b1f17b1804b1-488f4829bc6mr34154325e9.15.1776331094504; Thu, 16 Apr 2026 02:18:14 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488f5827da4sm35917145e9.14.2026.04.16.02.18.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2026 02:18:13 -0700 (PDT) Date: Thu, 16 Apr 2026 10:18:12 +0100 From: David Laight To: Dominique Martinet Cc: Pierre Barre , Eric Van Hensbergen , Latchesar Ionkov , Christian Schoenebeck , v9fs@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] 9p: use kvzalloc for readdir buffer Message-ID: <20260416101812.59e857d3@pumpkin> In-Reply-To: References: <06399e04-b019-4c3d-b941-5771b6ac33c2@app.fastmail.com> <20260415100157.4aa33364@pumpkin> <20260415113625.6d38441d@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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-Transfer-Encoding: 7bit On Thu, 16 Apr 2026 11:31:02 +0900 Dominique Martinet wrote: > David Laight wrote on Wed, Apr 15, 2026 at 11:36:25AM +0100: > > > Perhaps what you describe can explain what I was seeing there: > > > https://lore.kernel.org/v9fs/496d10b9-40fe-4f81-8014-37497c37ff63@app.fastmail.com/ > > (After seeking, getdents() returns stale cached entries instead of fetching from the new position.) > > > > Absolutely. > > But the fix probably isn't trivial. > > The offset that you need for the seek isn't directly related to the number > > of bytes copied to the user buffer - which is what I suspect ftell() (or > > whatever gets used) returns. > > I think there is some mechanism for arbitrary directory offsets; but IIRC that > > requires the code put the 'file system offset for the next directory entry' > > somewhere in the directory entry. > > Such an offset would have to be one the remote system would understand. > > > > A partial 'non-fix' would be to reject seeks to other than offset 0. > > > Thank you both for working on this and reviewing -- this is all > historical code that hasn't seen much love. > > > 9p Treaddir sends an offset on each call, so I think it'd be fine to > invalidate buffer/remember whatever the client set in a custom llseek > function and send this to the server on readdir call, but I honestly > didn't give this any more thought than the past 2 mintes (I'm totally > swamped and can't keep up/didn't even notice the bug report this > december, sorry :/) The problem is you need to get the correct offsets for the various calls. So the directory entry sent to the user needs the correct offset the server would use for the (next) directory entry. If the latter aren't byte offsets into the buffer it probably impossible. I have a vague recollection of some fs encoding 'directory block number' and 'offset in directory block' into the 'file offset' for directory fd. > I think some filesystems only allow seeks to 0 already? So given there > is a precendent this might be fine, but I don't see the harm in allowing > custom offsets: the server needs to be able to deal with junk offsets in > read requests anyway, so it's not a problem for me if userspace can set > something invalid and get itself stuck on EINVAL or whatever. > > > As for locking the vfs takes the file's f_lock for seek, but there > doesn't seem to be anything in the readdir path that would do that, so I > guess it probably would blow up with parallel readdirs on the same fd, > and could use improving... There might be something, file->offset needs protecting for readdir() the same as for read() (but not pread()). At least once (for some filesystem on some unix variant) readdir() would have been pretty much the same as read(). David >