Message-ID: <20250114232355.GB3561231@frogsfrogsfrogs>
Date: Tue, 14 Jan 2025 15:23:55 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Dave Chinner <david@...morbit.com>
Cc: Theodore Ts'o <tytso@....edu>, 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 Wed, Jan 15, 2025 at 08:21:04AM +1100, Dave Chinner wrote:
> 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...

Heh, I had some pretty strong suspicions of that when I saw the paper.

--D

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

Powered by blists - more mailing lists