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 15C25C63777 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 E31CC2075A for ; Sun, 22 Nov 2020 22:34:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726360AbgKVWeB (ORCPT ); Sun, 22 Nov 2020 17:34:01 -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: keyrings@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.