Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp809606rwi; Thu, 13 Oct 2022 05:40:23 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Qnhw/CDetmsZZKj/a4evpWbi7Dmxpy41W3rHGkWce/xS/kNQT7Si/BPcFbbliqJGxl9WG X-Received: by 2002:a17:907:7610:b0:78d:b374:898e with SMTP id jx16-20020a170907761000b0078db374898emr17748477ejc.28.1665664822692; Thu, 13 Oct 2022 05:40:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665664822; cv=none; d=google.com; s=arc-20160816; b=pYghdFfsaiqjP5homFBvnXe5p2nveV52Ifc7BxsJ6BHn94CpkDvarhqb0fyjH8Ezu8 Loh7QQ3bDi+LSDtig0o2ZeOyp2yrBcSzu8CrQZhPLtN6tETjIVAyg/yoybyTxH9q1QsW UlEAtJljOlmazU6jjLY7kh2iFSxLN90tRL81FuwCUoHtQYbY3f4EusADiL7IedSNn6g3 CmeqACca1Da3wrWNPWf+X1XF6Q9mLlJYs4yL+xVYxBUpDlUZODxxVBkMJYYGKPYryW3g geGydrtXuia05ApW0NFFt9p2ZX8//t/dWBSztfUyVQHsow/o30tAObtH7xDxqQ8T714/ exwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=APvObyH7Yxci3JC4nOwMrJjuBylthay0v3CgCOkmbX8=; b=DNhq7IUc1owET+PCGItVpo6VqjL5VLK0h0AjTdXHMrFHWc+GH4EZI7ld/ho787t9qV 4/gFUrnHugZBmLw+baP/ohkrT4SiLEctJ5mKvtJCiPyjm7WVXKpwB46FBWKHCsEXv8sZ Eho58Pb5Z/4XNKxR6MmGf289nkbKYqQE9xhS2PtHSedsdO4zcufj9eHtPwIYSQBp6lvw 4tp57G/JptYPCTYKIlXuG0oYq1n5s746kjeFiiMxg9Xp7QIwJHO6REBlKslrfWRrt/zQ 2ttUeA/fq3uVly91GNNnqaWKgf0KP1hhY1G8la5Anr0IzMwlkdu9ZdNgpuPB6WJzzQuG b+Jg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="B+ibmN/g"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qw34-20020a1709066a2200b007123952b00dsi17310833ejc.100.2022.10.13.05.39.56; Thu, 13 Oct 2022 05:40:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="B+ibmN/g"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229557AbiJMMeh (ORCPT + 99 others); Thu, 13 Oct 2022 08:34:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229513AbiJMMef (ORCPT ); Thu, 13 Oct 2022 08:34:35 -0400 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8AA39DED1D for ; Thu, 13 Oct 2022 05:34:34 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id h13so1812682pfr.7 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=RE8NkwAjtIQ4maKZZcD6HJuPtqawKDsn1m8OWqyxi6C+FtjHEK/tXCMVrhhZWqgtiD ET2+cILMdasrLblv3UXManLDfmN09uUEaLyLILxAdNS8JSjaanFcJ6WgUyM5GrtQF4zt SszQjIFMcYQxqGGlRvXpCc7SAj50EmyH7zqcdn/XtK5yQz0cpW1AYu6A4ysC5S5/yQh3 wRYgHEYV/IR8z34Vuk0QXFytCqkZvRNGD8FGz7Nx9OL3dM98rv670p5N+gX/ogVR56yb ys9bcMFgwThisNB6IpGAf1A6A2v+T1B0fayFYpooBqftn9+JKtol+qB1aVp87K+Ocnk8 9rhQ== X-Gm-Message-State: ACrzQf2H5kXv5KiuvSuu67Do5zPZedzR8H7bY3ELjUc64efoNqWsRr7a xpambHBIxVH+na+Huj3ighEcRg== 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> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.