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 9632619A288 for ; Fri, 24 Jan 2025 18:28:45 +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=1737743328; cv=none; b=uQ89T1k7+oFVxWo0gE9xwW9i2tEmHnjB9RPPlCCZSjHjTzE4p7IpM/FU7wfhP3Ro+cj8E7bNMDpY+Uw2W17Vuf2F4XJ54WRk220kA7m3CymDSav69AfMm9/OHjmrv4AEwGIwTwgxTNA+PXbxn+fytdF11aLKauEGZxwo9xw68KA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737743328; c=relaxed/simple; bh=NegJ/1TfbX7aVBPZSTyEMEIXIZQTbhOsVpc6eRBlXFo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u5m4FmirFfP+aSSPNrhbbyGO3/AY9GDGtWSViuUD4fX82PSZy6cIcQ2LZs4jHh+0egmfqoyuXZurfHOvjkIoDyWAcmemvoYH6FNvskk9aZA6No6l8PPUyAIfA5yOQbpIWzP9z0mSU9ba2veKhd0bOGmvx4etYp9cBxsEYCTzUa8= 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; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=Zymyuc7l; 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 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="Zymyuc7l" Received: from cwcc.thunk.org (pool-173-48-111-161.bstnma.fios.verizon.net [173.48.111.161]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 50OISITs003428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jan 2025 13:28:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1737743301; bh=PsSWnbdwaUY7PiWMxWMnA/Fu4dFrB4Pm66ETkG4yzns=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=Zymyuc7lVrdA4ETQ4f9rlS/KsX8V81+Zxo2Hle0IA54csUVqzLeYQDZKmcN3ag3WG SLOl895ehBWl8EWOHNlBygalhZrZMlBVHDQuK2rFiGi0yvDIPvpOmPWtS4SVYT+9Vm LYft1AOCUJ4rVTsiFq+53wkWvzP992Zm3gfM0WEEcdGRLxGI0e197JisETLuH+kJea yTC9QTIDuk4kLCYkcIsrCATxxqMnjQ3F0ZPcB2Dm18baedBrVPOkBhw/Rxjfg0TQ+n b/0Qlr5+hyNSTuXEnWzjIaF45eM1dpHiQojIgkK0x5nXtHGEJf0WOkbHS9TvcVcC+O RScCgMsD0caTw== Received: by cwcc.thunk.org (Postfix, from userid 15806) id DF4C815C0109; Fri, 24 Jan 2025 13:28:17 -0500 (EST) Date: Fri, 24 Jan 2025 13:28:17 -0500 From: "Theodore Ts'o" To: Kun Hu Cc: Kent Overstreet , Dmitry Vyukov , Jan Kara , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org, syzkaller@googlegroups.com Subject: Re: Bug: INFO_ task hung in lock_two_nondirectories Message-ID: <20250124182817.GB3847740@mit.edu> References: <42BD15B5-3C6C-437E-BF52-E22E6F200513@m.fudan.edu.cn> <5BCDEDB6-7A92-4401-A0A8-A12EF2F27ED0@m.fudan.edu.cn> <900A37C1-9A21-46DF-8416-B8ABF1D0667C@m.fudan.edu.cn> Precedence: bulk X-Mailing-List: linux-bcachefs@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: <900A37C1-9A21-46DF-8416-B8ABF1D0667C@m.fudan.edu.cn> On Fri, Jan 24, 2025 at 08:22:57PM +0800, Kun Hu wrote: > > But an interesting interaction relationship is that for researchers > from academia to prove the advanced technology of their fuzzer, they > seem to need to use their personal finding of real-world bugs as an > important experimental metric. I think that's why you get reports > that are modeled after syzbot (the official description of syzkaller > describes the process for independent reports). If the quality of > the individual reports is low, it does affect the judgment of the > maintainer, but also it is also a waste of everyone's time. If you're going to do this, I would suggest that you make sure that you're actually finding new bugs. More often than not, after wasting a huge amount of time of upstream developers because the researchers don't set up the syzbot dashboard and e-mail service to test to see if a patch fixes a bug (often which we can't reproduce on our own because it's highly environment sensitive), we discover that it's already been reported on the upstream syzbot. Which makes the academic syzbot a *double* waste of time, and this trains upstream developers to simply ignore reports from these research forks of syzbot unless it comes with a reproducer, or maybe (this hasn't happened yet) if the researchers actually set up the web dashboard and e-mail responder. I also blame the peer reviewers for the journals, for not asking the question, "why haven't you shown that the 'real world' bugs that your forked syzbot has found are ones that the original syzcaller hasn't found yet?" And for not demanding of the academics, "if you want *real* impact, get your changes merged upstream with the upstream syzcaller, so that it will continue to find and fix vulnerabilities instead of ceasing the moment we accept your paper." Cheers, - Ted