From patchwork Tue Oct 11 14:54:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13004097 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 81DE9C4332F for ; Tue, 11 Oct 2022 14:54:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 052476B0071; Tue, 11 Oct 2022 10:54:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0014D6B0073; Tue, 11 Oct 2022 10:54:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0BD76B0074; Tue, 11 Oct 2022 10:54:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CF3596B0071 for ; Tue, 11 Oct 2022 10:54:23 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8EFD6A12A1 for ; Tue, 11 Oct 2022 14:54:23 +0000 (UTC) X-FDA: 80008964406.14.ED720B7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id F21E58000F for ; Tue, 11 Oct 2022 14:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665500062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=gxl14rr+gZ4Prexr6Gkf/0xrN2bYKr3cP8aqjLcL9tI=; b=HJ23tKzXKp0YHMI5TzfOn6SKFiNgQDDu6I27GGq0A0WcbiXtHkm6fq0CiyxAPx9GrxUnL4 UFCPnolJ7Aysop/UTzu20CbS9OMg/VmNTdtYDV4cPqhplLQWOiFel356WSo1OfzLNU4PXS DCpT1pdu7w0AVMnxCwyMc3meh2Fj7iM= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-192-RLHEwjdZOHq8IbtPh4QX3w-1; Tue, 11 Oct 2022 10:54:18 -0400 X-MC-Unique: RLHEwjdZOHq8IbtPh4QX3w-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1E0AB3817962; Tue, 11 Oct 2022 14:54:16 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id B6751475066; Tue, 11 Oct 2022 14:54:14 +0000 (UTC) From: Alexander Aring To: cl@linux.com Cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cluster-devel@redhat.com, aahringo@redhat.com Subject: [PATCHv2] mm: slab: comment __GFP_ZERO case for kmem_cache_alloc Date: Tue, 11 Oct 2022 10:54:13 -0400 Message-Id: <20221011145413.8025-1-aahringo@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665500063; a=rsa-sha256; cv=none; b=xuQlkyJxwo1h/RDGF3HDp6cnucivxVJMCkd/qBxTSHgaSw+Nt0J47PPXsuCZEr+LnQJnOQ eU5VTmCF/i3NjR4o/o/gFTo9fVS/6O1mu6KU23Kr4mNbUq140zcdoSk+IxubIbMTfZpEI7 3e6wbuc4u/zmgpMOyhdV3vVcevCz1jA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HJ23tKzX; spf=pass (imf02.hostedemail.com: domain of aahringo@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=aahringo@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665500063; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=gxl14rr+gZ4Prexr6Gkf/0xrN2bYKr3cP8aqjLcL9tI=; b=UMhd8S9u2d/0Nk+WApWsCvd8WQUcBEHfZxHdNLii0k7vndZaUeTRFan9EISU96H7gEWZtf jtUvVybOlZiQ7vKO1hikTBDmUgAZFplrAVb+sLF9X87AWPVaixz6BBUx9MhQ9nKSW2Qn9y DeXrcioPPgJ0BxdA/RP16iuYkMU/jDQ= Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HJ23tKzX; spf=pass (imf02.hostedemail.com: domain of aahringo@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=aahringo@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: bs79m3cr5j8p3py1gq83kmoz15mwp811 X-Rspamd-Queue-Id: F21E58000F X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1665500062-650257 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: 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. Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Acked-by: David Rientjes Signed-off-by: Alexander Aring --- changes since v2: - don't make a separate sentence for except mm/slab.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/slab.c b/mm/slab.c index 10e96137b44f..a86879f42f2e 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 */