Utilize cpumask_first_but() helper instead of first using
cpumask_first() and then cpumask_next(). The logic is the same here,
using the new helper will make it more conscious.
Use bloat-o-meter to check the impact on code size, the result is the
same, does not have positive impact nor negative impact.
$ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new delta
Total: Before=22590709, After=22590709, chg +0.00%
Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
---
Generally speaking, I think this is just a small tweak on the code,
making it more readable. However, no benefit in code size or performance
as the implementation behind the helper is in fact the same as the one
used here.
Maybe more tests should be done to ensure the change is solid, I hope to
seek some suggestions from everyone who has any ideas, or this is enough
then it's good.
Best regards,
I Hsin Cheng
---
kernel/time/clocksource.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index bb48498ebb5a..12ff0c048570 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void)
return;
/* Make sure to select at least one CPU other than the current CPU. */
- cpu = cpumask_first(cpu_online_mask);
- if (cpu == smp_processor_id())
- cpu = cpumask_next(cpu, cpu_online_mask);
+ cpu = cpumask_first_but(cpu_online_mask, smp_processor_id());
if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
return;
cpumask_set_cpu(cpu, &cpus_chosen);
--
2.43.0I Hsin, 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. NAKed-by: Yury Norov <yury.norov@gmail.com> Thanks, Yury On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote: > Utilize cpumask_first_but() helper instead of first using > cpumask_first() and then cpumask_next(). The logic is the same here, > using the new helper will make it more conscious. > > Use bloat-o-meter to check the impact on code size, the result is the > same, does not have positive impact nor negative impact. > > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > Function old new delta > Total: Before=22590709, After=22590709, chg +0.00% > > Signed-off-by: I Hsin Cheng <richard120310@gmail.com> > --- > Generally speaking, I think this is just a small tweak on the code, > making it more readable. However, no benefit in code size or performance > as the implementation behind the helper is in fact the same as the one > used here. > > Maybe more tests should be done to ensure the change is solid, I hope to > seek some suggestions from everyone who has any ideas, or this is enough > then it's good. > > Best regards, > I Hsin Cheng > --- > kernel/time/clocksource.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c > index bb48498ebb5a..12ff0c048570 100644 > --- a/kernel/time/clocksource.c > +++ b/kernel/time/clocksource.c > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void) > return; > > /* Make sure to select at least one CPU other than the current CPU. */ > - cpu = cpumask_first(cpu_online_mask); > - if (cpu == smp_processor_id()) > - cpu = cpumask_next(cpu, cpu_online_mask); > + cpu = cpumask_first_but(cpu_online_mask, smp_processor_id()); > if (WARN_ON_ONCE(cpu >= nr_cpu_ids)) > return; > cpumask_set_cpu(cpu, &cpus_chosen); > -- > 2.43.0
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.
It's sufficient to point him to your series and tell him that it's
already been dealt with.
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.
Thanks,
tglx
On 6/13/25 04:48, 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. > > It's sufficient to point him to your series and tell him that it's > already been dealt with. Thank you Thomas. I Hsin is enrolled in kernel mentorship program and is new to the kernel community. Pleas give them the benefit of the doubt. It can be overwhelming when you just start sending patches. It can be difficult to figure out if there is duplicate work happening. Duplicate patches happen during kernel workflow. Most of us have done that at least once. thanks, -- Shuah
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
On Fri, Jun 13 2025 at 12:29, Yury Norov wrote: > On Fri, Jun 13, 2025 at 12:48:43PM +0200, Thomas Gleixner wrote: > 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. Indeed. > 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. Fair enough.
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. > > It's sufficient to point him to your series and tell him that it's > already been dealt with. > > 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. > > Thanks, > > tglx Hello Thomas, Thanks for your word, really appreciate it. Though I can understand abit why Yury was annoyed for this patch, at the patch [1] I sent earlier, it already collide with Yury's patch, he did paste the link of his patch for me, but I only take a look at the patch in the link, not the whole patch series. And then I send this patch, again collide with his work, if it were me, I might feel the same like alittle bit of offended. I send this patch because after I send this patch [2] , I think of Kuan-Wei's patch [3] months ago and see there might be a use case here, so I ask Kuan-Wei whether I can pick up his work. I admit I wasn't paying attention to detail enough when looking at other's work, neither did I subscribe the mailing list cuz I don't want my mail box to be exploded with mails that aren't sent to me. My workflow for patches was making sure it works as expected, and then use scripts to check patch format, get maintainers, and then send it. I know there's always room for improvments or something I might've done inappropriately, that's why I always send the first patch with RFC tag. That's the whole story, I am sorry to Yury, but again I think the accusation is too over, like I said earlier, if I mean to steal someone's work, why would I send it directly to the author ? Still, I respect Yury and his professions, months ago he gave me many suggesetions and help in another patch. That's why I send my patch [2] to him to asked him for some comments even though he's not in the maintainers list of that file. I would never want to offend someone I respect, I hope he can understand. [1]: https://lore.kernel.org/lkml/20250611104506.2270561-1-richard120310@gmail.com/ [2]: https://lore.kernel.org/lkml/20250609194611.690678-1-richard120310@gmail.com/ [3]: https://lore.kernel.org/lkml/20250117142658.297325-1-visitorckw@gmail.com/ Best regards, I Hsin Cheng
On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote: > I Hsin, > > 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. > However, I have to defend myself while I'm sincerely sorry for causing your trouble. I think the statement here is an excessive accusation, if I mean to stole other's patch, why would I send the patch to the author? I hope you can understand this, I was not careful enough and made this trouble, I should've browse through your patch series thoroughly and thus made this trouble, I'm sorry, but the accusation here is too over for me. Thanks, I Hsin Cheng > NAKed-by: Yury Norov <yury.norov@gmail.com> > > Thanks, > Yury > > On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote: > > Utilize cpumask_first_but() helper instead of first using > > cpumask_first() and then cpumask_next(). The logic is the same here, > > using the new helper will make it more conscious. > > > > Use bloat-o-meter to check the impact on code size, the result is the > > same, does not have positive impact nor negative impact. > > > > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > Function old new delta > > Total: Before=22590709, After=22590709, chg +0.00% > > > > Signed-off-by: I Hsin Cheng <richard120310@gmail.com> > > --- > > Generally speaking, I think this is just a small tweak on the code, > > making it more readable. However, no benefit in code size or performance > > as the implementation behind the helper is in fact the same as the one > > used here. > > > > Maybe more tests should be done to ensure the change is solid, I hope to > > seek some suggestions from everyone who has any ideas, or this is enough > > then it's good. > > > > Best regards, > > I Hsin Cheng > > --- > > kernel/time/clocksource.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c > > index bb48498ebb5a..12ff0c048570 100644 > > --- a/kernel/time/clocksource.c > > +++ b/kernel/time/clocksource.c > > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void) > > return; > > > > /* Make sure to select at least one CPU other than the current CPU. */ > > - cpu = cpumask_first(cpu_online_mask); > > - if (cpu == smp_processor_id()) > > - cpu = cpumask_next(cpu, cpu_online_mask); > > + cpu = cpumask_first_but(cpu_online_mask, smp_processor_id()); > > if (WARN_ON_ONCE(cpu >= nr_cpu_ids)) > > return; > > cpumask_set_cpu(cpu, &cpus_chosen); > > -- > > 2.43.0
On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote: > I Hsin, > > 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. > > NAKed-by: Yury Norov <yury.norov@gmail.com> > > Thanks, > Yury > Hello Yury, Sorry again, just like I mentioned in another thread, I didn't check the patch 1 of your patch series, I'm really sorry for that and causing your trouble. I really have no offense on that, the motivation of this patch was just like I mentioned earlier, anyway sorry for not be careful enough and interrupt your work. Hope you can forgive me this time. Best regards, I Hsin Cheng > On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote: > > Utilize cpumask_first_but() helper instead of first using > > cpumask_first() and then cpumask_next(). The logic is the same here, > > using the new helper will make it more conscious. > > > > Use bloat-o-meter to check the impact on code size, the result is the > > same, does not have positive impact nor negative impact. > > > > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > Function old new delta > > Total: Before=22590709, After=22590709, chg +0.00% > > > > Signed-off-by: I Hsin Cheng <richard120310@gmail.com> > > --- > > Generally speaking, I think this is just a small tweak on the code, > > making it more readable. However, no benefit in code size or performance > > as the implementation behind the helper is in fact the same as the one > > used here. > > > > Maybe more tests should be done to ensure the change is solid, I hope to > > seek some suggestions from everyone who has any ideas, or this is enough > > then it's good. > > > > Best regards, > > I Hsin Cheng > > --- > > kernel/time/clocksource.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c > > index bb48498ebb5a..12ff0c048570 100644 > > --- a/kernel/time/clocksource.c > > +++ b/kernel/time/clocksource.c > > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void) > > return; > > > > /* Make sure to select at least one CPU other than the current CPU. */ > > - cpu = cpumask_first(cpu_online_mask); > > - if (cpu == smp_processor_id()) > > - cpu = cpumask_next(cpu, cpu_online_mask); > > + cpu = cpumask_first_but(cpu_online_mask, smp_processor_id()); > > if (WARN_ON_ONCE(cpu >= nr_cpu_ids)) > > return; > > cpumask_set_cpu(cpu, &cpus_chosen); > > -- > > 2.43.0
On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote: > I Hsin, > > 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. > > NAKed-by: Yury Norov <yury.norov@gmail.com> > > Thanks, > Yury > Hello Yury, Sorry to make troubles, I didn't mean to do this, I wasn't aware that you've send the same work and nor do I mean to interrupt your work. I didn't have the habit to check others patches regularly, I'm sorry for that. I just saw Kuan-Wei's patch from months ago and I asked him whether I can continue that work, and he agrees, so I try to do something from there. Again sorry for causing troubles, I'll make sure to look for others patches first before submitting them. Sincerely sorry for this. Thanks, I Hsin Cheng > On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote: > > Utilize cpumask_first_but() helper instead of first using > > cpumask_first() and then cpumask_next(). The logic is the same here, > > using the new helper will make it more conscious. > > > > Use bloat-o-meter to check the impact on code size, the result is the > > same, does not have positive impact nor negative impact. > > > > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) > > Function old new delta > > Total: Before=22590709, After=22590709, chg +0.00% > > > > Signed-off-by: I Hsin Cheng <richard120310@gmail.com> > > --- > > Generally speaking, I think this is just a small tweak on the code, > > making it more readable. However, no benefit in code size or performance > > as the implementation behind the helper is in fact the same as the one > > used here. > > > > Maybe more tests should be done to ensure the change is solid, I hope to > > seek some suggestions from everyone who has any ideas, or this is enough > > then it's good. > > > > Best regards, > > I Hsin Cheng > > --- > > kernel/time/clocksource.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c > > index bb48498ebb5a..12ff0c048570 100644 > > --- a/kernel/time/clocksource.c > > +++ b/kernel/time/clocksource.c > > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void) > > return; > > > > /* Make sure to select at least one CPU other than the current CPU. */ > > - cpu = cpumask_first(cpu_online_mask); > > - if (cpu == smp_processor_id()) > > - cpu = cpumask_next(cpu, cpu_online_mask); > > + cpu = cpumask_first_but(cpu_online_mask, smp_processor_id()); > > if (WARN_ON_ONCE(cpu >= nr_cpu_ids)) > > return; > > cpumask_set_cpu(cpu, &cpus_chosen); > > -- > > 2.43.0
On 6/12/25 23:22, I Hsin Cheng wrote: > On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote: >> I Hsin, >> >> 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. >> >> NAKed-by: Yury Norov <yury.norov@gmail.com> >> >> Thanks, >> Yury >> > > Hello Yury, > > Sorry to make troubles, I didn't mean to do this, I wasn't aware that > you've send the same work and nor do I mean to interrupt your work. I > didn't have the habit to check others patches regularly, I'm sorry for > that. > > I just saw Kuan-Wei's patch from months ago and I asked him whether I > can continue that work, and he agrees, so I try to do something from > there. > > Again sorry for causing troubles, I'll make sure to look for others > patches first before submitting them. > > Sincerely sorry for this. > > Thanks, > I Hsin Cheng > >> On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote: >>> Utilize cpumask_first_but() helper instead of first using >>> cpumask_first() and then cpumask_next(). The logic is the same here, >>> using the new helper will make it more conscious. >>> >>> Use bloat-o-meter to check the impact on code size, the result is the >>> same, does not have positive impact nor negative impact. >>> >>> $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new >>> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) >>> Function old new delta >>> Total: Before=22590709, After=22590709, chg +0.00% >>> >>> Signed-off-by: I Hsin Cheng <richard120310@gmail.com> >>> --- >>> Generally speaking, I think this is just a small tweak on the code, >>> making it more readable. However, no benefit in code size or performance >>> as the implementation behind the helper is in fact the same as the one >>> used here. >>> >>> Maybe more tests should be done to ensure the change is solid, I hope to >>> seek some suggestions from everyone who has any ideas, or this is enough >>> then it's good. >>> Thank you for explaining what transpired and clearing the misunderstanding. It can be difficult to figure if there is a duplicate patch unless you are closely watching the mailing lists - it is very hard to keep up. Don't be discouraged with this experience. Continue to contribute. thanks, -- Shuah
© 2016 - 2025 Red Hat, Inc.