Message-ID: <Z4bVQEKdj4ouAGI4@dread.disaster.area>
Date: Wed, 15 Jan 2025 08:21:04 +1100
From: Dave Chinner <david@...morbit.com>
To: Theodore Ts'o <tytso@....edu>
Cc: Dmitry Vyukov <dvyukov@...gle.com>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Jan Kara <jack@...e.cz>, Kun Hu <huk23@...udan.edu.cn>,
	jlayton@...hat.com, adilger.kernel@...ger.ca, bfields@...hat.com,
	viro@...iv.linux.org.uk, christian.brauner@...ntu.com, hch@....de,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	brauner@...nel.org, linux-bcachefs@...r.kernel.org,
	syzkaller@...glegroups.com
Subject: Re: Bug: INFO_ task hung in lock_two_nondirectories

On Tue, Jan 14, 2025 at 08:57:51AM -0500, Theodore Ts'o wrote:
> 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.

The problem is that the Usenix/FAST paper committees will not reach
out to OSS subject matter experts to review papers that they have
been asked to review for the conference.

Let me give you a recent example of a clear failure of the FAST
paper committee w.r.t. plagarism.

The core of this paper from FAST 2022:

https://www.usenix.org/conference/fast22/presentation/kim-dohyun

"ScaleXFS: Getting scalability of XFS back on the ring"

is based on the per-CPU CIL logging work I prototyped and posted an
RFC for early in 2021:

https://lore.kernel.org/linux-xfs/20200512092811.1846252-1-david@fromorbit.com/

The main core of the improvements described in the ScaleXFS paper
are the exact per-cpu CIL algorithm in that was contained in the
above RFC patchset.

That algorithm had serious problems that meant it was unworkable in
practice - these didn't show up until journal recovery was tested
and it resulted in random filesystem corruptions. I didn't
understand the root cause of the problem until months later.

These problems were all based on failures to correctly order the
per-CPU log items in the journal due to the per-CPU CIL being
inherently racy.  The algorithm I proposed 6 months later (and
eventually got merged in July 2022) had significant changes to the
way the per-CPU CIL ordered operations to address these problems.

IOWs, object ordering on the CIL is the single most important
critical correctness citeria for the entire journalling algorithm
and hence a fundamental algorithmic constraint for the per-CPU CIL
implementation.

However, the ScaleXFS paper does not make any mention of this
fundamental algorithmic constraint - I did not publish anything
about this constraint until the November 2022 patch set....

There were more clear tell-tales in the paper that indicate
that the "research" was based on that early per-CPU CIL RFC I
posted, but I won't go into details.

I brought this to the FAST committee almost immediately after I was
able to review the paper (a couple of days after the FAST conference
itself). I provided them with all the links to public postings of
the algorithm, detailed analysis of the paper and publicly posted
code, etc. In response, they basically did nothing and brushed my
concerns off. It would take weeks to get any response from the paper
committee, and the overall response really felt like the Usenix
people simply didn't care at all about what was obviously plagarised
work.

IOWs, the Usenix/FAST peer review process for OSS related papers is
broken, and they don't seem to care when experts from the OSS
community actually bring clear cases of academic malpractice to
them...

-Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists