From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 CC24F32A3C8 for ; Wed, 15 Apr 2026 10:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776249390; cv=none; b=C2M0MJqnZs8wkyRzG3bIdHiTl22/Y7LJ+ohzmaejXbkymtYT5nXGsPrML8f5GJRzs5MIrKnFsxHox6PY4VUZZ2kxwP2b5GENNqBTLd1yWWjK2qN0HvZnXNm6EaPm6dvxDFEFzoSOv3QOUSADwMfwwz0Ts5Aflk+uZSDYplyu7Ic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776249390; c=relaxed/simple; bh=NxnF4CK1FqxBbrKmbiMurgO82lCtFPaN6WHaOcYG2EQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ePRx292fu+cw/K5U4lraXtKlf53H3zXGTQ/viiQhslPqZVYDxVkxVRddCZlgsgtKkJeH1bZraw4DNwKXriOYU2Z2AkrqjQmxe8liknEGw4AORA32ejVEQYwH+Sg3YRsySejhRqFgtQgOowi+TThwj/QRZ2w+Rp2XwnolU7xsMeU= 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=Q0ycV7JZ; arc=none smtp.client-ip=209.85.128.43 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="Q0ycV7JZ" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-48374014a77so88734455e9.3 for ; Wed, 15 Apr 2026 03:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776249387; x=1776854187; 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=uQsaK5fpmw9qRbAqGp4qBmJu047lOibXZ/dUKVuEGTc=; b=Q0ycV7JZ9xpndupa898AtAxOmT/U4huI82HIDXni04fFAfG5EGeJPORsmkXQRAaPeJ PNKkv0L2wHFTEl5lbWZHU9wny4lhFcDPTGWGIDxblRNCHkfSjXSsHuZcDqU1MhMtva35 oehot5mR6jiPrbh1TR01HJWtRAv/5mvfPSs6vlnTLLHRaZVKaTXK9YNFdNOXhjbL1Yct +DgP6+z99Mt1gjia+x11wDypd65d1yp8JJAXt4bZi8oDEd/mrESi0Os0CCWtnMBfvlT4 Rco4dHmI4OX4XA4WY8DSxc4CKa4lJ4p9puKCmPsDAJE6S7Om8mhItUVOGagGB1w6Yinj iBCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776249387; x=1776854187; 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=uQsaK5fpmw9qRbAqGp4qBmJu047lOibXZ/dUKVuEGTc=; b=hYk2M1Yc9VYeeO/r19WJNFlfNDhQCIVE/HFp++nfnROXOM4v/n2lQrKxaXdPDxMwaB 5vKGV2qVXeVC+n1iKbr2JkPyzYvjxgyTcAXdJPE6+OIy46KsPJZPvQIg/utaqlZWU4+s 2ubLHvEFJgHiQY1t4xVCKQwTWvgWNUxOFCSuEwblI/+xZmTSiHm+ZjI+XxhxbgOaF9zG tjKA+zKoJ7q3IMtdB+8VYqt6PlL9aancnGtmHBXQ31Sdp18Ix0mV6Oc8oV+E/qJKoK8Q 3YBsYJFNJMu+mKdNi815UKyxb0ztIMSjnqClG9C0Sc2G7xNkYlQUzB0yqxWCngKb5EuM TFAw== X-Forwarded-Encrypted: i=1; AFNElJ//bc0s6NnxqHEnMCl/Slbh+vHcVQSdRkvrOQNRbXjrv2736J6KWMQlPH5q1FQC9yPHi4PyaBVK2n431lo=@vger.kernel.org X-Gm-Message-State: AOJu0YyAo5bicokENXvrUXglZPITygBCY9PhjxFvMShx5DHLnsQ+c8ha GdVbMZLV6nVpHP58rcCtfApQpHn3LGeNxUA/vz0/eXUdCPTFM0H9jsk0N2fgPa7H X-Gm-Gg: AeBDievgErcne6SgyAdcgl1KTv667bvd3W1BgMvdOrDW2Oex4asx01v67LmJakmtpRp BmCaAezmURx/Vma18WNLPvwlKtDHm8PgngVhZzTdOhSxJprPsNEtZMrCr3irYraDmqaa0mL5jfp Ac8TwCPIRq0/3cIuSglgSEg8W10yMxer90teb/mHFzXQIpCv9wSCf6hrTN79LiappC11t2Tv2h3 MyokPN+r96s/whgdkFmc5kLAbBkfj22hB+NwfgJMdIMOMj4WQ7+I59XRgNtfjbIDSugpRlL+seg 8R7PKR0X3wwKjToKkxiHP15s/gY6zRm2EKc1gEI7986L1B8stC8BTtHCY2xF5LF3WBp8yIWWIB+ iHACYeWjDuRiGUvWBYvgMov47eG2x7Qe18U4++P2RTv0n4VnluDuj/jy7SNjhSdWzfS3vCkwBfg 4HD5ogqXI0kuVJ7zVqHa+Iip2/KvLDfseohSldOS8L9mkhN1PkBRWnOjqmdClpyl0Q2FiNW6isG H8= X-Received: by 2002:a05:600c:64cd:b0:485:3cf3:1010 with SMTP id 5b1f17b1804b1-488d67df592mr298005975e9.2.1776249386934; Wed, 15 Apr 2026 03:36:26 -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 ffacd0b85a97d-43ead3fd3b7sm4531195f8f.35.2026.04.15.03.36.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 03:36:26 -0700 (PDT) Date: Wed, 15 Apr 2026 11:36:25 +0100 From: David Laight To: "Pierre Barre" Cc: "Eric Van Hensbergen" , "Latchesar Ionkov" , asmadeus , "Christian Schoenebeck" , v9fs@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] 9p: use kvzalloc for readdir buffer Message-ID: <20260415113625.6d38441d@pumpkin> In-Reply-To: References: <06399e04-b019-4c3d-b941-5771b6ac33c2@app.fastmail.com> <20260415100157.4aa33364@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 Wed, 15 Apr 2026 11:27:21 +0200 "Pierre Barre" wrote: > Hi David, > > 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. David > > Thanks, > Pierre > > On Wed, Apr 15, 2026, at 11:01, David Laight wrote: > > On Wed, 15 Apr 2026 07:45:08 +0200 > > "Pierre Barre" wrote: > > > >> The readdir buffer is sized to msize, so kzalloc() can fail under > >> fragmentation with a page allocation failure in v9fs_alloc_rdir_buf() > >> / v9fs_dir_readdir_dotl(). > >> > >> The buffer is only a response sink and is never pack_sg_list()'d, > >> so kvzalloc() is safe for all transports, unlike the fcall buffers > >> fixed in e21d451a82f3. > >> > >> Signed-off-by: Pierre Barre > >> --- > >> fs/9p/vfs_dir.c | 2 +- > >> net/9p/client.c | 2 +- > >> 2 files changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/fs/9p/vfs_dir.c b/fs/9p/vfs_dir.c > >> index af7f72abbb76..487c177aae38 100644 > >> --- a/fs/9p/vfs_dir.c > >> +++ b/fs/9p/vfs_dir.c > >> @@ -70,7 +70,7 @@ static struct p9_rdir *v9fs_alloc_rdir_buf(struct file *filp, int buflen) > >> struct p9_fid *fid = filp->private_data; > >> > >> if (!fid->rdir) > >> - fid->rdir = kzalloc(sizeof(struct p9_rdir) + buflen, GFP_KERNEL); > >> + fid->rdir = kvzalloc(sizeof(struct p9_rdir) + buflen, GFP_KERNEL); > > > > That code isn't really well thought out at all. > > The default for buflen seems to be 128k + 24 - 24. > > struct p9_rdir adds another 8 bytes, I'm not sure whether that doubles it to > > 128k or just adds an extra page (which might be 64k not 4k). > > It also looks as though the user can specify an arbitrary buffers size (min 4k). > > So who knows how big that (and other associated) buffers actually are. > > > > The buffer seems to persist across readdir() system calls. > > I can't see any code that might attempt to honour seekdir(). > > I hope there is a global lock that stops multiple threads issuing readdir() > > on the same fd in parallel. > > > > David > > > >> return fid->rdir; > >> } > >> > >> diff --git a/net/9p/client.c b/net/9p/client.c > >> index f60d1d041adb..6d9b9054841e 100644 > >> --- a/net/9p/client.c > >> +++ b/net/9p/client.c > >> @@ -765,7 +765,7 @@ static void p9_fid_destroy(struct p9_fid *fid) > >> spin_lock_irqsave(&clnt->lock, flags); > >> idr_remove(&clnt->fids, fid->fid); > >> spin_unlock_irqrestore(&clnt->lock, flags); > >> - kfree(fid->rdir); > >> + kvfree(fid->rdir); > >> kfree(fid); > >> } > >> > >> -- > >> 2.51.0 > >>