Received: by 2002:ab2:6203:0:b0:1f5:f2ab:c469 with SMTP id o3csp82155lqt; Thu, 18 Apr 2024 09:00:00 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCU/7JD6kYdKYeneRizrCzSk/5kS2JcozWS/Qbi+b1AfERVIvLyQnJIMx0HoGceChEZi8j9tjFa3HrbkB2GCkm8XIjUdCCau9EpMIU52/A== X-Google-Smtp-Source: AGHT+IFvGsv5wwtnRoxMwQSnPLOV+8GdBESGHaDtsF2QI7arquNersLxVIHbL7djFltHDcQDTGXJ X-Received: by 2002:a05:6a00:1786:b0:6ea:86f2:24fb with SMTP id s6-20020a056a00178600b006ea86f224fbmr4348923pfg.25.1713456000449; Thu, 18 Apr 2024 09:00:00 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713456000; cv=pass; d=google.com; s=arc-20160816; b=WKzAsuEBfSLZFPAH/6aen4xLAwJL7N2dqTNC4pSM1c4dcPQhagW5B8L2ztEX6GSCcu DylUDzP34GUpzAD872WKilivPZA03E3unMN+ia9+++razmZaK35BjFKzkpkPdjr9h7vK BE7B3LS6e48Luuqye/lBKc4BkkN5MuR5wwG44LkYpJeYh4TGYcxW8S/wlU0S52Fmx8/9 pt6b43ZLR2aqdxc9wUJENFBcjXQBI+ldL7wl4ai9chpb9PK+NL7xrcrVVJnFfYrshbEY cax2v6xxLmXKptaKOPI+Pog72Gr9YaokJxG3bZDq3pLgWG+5ulbmi+ezHQZGv1UAQpSd ylKA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=OfCwZ2AwhrE2Zd1Kkt7i9hQF6qrDNPRufzN+RHay758=; fh=HWFa9OHfj0Ps7nL/a4hLZPGA7/m6bg51hnDB8ecS6qI=; b=p8tft1CtpDYfM0+PdrxpioHRq+umF/1Uh58BAu0E+guc8fPSZRnbQ4NvoFFiMKSCh+ UKcXyYDKTmGErp8PAB+DeXKbKStXU56UJyuwTe5V3btiXAEslMuG7fuH3s/h9ibylghE 9FdHWv+b28RDZEQBxPqv/OIx7O8tQ+lzyKmsQ4C1MiqpYbk6ZpsEVkHt4bNNOeCOBUph d+Uueqm7ZkS+9hK3avvDuC5XMLg/wQ2AIPUdkFp/Xx0Q8wSVLPDHpk79XyAiXOFHhZ+X xogUGtgJ2XYzSM61ipmCVlZDbylpzi88sRnODJIAaABSV4yZe5+MNoXc5xqb1ZLol+M8 28bA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=mNiKJAJD; arc=pass (i=1 spf=pass spfdomain=ideasonboard.com dkim=pass dkdomain=ideasonboard.com); spf=pass (google.com: domain of linux-kernel+bounces-150417-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-150417-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id 7-20020a630207000000b005f768a2668csi1613012pgc.25.2024.04.18.08.59.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Apr 2024 09:00:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-150417-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=mNiKJAJD; arc=pass (i=1 spf=pass spfdomain=ideasonboard.com dkim=pass dkdomain=ideasonboard.com); spf=pass (google.com: domain of linux-kernel+bounces-150417-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-150417-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id BE7E4B2349F for ; Thu, 18 Apr 2024 15:46:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B53A116F843; Thu, 18 Apr 2024 15:46:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="mNiKJAJD" Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D41A116E89A; Thu, 18 Apr 2024 15:46:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713455205; cv=none; b=YR//jvise81xYQ2aQEMmbPtmnrRDx4bZGp6Um27E4jtfc0u6ohLe78f/y0pGsRg17q7oCwr49QPSB9bUi2P2ovbsF/is64C/Cc20yLaeKWJtZBOfYOwLuZmFub/QKrPv3EgnyriyPBeod7z4cxdK6YST2cyBlqwNRh/QPl3nMf0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713455205; c=relaxed/simple; bh=K6H40zZOBruNXEKy+mLBxL40J3Voj2XWEqqGuvJ9w94=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VfVRCHVMHNoh9wGLSl4uMOSmJROR8cKJdQYUjvElGmsW/wkiKcZqQx570pEsg6O15wwQ7y12722j5dbSyH0ZIEE2auO+fa1uiNhnzkJqgCa0Lb2JpDB8ZnebOYXznVgx5eOrAws7/H/yqow9cd68DaSZSgyBnyD5QDfhW7jmF8g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=mNiKJAJD; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Received: from pendragon.ideasonboard.com (117.145-247-81.adsl-dyn.isp.belgacom.be [81.247.145.117]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 2A03C802; Thu, 18 Apr 2024 17:45:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1713455153; bh=K6H40zZOBruNXEKy+mLBxL40J3Voj2XWEqqGuvJ9w94=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mNiKJAJDsTkJYMYK4ZtsZ9zlV7xPYE85xk9V7yAnZZ4lXnvj+UhwJ4fKqYaFra0Xc 2eBi44CBZWoMWyMkwDoCJV3GUcE9zfI7hzMI60oHIg/o5NGSS92iXbFgMGqv+gOkZe 2N/SspWfXOLe5x5IbsUKTfY8A/Ga1vjvyZkxLsrw= Date: Thu, 18 Apr 2024 18:46:33 +0300 From: Laurent Pinchart To: Ricardo Ribalda Cc: Dan Carpenter , Martin Tuma , Mauro Carvalho Chehab , Hans Verkuil , Hugues Fruchet , Alain Volmat , Maxime Coquelin , Alexandre Torgue , Paul Kocialkowski , Greg Kroah-Hartman , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Sakari Ailus , Thierry Reding , Jonathan Hunter , Sowjanya Komatineni , Luca Ceresoli , Matthias Brugger , AngeloGioacchino Del Regno , Hans Verkuil , Sergey Kozlov , Abylay Ospan , Ezequiel Garcia , Dmitry Osipenko , Stanimir Varbanov , Vikash Garodia , Bryan O'Donoghue , Bjorn Andersson , Konrad Dybcio , Benjamin Mugnier , Sylvain Petinot , Jacopo Mondi , Kieran Bingham , Niklas =?utf-8?Q?S=C3=B6derlund?= , Pavel Machek , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-staging@lists.linux.dev, linux-sunxi@lists.linux.dev, linux-tegra@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-msm@vger.kernel.org, Oleg Drokin Subject: Re: [PATCH 00/35] media: Fix coccinelle warning/errors Message-ID: <20240418154633.GD31776@pendragon.ideasonboard.com> References: <20240415-fix-cocci-v1-0-477afb23728b@chromium.org> <20240417155112.GQ12561@pendragon.ideasonboard.com> <20240418105310.GV12561@pendragon.ideasonboard.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Hi Ricardo, On Thu, Apr 18, 2024 at 04:51:06PM +0200, Ricardo Ribalda wrote: > On Thu, 18 Apr 2024 at 12:53, Laurent Pinchart wrote: > > On Wed, Apr 17, 2024 at 06:19:14PM +0200, Ricardo Ribalda wrote: > > > On Wed, 17 Apr 2024 at 17:51, Laurent Pinchart wrote: > > > > On Tue, Apr 16, 2024 at 11:47:17AM +0300, Dan Carpenter wrote: > > > > > In my opinion, it's better to just ignore old warnings. > > > > > > > > I agree. Whatever checkers we enable, whatever code we test, there will > > > > always be false positives. A CI system needs to be able to ignore those > > > > false positives and only warn about new issues. > > > > > > We already have support for that: > > > https://gitlab.freedesktop.org/linux-media/media-ci/-/tree/main/testdata/static?ref_type=heads > > > > Those are manually written filters. Would it be possible to reduce the > > manual step to flagging something as a false positive, and have a > > machine build the filters ? > > Do you expect that the list of exceptions will grow? > > I hope that once the CI is in place we will fix the warnings before > they land in the tree. Any static checker is bound to produce false positives. Some of them can be addressed by improving the checker, others by modifying the source code, but in some cases the first option would be too difficult and the second would reduce readability of the code. I thus thing the list of accepted false positives will grow over time. > > > But it would be great if those lists were as small as possible: > > > > > > - If we have a lot of warnings, two error messages can be combined and > > > will scape the filters > > > eg: > > > print(AAAA); > > > print(BBBB); > > > > AABBBAAB > > > > > > - The filters might hide new errors if they are too broad > > > > > > > > > Most of the patches in this series are simple and make a nicer code: > > > Eg the non return minmax() , > > > Other patches show real integer overflows. > > > > > > Now that the patches are ready, let's bite the bullet and try to > > > reduce our technical debt. > > > > > > > > When code is new the warnings are going to be mostly correct. The > > > > > original author is there and knows what the code does. Someone has > > > > > the hardware ready to test any changes. High value, low burden. > > > > > > > > > > When the code is old only the false positives are left. No one is > > > > > testing the code. It's low value, high burden. > > > > > > > > > > Plus it puts static checker authors in a difficult place because now > > > > > people have to work around our mistakes. It creates animosity. > > > > > > > > > > Now we have to hold ourselves to a much higher standard for false > > > > > positives. It sounds like I'm complaining and lazy, right? But Oleg > > > > > Drokin has told me previously that I spend too much time trying to > > > > > silence false positives instead of working on new code. He's has a > > > > > point which is that actually we have limited amount of time and we have > > > > > to make choices about what's the most useful thing we can do. > > > > > > > > > > So what I do and what the zero day bot does is we look at warnings one > > > > > time and we re-review old warnings whenever a file is changed. > > > > > > > > > > Kernel developers are very good at addressing static checker warnings > > > > > and fixing the real issues... People sometimes ask me to create a > > > > > database of warnings which I have reviewed but the answer is that > > > > > anything old can be ignored. As I write this, I've had a thought that > > > > > instead of a database of false positives maybe we should record a > > > > > database of real bugs to ensure that the fixes for anything real is > > > > > applied. -- Regards, Laurent Pinchart