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 421DDC433FE for ; Thu, 13 Oct 2022 12:34:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3255C6B0071; Thu, 13 Oct 2022 08:34:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D4486B0073; Thu, 13 Oct 2022 08:34:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1765B6B0074; Thu, 13 Oct 2022 08:34:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0040A6B0071 for ; Thu, 13 Oct 2022 08:34:35 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 947C84083E for ; Thu, 13 Oct 2022 12:34:35 +0000 (UTC) X-FDA: 80015869710.02.CC155D3 Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf29.hostedemail.com (Postfix) with ESMTP id 2B988120035 for ; Thu, 13 Oct 2022 12:34:34 +0000 (UTC) Received: by mail-pg1-f181.google.com with SMTP id bh13so1442136pgb.4 for ; Thu, 13 Oct 2022 05:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; 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=APvObyH7Yxci3JC4nOwMrJjuBylthay0v3CgCOkmbX8=; b=B+ibmN/g+mZp20zCK5FLPpxB9fs1HPP+TPkGjqE2JglZgP79Rk8ZKknxxkYqaYv3n2 mhnO3P4lIrXR1nPrzJ0TD5FjGIMMXmrbfzPsuHVrEi0DRVgA+IpqTsgJIQSVlEQPeoP2 ao7mZQzNQZXUVAShA1RddUFD9znh89ueyXXGo= 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=APvObyH7Yxci3JC4nOwMrJjuBylthay0v3CgCOkmbX8=; b=L5jFvFYflx5h1E8eB1jzTiFRiv2yzyJMY5LdRI721QlbRK9NHesbUAm7WKKOc71ygT BD1xDdn+bvwNTTKRAyCMscnACAyzJ2HzfG06tpDUBDUIjg3lduzmd0FaWt/u2ixKII+t ysM2Y7xLZPDiLg4eUj92bhz8getwCGIOCbEOmc/s3bqlqYnN+fP2YS3hkWBVRq0NJ5NI vNBv/42DkmdTrB6j/d89QtWFU+lJHmDzgei9XzI5aFRgZ/nGDoe36DPbAQbjeuTP2YXp 3peVXW78ALDxE2QRLzo9tSpbXbMj3hf+ao36S5jK0h3mBGYz/5hgCVdsIXsfkSmYCAjW Gz6g== X-Gm-Message-State: ACrzQf2mp3piQKcWdrxvcfjrKAf6k/W2ysZH1WsirlSgznbgGjP66OSk dbQjQrtbxwYZm4uFJyk03e3VkQ== X-Google-Smtp-Source: AMsMyM6zFl7HUELQyzdf5QZKzojt2du14cXdUpm68Yb20UupNgFgDxw29LoiBbzZN0gIA2+kbmatXA== X-Received: by 2002:a63:1326:0:b0:439:40b5:77cc with SMTP id i38-20020a631326000000b0043940b577ccmr30621188pgl.473.1665664474025; Thu, 13 Oct 2022 05:34:34 -0700 (PDT) Received: from google.com ([240f:75:7537:3187:633d:4747:63f5:81b6]) by smtp.gmail.com with ESMTPSA id u3-20020a170902e5c300b0017f592a7eccsm12498152plf.298.2022.10.13.05.34.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 05:34:33 -0700 (PDT) Date: Thu, 13 Oct 2022 21:34:29 +0900 From: Sergey Senozhatsky To: Andrew Morton , Alexey Romanov Cc: minchan@kernel.org, senozhatsky@chromium.org, ngupta@vflare.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@sberdevices.ru Subject: Re: [PATCH v1] zsmalloc: zs_destroy_pool: add size_class NULL check Message-ID: References: <20221013112825.61869-1-avromanov@sberdevices.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221013112825.61869-1-avromanov@sberdevices.ru> ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="B+ibmN/g"; spf=pass (imf29.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665664475; a=rsa-sha256; cv=none; b=MUwgqeSxky3VUpZ/ZoctgWPbhVD7xLfOYWNGGN5ZllRI+VwjohxZZtIleSUKu5ZgdWCqx+ Sj+lavogFXEGXItg9LASvjj2GSfpywHwvqvv0OEFRBbrz0VYvV7cuv3qazQaWfW2m68NB/ 6HcH05UsM676slXQU/qvTmzvlUQL+VE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665664475; 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=APvObyH7Yxci3JC4nOwMrJjuBylthay0v3CgCOkmbX8=; b=Z8YZyemUGQWCJTobJje+gliMSLckjYcVavlKaeTdNDkFH8yaYE1/TWJxXR3CXRyOItG25K Trd29IgCnG0Ev6wJiWKWWVaZBlyfW7usvhEpKh4FOUsVDJkImCAgoMyuhrHiUQni7p4gUS 1FDBE3GLt4Fsn2jTgtl33k/u3VAw5is= X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="B+ibmN/g"; spf=pass (imf29.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.215.181 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 2B988120035 X-Stat-Signature: whrzy9hqs39xd8z7f15ruefnqz4shyo8 X-HE-Tag: 1665664474-848230 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 (22/10/13 14:28), Alexey Romanov wrote: > Inside the zs_destroy_pool() function, there can still > be NULL size_class pointers: if when the next size_class is > allocated, inside zs_create_pool() function, kzalloc will > return NULL and handling the error condition, zs_create_pool() > will call zs_destroy_pool(). > > Fixes: f24263a5a076 ("zsmalloc: remove unnecessary size_class NULL check") > Signed-off-by: Alexey Romanov > --- > mm/zsmalloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > index 525758713a55..d03941cace2c 100644 > --- a/mm/zsmalloc.c > +++ b/mm/zsmalloc.c > @@ -2311,6 +2311,9 @@ void zs_destroy_pool(struct zs_pool *pool) > int fg; > struct size_class *class = pool->size_class[i]; > > + if (!class) > + continue; > + > if (class->index != i) > continue; Yeah, OK... And totally my fault! I think, I, personally, am done with the "remove if" patches at this point, they are too painful. Alexey, is there anything else we missed? FWIW, Reviewed-by: Sergey Senozhatsky Andrew, The allocation in question should be of a "too small to fail" size, below PAGE_ALLOC_COSTLY_ORDER. So unless that unspoken rule has changed, we should be "fine", since that kmalloc() simply should not fail. It still makes sense to have that particular check in place, just in case. Can you please pull this patch in? And, like I said, I'm going to NAK all future micro-optimizations.