Message ID | 20231208151022.156273-1-aleksandr.mikhalitsyn@canonical.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp5519690vqy; Fri, 8 Dec 2023 07:12:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IG3mqlXIp1VGNJksvDuBStjm81QB33bZDqyyJ0zMGAhNDeoMUk2atVwkzoIIGEH75QgOMCq X-Received: by 2002:a17:902:ee4d:b0:1d0:bb51:d791 with SMTP id 13-20020a170902ee4d00b001d0bb51d791mr187692plo.62.1702048368110; Fri, 08 Dec 2023 07:12:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702048368; cv=none; d=google.com; s=arc-20160816; b=dW7/dIWXpRs+nShrOQ9kSdwu8DZIMaqSVAVBCCrCiQTD9ufzudiMtQAu8pId27RUKe SBCCJW2/q/tUEjtPt2iUKKyDZ16bgtkaRiLXpEN8eGY+sxQxGMZIKOH8iccSQKhIyVka pUg+C1BUb/f+ax9UYlA1EFeegYBMBD9ug9en6VOn2MapvzDzZ7O5rCMoHAeXuXQs+jLq UvBoCzGR7hHeWxUZtq5SzoHX7usSBiD7UCEs87qfPf2J8dsm89PXdQj+Zn/oLeM17i9G aeLWFsUGrfdKyr3kzpeE/CImiOKVBF72Q5vIG1CB7b7agdKiEZ/BO0BQjDNMqXlMOUsu jcHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ahAq0bs9SRy7utEnw9I8X1oqpnFPhDexGIr3W8i6/sw=; fh=zpAjPKQ9oMGKl9fRUIvMVyfcPFrbwKENCUuFSz7sn4M=; b=cmuSmkleBkmWOUKbbYcmXCL6fx8L/ikcaK9bEe6tAdsV+XGKHtmleTgKd9AWL+hcCK e2ovFUx1lDPT7yhI7HkgZ4ILuGUJUdOHo4Mu72PaZ8yfq7nDG0ZQyxyknSH0stTTGpox fOMc2N1YcKKjcT0ZjUj35leWCsGRnEDmLqubk8m23hwr8WKIEJuNyVTn26MoW2r8v3oO ateMvdna1OcTZHzz+7jUAhetgepjqul6LOourcwi/53uaiWlrUa3pYGKX45/0eTL+0pD d8dxBJmQ0z0D1U0zdVp9EN60yPH269HtLt7oztV3zlikF5lBrjYJ18wzotzANkIunx9D cF2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=Ti4KS7vR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id p4-20020a170902e74400b001d01ace7633si1728320plf.567.2023.12.08.07.12.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 07:12:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=Ti4KS7vR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id 9D2EA802B17A; Fri, 8 Dec 2023 07:12:45 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1574331AbjLHPMg (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Fri, 8 Dec 2023 10:12:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1574321AbjLHPMP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 8 Dec 2023 10:12:15 -0500 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CA1E1BC8 for <linux-kernel@vger.kernel.org>; Fri, 8 Dec 2023 07:10:59 -0800 (PST) Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 0175F3F4C0 for <linux-kernel@vger.kernel.org>; Fri, 8 Dec 2023 15:10:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1702048256; bh=ahAq0bs9SRy7utEnw9I8X1oqpnFPhDexGIr3W8i6/sw=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Ti4KS7vRnia70hFmmpifOOxX37fpa4kMxFGbSQHupGwLe4IPmtc/OQbQKmh+2zTQd E7Oxw1Pxh+/HqcQ65ZBJxqIyTqWaTqp0Lp8pFjHaTSQL05XtjJPSOjQaNEZv7d0Yue 8ETldMgyFHwgXDG4f8HkDNbA8mgNepgVDusnNhm4rNfTRbqGbVdl1Syg5pmY7UtHJM vHzyUkjU43tBXFD+Xb2XW/cQNK6ooePReqmam/0lPU8L3YRbEkadvrK8aYsQOba5hB RzFYVM7yFpyUHYvrHDTzj65eHGMsQX4yrmRQAUtMEBykp9EKgRT1vTB4AFyNum1Nu9 ck9MBCJFP0lug== Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a1f6b30185bso42860266b.2 for <linux-kernel@vger.kernel.org>; Fri, 08 Dec 2023 07:10:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702048255; x=1702653055; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ahAq0bs9SRy7utEnw9I8X1oqpnFPhDexGIr3W8i6/sw=; b=a85AHUW6fsBnRZWujkU++quXtl+hn09oDrfQPx0Ity+kohDVnnBS6VcSjvD4T42xQO Er01/rOrSFFOgo2eFW4xvEVpO9dhXwfYCHQ1df7TzYwbYYkkzcQkkSSKralKCLI0f654 u6CVJANPlH4SSt19WsaKBaIjLwQ4ebI5PVvahgapc6vbav3ZblxfZ6lC5S7ygBG59wgT jBjmNsUEeq2qF7TT/u6CfYUJEW+hUFGeiIeEDMBBpzZ1sDPERKoEbv5QuAWl287kDExj 3bUljwTIxsX3YtgXvOTFUX5NfSas79pOPvIJ76KTPpppSmGboJ08HAG1KkBJbaGEQUtd rFkQ== X-Gm-Message-State: AOJu0YwAZ33Ft2bFYlybe0AlJOYKdS14gvVFcLJ5kI6NCPfOE8Vs7QgO liuyiSPspNKHFiZaiTasOrPuJCUUnFe5tBsbmDO/uobudvA8Qz1wPaFSYpvwpeZCWrLfN1YNvVD eQ5SClEFmYv9/oeIxEn6KOTYiXL552Bi3GdDXZvyGRw== X-Received: by 2002:a17:907:7882:b0:a19:d40a:d225 with SMTP id ku2-20020a170907788200b00a19d40ad225mr30588ejc.241.1702048255607; Fri, 08 Dec 2023 07:10:55 -0800 (PST) X-Received: by 2002:a17:907:7882:b0:a19:d40a:d225 with SMTP id ku2-20020a170907788200b00a19d40ad225mr30582ejc.241.1702048255312; Fri, 08 Dec 2023 07:10:55 -0800 (PST) Received: from amikhalitsyn.. ([2a02:8109:8624:a300:c1aa:a6b2:15a4:a9b9]) by smtp.gmail.com with ESMTPSA id vi12-20020a170907d40c00b00a1a8d03347csm1120847ejc.13.2023.12.08.07.10.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Dec 2023 07:10:54 -0800 (PST) From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> To: brauner@kernel.org Cc: linux-fsdevel@vger.kernel.org, Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>, Jan Kara <jack@suse.cz>, Alexander Viro <viro@zeniv.linux.org.uk>, linux-kernel@vger.kernel.org Subject: [PATCH] fs: super: use GFP_KERNEL instead of GFP_USER for super block allocation Date: Fri, 8 Dec 2023 16:10:22 +0100 Message-Id: <20231208151022.156273-1-aleksandr.mikhalitsyn@canonical.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Fri, 08 Dec 2023 07:12:45 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784727069135294229 X-GMAIL-MSGID: 1784727069135294229 |
Series |
fs: super: use GFP_KERNEL instead of GFP_USER for super block allocation
|
|
Commit Message
Aleksandr Mikhalitsyn
Dec. 8, 2023, 3:10 p.m. UTC
There is no reason to use a GFP_USER flag for struct super_block allocation
in the alloc_super(). Instead, let's use GFP_KERNEL for that.
From the memory management perspective, the only difference between
GFP_USER and GFP_KERNEL is that GFP_USER allocations are tied to a cpuset,
while GFP_KERNEL ones are not.
There is no real issue and this is not a candidate to go to the stable,
but let's fix it for a consistency sake.
Cc: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
---
fs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri 08-12-23 16:10:22, Alexander Mikhalitsyn wrote: > There is no reason to use a GFP_USER flag for struct super_block allocation > in the alloc_super(). Instead, let's use GFP_KERNEL for that. > > From the memory management perspective, the only difference between > GFP_USER and GFP_KERNEL is that GFP_USER allocations are tied to a cpuset, > while GFP_KERNEL ones are not. > > There is no real issue and this is not a candidate to go to the stable, > but let's fix it for a consistency sake. > > Cc: Jan Kara <jack@suse.cz> > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > Cc: Christian Brauner <brauner@kernel.org> > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Yeah, since we allocate other filesystem objects with GFP_KERNEL as well I agree. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > diff --git a/fs/super.c b/fs/super.c > index 076392396e72..6fe482371633 100644 > --- a/fs/super.c > +++ b/fs/super.c > @@ -323,7 +323,7 @@ static void destroy_unused_super(struct super_block *s) > static struct super_block *alloc_super(struct file_system_type *type, int flags, > struct user_namespace *user_ns) > { > - struct super_block *s = kzalloc(sizeof(struct super_block), GFP_USER); > + struct super_block *s = kzalloc(sizeof(struct super_block), GFP_KERNEL); > static const struct super_operations default_op; > int i; > > -- > 2.34.1 >
On Fri, 08 Dec 2023 16:10:22 +0100, Alexander Mikhalitsyn wrote: > There is no reason to use a GFP_USER flag for struct super_block allocation > in the alloc_super(). Instead, let's use GFP_KERNEL for that. > > >From the memory management perspective, the only difference between > GFP_USER and GFP_KERNEL is that GFP_USER allocations are tied to a cpuset, > while GFP_KERNEL ones are not. > > [...] Applied to the vfs.misc branch of the vfs/vfs.git tree. Patches in the vfs.misc branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.misc [1/1] fs: super: use GFP_KERNEL instead of GFP_USER for super block allocation https://git.kernel.org/vfs/vfs/c/b91dbdebd653
diff --git a/fs/super.c b/fs/super.c index 076392396e72..6fe482371633 100644 --- a/fs/super.c +++ b/fs/super.c @@ -323,7 +323,7 @@ static void destroy_unused_super(struct super_block *s) static struct super_block *alloc_super(struct file_system_type *type, int flags, struct user_namespace *user_ns) { - struct super_block *s = kzalloc(sizeof(struct super_block), GFP_USER); + struct super_block *s = kzalloc(sizeof(struct super_block), GFP_KERNEL); static const struct super_operations default_op; int i;