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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E75BC433FE for ; Mon, 28 Mar 2022 10:10:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240169AbiC1KM1 (ORCPT ); Mon, 28 Mar 2022 06:12:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235601AbiC1KMZ (ORCPT ); Mon, 28 Mar 2022 06:12:25 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C88F452E12 for ; Mon, 28 Mar 2022 03:10:44 -0700 (PDT) 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 841381F37E; Mon, 28 Mar 2022 10:10:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1648462243; 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=MEUjP7knGa/NIjIdm17InHHeis0a7CbD1Zy0ms8KFt4=; b=VGijNzoIi8tSLKplwWXwpv83yPzhlX4c6/0YnH7iiqrDPb9dOGGWen4T78zMRbWgbCvhnE 15/NrhAfM3yDAGnOGM7aOzv51N1/AZ7/xUlAvga01H6F49oZnTEKg9AQ+k/NSoP3cW6Ost +i7rgMR2GV9JiRZjR+rBuIBUpxSjf4U= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1648462243; 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=MEUjP7knGa/NIjIdm17InHHeis0a7CbD1Zy0ms8KFt4=; b=b23bF/+1Gspjhj8aQE39s29aPL3wPkpcD12HSrGVystQMZa029E8E04iQl8AxUdqH3wrhX jKpFwpW0W6D584Ag== 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 4E80413215; Mon, 28 Mar 2022 10:10:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id MN8rEqOJQWLlPQAAMHmgww (envelope-from ); Mon, 28 Mar 2022 10:10:43 +0000 Message-ID: <0b22192a-b5e5-93a3-6ed7-7670ff15844d@suse.cz> Date: Mon, 28 Mar 2022 12:09:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] mm, kasan: fix __GFP_BITS_SHIFT definition breaking LOCKDEP Content-Language: en-US To: andrey.konovalov@linux.dev, Andrew Morton Cc: Andrey Konovalov , Marco Elver , Alexander Potapenko , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, linux-mm@kvack.org, Matthew Wilcox , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Andrey Konovalov References: <462ff52742a1fcc95a69778685737f723ee4dfb3.1648400273.git.andreyknvl@google.com> From: Vlastimil Babka In-Reply-To: <462ff52742a1fcc95a69778685737f723ee4dfb3.1648400273.git.andreyknvl@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/27/22 19:00, andrey.konovalov@linux.dev wrote: > From: Andrey Konovalov > > KASAN changes that added new GFP flags mistakenly updated __GFP_BITS_SHIFT > as the total number of GFP bits instead of as a shift used to define > __GFP_BITS_MASK. > > This broke LOCKDEP, as __GFP_BITS_MASK now gets the 25th bit enabled > instead of the 28th for __GFP_NOLOCKDEP. > > Update __GFP_BITS_SHIFT to always count KASAN GFP bits. > > In the future, we could handle all combinations of KASAN and LOCKDEP to > occupy as few bits as possible. For now, we have enough GFP bits to be > inefficient in this quick fix. > > Fixes: 9353ffa6e9e9 ("kasan, page_alloc: allow skipping memory init for HW_TAGS") > Fixes: 53ae233c30a6 ("kasan, page_alloc: allow skipping unpoisoning for HW_TAGS") > Fixes: f49d9c5bb15c ("kasan, mm: only define ___GFP_SKIP_KASAN_POISON with HW_TAGS") > Reported-by: Sebastian Andrzej Siewior > Signed-off-by: Andrey Konovalov Acked-by: Vlastimil Babka > --- > include/linux/gfp.h | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 0fa17fb85de5..761f8f1885c7 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -264,9 +264,7 @@ struct vm_area_struct; > #define __GFP_NOLOCKDEP ((__force gfp_t)___GFP_NOLOCKDEP) > > /* Room for N __GFP_FOO bits */ > -#define __GFP_BITS_SHIFT (24 + \ > - 3 * IS_ENABLED(CONFIG_KASAN_HW_TAGS) + \ > - IS_ENABLED(CONFIG_LOCKDEP)) > +#define __GFP_BITS_SHIFT (27 + IS_ENABLED(CONFIG_LOCKDEP)) > #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1)) > > /**