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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C9A08C64E7B for ; Sun, 22 Nov 2020 22:34:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A39BC20776 for ; Sun, 22 Nov 2020 22:34:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726831AbgKVWeC (ORCPT ); Sun, 22 Nov 2020 17:34:02 -0500 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:50298 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbgKVWeB (ORCPT ); Sun, 22 Nov 2020 17:34:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) From: Finn Thain To: Joe Perches cc: James Bottomley , Tom Rix , Matthew Wilcox , clang-built-linux@googlegroups.com, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, tboot-devel@lists.sourceforge.net, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, netdev@vger.kernel.org, linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org, linux-wireless@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, ecryptfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, keyrings@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, alsa-devel@alsa-project.org, bpf@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-nfs@vger.kernel.org, patches@opensource.cirrus.com Subject: Re: [RFC] MAINTAINERS tag for cleanup robot In-Reply-To: Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D520C2D0E4 for ; Tue, 24 Nov 2020 17:10:54 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6130B20715 for ; Tue, 24 Nov 2020 17:10:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="izwf+02w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6130B20715 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id CE6D31797; Tue, 24 Nov 2020 18:10:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz CE6D31797 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1606237851; bh=HW81nGhWsfY5NPxuDsEpxfrrL+HD6qeah97Y7TCcv5c=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=izwf+02wYKyZ7U+TQn4qsOMsnZmFzwZpWPx83rhH28h0DTEmWcuwqI+qivHavBXDq fSA457OotdfK1ro33SL/O0sa1gzCWPK0pGKT2ZdUy5krVxH4WePGXXkLwZxC9dkdPs M6oKgVlMy+zflaZIUR2wmVFoIdNqG/AT9+4RITD0= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 4F743F805C0; Tue, 24 Nov 2020 17:58:38 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DA1F0F80165; Sun, 22 Nov 2020 23:34:04 +0100 (CET) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by alsa1.perex.cz (Postfix) with ESMTP id BEA7CF8015B for ; Sun, 22 Nov 2020 23:34:01 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz BEA7CF8015B Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) From: Finn Thain To: Joe Perches Subject: Re: [RFC] MAINTAINERS tag for cleanup robot In-Reply-To: Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 24 Nov 2020 17:58:07 +0100 Cc: linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, Tom Rix , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, James Bottomley , ibm-acpi-devel@lists.sourceforge.net, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, Matthew Wilcox , linux-scsi@vger.kernel.org, clang-built-linux@googlegroups.com, amd-gfx@lists.freedesktop.org, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, tboot-devel@lists.sourceforge.net, coreteam@netfilter.org, xen-devel@lists.xenproject.org, MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org, alsa-devel@alsa-project.org, intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org, linux-omap@vger.kernel.org, devel@acpica.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, netfilter-devel@vger.kernel.org, linux-crypto@vger.kernel.org, patches@opensource.cirrus.com, linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A5F3C5519F for ; Sun, 22 Nov 2020 22:34:47 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 35FCF2075A for ; Sun, 22 Nov 2020 22:34:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="NoSeAC3z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 35FCF2075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DeAUVwkg4jxLshz5Y5CD457yoS21zax3HuoF4aHp8M0=; b=NoSeAC3zBEXOJ/Wvz1KN9wQyV SDDPFoh3yhFUbtHu7AjXaML2sdjEgvYzGNRRkqkNzLJJPPP/GCK23otjDsLoHr5KfKEWT6q0Zxfaj CZgexY3Ltb7FgoWtfVgdx2LiXdrTJTU7qxv7TNZII1BZNk9KUKaOct6vcZmH4UMiwWXGSNvFeVLiv 3qGSyQm+Xxdpf4Zz04EtwrqmkA/uaDpVFW2rdmxKvuWS/gqFdlmgRBW7lID7B4/RkTZgXyj9fbCqc L9qThCoEzRgHclT8hW7JYLWiqSLB7KzlnqE3VcklWAlaJlw7y7KQAUltOX5OYcwNe4XsNHMtLLX/x EznyffDRw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kgxvs-0002gX-1A; Sun, 22 Nov 2020 22:34:08 +0000 Received: from kvm5.telegraphics.com.au ([98.124.60.144]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kgxvp-0002fJ-4H for linux-mtd@lists.infradead.org; Sun, 22 Nov 2020 22:34:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) From: Finn Thain To: Joe Perches Subject: Re: [RFC] MAINTAINERS tag for cleanup robot In-Reply-To: Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201122_173405_207246_8C28CC75 X-CRM114-Status: GOOD ( 15.20 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, Tom Rix , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, James Bottomley , ibm-acpi-devel@lists.sourceforge.net, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, Matthew Wilcox , linux-scsi@vger.kernel.org, clang-built-linux@googlegroups.com, amd-gfx@lists.freedesktop.org, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, tboot-devel@lists.sourceforge.net, coreteam@netfilter.org, xen-devel@lists.xenproject.org, MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org, alsa-devel@alsa-project.org, intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org, linux-omap@vger.kernel.org, devel@acpica.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, netfilter-devel@vger.kernel.org, linux-crypto@vger.kernel.org, patches@opensource.cirrus.com, linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17A63C2D0E4 for ; Mon, 23 Nov 2020 04:56:25 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A1E4F207FF for ; Mon, 23 Nov 2020 04:56:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1E4F207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 220F689B0B; Mon, 23 Nov 2020 04:56:24 +0000 (UTC) X-Greylist: delayed 532 seconds by postgrey-1.36 at gabe; Sun, 22 Nov 2020 22:42:53 UTC Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by gabe.freedesktop.org (Postfix) with ESMTP id 59BAB89AC0 for ; Sun, 22 Nov 2020 22:42:53 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) From: Finn Thain To: Joe Perches In-Reply-To: Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 23 Nov 2020 04:56:23 +0000 Subject: Re: [Intel-gfx] [RFC] MAINTAINERS tag for cleanup robot X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, Tom Rix , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, James Bottomley , ibm-acpi-devel@lists.sourceforge.net, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, Matthew Wilcox , linux-scsi@vger.kernel.org, clang-built-linux@googlegroups.com, amd-gfx@lists.freedesktop.org, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, tboot-devel@lists.sourceforge.net, coreteam@netfilter.org, xen-devel@lists.xenproject.org, MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org, alsa-devel@alsa-project.org, intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org, linux-omap@vger.kernel.org, devel@acpica.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, netfilter-devel@vger.kernel.org, linux-crypto@vger.kernel.org, patches@opensource.cirrus.com, linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD586C5519F for ; Sun, 22 Nov 2020 22:34:20 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 93B232075A for ; Sun, 22 Nov 2020 22:34:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93B232075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.33526.64590 (Exim 4.92) (envelope-from ) id 1kgxvm-00086v-67; Sun, 22 Nov 2020 22:34:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 33526.64590; Sun, 22 Nov 2020 22:34:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kgxvm-00086o-38; Sun, 22 Nov 2020 22:34:02 +0000 Received: by outflank-mailman (input) for mailman id 33526; Sun, 22 Nov 2020 22:34:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kgxvl-00086j-4Y for xen-devel@lists.xenproject.org; Sun, 22 Nov 2020 22:34:01 +0000 Received: from kvm5.telegraphics.com.au (unknown [98.124.60.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 23bfc369-788e-4889-a1cb-fdcf3babc460; Sun, 22 Nov 2020 22:33:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kgxvl-00086j-4Y for xen-devel@lists.xenproject.org; Sun, 22 Nov 2020 22:34:01 +0000 X-Inumbo-ID: 23bfc369-788e-4889-a1cb-fdcf3babc460 Received: from kvm5.telegraphics.com.au (unknown [98.124.60.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 23bfc369-788e-4889-a1cb-fdcf3babc460; Sun, 22 Nov 2020 22:33:59 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) From: Finn Thain To: Joe Perches cc: James Bottomley , Tom Rix , Matthew Wilcox , clang-built-linux@googlegroups.com, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, tboot-devel@lists.sourceforge.net, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, netdev@vger.kernel.org, linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org, linux-wireless@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, ecryptfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, keyrings@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, alsa-devel@alsa-project.org, bpf@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-nfs@vger.kernel.org, patches@opensource.cirrus.com Subject: Re: [RFC] MAINTAINERS tag for cleanup robot In-Reply-To: Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0CC5C2D0E4 for ; Mon, 23 Nov 2020 08:26:02 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 677D520719 for ; Mon, 23 Nov 2020 08:26:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 677D520719 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=telegraphics.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B52AA89B7D; Mon, 23 Nov 2020 08:25:58 +0000 (UTC) Received: from kvm5.telegraphics.com.au (kvm5.telegraphics.com.au [98.124.60.144]) by gabe.freedesktop.org (Postfix) with ESMTP id 4645B89973; Sun, 22 Nov 2020 22:34:01 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id A588721F21; Sun, 22 Nov 2020 17:33:55 -0500 (EST) Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) From: Finn Thain To: Joe Perches Subject: Re: [RFC] MAINTAINERS tag for cleanup robot In-Reply-To: Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 23 Nov 2020 08:25:57 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, Tom Rix , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, platform-driver-x86@vger.kernel.org, James Bottomley , ibm-acpi-devel@lists.sourceforge.net, keyrings@vger.kernel.org, linux-mtd@lists.infradead.org, Matthew Wilcox , linux-scsi@vger.kernel.org, clang-built-linux@googlegroups.com, amd-gfx@lists.freedesktop.org, cluster-devel@redhat.com, linux-acpi@vger.kernel.org, tboot-devel@lists.sourceforge.net, coreteam@netfilter.org, xen-devel@lists.xenproject.org, MPT-FusionLinux.pdl@broadcom.com, linux-media@vger.kernel.org, alsa-devel@alsa-project.org, intel-gfx@lists.freedesktop.org, ecryptfs@vger.kernel.org, linux-omap@vger.kernel.org, devel@acpica.org, linux-nfs@vger.kernel.org, netdev@vger.kernel.org, linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org, netfilter-devel@vger.kernel.org, linux-crypto@vger.kernel.org, patches@opensource.cirrus.com, linux-fsdevel@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Subject: Re: [RFC] MAINTAINERS tag for cleanup robot Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) Message-ID: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> Mime-Version: 1.0 Return-path: List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Joe Perches Cc: James Bottomley , Tom Rix , Matthew Wilcox , clang-built-linux@googlegroups.com, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, tboot-devel@lists.sourceforge.net, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-acpi@vger.kernel.org, devel@acpica.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, netdev@vger.kernel.org, linux-media@vger.kernel.org, MPT-FusionLinux.pdl@broadcom.com, linux-scsi@vger.kernel.org, linux-wireless@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, linux-usb@vger.kernel.org, linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, ecryptfs@vger.kernel.org, linux-fsdevel@vger.k On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finn Thain Date: Mon, 23 Nov 2020 09:33:55 +1100 (AEDT) Subject: [Cluster-devel] [RFC] MAINTAINERS tag for cleanup robot In-Reply-To: References: <20201121165058.1644182-1-trix@redhat.com> <20201122032304.GE4327@casper.infradead.org> <20201122145635.GG4327@casper.infradead.org> <0819ce06-c462-d4df-d3d9-14931dc5aefc@redhat.com> <751803306cd957d0e7ef6a4fc3dbf12ebceaba92.camel@HansenPartnership.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, 22 Nov 2020, Joe Perches wrote: > On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote: > > We can enforce sysfs_emit going forwards > > using tools like checkpatch > > It's not really possible for checkpatch to find or warn about > sysfs uses of sprintf. checkpatch is really just a trivial > line-by-line parser and it has no concept of code intent. > Checkpatch does suffer from the limitations of regular expressions. But that doesn't stop people from using it. Besides, Coccinelle can do analyses that can't be done with regular expressions, so it's moot. > It just can't warn on every use of the sprintf family. > There are just too many perfectly valid uses. > > > but there's no benefit and a lot of harm to > > be done by trying to churn the entire tree > > Single uses of sprintf for sysfs is not really any problem. > > But likely there are still several possible overrun sprintf/snprintf > paths in sysfs. Some of them are very obscure and unlikely to be > found by a robot as the logic for sysfs buf uses can be fairly twisty. > Logic errors of this kind are susceptible to fuzzing, formal methods, symbolic execution etc. No doubt there are other techniques that I don't know about. > But provably correct conversions IMO _should_ be done and IMO churn > considerations should generally have less importance. > Provably equivalent conversions are provably churn. So apparently you're advocating changes that are not provably equivalent. These are patches for code not that's not been shown to be buggy. Code which, after patching, can be shown to be free of a specific kind of theoretical bug. Hardly "provably correct". The problem is, the class of theoretical bugs that can be avoided in this way is probably limitless, as is the review cost and the risk of accidental regressions. And the payoff is entirely theoretical. Moreover, the patch review workload for skilled humans is being generated by the automation, which is completely backwards: the machine is supposed to be helping.