Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp139944rwe; Tue, 23 Aug 2022 20:32:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR6N7NnZH9ftwBQlzRO7WGjSdqqZavxp6ItddQKbDTQ2nvj3nDvf9OUENFWsz1aPMyPakyuf X-Received: by 2002:a17:907:6e86:b0:73d:7f7f:bbc9 with SMTP id sh6-20020a1709076e8600b0073d7f7fbbc9mr1570395ejc.409.1661311972750; Tue, 23 Aug 2022 20:32:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661311972; cv=none; d=google.com; s=arc-20160816; b=yck99qoBS4lcPvfbIbuibRXl6OHuTpqFsWxWepl4+nv4BDGbEvGMY2JuIAQHLoHQ4F lbbGAdN5eJxZg/ygLYvblH3+BQNgr/khYkVZRBsYpNt8Vq94v2v+UW8hAftqdIciCiZm IFOhd8UWTTVlSST8dJf9GOUj+HofnJiG0fJn/kgjplbtro1I8UHumoWy7IGCtbiicQ1u UbQrc1CgscHZSZGmK27KWshTZRwHXj1S7cLCjSiS/tDNIyjkzXQsZrg/l5l/p9TQCnbk fykfjqJ9DhurM+cn8jKfYEVQQdvk+Yuorllr09ywkXL0KKLasBEFxINPc82Ckm9jaKpY dzCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=QJGeRreNTQFFl/bsTPloLjtIHYkEFtbk/1jiV/Jw+FU=; b=U5QNhJ2cApj6qaoKRMfsMV8H+vk8YHbKnh8osj7mHbgUUeZlHi8byJ39AS7BKDSyeS gSnM9AgIxVPuhysOJvkYy/LWyntj6014TfwqQFyUGLirNh1Bx010xR1otJ9pIyhKglZA 76kIJ4ksPDaICNeT7/dpCCJBHE/IGPdCtaJRpYPCCXut5IsMpz/IHWXU72bsfVp0mbZe /kxk08TDuR43Gsx0AZ2F4TiWdEdVbrFrdqdw2YeO6d7Vqks9bHRzt3CYSeVw+j08QNm9 oIsCl6ak2c/QKXsf1AaZxB7ekfQtX64/7oNKNfnvEQLOyAaGXUkGkOpUyxZS1N2VW+RG HqeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=hvFJQAjL; 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=zeniv.linux.org.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s6-20020a1709062ec600b0072f09e7093fsi1082303eji.141.2022.08.23.20.32.27; Tue, 23 Aug 2022 20:32:52 -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=@linux.org.uk header.s=zeniv-20220401 header.b=hvFJQAjL; 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=zeniv.linux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234187AbiHXDMM (ORCPT + 99 others); Tue, 23 Aug 2022 23:12:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235362AbiHXDL3 (ORCPT ); Tue, 23 Aug 2022 23:11:29 -0400 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 754B67EFC2 for ; Tue, 23 Aug 2022 20:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=QJGeRreNTQFFl/bsTPloLjtIHYkEFtbk/1jiV/Jw+FU=; b=hvFJQAjLGb4Z18Tb3hVWfA7PHV o4IukyyyNa1V1G7Hrx+JdZXXxog4iQDuwIMrBGSFXp/L1N4Os3XJUO6cx9nbOeavzg4C3/8VFBmx5 dmjXVA/KD4aOOw9yl8/AreK4mcdMgYXHV/upiHgPrWy6InfRYUR+kBpedqq7IEOord7KnbwNWIAp4 iupnkbXu0HnyCEdjNP5t5Q5oXr4NVM1cSfNFJ1hfoM1YM8xJ7X0LptJ/ZdPs0ovc/1mXPYmDSqCPq YXCBBX3gYsWyekIw6ICLskFk0y29YyYlBdyaeHohwkbg/DuY6kIoE38d+adY+QSq1UBO7uSyFSp9D GcsZTPIw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1oQgmf-007d0f-Q9; Wed, 24 Aug 2022 03:10:25 +0000 Date: Wed, 24 Aug 2022 04:10:25 +0100 From: Al Viro To: Linus Torvalds Cc: Bart Van Assche , Rasmus Villemoes , Steven Rostedt , linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Christoph Hellwig , Luc Van Oostenryck , Jens Axboe Subject: Re: [for-linus][PATCH 01/10] tracing: Suppress sparse warnings triggered by is_signed_type() Message-ID: References: <20220821000737.328590235@goodmis.org> <20220821000844.510643400@goodmis.org> <5700ac75-f6a9-877e-4011-9b314f12b5ab@acm.org> <02daa3d6-2847-d7e0-e23e-411076c6d4db@rasmusvillemoes.dk> <0163b361-14bf-7b4c-751a-14f1a004b1a9@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED 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 Wed, Aug 24, 2022 at 03:09:07AM +0100, Al Viro wrote: > On Tue, Aug 23, 2022 at 04:57:00PM -0700, Linus Torvalds wrote: > > On Tue, Aug 23, 2022 at 4:18 PM Linus Torvalds > > wrote: > > > > > > Can you try the sparse version at > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git > > > > > > which I just set up temporarily with some patches of mine. > > > > Ugh, and while testing this with sparse, I noticed that sparse itself > > got that whole 'is_signed_type()' check wrong. > > > > The sparse fix was to remove one line of code, but that one worries > > me, because that one line was clearly very intentional: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git/commit/?id=7e5f1c2eba1426e414698071dd0de7d039eb385d > > > > Adding Al, since he's actually the original source of that bitwise > > code (and did a lot of other sparse code on the type handling and > > preprocessor side in particular). > > Ouch... That'll take quite a bit of swap-in (and digging through the > old notes). The basic approach was to have them *NOT* treated as integer types; it's SYM_RESTRICT node refering to the node for underlying type. MOD_CHAR/MOD_LONG/MOD_UNSIGNED/etc. make no more sense for that than they do for e.g. pointers. Any operations like ordered comparisons would trigger unrestrict() on these suckers, which would warn and convert to underlying type. Your addition of "ordered comparison with 0 or -1" evades unrestrict(). Which shuts the warning up, but that leaves evaluate_compare() with something unexpected - if (ctype->ctype.modifiers & MOD_UNSIGNED) expr->op = modify_for_unsigned(expr->op); running into SYM_RESTRICT node. *IF* you want to go that way, I would suggest a new return value for restricted_binop() ("comparison with magical value"), with something like switch (restricted_binop(op, ctype)) { case 1: .... default: break; case 4: // comparison with magic value: // quietly go for underlying type, if not fouled // if fouled, just return NULL and let the caller // deal with that - loudly. if (!(lclass & rclass & TYPE_FOULED)) ctype = ctype->ctype.base_type; else ctype = NULL; } in restricted_binop_type().