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 1B73FC4332F for ; Fri, 14 Oct 2022 07:35:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 372A16B0072; Fri, 14 Oct 2022 03:35:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3223E6B0075; Fri, 14 Oct 2022 03:35:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C2CE6B0078; Fri, 14 Oct 2022 03:35:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 0A0E66B0072 for ; Fri, 14 Oct 2022 03:35:20 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 74A99140CF5 for ; Fri, 14 Oct 2022 07:35:19 +0000 (UTC) X-FDA: 80018744358.17.E29DA48 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf07.hostedemail.com (Postfix) with ESMTP id A050340030 for ; Fri, 14 Oct 2022 07:35:18 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3B4BB1F74A; Fri, 14 Oct 2022 07:35:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1665732917; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IjAKlOIc9+kUV/2uFXOWSjipZ0QlJBcD+i3sVbc0+lY=; b=gmQwQOa+gwNxtkeplHUOMU3gKgX7mP0mtx4iu+znQ2QvrIlNFei5ASTKBl/mtTMlo//O/w SNxmnvMPUdinLaNeSs3H2kVnavMnWG46bTazFARv9CyT17JEGcjZ3TWe4ckMjUKyqUjZfG 032F7Udc+ls7zH5Kf7dmCUje5n0skko= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1665732917; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IjAKlOIc9+kUV/2uFXOWSjipZ0QlJBcD+i3sVbc0+lY=; b=YL77d77d5dBqe8q7MpQmiDcaPuTwxUAK4y6Ge1KacsVLcMLPggf+MfZFLn8onwSczLZtyZ Vb/UZ7DK184TkAAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 13A1A13A4A; Fri, 14 Oct 2022 07:35:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 3jMPBDURSWPXXQAAMHmgww (envelope-from ); Fri, 14 Oct 2022 07:35:17 +0000 Message-ID: <931c87d8-5856-e393-7108-66275ee4099a@suse.cz> Date: Fri, 14 Oct 2022 09:35:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCHv2] mm: slab: comment __GFP_ZERO case for kmem_cache_alloc Content-Language: en-US To: Alexander Aring , cl@linux.com Cc: penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cluster-devel@redhat.com References: <20221011145413.8025-1-aahringo@redhat.com> From: Vlastimil Babka In-Reply-To: <20221011145413.8025-1-aahringo@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665732919; a=rsa-sha256; cv=none; b=SyUJ3o5ZeB/bS8VmTW/n0MWkm7ozdA8BEu1WywDkFdYPySYGyp388cKnJ/ZiASjBGfZiSa rZuvuC+cwAVIzy4VcTxTEgicArMIhv/NmhOojktGKeU/Er2qR8i1kyyKTfXF5cFsbpcYX8 FSvfmamP7Xo+F57a0iiUKrkwawXq9qo= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=gmQwQOa+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YL77d77d; spf=pass (imf07.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665732919; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=IjAKlOIc9+kUV/2uFXOWSjipZ0QlJBcD+i3sVbc0+lY=; b=z7Cr3XhhiZlqW4PlaojuY8cmqLxbos+0IgSMLFtKuGdYZuFCkG52buZAOuJsOOLsdNhj0l AdP+hHwNWlXa3f2gLZTJNZQgnO0CHj8SGY+9TyHbjG019pbVOlFOVY6mZySB69k3otOuGz x3aDog0et60Tymm/9er1X2O/wSEE0uY= X-Stat-Signature: 1d11xhy5fn8ytin1qintxnzs7koeoxzf X-Rspamd-Queue-Id: A050340030 X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=gmQwQOa+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YL77d77d; spf=pass (imf07.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-Rspamd-Server: rspam06 X-HE-Tag: 1665732918-962186 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 10/11/22 16:54, 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. Hmm, but even with the update, the comment is still rather misleading, no? - can the caller know if the cache has available objects and thus the flags are irrelevant, in order to pass flags that are potentially wrong (if there were no objects)? Not really. - even if cache has available objects, we'll always end up in slab_pre_alloc_hook doing might_alloc(flags) which will trigger warnings (given CONFIG_DEBUG_ATOMIC_SLEEP etc.) if the flags are inappropriate for given context. So they are still "relevant" So maybe just delete the whole comment? slub.c doesn't have it, and if any such comment should exist for kmem_cache_alloc() and contain anything useful and not misleading, it should be probably in include/linux/slab.h anyway? > 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 > */