From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 5EE4D126F3B for ; Wed, 15 Apr 2026 09:02:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776243722; cv=none; b=MtdnTDaQB9aN868xxntEo3IxY98kgI2Aq6F8FoKSzrCJbqysQIRt+J2LIPmgfQEBUbDmbceUQMNWNHXHVCttHU4ehZaNRyZHJDYfxXBBZSJGiIaez3ywn1BJrfFb+OM8E1ZeB2W+S7zNT7JpcJXnAoerpa6+bK8AarhtgpIkliY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776243722; c=relaxed/simple; bh=6Veu3+OJTF13t1/QXFGJ7fP5M24qm+9jH9gWhW6qe/A=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tyK7dZwCqSplpEOOHRaAxns5Nm6EKLMmprxFLi3KuRCUh44XnevFvUdEY5BY5poIM2vbIc24StqRh6hCzjjIdKR+8zRUEyiaKFh2ZF0ptwZmBXBXtGBuigKjUHPx6F4s70lW5tQ4Sb8xOHsSjXKO8NRj9Z83OJiA3ahwVC8AOus= 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=Hm2QRSOC; arc=none smtp.client-ip=209.85.221.51 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="Hm2QRSOC" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-43d75312379so2125727f8f.1 for ; Wed, 15 Apr 2026 02:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776243720; x=1776848520; 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=IlGudTqrzaNt1I4lqmhLbwqt94V5J4w43GUmCskM5sw=; b=Hm2QRSOCTw77ADCk+f1zsh90hkAhTtRvtsGiPQ/Jc/hbciTMfTE1PsI13knpYcNS9f 9lCvjoMDyXrApyQoDJHQrQOzrP5TS/OZJ/F0xjEB0B3bZcUsuiTubjlT638D/7u2oEXY JMuVZmsJXxA0yMhWw/vC5q1D8xQZteadeSZ4GXSSyw2Ci0AwotFMSrEwC9AHh6rpnohD EzATWzcQF/EhfTbzbaZHDpuK7svFM92QfjGfnG/5IKo6b0f6lqidSzCGH8xvpqFRGxxH pmc8CZJ+ZuukWgMS2UkA5aEkBJoDgT6VUeV2lRXnuQlsAOUqwK70moXf4fbop00PNObq hXRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776243720; x=1776848520; 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=IlGudTqrzaNt1I4lqmhLbwqt94V5J4w43GUmCskM5sw=; b=CSxLxjsf3mP4uIKcZQZnddNlkrniquPWykoyZQ7Kn+lsOtf+uQddGHWbI9Y8Bks3eV W1wHRO5BLteZtIL7v+0u8dljKfdXgbUmtJ6v5SJ85u0vCkOND0BSDu9T3BwZ98W1l/FK Wn944Bdi9hg6Nn6t4Dspm9WAbO/W0hPZEk7r2IGRDXwSXXyQ2QTtvGIEYxk6/eAn8MmG 02AH8+tW/TGV9VjMaHSFutN3GKsWKin/+OijT6axBeG88bWyahN4LpXlyUkJsaDBFTQz ke8l4r1E+OPIJ5yDPFhSH8CrTDO9BVl0U7LzNY/lIoIPLupYGHIY8G/nHfDqcK9bWRTu No7g== X-Forwarded-Encrypted: i=1; AFNElJ8dOqE75CxeXRN2ZmfEriM2u03yf8BoN9AGLRuC9nDXZqDinKXxIEpY/rvfJyPLB1U9vIKm/NqJ2NK5g78=@vger.kernel.org X-Gm-Message-State: AOJu0YzG2WheqfZ08FsiY7O+a6Bimym1ZxDhO6pMClmJPDC07rvUaPA7 kkkAY123R+AUMgnk7HrYvXEtquENhyJYmFUxos+VbQLf9maSrea1TMvC X-Gm-Gg: AeBDies8AGcwH7SorBzzAaUD5Gu8uPkb+HoKXSVgcwSzHp4y/yiFemSbYUR+Vk/nC9d UjO1wcFNKrSUlMt7f7PJBMxXs+UEQ7EFEZfDZ6Gck4r/GONaDXox9dKk1YT5Kai6ocAunkrpZ2+ 0lar0p+8jz8MhpLRW1lxS9NBjO9dVc2QVP53NHlCwdofQb0OMCQ9kR6OskTRfDYs70FfsTw8Dcs ha9V3P4dbc/Q1gBfbv9UYSKZgtiPnPlKQGKJuSauYUJvqVp+88HqEftSmtvu3VNct95mXSeyH3k gu/mtjvP+SlMJdkrBtN8TSfsY0qrCAznGpSaNONDWydfs2bvfrXNj2JWmO8vPOuEOT44zVpOGMD aJ6OuvCs7Kb7c7uswO1BO/SFAI30cVkTnUD3PiEGE8UmNsTqfUJlkavwAfSiIQJUMrzb5KDZvZw RQ8giohELx+4Gh+n1UhheAscraR0ANXW8snPcgu0G7wXb6m72dcA== X-Received: by 2002:a05:6000:1868:b0:43d:7874:5d3b with SMTP id ffacd0b85a97d-43d78745de3mr16241424f8f.9.1776243719489; Wed, 15 Apr 2026 02:01:59 -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-43ead33d6desm3944547f8f.3.2026.04.15.02.01.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 02:01:58 -0700 (PDT) Date: Wed, 15 Apr 2026 10:01:57 +0100 From: David Laight To: "Pierre Barre" Cc: "Eric Van Hensbergen" , "Latchesar Ionkov" , "Dominique Martinet" , "Christian Schoenebeck" , v9fs@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] 9p: use kvzalloc for readdir buffer Message-ID: <20260415100157.4aa33364@pumpkin> In-Reply-To: <06399e04-b019-4c3d-b941-5771b6ac33c2@app.fastmail.com> References: <06399e04-b019-4c3d-b941-5771b6ac33c2@app.fastmail.com> 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 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 >