From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B25452F549F for ; Fri, 24 Jul 2026 14:52:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784904773; cv=none; b=e1nkPx7IhFU7/xohKOlb1NxNh+WStkCs6fNCPmOhA3ruEmdldRbPjJb93KstxTPqeuPhfWykZwy55xZw420lIaKLC5q3gM35e9IY44P10QLhVmiZi7JA738Rz8fiDUUyG8oEJEUHsvPyjIDQdG4HZbAo+OolvC+1vxf3h8QBg+w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784904773; c=relaxed/simple; bh=A8ek8GKz5JiVkbEnS0bK21rHITjTJZ47RcUAfJ4mBrE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Zsdp5Pd2iXNeuzAsXIwzBOBjhWH20IwbI7j6PbVOTDZW08AbEcAs2oWzJxcn9tWChG2MmIT4aWzzh0oSBPFhs3UBqWUTgsy6Nog3VcswsGoXjhKRL0EZ5GBe/YsDZdUua6aJd1jQUZ5TL2vxXQlwevWIirTNSEzJokXPnIlRyNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=fail smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=qRxGqYSi; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="qRxGqYSi" Received: from macsyma.thunk.org (pool-108-49-209-71.bstnma.fios.verizon.net [108.49.209.71]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 66OEqGlM032366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2026 10:52:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1784904740; bh=ym53p+2yu95mK9DkJGRwi4QY0kNJ6XxYvL/0oVaFWOc=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=qRxGqYSi4MGRAvEXx9ijYg/gVqaG0E6uoYYETHsMwEPHJXf1pmLOCNQf80YxZpu/M qpzRCG0ojOItxoZGiA1As4oD+s1YZc1wnUx0iZ73DMb2t/y3AU1AcFUXHgw+g2ngPb XZ+l9uZSDktXWxdU1vyhN1MK4OaXOhdLTkvaj9wKg60/GwdJoHRAm6OB4UpVQDmTxM pPRD5HRrDfw5nQuvf6DmXIOlKnQ4wq8snXmT8VLVZOAj9Jx0I+y3kpCbro9BpAQEgS Gm+FNh4f0tJR8mqr57sRPEjGwfBsr36Iesz1kL7AH5NSzZE5x0beIRQM1fvg+qTKoW eGySgZQuIX2lA== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 25636BE9A6A; Fri, 24 Jul 2026 10:51:16 -0400 (EDT) Date: Fri, 24 Jul 2026 10:51:16 -0400 From: "Theodore Tso" To: Tetsuo Handa Cc: Alexander Potapenko , Mark Brown , Christoph Hellwig , Aleksandr Nogikh , Boqun Feng , Gary Guo , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Miguel Ojeda , Linus Torvalds , peterz@infradead.org, will@kernel.org, longman@redhat.com, mingo@kernel.org, gregkh@linuxfoundation.org, Miguel Ojeda Subject: Re: Policy regarding linux-next only changes Message-ID: References: <2d0d3f6b-4392-4081-9390-9b588e38de7a@I-love.SAKURA.ne.jp> <2c903636-532f-47b5-9894-00470f235682@I-love.SAKURA.ne.jp> <58689827-9211-4f26-9777-51c0b5e1eebb@I-love.SAKURA.ne.jp> 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=us-ascii Content-Disposition: inline In-Reply-To: <58689827-9211-4f26-9777-51c0b5e1eebb@I-love.SAKURA.ne.jp> On Fri, Jul 24, 2026 at 11:35:36PM -0500, Tetsuo Handa wrote: > I wonder whether it is appropriate to call "syzbot issues". syzbot is > finding bugs in upstream git trees. Unless the cause of a bug is either > syzbot is doing a stupid thing or compiler/toolchain is broken, it is > "an upstream kernel issue". I know that people have different experiences of Syzbot reported issues, but the bugs I see require root privileges, modifying a file system while it is mounted, maliciously corrupting file system images and then mounting it without first running fsck, mucking with the loop device (which requires root privileges) while it is in use by a file system. I do agree that if you mount a file system without running fsck, and it has been maliciously corrupted, it woud be nice(tm) if it didn't result in a crash or a WARN_ON. If someone wants to fund the engineering work to make this be true, so long as it doesn't compromise long-term code maintainability or performance, patches would be welcome. So perhaps this is a P2 bug. But it's not something I'm going to consider high priority, because it's not in any threat model that I or the people who manage the budget and head count authorizations, care about. Since that's the *vast* majority of the issues reported by syzbot, I tend to use "syzbot bug" as a shorthand. I can't speak to whether the syzbot bugs you are chasing fall into this category or not. But if it requires *vast* amount of VM time, it makes me suspect that it falls into that category. > Those who hate my attempts (i.e. sending patches to linux-next without > being reviewed/acked by maintainers) are expecting that any patch is > reviewed/acked by maintainers. But some maintainers are considering bugs > reported by syzbot as "not worth looking into". Therefore, not only > debug printk() patches (for bugs found by syzbot) but also bug fix patches > (which syzbot has found) are getting ignored. Yep, and I've explained above why that's the case. I've tried to make the case that if there was a way that we could easily separate out those bugs which are signal from noise (at leat as defined by those people who refuse to fund this development work), it might be good for improving syzbot's reputation. But I'm so busy that I don't have time to go through all of the syzbot reported issues to see if any of them are actually ones that should be considered high priority. > In other words, the interest (by the upstream Linux kernel community) on > fixing kernel bugs which syzbot found are decreasing. This is a deadlock > situation, and just saying "Not my business." is not helpful. Perhaps if Syzbot could be improved so we can be more selective about which bugs are worth fixing, it might actually be better for the kernel's quality. But if the goal is to get ourselves to zero bugs, or zero syzbot reported issues, that's not a goal I can get behind. It certainly isn't something my management chain isn't willing to support that goal, and it's NOT going to happen out of my own personal time. Cheers, - Ted