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 0EE8A39C00B for ; Sat, 4 Jul 2026 13:23:03 +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=1783171385; cv=none; b=ofJUER1ed9aMietF0YYF+cVdj78UVr/LGohPm4CiGKajJzsU8tsd5nx8thnNIPqkLze3O+qj3WpZV8U2y17rBIFZArh+u4SX4q3oVWcH2hYQJqjzsekVkSTPpQVubJ8o5jFr1fGy7Xi8Oj9rqBUHdTLeirH39XdZz7EkM1lOEco= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783171385; c=relaxed/simple; bh=l+Mf6Es56jBvIpABwJERxVIAFd7jO+ujEUy6LgW7jkk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c+5XE7yypTIc+ojRZY9VcXNisXf2GzIyhq0CfxsSey6/3/b8lQDEN+FbA+MkiDlvQyGC5BeQCZq3AHhqiGgUdH67KwVc9u7dz0t1bMwvy4Hh3sclVCXp+x8nZBSadd77/om27ebh8ZsAtZbFXqkTLU6mQv/erVlbZzHtcnz6DMA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; 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=pass smtp.mailfrom=mit.edu Received: from macsyma.thunk.org (cclpop0120.carnival.com [151.124.104.120]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 664DMLHB006040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 4 Jul 2026 09:22:23 -0400 Received: by macsyma.thunk.org (Postfix, from userid 15806) id A24598BC58A; Sat, 4 Jul 2026 09:22:20 -0400 (EDT) Date: Sat, 4 Jul 2026 09:22:20 -0400 From: "Theodore Tso" To: Miguel Ojeda Cc: Tetsuo Handa , Alexander Potapenko , Boqun Feng , Gary Guo , Mark Brown , 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 Subject: Re: Policy regarding linux-next only changes Message-ID: References: <69f2f52c-a13a-4f9d-ab57-789eb4fdc335@I-love.SAKURA.ne.jp> <7f1b93a9-f756-4bfc-81d7-1350ac1d50ac@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: On Sat, Jul 04, 2026 at 02:06:43PM -0500, Miguel Ojeda wrote: > Now, reading the Google Groups thread you link, it seems like your > *actual constraint* doesn't come from syzkaller, but rather that you > want to use the compute resources Google allocates for big trees like > linux-next. Note that if you are trying to debug a specific syzbot bug, you don't need to send it to linux-next. You can just reply to reproducer with #syz test: git://repo/address.git branch-or-commit-hash So I think we need to distinguish between two cases. One is where you are trying to address specific syzkaller reproducer. The other is where you want to do a full set of fuzzing on a draft series. I'd argue that though, that this is something you want to do when the patch is almost ready to land upstream --- and at that point, putting in linux-next makes perfect sense. I'm not really see the case where it's not quite ready to land upstream (and so you want the full set of testing, not just with syzbot, with other people testing linux-next), but you still want to get the full set syzkaller testing. Do people think this is really such a common scenario? - Ted