From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 909C3C433FE for ; Sat, 8 Oct 2022 04:38:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7E816B0072; Sat, 8 Oct 2022 00:38:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C2F7A6B0073; Sat, 8 Oct 2022 00:38:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF6456B0074; Sat, 8 Oct 2022 00:38:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9DD1F6B0072 for ; Sat, 8 Oct 2022 00:38:55 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 588AC160567 for ; Sat, 8 Oct 2022 04:38:55 +0000 (UTC) X-FDA: 79996527030.09.6CFFAB5 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) by imf15.hostedemail.com (Postfix) with ESMTP id F3D42A001C for ; Sat, 8 Oct 2022 04:38:54 +0000 (UTC) Received: by mail-pf1-f180.google.com with SMTP id i6so6550203pfb.2 for ; Fri, 07 Oct 2022 21:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=knSy7HMcW9hIxtzP/QHqpkjPX5uvUVeEAsZZrCBYftM=; b=FZq7MetQyUKFfEwcL1sCK+u+TIBWXMPgmMOzjw+aiOcDxpXDaA9XfkBdEFYZugPX+w 8ijnSUaY+1582TA1w6/yeIJsW7xVgVmt6yhODXDoX/JOz5e4z1OY/ZTRB3dAnk8Zvrin iCHxrLrDvM4RAQeLImS5PexVJnJcupRXM7oHgN6xmfk99d/hrqCBQWLu2sKugMbqwhds qKftxNDQfON7cJIiSeQ+r7R18ic2fAfAVgRRpVXWPW/HQHbMarvEoA7Wor9hcJE5yQWT btIoSFm17ZAmvAtEK2ludpJn7AJYt4ykEV2QgFyMDTwwVuV77sJVWhnXlWuX/Xz2ZW3A K92w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=knSy7HMcW9hIxtzP/QHqpkjPX5uvUVeEAsZZrCBYftM=; b=SDHXVWujRiTjLmFRXyy6wVc8Jpwq9ksHgGB3GFgiMb83jx4y0RokXMCk84Tr4ODam7 Bu5VNJuhKeC0PH+GBchdV00VBZ9Td8vPIo6NqyBTVjhbvoJ4vUuDD8yB1G7TUbbyeHTk V3524HAG6hDh2jyL/XrkrXi8D5w//RswV1s3XuR9roe3ha760GUun/qN5HE3lT77P47z au24ti2o29wT6ZulfocdqDXElEBAzZW5pp7V2YlWQ2M/mih6FSWV5VQMOGWPk9VYx1Hb +sTBb1+1vO1C7bD2yT+IYCG30CZq9awQzR5Yjcd/ZTWihcg8mJKdjbdsznytcsBDUt5Y ffUg== X-Gm-Message-State: ACrzQf07ITN/imo7AyIrq0dmWhLpgGZTJ25cnjdmX74eQhqEBAU8KyrT KvJm4dA3R4I3h6jRE0bLzepzAAOn9K4ctgeK X-Google-Smtp-Source: AMsMyM6dMrfJHPQGVen9cJacv4Rm9dU1784g4PuV2+RhUSXl9rTsm4n+ngPuL7ehdjL14Joz/JkaYw== X-Received: by 2002:a63:4507:0:b0:43c:9cf4:f1d6 with SMTP id s7-20020a634507000000b0043c9cf4f1d6mr7674900pga.316.1665203933858; Fri, 07 Oct 2022 21:38:53 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id u13-20020a170903124d00b0017f80305239sm2348032plh.136.2022.10.07.21.38.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Oct 2022 21:38:52 -0700 (PDT) Date: Sat, 8 Oct 2022 13:38:47 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Alexander Aring Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cluster-devel@redhat.com Subject: Re: [PATCH] mm: slab: comment __GFP_ZERO case for kmem_cache_alloc Message-ID: References: <20221008020312.1932347-1-aahringo@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221008020312.1932347-1-aahringo@redhat.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665203935; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=knSy7HMcW9hIxtzP/QHqpkjPX5uvUVeEAsZZrCBYftM=; b=Rvf6GPkpFzaygCRrgw7O4IuFtvBXPxyGf0quTor+ODnLdF83nJqOHLK88XUREwjOhLSlCW 7F575WR6fqpM9ySzP9tBA71fQO2XLktPStNNNdX5cKE9K/3lnbDvNZcx1QIKBeVUsQxr+1 qLDO8AlBKwkJGatB6TxqONTsbbMaeyw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FZq7MetQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665203935; a=rsa-sha256; cv=none; b=xBZgqrO2DCgJAQzoqfJ6CRZ6VqdV6U4c+Ksi7X1hmoZEwSG7AydQyWX5ODlzhAC9/LrrK7 hvcM/nUeLAY2BTF9p9hCzxdeRCDSjpTl5rF7I54u35q/MiLJWUy0VbuAb7r7d5ySiTgLMW a35/ttE8UlFF+yIbBKXn092h3JV9rBc= Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FZq7MetQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.180 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Stat-Signature: pso6s15azw1gijg4n8kjmq5yqwqetnp6 X-Rspamd-Queue-Id: F3D42A001C X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1665203934-400193 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 07, 2022 at 10:03:12PM -0400, Alexander Aring wrote: > This patch will add a comment for the __GFP_ZERO flag case for > kmem_cache_alloc(). As the current comment mentioned that the flags only > matters if the cache has no available objects it's different for the > __GFP_ZERO flag which will ensure that the returned object is always > zeroed in any case. > > I have the feeling I run into this question already two times if the > user need to zero the object or not, but the user does not need to zero > the object afterwards. However another use of __GFP_ZERO and only zero > the object if the cache has no available objects would also make no > sense. > > Signed-off-by: Alexander Aring > --- > mm/slab.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/slab.c b/mm/slab.c > index 10e96137b44f..7a84c2aae85a 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -3482,7 +3482,8 @@ void *__kmem_cache_alloc_lru(struct kmem_cache *cachep, struct list_lru *lru, > * @flags: See kmalloc(). > * > * Allocate an object from this cache. The flags are only relevant > - * if the cache has no available objects. > + * if the cache has no available objects. Except flag __GFP_ZERO which > + * will zero the returned object. > * > * Return: pointer to the new object or %NULL in case of error > */ > -- > 2.31.1 > Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Thanks! -- Thanks, Hyeonggon