Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1155644pxb; Fri, 6 Nov 2020 02:23:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJw06DXPFmnmnj8UyMlITVpC8R3rYin5GfR2O3D3V7LlbT89sRafPv3S4hhejH27vDzAmKz1 X-Received: by 2002:a05:6402:236e:: with SMTP id a14mr1277408eda.103.1604658224504; Fri, 06 Nov 2020 02:23:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604658224; cv=none; d=google.com; s=arc-20160816; b=UP7h+zyGpy7JwUGyrR43aFDhNawCtaihjAbcUKa3GjGL+e/S0trjuStDX9HVgizPPV BUkKmBL0eEVuFJ11bhnQBgyL/16PQbzlgJMPnEFC/cnncY4Xvxz7LABdYzMKyCC96hLN ATCNdLfBUrCyUjJHPJa6ka5Qr3h7zPL1L+kQjT9cH29soRsLWRjSN9cXd5/63+c9bMT8 F7WxeN/G0EVv3zUvbq51IEv6EgbLJQqT7Ksv/wfp8NpbFbHo5VYPwMH8+wSYrj/yZKMm rOb9d/FDL2zPKSOJ5S6ykQEVj4aStKmFvPP/WpCVqC+nFj8c22FwNLLXxoKICNzhqepz TIXQ== 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=sdK5L9LlPpSjmRzKF8fKPQux7TO4MN23Bk2tcXAjg8U=; b=NqbUwhKE/QNGt8S/leipqGigOi+BLPs/tu+Zid7qs52ApUPPXp2RSLed3N8Uu4HfyP 9w8FMQrUNz3cIvBxStkzUxi2wvfLaaiMKZWgjDZByBTBjyyCxcN/unoR8mIJq8qrIszr QcJHzmTUlN7boxr6wwWVQ8/GsGD4nLEOn6seDi9qeur3rAW9PB9CEafK20+aDTkHD3GK 3ED99HK426AVCeSjFMETDbq2uu+q21VIgkrBHCpvaEf+JnftgOiKbqTmx4H2whKzU90p sYtGrKwcslfGkyw7jQgHqXf4FkqAA7xpgwYNml44HfYPFqUUVLcvjYqso7J5JDAeCaZk gseQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eTkda+8e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q18si502320ejx.84.2020.11.06.02.23.21; Fri, 06 Nov 2020 02:23:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=eTkda+8e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726974AbgKFKTI (ORCPT + 99 others); Fri, 6 Nov 2020 05:19:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725868AbgKFKTH (ORCPT ); Fri, 6 Nov 2020 05:19:07 -0500 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 44BE8C0613CF for ; Fri, 6 Nov 2020 02:19:07 -0800 (PST) Received: by mail-il1-x143.google.com with SMTP id x20so613759ilj.8 for ; Fri, 06 Nov 2020 02:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sdK5L9LlPpSjmRzKF8fKPQux7TO4MN23Bk2tcXAjg8U=; b=eTkda+8ePvyiA3OB64oUVgvBl6/wGPdkBmwVrHs5GpikZ6yvSet20NZ/A2SHxeNsR9 hC4yjjRYMctJJu2wePpWU2Bs2qnjDTHdNiBQDKPhGx9yR7JP6UsbdadbclNX+WeMaPPA Ku/rJWNVJHb91Udl8dzGwQhVbpEVA6IDjNTePL9zubTvDqEFkynmchU1RNmOlmnLvFxt aDFXsUmec4dRTMHM1C/AnQ2i2vPfIK2xdy2e6ubT/HhgX9TWP/LGKVWzJaNa29bcI3hX 6XR1VCYWzp31R7GanSJk0kaPsugEV+hoAF5PNmq7Pli2IeYopyVr6vfHVwcdyCxLXb3/ Og6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sdK5L9LlPpSjmRzKF8fKPQux7TO4MN23Bk2tcXAjg8U=; b=kFcdhO3pepY0skIv+V2MpgCXbAtr4PoJkvM6nRx+aSK0jtg+RdSuc/rgDAYii1Y7jv i7Bac4pQIYe7CfgNScdaMj8ONU3sZ+boF+M8oJc/cUU/R5C6ORVvs7cyJ9JGfWo9MVDM L7kKzUlX/6LoVyCayXGAduRlj2piDAyy6oDW2aAgWtWC2ZjMzZIvwprRogLZrGpRFbBt h+IKCYdOWwz23wrPcdwJbuOJQ8Clw/MdAiDIZaEPA2I6CdTcjLDUGsJjlWIoYa+tDTI3 UqXX5m7D/2iYus+N6TtfwHEQnRDI3DvB1GUqJebDYmJt2AKURHCziLvqRz1x/4m6SGtN mOAg== X-Gm-Message-State: AOAM533L2g1T8bfDirRQBXvLjAEac7vAE4eN+IeYFFpyjGBNzJUogprI jyhj3xNt+n+6AgTF5FScS6c= X-Received: by 2002:a05:6e02:2cc:: with SMTP id v12mr853240ilr.115.1604657946689; Fri, 06 Nov 2020 02:19:06 -0800 (PST) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com. [66.111.4.227]) by smtp.gmail.com with ESMTPSA id m10sm752952ilg.77.2020.11.06.02.19.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2020 02:19:06 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 002C627C005A; Fri, 6 Nov 2020 05:19:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 06 Nov 2020 05:19:01 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtledgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhn ucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrth htvghrnhepvdelieegudfggeevjefhjeevueevieetjeeikedvgfejfeduheefhffggedv geejnecukfhppedufedurddutdejrddugeejrdduvdeinecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhh phgvrhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunh drfhgvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgv X-ME-Proxy: Received: from localhost (unknown [131.107.147.126]) by mail.messagingengine.com (Postfix) with ESMTPA id D88B33060060; Fri, 6 Nov 2020 05:18:59 -0500 (EST) Date: Fri, 6 Nov 2020 18:18:56 +0800 From: Boqun Feng To: Marco Elver Cc: "Paul E. McKenney" , LKML , kasan-dev , kernel-team@fb.com, Ingo Molnar , Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Qian Cai Subject: Re: [PATCH kcsan 3/3] kcsan: Fix encoding masks and regain address bit Message-ID: <20201106101856.GC3025@boqun-archlinux> References: <20201105220302.GA15733@paulmck-ThinkPad-P72> <20201105220324.15808-3-paulmck@kernel.org> <20201106012335.GA3025@boqun-archlinux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 06, 2020 at 10:03:21AM +0100, Marco Elver wrote: > On Fri, 6 Nov 2020 at 02:23, Boqun Feng wrote: > > Hi Marco, > > > > On Thu, Nov 05, 2020 at 02:03:24PM -0800, paulmck@kernel.org wrote: > > > From: Marco Elver > > > > > > The watchpoint encoding masks for size and address were off-by-one bit > > > each, with the size mask using 1 unnecessary bit and the address mask > > > missing 1 bit. However, due to the way the size is shifted into the > > > encoded watchpoint, we were effectively wasting and never using the > > > extra bit. > > > > > > For example, on x86 with PAGE_SIZE==4K, we have 1 bit for the is-write > > > bit, 14 bits for the size bits, and then 49 bits left for the address. > > > Prior to this fix we would end up with this usage: > > > > > > [ write<1> | size<14> | wasted<1> | address<48> ] > > > > > > Fix it by subtracting 1 bit from the GENMASK() end and start ranges of > > > size and address respectively. The added static_assert()s verify that > > > the masks are as expected. With the fixed version, we get the expected > > > usage: > > > > > > [ write<1> | size<14> | address<49> ] > > > > > > Functionally no change is expected, since that extra address bit is > > > insignificant for enabled architectures. > > > > > > Signed-off-by: Marco Elver > > > Signed-off-by: Paul E. McKenney > > > --- > > > kernel/kcsan/encoding.h | 14 ++++++-------- > > > 1 file changed, 6 insertions(+), 8 deletions(-) > > > > > > diff --git a/kernel/kcsan/encoding.h b/kernel/kcsan/encoding.h > > > index 4f73db6..b50bda9 100644 > > > --- a/kernel/kcsan/encoding.h > > > +++ b/kernel/kcsan/encoding.h > > > @@ -37,14 +37,12 @@ > > > */ > > > #define WATCHPOINT_ADDR_BITS (BITS_PER_LONG-1 - WATCHPOINT_SIZE_BITS) > > > > > > -/* > > > - * Masks to set/retrieve the encoded data. > > > - */ > > > -#define WATCHPOINT_WRITE_MASK BIT(BITS_PER_LONG-1) > > > -#define WATCHPOINT_SIZE_MASK \ > > > - GENMASK(BITS_PER_LONG-2, BITS_PER_LONG-2 - WATCHPOINT_SIZE_BITS) > > > -#define WATCHPOINT_ADDR_MASK \ > > > - GENMASK(BITS_PER_LONG-3 - WATCHPOINT_SIZE_BITS, 0) > > > +/* Bitmasks for the encoded watchpoint access information. */ > > > +#define WATCHPOINT_WRITE_MASK BIT(BITS_PER_LONG-1) > > > +#define WATCHPOINT_SIZE_MASK GENMASK(BITS_PER_LONG-2, BITS_PER_LONG-1 - WATCHPOINT_SIZE_BITS) > > > +#define WATCHPOINT_ADDR_MASK GENMASK(BITS_PER_LONG-2 - WATCHPOINT_SIZE_BITS, 0) > > > +static_assert(WATCHPOINT_ADDR_MASK == (1UL << WATCHPOINT_ADDR_BITS) - 1); > > > > Nit: > > > > Since you use the static_assert(), why not define WATCHPOINT_ADDR_MASK > > as: > > > > #define WATCHPOINT_ADDR_MASK (BIT(WATCHPOINT_SIZE_BITS) - 1) > > This is incorrect, as the static_assert()s would have indicated. It > should probably be (BIT(WATCHPOINT_ADDR_BITS) - 1)? > > As an aside, I explicitly did *not* want to use additional arithmetic > to generate the masks but purely rely on BIT(), and GENMASK(), as it > would be inconsistent otherwise. The static_assert()s then sanity > check everything without BIT+GENMASK (because I've grown slightly > paranoid about off-by-1s here). So I'd rather not start bikeshedding > about which way around things should go. > > In general, GENMASK() is safer, because subtracting 1 to get the mask > doesn't always work, specifically e.g. (BIT(BITS_PER_LONG) - 1) does > not work. > > > Besides, WATCHPOINT_SIZE_MASK can also be defined as: > > No, sorry it cannot. > > > #define WATCHPOINT_SIZE_MASK GENMASK(BITS_PER_LONG - 2, WATCHPOINT_SIZE_BITS) > > GENMASK(BITS_PER_LONG - 2, WATCHPOINT_SIZE_BITS) > > is not equivalent to the current > > GENMASK(BITS_PER_LONG-2, BITS_PER_LONG-1 - WATCHPOINT_SIZE_BITS) > > Did you mean GENMASK(BITS_PER_LONG-2, WATCHPOINT_ADDR_BITS)? I can You're right! Guess I should check first about what vim completes for me ;-) And I agree with you on the preference to GENMASK() > send a v2 for this one. Let me add an ack for that one, thanks! Regards, Boqun > > Thanks, > -- Marco