Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1115988pxb; Fri, 6 Nov 2020 01:05:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJxe7RZH5xiF5BbkBAGnoCk8WGtZ413ftwi7afy3LzqNXOcLq8aGtnU6Ew1oKeiJ1Q0bBH6V X-Received: by 2002:a17:906:ca83:: with SMTP id js3mr1138004ejb.42.1604653536290; Fri, 06 Nov 2020 01:05:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604653536; cv=none; d=google.com; s=arc-20160816; b=owJM88Knr2aXLvxTj+HZguLzyQ2lIph8jxkVKoJ4GYrSL498hCdih4cE7bjUQhv+ez QgPCHYmc2t3UA/5o0k3XFcBs6GxkuwU7jEuWASKtLJ+uOYQb8Xy5A2CGh2rwiLIaEwBw Fs19uZWEaXh1+45a0QQciH1s0pNeYXozU9aawLKPIojk8zbFiG5aFusB07+6+ddo4JFc XZotLUBu3qN/1o0J/A9c8b7S4EwEbPJFEir7DNgMFzmvdTbjrCHA9qNBbvexzhVT1J1J SnGwnIb0uGSpO8pNWd1GOSaiHnxyJ1w5VRcoisVWgkvI42+5/4XteI/QMpQYd+Ni0NwV PgWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=AXXvxPLeZ0ZgicbNMUP+ayy35qo6/4lRgD84ddHygf8=; b=MelrRmGjDEvXF5QiHKvlBo3VFIc33SIE3nAtvEhYJFiwC71Rnjp8HZMkDHGRCh/TAY 13AZ+Ccq9uwzIrDMx+9QAvJGSVzTDcHwahCQF7G3iUyNSidKMu2GOg3B9OFQkfTZ+JA5 gcMShsiM/KD23ISgNR6O0lZGnq1VV6/RuRO8YwqXu7kp5d6CUWEARXzWfW2QD2x8fGbe BZWmDOV4ZKH0bUTo8YsuDOmoXdyWoYo4CstxJDkF23SDQW7s56Yxv+4ys5rju1uwtHgd pMPTQyTgHB8k3inryR4UXpnWpB+2JtdcQuvxH/07N7yDbRteZlO6qiJPkpX1iTw1vFo3 4TPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dllwsNe+; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o19si521139edq.24.2020.11.06.01.05.13; Fri, 06 Nov 2020 01:05:36 -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=@google.com header.s=20161025 header.b=dllwsNe+; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726027AbgKFJDl (ORCPT + 99 others); Fri, 6 Nov 2020 04:03:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726422AbgKFJDe (ORCPT ); Fri, 6 Nov 2020 04:03:34 -0500 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7737C0613CF for ; Fri, 6 Nov 2020 01:03:33 -0800 (PST) Received: by mail-ot1-x344.google.com with SMTP id h62so619982oth.9 for ; Fri, 06 Nov 2020 01:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AXXvxPLeZ0ZgicbNMUP+ayy35qo6/4lRgD84ddHygf8=; b=dllwsNe+675HsXKQuBe0cCmuH+q/b2r+ekFaL7oZ0A5HUg7OEjDg/RLUYexOcbASBD 8pV4JqvCL86fFOR4Gnxo9lu5ZJdncJvDUCqYUjfFpBs6vT13XZK2dYMRxL/tt/i5vRxz DMS/Zlakx50hvra67t4XusA8zTB+Jv+OnBBYgxW+eDbxKPGVPQepiWbVAx2vF/sH4bVf QB7hlEAUtMHcFvBaVxkrkflcuaiLflUfW2cpQcy9t6FuFWwp94A/v6dq7h6MwBTCSXX0 8Uk2G6B4uAOkS/DqOonOTfVthI+D6LRYgA77Gl5C80NGHawV44eiXvK7Z4bAm5fD8QaR fDFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AXXvxPLeZ0ZgicbNMUP+ayy35qo6/4lRgD84ddHygf8=; b=ojUwgigkIgZsX7twZvZaVYVNBzPXDW9ty/HEJ4ADvgBXOV8eO5yHADNKNtIO9ZRM1c SKYrk+mVheqjLjsboZIR/RDDoTaC1yacA25HcWpMhcggD9/IY+mNdSwtXOMXg2OsvzTr RqmS8Zv5aIQ1xglUTO2qP6Cpl3Lbc6lOgKdxxjYa2rjGskRjdfAxqOK26cqLjlsvpbjy Dc5oO8qv77YpoeSg4P0JLd8uBf4oYc8sim4LoKe7j47BDXylBB/jngv1FOu5l5m+UjzJ 5wbyAsF8LBKu6GZdbWmbQS8r6NSxsC+LgKmou3W2pqI3o8CksNO8rCNMjZI9DoHnblIF nThg== X-Gm-Message-State: AOAM5303EhSeU7ItkRXaovH+z1dqdThQ+wA1vy7DPK1stcssSc5YoJGx ky/0QYRTn2q+C0Yk0Ua8FnnWx1mgnVLOxxjS6DMMKA== X-Received: by 2002:a9d:65d5:: with SMTP id z21mr446676oth.251.1604653412954; Fri, 06 Nov 2020 01:03:32 -0800 (PST) MIME-Version: 1.0 References: <20201105220302.GA15733@paulmck-ThinkPad-P72> <20201105220324.15808-3-paulmck@kernel.org> <20201106012335.GA3025@boqun-archlinux> In-Reply-To: <20201106012335.GA3025@boqun-archlinux> From: Marco Elver Date: Fri, 6 Nov 2020 10:03:21 +0100 Message-ID: Subject: Re: [PATCH kcsan 3/3] kcsan: Fix encoding masks and regain address bit To: Boqun Feng Cc: "Paul E. McKenney" , LKML , kasan-dev , kernel-team@fb.com, Ingo Molnar , Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , Qian Cai Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 send a v2 for this one. Thanks, -- Marco