linux-kernel - Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aExR9fLgCNHOaBMS@yury>
Date: Fri, 13 Jun 2025 12:29:41 -0400
From: Yury Norov <yury.norov@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: I Hsin Cheng <richard120310@...il.com>, linux@...musvillemoes.dk,
	jstultz@...gle.com, sboyd@...nel.org, linux-kernel@...r.kernel.org,
	eleanor15x@...il.com, visitorckw@...il.com, jserv@...s.ncku.edu.tw,
	skhan@...uxfoundation.org, linux-kernel-mentees@...ts.linux.dev
Subject: Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in
 clocksource_verify_choose_cpus()

On Fri, Jun 13, 2025 at 12:48:43PM +0200, Thomas Gleixner wrote:
> Yury!
> 
> On Fri, Jun 13 2025 at 01:02, Yury Norov wrote:
> > This exact change has already been submitted by me and is under review.
> >
> > https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
> >
> > I don't understand why are you undercutting my work, and moreover do it 
> > for the second time.
> >
> > For the first time you submitted something that duplicates my another
> > patch from the exact same series. John Stultz has pointed that, so you're
> > surely aware.
> >
> > https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
> >
> > Kernel development process implies that one makes sure that his work
> > is unique and doesn't break someone else's development, at one's best
> > knowledge.
> >
> > What you're doing not only breaks this rule. You're in fact trying to
> > get credit for the work that is done by someone else. This is the
> > definition of fraud.
> >
> > I cannot make sure that any other patches from you are unique and
> > written by actually you. Therefore, I will not take your work anymore.
> >
> > I encourage everyone else to be careful working with I Hsing Cheng
> > and check his patches for uniqueness, at minimum.  
> 
> There is absolutely no justification for accusing Hsin of fraud or other
> nasty intentions.

No, there is. It looks like a pure plagiarism - a sort of fraud.

You see, in the other email in this thread Kuan-Wei Chiu complains
about the lack of credit, as well.

> It's sufficient to point him to your series and tell him that it's
> already been dealt with.

He'd been pointed at least once. Obviously, it's not sufficient in
this case.

> I deal with redundant and conflicting patches every other day. That's part
> of how open source development works and it's trivial enough to either
> pick one of the patches or ask the involved parties to sort the
> conflicts out.

It's not about conflicts. I know how conflicts look and how to manage
them. Check this example from the last merge window:

        791a9b25ce2e6ecbe404ee32eed8a96a17e52896

I work on kernel for over 15 years, and contribute regularly for at least
a decade, and such thing happens to me for the first time. If it's indeed
a normal workflow, can you please share a couple recent examples where
people submit someone else's patchsets in whole with different commit
messages and with absolutely no credit, despite being warned? I'll then
consider to adjust my tolerance level to such things.

Nevertheless.

At this point it looks more like a lack of professionalism rather than
an evil will, and I hope he'll do better next time.

This doesn't mean that I revoke my NAK, or willing to give him any
credit for this work. But I will review and take his patches in case
he'll send something valuable to me; with reasonable precautions.

Thanks,
Yury