From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240]) (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 88F2E2F83 for ; Wed, 21 Apr 2021 20:18:47 +0000 (UTC) Received: from relay5-d.mail.gandi.net (unknown [217.70.183.197]) by mslow1.mail.gandi.net (Postfix) with ESMTP id A9B5EC51B7 for ; Wed, 21 Apr 2021 19:49:40 +0000 (UTC) X-Originating-IP: 90.65.108.55 Received: from localhost (lfbn-lyo-1-1676-55.w90-65.abo.wanadoo.fr [90.65.108.55]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 7C21F1C0003; Wed, 21 Apr 2021 19:49:33 +0000 (UTC) Date: Wed, 21 Apr 2021 21:49:33 +0200 From: Alexandre Belloni To: James Bottomley Cc: ksummit@lists.linux.dev Subject: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Message-ID: References: X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi, On 21/04/2021 11:35:36-0700, James Bottomley wrote: > I've long been on record as not really being a fan of trivial patches > because they can cause merge issues with current patches and introduce > bugs, particularly in older drivers, that don't get detected for a long > while. However, the recent events with the University of Minnesota: > > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/ > > Have elevated the risk factor around trivial patches claiming to fix > bugs to the point where it looks like there's no such thing as a truly > trivial patch and they all need reviewing. > > Our policy in SCSI for a long time has been no trivial patches accepted > to maintained drivers, and I think that would be a good start if > adopted kernel wide, but I think the next policy should be no trivial > bug fix without a pointer to the actual bug report or report from a > trusted static checker. This would likely mean we have to create a > list of trusted static checkers ... obviously 0day and coverity but > what else? > I find it very difficult to trust coverity because it has a tendency of adding unnecessary checks for return values just because other drivers are checking for the return value and this adds a lot of bloat in the kernel for condition that will never happen on real hardware. Also we have a lot of useless refactoring due to 0day and coccinnelle. I'm not sure blessing any static checker is really a good option. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com