All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
	Jan Kara <jack@suse.cz>, Kun Hu <huk23@m.fudan.edu.cn>,
	jlayton@redhat.com, adilger.kernel@dilger.ca,
	david@fromorbit.com, bfields@redhat.com, viro@zeniv.linux.org.uk,
	christian.brauner@ubuntu.com, hch@lst.de,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	brauner@kernel.org, linux-bcachefs@vger.kernel.org,
	syzkaller@googlegroups.com
Subject: Re: Bug: INFO_ task hung in lock_two_nondirectories
Date: Tue, 14 Jan 2025 08:57:51 -0500	[thread overview]
Message-ID: <20250114135751.GB1997324@mit.edu> (raw)
In-Reply-To: <CACT4Y+ZtHUhXpETW+x8FpNbvN=xtKGZ1sBUQDr3TtKM+=7-xcg@mail.gmail.com>

On Tue, Jan 14, 2025 at 10:07:03AM +0100, Dmitry Vyukov wrote:
> I suspect the bulk of the reports are coming from academia
> researchers. In lots of academia papers based on syzkaller I see "we
> also reported X bugs to the upstream kernel". Somehow there seems to
> be a preference to keep things secret before publication, so upstream
> syzbot integration is problematic. Though it is well possible to
> publish papers based on OSS work, these usually tend to be higher
> quality and have better evaluation.
> 
> I also don't fully understand the value of "we also reported X bugs to
> the upstream kernel" for research papers. There is little correlation
> with the quality/novelty of research.

Oh, that's easy.  Statements make it more likely that program
committee members will more likely accept the paper because it's "real
world impact".

And if you're an academic, it's publish or perish, because due to the
gamification of tenure track committees.  Apparently in some countries
the pressure is so huge that academics have started submit fake/sham
papers:

   The startling rise in the publication of sham science papers has
   its roots in China, where young doctors and scientists seeking
   promotion were required to have published scientific papers. Shadow
   organisations – known as “paper mills” – began to supply fabricated
   work for publication in journals there.

   The practice has since spread to India, Iran, Russia, former Soviet
   Union states and eastern Europe, with paper mills supplying
   fabricated studies to more and more journals as increasing numbers
   of young scientists try to boost their careers by claiming false
   research experience. In some cases, journal editors have been
   bribed to accept articles, while paper mills have managed to
   establish their own agents as guest editors who then allow reams of
   falsified work to be published.

   https://www.theguardian.com/science/2024/feb/03/the-situation-has-become-appalling-fake-scientific-papers-push-research-credibility-to-crisis-point

At least in this case it appears to be real syzkaller reports,
although if they were submitting sham papers to sham journals, they at
least wouldn't be wasting upstream kernel developers' time.  :-)

It would be *nice* if researchers at *least* checked to see if their
reports had already been discovered using an unmodified Syzkaller (for
example, by checking the upstream Syzbot web pages).  After all, if
the unmodified/upstream Syzkaller can find the problem, in addition to
wasting our time even more, it's *clearly* not a new/novel result.

	    	    	     	    		- Ted

P.S.  If you want to push back on this nonsense, Usenix program
committee chairs are very much looking for open source professionals
to participate on the program committees for Usenix ATC (Annual
Technical Conference) and FAST (File System and Storage Technologies)
conference.  It's a huge amount of work; easily 40-60 hours of work over
3-4 months.  But it does get you to see what academics are up to, and
it's a way to help point out bogus research, and to push back on
research groups using ancient kernels (typically whatever kernel was
current when the lead professor was a graduate student)....

If you're interested, I can put you in touch with some of those
Program Committee chairs when they are asking me to serve --- there's
more than enough opportunity to go around.  :-)


  parent reply	other threads:[~2025-01-14 13:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 10:00 Bug: INFO_ task hung in lock_two_nondirectories Kun Hu
2025-01-13 10:28 ` Jan Kara
2025-01-13 20:00   ` Kent Overstreet
2025-01-14  9:07     ` Dmitry Vyukov
2025-01-14  9:20       ` Kun Hu
2025-01-14 13:57       ` Theodore Ts'o [this message]
2025-01-14 21:21         ` Dave Chinner
2025-01-14 23:23           ` Darrick J. Wong
2025-01-15  0:38           ` Kent Overstreet
2025-01-14 13:58       ` Jan Kara
2025-01-14 15:39         ` James Bottomley
     [not found]       ` <D067012D-7E8D-4AD9-A0CA-66B397110989@m.fudan.edu.cn>
2025-01-14 15:09         ` Kent Overstreet
2025-01-16  9:37           ` Kun Hu
2025-01-16 14:12             ` Kent Overstreet
2025-01-24 12:22               ` Kun Hu
2025-01-24 14:15                 ` Kent Overstreet
2025-01-24 18:28                 ` Theodore Ts'o
2025-01-24 18:39                   ` Kent Overstreet
2025-01-14  9:27     ` Kun Hu
2025-01-14  2:54   ` Kun Hu
2025-01-13 14:38 ` Christian Brauner
2025-01-13 16:19   ` Matthew Wilcox
2025-01-13 18:08     ` Darrick J. Wong
2025-01-14  8:59       ` Dmitry Vyukov
2025-01-14 23:42         ` Darrick J. Wong
2025-01-14  9:15       ` Dmitry Vyukov
2025-01-14 23:43         ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250114135751.GB1997324@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=bfields@redhat.com \
    --cc=brauner@kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=david@fromorbit.com \
    --cc=dvyukov@google.com \
    --cc=hch@lst.de \
    --cc=huk23@m.fudan.edu.cn \
    --cc=jack@suse.cz \
    --cc=jlayton@redhat.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.