From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 E54BC3C3C02 for ; Wed, 15 Apr 2026 13:45:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776260721; cv=none; b=JQPcToq9KoMGyEAhTXpbF4yuWWVPZIeOZ8ILIzbi1bBe6jtZGddgvFK+wgEVFf2juWrSzpT/M24GmCflJGns+tifFijsDkgGJ0jILir1KFbclQsShXPj0FpXlg9BsWM+7Ip6d4Io+a/XkMcjeTxv489X92bdsqPgDChfFrE8PZw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776260721; c=relaxed/simple; bh=yNep/9PJEs3PTjQsUSNsv0cMrrDg0ssQJNQ8w5cudl4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mcjknbSrQnhDpbGnAXd1RHvkv2t09JX1sDChQutth2lxv3T7Z/TnjXzOmIyazMKoIZDQ9HgTgf4vcw8+fBTp9Ey8bCc+8huHD0OVXc13koBNlXNW+Icn0oG7tGKulzeKIK1IwyUYQY/K3B+PsaQ0P+4AJ3Mur+EgmR3bgu50b7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=Gzwacxbd; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Gzwacxbd" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=BnqbigBGJMzyNSdWaIgD61qj4pLhrUMBjXiM4G7xin4=; b=GzwacxbdjU4k8LyifGbcckiLgj ijR9FdhwFHMZd+iBAjDhtFqjxb1RDxKY5/BWaCvBsoycEp3O/ertlOXS5PjBZ3eij88akegBpnnf2 HWS2XwCkfprhGHaJ9Pi41O046zKLnHYcUgBhOmGsXY5AJ9ZwO29zs4dawAI5fUgFBXEHWGyhXxUoc FPhYWJvgGvp9jPwvKUwXKuGU1RnVmlxszRbCrD+l620daTH4rIMINeJZkQcCftj+KisOsk4H0dSH1 /ejwL14Rl88je0dBGoDdXYd6UcA/4WRn/ZTALb4Ey2y42iV6m19yW2FB/6E1PQJPQC/iCgxLVp0KG 2Q8z2pcw==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1wD0YF-0000000HVrc-3XDh; Wed, 15 Apr 2026 13:45:07 +0000 Date: Wed, 15 Apr 2026 14:45:07 +0100 From: Matthew Wilcox To: Baolin Wang Cc: akpm@linux-foundation.org, hughd@google.com, ziy@nvidia.com, david@kernel.org, ljs@kernel.org, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: shmem: don't set large-order range for internal shmem mount Message-ID: References: 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: On Wed, Apr 15, 2026 at 04:22:53PM +0800, Baolin Wang wrote: > + /* > + * Only set the large order range for tmpfs mounts. The large order > + * selection for the internal shmem mount is configured dynamically > + * via the 'shmem_enabled' interfaces, so there is no need to set a > + * large order range for the internal shmem mount's mapping. > + * > + * Note: Don't consider 'deny' for emergencies and 'force' for > + * testing. > + */ > + if (sbinfo->huge && !(sb->s_flags & SB_KERNMOUNT)) > mapping_set_large_folios(inode->i_mapping); This isn't how mapping_set_large_folios() is supposed to be used. It's supposed to indicate "does the filesystem support large folios". shmem should be setting it unconditionally and if there needs to be some other way to prevent large folios from being created, we should do that instead. The current code is wrong too.