* Re: [5.4.y] Found 27 commits that might missed
2020-08-28 15:27 [5.4.y] Found 27 commits that might missed SeongJae Park
@ 2020-08-31 7:50 ` Jan Kara
2020-08-31 8:16 ` [External] " Muchun Song
` (3 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Jan Kara @ 2020-08-31 7:50 UTC (permalink / raw)
To: SeongJae Park
Cc: Muchun Song, Filipe Manana, Hauke Mehrtens, Alexander Tsoy,
Takashi Iwai, Arnaldo Carvalho de Melo, Michael Chan,
Christophe JAILLET, Vincent Guittot, Taehee Yoo, Fabio Estevam,
Jan Kara, Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson,
Mika Kuoppala, Nicholas Johnson, Adam Ford, Tudor Ambarus,
Xiaochen Shen, Greg Kroah-Hartman, sashal, amit, sj38.park,
stable
On Fri 28-08-20 17:27:45, SeongJae Park wrote:
> c3dbe541ef77 ("blktrace: Avoid sparse warnings when assigning q->blk_trace")
> # commit date: 2020-06-17, author: Jan Kara <jack@suse.cz>
> # mentions 'blktrace: Protect q->blk_trace with RCU'
Backporting this is not needed. As the changelog states, it fixes only
sparse warnings, not real bugs...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [External] [5.4.y] Found 27 commits that might missed
2020-08-28 15:27 [5.4.y] Found 27 commits that might missed SeongJae Park
2020-08-31 7:50 ` Jan Kara
@ 2020-08-31 8:16 ` Muchun Song
2020-08-31 8:37 ` Vincent Guittot
` (2 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: Muchun Song @ 2020-08-31 8:16 UTC (permalink / raw)
To: SeongJae Park
Cc: Filipe Manana, Hauke Mehrtens, Alexander Tsoy, Takashi Iwai,
Arnaldo Carvalho de Melo, Michael Chan, Christophe JAILLET,
Vincent Guittot, Taehee Yoo, Fabio Estevam, Jan Kara,
Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson, Mika Kuoppala,
Nicholas Johnson, Adam Ford, Tudor Ambarus, Xiaochen Shen,
Greg Kroah-Hartman, sashal, amit, sj38.park, linux- stable
On Fri, Aug 28, 2020 at 11:28 PM SeongJae Park <sjpark@amazon.com> wrote:
> 10de795a5add ("kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE")
> # commit date: 2020-08-06, author: Muchun Song <songmuchun@bytedance.com>
> # fixes 'kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler'
>
Just avoid compiler warnings, so it is not needed to backport.
--
Yours,
Muchun
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [5.4.y] Found 27 commits that might missed
2020-08-28 15:27 [5.4.y] Found 27 commits that might missed SeongJae Park
2020-08-31 7:50 ` Jan Kara
2020-08-31 8:16 ` [External] " Muchun Song
@ 2020-08-31 8:37 ` Vincent Guittot
2020-08-31 9:43 ` Takashi Iwai
2020-09-04 11:49 ` Greg KH
4 siblings, 0 replies; 11+ messages in thread
From: Vincent Guittot @ 2020-08-31 8:37 UTC (permalink / raw)
To: SeongJae Park
Cc: Muchun Song, Filipe Manana, Hauke Mehrtens, Alexander Tsoy,
Takashi Iwai, Arnaldo Carvalho de Melo, Michael Chan,
Christophe JAILLET, Taehee Yoo, Fabio Estevam, Jan Kara,
Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson, Mika Kuoppala,
Nicholas Johnson, Adam Ford, Tudor Ambarus, Xiaochen Shen,
Greg Kroah-Hartman, Sasha Levin, amit, sj38.park, # v4 . 16+
On Fri, 28 Aug 2020 at 17:28, SeongJae Park <sjpark@amazon.com> wrote:
>
> From: SeongJae Park <sjpark@amazon.de>
>
> Hello,
>
>
> We found below 27 commits in the 'v5.5..linus/master (upstream)' seems fixing or mentioning
> commits in the 'v5.4..stable/linux-5.4.y (downstream)' but are not merged in the 'downstream' yet.
> Could you please review if those need to be merged in?
>
> A commit is considered as fix of another if the complete 'Fixed:' tag is in the
> commit message. If the tag is not found but the commit message contains the
> title or the hash id of the other commit, it is considered mentioning it. So,
> the 'mentions' might have many false positives, but it could cover the typos (I
> found such cases before).
>
> The commits are grouped as 'fixes cleanly applicable', 'fixes not cleanly
> applicable (need manual backporting to be applied)', 'mentions cleanly
> applicable', and 'mentions not cleanly applicable'. Also, the commits in each
> group are sorted by the commit dates (oldest first).
>
> Both the finding of the commits and the writeup of this report is automatically
> done by a little script[1]. I'm going to run the tool and post this kind of
> report every couple of weeks or every month. Any comment (e.g., regarding
> posting period, new features request, bug report, ...) is welcome.
>
> Especially, if you find some commits that don't need to be merged in the
> downstream, please let me know so that I can mark those as unnecessary and
> don't bother you again.
>
> [1] https://github.com/sjp38/stream-track
>
>
> Thanks,
> SeongJae
>
>
> # v5.5: 4e3112a240ba9986cc3f67a6880da6529a955006
> # linus/master: 15bc20c6af4ceee97a1f90b43c0e386643c071b4
> # v5.4: 6e815efe19a99a33b16cc720c3d3a727565a4fa1
> # stable/linux-5.4.y: 6576d69aac94cd8409636dfa86e0df39facdf0d2
>
>
...
>
>
>
> Mentions not cleanly applicable
> -------------------------------
>
...
>
> 39f23ce07b93 ("sched/fair: Fix unthrottle_cfs_rq() for leaf_cfs_rq list")
> # commit date: 2020-05-19, author: Vincent Guittot <vincent.guittot@linaro.org>
> # mentions 'sched/fair: Fix enqueue_task_fair warning'
A backport has already been sent:
https://lore.kernel.org/stable/20200525172709.GB7427@vingu-book/
>
...
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [5.4.y] Found 27 commits that might missed
2020-08-28 15:27 [5.4.y] Found 27 commits that might missed SeongJae Park
` (2 preceding siblings ...)
2020-08-31 8:37 ` Vincent Guittot
@ 2020-08-31 9:43 ` Takashi Iwai
2020-09-04 11:49 ` Greg KH
4 siblings, 0 replies; 11+ messages in thread
From: Takashi Iwai @ 2020-08-31 9:43 UTC (permalink / raw)
To: SeongJae Park
Cc: Muchun Song, Filipe Manana, Hauke Mehrtens, Alexander Tsoy,
Takashi Iwai, Arnaldo Carvalho de Melo, Michael Chan,
Christophe JAILLET, Vincent Guittot, Taehee Yoo, Fabio Estevam,
Jan Kara, Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson,
Mika Kuoppala, Nicholas Johnson, Adam Ford, Tudor Ambarus,
Xiaochen Shen, Greg Kroah-Hartman, sashal, amit, sj38.park,
stable
On Fri, 28 Aug 2020 17:27:45 +0200,
SeongJae Park wrote:
>
> e4b0e41fee94 ("ALSA: usb-audio: Use the new macro for HP Dock rename quirks")
> # commit date: 2020-06-08, author: Takashi Iwai <tiwai@suse.de>
> # fixes 'ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock'
This is not really a fix but rather some cleanup, so no need for
stable.
> 695cf5ab401c ("ALSA: usb-audio: Fix packet size calculation")
> # commit date: 2020-06-30, author: Alexander Tsoy <alexander@tsoy.me>
> # fixes 'ALSA: usb-audio: Improve frames size computation'
The commit that was fixed by this patch was already reverted in stable
tree, so no need.
> ff7e06a55676 ("ALSA: pcm: oss: Fix regression by buffer overflow fix (again)")
> # commit date: 2020-04-03, author: Takashi Iwai <tiwai@suse.de>
> # mentions 'ALSA: pcm: oss: Avoid plugin buffer overflow'
>
> ac957e8c5411 ("ALSA: pcm: oss: Place the plugin buffer overflow checks correctly (for 5.7)")
> # commit date: 2020-04-24, author: Takashi Iwai <tiwai@suse.de>
> # mentions 'ALSA: pcm: oss: Avoid plugin buffer overflow'
The other equivalent fix to those was already merged for stable.
thanks,
Takashi
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [5.4.y] Found 27 commits that might missed
2020-08-28 15:27 [5.4.y] Found 27 commits that might missed SeongJae Park
` (3 preceding siblings ...)
2020-08-31 9:43 ` Takashi Iwai
@ 2020-09-04 11:49 ` Greg KH
2020-09-04 14:17 ` SeongJae Park
4 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2020-09-04 11:49 UTC (permalink / raw)
To: SeongJae Park
Cc: Muchun Song, Filipe Manana, Hauke Mehrtens, Alexander Tsoy,
Takashi Iwai, Arnaldo Carvalho de Melo, Michael Chan,
Christophe JAILLET, Vincent Guittot, Taehee Yoo, Fabio Estevam,
Jan Kara, Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson,
Mika Kuoppala, Nicholas Johnson, Adam Ford, Tudor Ambarus,
Xiaochen Shen, sashal, amit, sj38.park, stable
On Fri, Aug 28, 2020 at 05:27:45PM +0200, SeongJae Park wrote:
> From: SeongJae Park <sjpark@amazon.de>
>
> Hello,
>
>
> We found below 27 commits in the 'v5.5..linus/master (upstream)' seems fixing or mentioning
> commits in the 'v5.4..stable/linux-5.4.y (downstream)' but are not merged in the 'downstream' yet.
> Could you please review if those need to be merged in?
>
> A commit is considered as fix of another if the complete 'Fixed:' tag is in the
> commit message. If the tag is not found but the commit message contains the
> title or the hash id of the other commit, it is considered mentioning it. So,
> the 'mentions' might have many false positives, but it could cover the typos (I
> found such cases before).
>
> The commits are grouped as 'fixes cleanly applicable', 'fixes not cleanly
> applicable (need manual backporting to be applied)', 'mentions cleanly
> applicable', and 'mentions not cleanly applicable'. Also, the commits in each
> group are sorted by the commit dates (oldest first).
>
> Both the finding of the commits and the writeup of this report is automatically
> done by a little script[1]. I'm going to run the tool and post this kind of
> report every couple of weeks or every month. Any comment (e.g., regarding
> posting period, new features request, bug report, ...) is welcome.
>
> Especially, if you find some commits that don't need to be merged in the
> downstream, please let me know so that I can mark those as unnecessary and
> don't bother you again.
>
> [1] https://github.com/sjp38/stream-track
>
>
> Thanks,
> SeongJae
>
>
> # v5.5: 4e3112a240ba9986cc3f67a6880da6529a955006
> # linus/master: 15bc20c6af4ceee97a1f90b43c0e386643c071b4
> # v5.4: 6e815efe19a99a33b16cc720c3d3a727565a4fa1
> # stable/linux-5.4.y: 6576d69aac94cd8409636dfa86e0df39facdf0d2
>
>
> Fixes cleanly applicable
> ------------------------
>
> 2fb75ceaf71a ("remoteproc: Add missing '\n' in log messages")
> # commit date: 2020-04-22, author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> # fixes 'remoteproc: Fix NULL pointer dereference in rproc_virtio_notify'
Not a real fix, right?
> 1b9ae0c92925 ("wireless: Use linux/stddef.h instead of stddef.h")
> # commit date: 2020-05-27, author: Hauke Mehrtens <hauke@hauke-m.de>
> # fixes 'wireless: Use offsetof instead of custom macro.'
Is this really needed?
> e4b0e41fee94 ("ALSA: usb-audio: Use the new macro for HP Dock rename quirks")
> # commit date: 2020-06-08, author: Takashi Iwai <tiwai@suse.de>
> # fixes 'ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock'
Alsa stuff has been covered already...
> efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 Display")
> # commit date: 2020-06-21, author: Adam Ford <aford173@gmail.com>
> # fixes 'drm/panel: simple: Add Logic PD Type 28 display support'
Why is this applicable to 5.4.y? It says "5.6+" in the commit itself,
right?
>
> 2f57b8d57673 ("dmaengine: imx-sdma: Fix: Remove 'always true' comparison")
> # commit date: 2020-06-24, author: Fabio Estevam <festevam@gmail.com>
> # fixes 'dmaengine: imx-sdma: Fix the event id check to include RX event for UART6'
Does not change any logic
>
> 10de795a5add ("kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE")
> # commit date: 2020-08-06, author: Muchun Song <songmuchun@bytedance.com>
> # fixes 'kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler'
Not needed, as mentioned.
> Fixes not cleanly applicable
<snip>
Stopping right here, if you have fixes that will not cleanly apply, and
you think they should be applied, please fix them and send the proper
backport. I don't have the cycles to do these on my own.
Same for anything else here that you think should be applied but does
not cleanly build/apply.
> ----------------------------
>
> 3907ccfaec5d ("crypto: atmel-aes - Fix CTR counter overflow when multiple fragments")
> # commit date: 2019-12-20, author: Tudor Ambarus <tudor.ambarus@microchip.com>
> # fixes 'crypto: atmel-aes - Fix counter overflow in CTR mode'
>
> 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()")
> # commit date: 2020-05-27, author: Dongli Zhang <dongli.zhang@oracle.com>
> # fixes 'nvme/pci: move cqe check after device shutdown'
>
> 6e2f83884c09 ("bnxt_en: Fix AER reset logic on 57500 chips.")
> # commit date: 2020-06-15, author: Michael Chan <michael.chan@broadcom.com>
> # fixes 'bnxt_en: Improve AER slot reset.'
>
> 695cf5ab401c ("ALSA: usb-audio: Fix packet size calculation")
> # commit date: 2020-06-30, author: Alexander Tsoy <alexander@tsoy.me>
> # fixes 'ALSA: usb-audio: Improve frames size computation'
>
> 2fb2799a2abb ("net: rmnet: do not allow to add multiple bridge interfaces")
> # commit date: 2020-07-04, author: Taehee Yoo <ap420073@gmail.com>
> # fixes 'net: rmnet: use upper/lower device infrastructure'
>
>
>
> Mentions cleanly applicable
> ---------------------------
>
> 32ada3b9e04c ("x86/resctrl: Clean up unused function parameter in mkdir path")
> # commit date: 2020-01-20, author: Xiaochen Shen <xiaochen.shen@intel.com>
> # mentions 'x86/resctrl: Fix a deadlock due to inaccurate reference'
>
> 20f513091caf ("crypto: ccree - remove set but not used variable 'du_size'")
> # commit date: 2020-02-13, author: YueHaibing <yuehaibing@huawei.com>
> # mentions 'crypto: ccree - fix FDE descriptor sequence'
Oh come on, why is this tripping anything?
Please read the patches and see if you think they make sense for a
stable kernel, please tell me how the above one does?
stopping here...
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [5.4.y] Found 27 commits that might missed
2020-09-04 11:49 ` Greg KH
@ 2020-09-04 14:17 ` SeongJae Park
2020-09-05 7:09 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: SeongJae Park @ 2020-09-04 14:17 UTC (permalink / raw)
To: Greg KH
Cc: SeongJae Park, Muchun Song, Filipe Manana, Hauke Mehrtens,
Alexander Tsoy, Takashi Iwai, Arnaldo Carvalho de Melo,
Michael Chan, Christophe JAILLET, Vincent Guittot, Taehee Yoo,
Fabio Estevam, Jan Kara, Dongli Zhang, YueHaibing, Cong Wang,
Chris Wilson, Mika Kuoppala, Nicholas Johnson, Adam Ford,
Tudor Ambarus, Xiaochen Shen, sashal, amit, sj38.park, stable
On Fri, 4 Sep 2020 13:49:35 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Aug 28, 2020 at 05:27:45PM +0200, SeongJae Park wrote:
> > From: SeongJae Park <sjpark@amazon.de>
> >
> > Hello,
> >
> >
> > We found below 27 commits in the 'v5.5..linus/master (upstream)' seems fixing or mentioning
> > commits in the 'v5.4..stable/linux-5.4.y (downstream)' but are not merged in the 'downstream' yet.
> > Could you please review if those need to be merged in?
> >
> > A commit is considered as fix of another if the complete 'Fixed:' tag is in the
> > commit message. If the tag is not found but the commit message contains the
> > title or the hash id of the other commit, it is considered mentioning it. So,
> > the 'mentions' might have many false positives, but it could cover the typos (I
> > found such cases before).
> >
> > The commits are grouped as 'fixes cleanly applicable', 'fixes not cleanly
> > applicable (need manual backporting to be applied)', 'mentions cleanly
> > applicable', and 'mentions not cleanly applicable'. Also, the commits in each
> > group are sorted by the commit dates (oldest first).
> >
> > Both the finding of the commits and the writeup of this report is automatically
> > done by a little script[1]. I'm going to run the tool and post this kind of
> > report every couple of weeks or every month. Any comment (e.g., regarding
> > posting period, new features request, bug report, ...) is welcome.
> >
> > Especially, if you find some commits that don't need to be merged in the
> > downstream, please let me know so that I can mark those as unnecessary and
> > don't bother you again.
> >
> > [1] https://github.com/sjp38/stream-track
> >
> >
> > Thanks,
> > SeongJae
> >
> >
> > # v5.5: 4e3112a240ba9986cc3f67a6880da6529a955006
> > # linus/master: 15bc20c6af4ceee97a1f90b43c0e386643c071b4
> > # v5.4: 6e815efe19a99a33b16cc720c3d3a727565a4fa1
> > # stable/linux-5.4.y: 6576d69aac94cd8409636dfa86e0df39facdf0d2
> >
> >
> > Fixes cleanly applicable
> > ------------------------
> >
> > 2fb75ceaf71a ("remoteproc: Add missing '\n' in log messages")
> > # commit date: 2020-04-22, author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > # fixes 'remoteproc: Fix NULL pointer dereference in rproc_virtio_notify'
>
> Not a real fix, right?
>
> > 1b9ae0c92925 ("wireless: Use linux/stddef.h instead of stddef.h")
> > # commit date: 2020-05-27, author: Hauke Mehrtens <hauke@hauke-m.de>
> > # fixes 'wireless: Use offsetof instead of custom macro.'
>
> Is this really needed?
>
> > e4b0e41fee94 ("ALSA: usb-audio: Use the new macro for HP Dock rename quirks")
> > # commit date: 2020-06-08, author: Takashi Iwai <tiwai@suse.de>
> > # fixes 'ALSA: usb-audio: Add vendor, product and profile name for HP Thunderbolt Dock'
>
> Alsa stuff has been covered already...
>
> > efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 Display")
> > # commit date: 2020-06-21, author: Adam Ford <aford173@gmail.com>
> > # fixes 'drm/panel: simple: Add Logic PD Type 28 display support'
>
> Why is this applicable to 5.4.y? It says "5.6+" in the commit itself,
> right?
>
> >
> > 2f57b8d57673 ("dmaengine: imx-sdma: Fix: Remove 'always true' comparison")
> > # commit date: 2020-06-24, author: Fabio Estevam <festevam@gmail.com>
> > # fixes 'dmaengine: imx-sdma: Fix the event id check to include RX event for UART6'
>
> Does not change any logic
>
> >
> > 10de795a5add ("kprobes: Fix compiler warning for !CONFIG_KPROBES_ON_FTRACE")
> > # commit date: 2020-08-06, author: Muchun Song <songmuchun@bytedance.com>
> > # fixes 'kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler'
>
> Not needed, as mentioned.
Thanks for the review, I will apply those in the tool so that I never bother
you again with those.
>
> > Fixes not cleanly applicable
>
> <snip>
>
> Stopping right here, if you have fixes that will not cleanly apply, and
> you think they should be applied, please fix them and send the proper
> backport. I don't have the cycles to do these on my own.
>
> Same for anything else here that you think should be applied but does
> not cleanly build/apply.
Totally agreed. Actually, I posted a similar report[1] before and received
similar response. I promised to back-port some of those by myself. That's
still in my TODO list, but I was unable to get a time to revisit it quite long
time. From this, I realized that it wouldn't be easy to review, test, and
backport all of the such suspicious things by myself. Scaling up to multiple
stable series (the tool says there are 152 fixes and 147 mentions for 4.9.y)
seems impossible.
For the reason, I updated the tool to make the report to be sent to not only
the stable maintainers but also the authors of the suspicious commits, because
the review / test / backport of their own commits would be much easier that
others. As a result, we were able to find one suspended commit:
https://lore.kernel.org/stable/CAKfTPtAkOes+HmVabRazhCBBUo0M+QW38q3Zzj_O3O+Ghvc1pA@mail.gmail.com/
Of course, I will use my spare time to gradually check the nobody checked
commits one by one.
So, I supposed you may read only the replies from the authors. IOW, you're ok
to stop here or even above. If even reading the replies from the authors is
also just a burden, I could report the summary, as I should summarize the
replies anyway, to make next report ignores the commits the others confirmed
not necessary for the stable@.
[1] https://lore.kernel.org/stable/20200629161542.GA683634@kroah.com/
>
[...]
> >
> >
> >
> > Mentions cleanly applicable
> > ---------------------------
> >
> > 32ada3b9e04c ("x86/resctrl: Clean up unused function parameter in mkdir path")
> > # commit date: 2020-01-20, author: Xiaochen Shen <xiaochen.shen@intel.com>
> > # mentions 'x86/resctrl: Fix a deadlock due to inaccurate reference'
> >
> > 20f513091caf ("crypto: ccree - remove set but not used variable 'du_size'")
> > # commit date: 2020-02-13, author: YueHaibing <yuehaibing@huawei.com>
> > # mentions 'crypto: ccree - fix FDE descriptor sequence'
>
> Oh come on, why is this tripping anything?
>
> Please read the patches and see if you think they make sense for a
> stable kernel, please tell me how the above one does?
So, as described above, 'mentions' could contain more false positives. I may
try to improve the tool, but the report would still contain a large number of
false positives. It's not aimed to replace other advanced tools like PatchNet
but to pick their rare mistakes.
Checking the false positives would be annoying, but I think it is possible if
the original authors helps together. And, once a commit is reported as false
positive, the tool will not annoy people again (if there is no bug in the
tool).
As mentioned in the original mail, I'm going to send this kind of
report periodically. Nonetheless, I'm doing this only in hope of making stable
series just a little bit more stable. If you think this still makes no sense
but only makes you annoying, please let me know. I could exclude you from the
recipients of this report and send you only authors opinions summarized one or
even simply stop generating and sending this kind of reports to stable@.
Thanks,
SeongJae Park
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [5.4.y] Found 27 commits that might missed
2020-09-04 14:17 ` SeongJae Park
@ 2020-09-05 7:09 ` Greg KH
2020-09-05 8:02 ` SeongJae Park
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2020-09-05 7:09 UTC (permalink / raw)
To: SeongJae Park
Cc: Muchun Song, Filipe Manana, Hauke Mehrtens, Alexander Tsoy,
Takashi Iwai, Arnaldo Carvalho de Melo, Michael Chan,
Christophe JAILLET, Vincent Guittot, Taehee Yoo, Fabio Estevam,
Jan Kara, Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson,
Mika Kuoppala, Nicholas Johnson, Adam Ford, Tudor Ambarus,
Xiaochen Shen, sashal, amit, sj38.park, stable
On Fri, Sep 04, 2020 at 04:17:48PM +0200, SeongJae Park wrote:
> > <snip>
> >
> > Stopping right here, if you have fixes that will not cleanly apply, and
> > you think they should be applied, please fix them and send the proper
> > backport. I don't have the cycles to do these on my own.
> >
> > Same for anything else here that you think should be applied but does
> > not cleanly build/apply.
>
> Totally agreed. Actually, I posted a similar report[1] before and received
> similar response. I promised to back-port some of those by myself. That's
> still in my TODO list, but I was unable to get a time to revisit it quite long
> time. From this, I realized that it wouldn't be easy to review, test, and
> backport all of the such suspicious things by myself. Scaling up to multiple
> stable series (the tool says there are 152 fixes and 147 mentions for 4.9.y)
> seems impossible.
>
> For the reason, I updated the tool to make the report to be sent to not only
> the stable maintainers but also the authors of the suspicious commits, because
> the review / test / backport of their own commits would be much easier that
> others. As a result, we were able to find one suspended commit:
> https://lore.kernel.org/stable/CAKfTPtAkOes+HmVabRazhCBBUo0M+QW38q3Zzj_O3O+Ghvc1pA@mail.gmail.com/
That work had already been done before your email was sent.
I too can write a tool that sends out "this patch might be for stable,
will you do the work for it!" emails, but that's a bit rude to ask
others to do your work for you, don't you agree? By asking me and
others to dig through this list, when you said you don't have the time
to do so, feels very odd to me.
And if you have only 152 "fixes" for 4.9.y, that's great, should be easy
to work through. I do know that most of the "easy" backports are
already done, so what is left are the ones that take real work, or do
not make any sense, as your list shows.
So I don't think this report actually helped anyone here, do you?
Again, if you can do the backporting, that will help out greatly.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [5.4.y] Found 27 commits that might missed
2020-09-05 7:09 ` Greg KH
@ 2020-09-05 8:02 ` SeongJae Park
2020-09-05 22:50 ` Sasha Levin
0 siblings, 1 reply; 11+ messages in thread
From: SeongJae Park @ 2020-09-05 8:02 UTC (permalink / raw)
To: Greg KH
Cc: SeongJae Park, Muchun Song, Filipe Manana, Hauke Mehrtens,
Alexander Tsoy, Takashi Iwai, Arnaldo Carvalho de Melo,
Michael Chan, Christophe JAILLET, Vincent Guittot, Taehee Yoo,
Fabio Estevam, Jan Kara, Dongli Zhang, YueHaibing, Cong Wang,
Chris Wilson, Mika Kuoppala, Nicholas Johnson, Adam Ford,
Tudor Ambarus, Xiaochen Shen, sashal, amit, sj38.park, stable
From: SeongJae Park <sjpark@amazon.com>
On Sat, 5 Sep 2020 09:09:46 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
> On Fri, Sep 04, 2020 at 04:17:48PM +0200, SeongJae Park wrote:
> > > <snip>
> > >
> > > Stopping right here, if you have fixes that will not cleanly apply, and
> > > you think they should be applied, please fix them and send the proper
> > > backport. I don't have the cycles to do these on my own.
> > >
> > > Same for anything else here that you think should be applied but does
> > > not cleanly build/apply.
> >
> > Totally agreed. Actually, I posted a similar report[1] before and received
> > similar response. I promised to back-port some of those by myself. That's
> > still in my TODO list, but I was unable to get a time to revisit it quite long
> > time. From this, I realized that it wouldn't be easy to review, test, and
> > backport all of the such suspicious things by myself. Scaling up to multiple
> > stable series (the tool says there are 152 fixes and 147 mentions for 4.9.y)
> > seems impossible.
> >
> > For the reason, I updated the tool to make the report to be sent to not only
> > the stable maintainers but also the authors of the suspicious commits, because
> > the review / test / backport of their own commits would be much easier that
> > others. As a result, we were able to find one suspended commit:
> > https://lore.kernel.org/stable/CAKfTPtAkOes+HmVabRazhCBBUo0M+QW38q3Zzj_O3O+Ghvc1pA@mail.gmail.com/
>
> That work had already been done before your email was sent.
>
> I too can write a tool that sends out "this patch might be for stable,
> will you do the work for it!" emails, but that's a bit rude to ask
> others to do your work for you, don't you agree? By asking me and
> others to dig through this list, when you said you don't have the time
> to do so, feels very odd to me.
I thought the tool and this report are like a very simple form of the CI test
bots like 0day, syzbot, or some kind of static analyzers. Mine has quite large
number of false positives, though. Actually that was my only one concern.
Therefore I thought asking the authors to check this could be a little bit
annoying and therefore I asked them to let me know if they don't want this.
I also thought making an explicit list of false-positive 'Fixes:' could help
someone in the community. Also, I didn't intend to make others do my work
instead, but I just wanted to help the community finding missed patches.
For the reason, I didn't think this as rude, but seems I thought in a wrong
way. If you felt it rude, it's rude. I apology for that. I will stop posting
this report.
Thanks,
SeongJae Park
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [5.4.y] Found 27 commits that might missed
2020-09-05 8:02 ` SeongJae Park
@ 2020-09-05 22:50 ` Sasha Levin
2020-09-06 5:24 ` SeongJae Park
0 siblings, 1 reply; 11+ messages in thread
From: Sasha Levin @ 2020-09-05 22:50 UTC (permalink / raw)
To: SeongJae Park
Cc: Greg KH, SeongJae Park, Muchun Song, Filipe Manana,
Hauke Mehrtens, Alexander Tsoy, Takashi Iwai,
Arnaldo Carvalho de Melo, Michael Chan, Christophe JAILLET,
Vincent Guittot, Taehee Yoo, Fabio Estevam, Jan Kara,
Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson, Mika Kuoppala,
Nicholas Johnson, Adam Ford, Tudor Ambarus, Xiaochen Shen, amit,
stable
On Sat, Sep 05, 2020 at 10:02:20AM +0200, SeongJae Park wrote:
>From: SeongJae Park <sjpark@amazon.com>
>
>On Sat, 5 Sep 2020 09:09:46 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
>
>> On Fri, Sep 04, 2020 at 04:17:48PM +0200, SeongJae Park wrote:
>> > > <snip>
>> > >
>> > > Stopping right here, if you have fixes that will not cleanly apply, and
>> > > you think they should be applied, please fix them and send the proper
>> > > backport. I don't have the cycles to do these on my own.
>> > >
>> > > Same for anything else here that you think should be applied but does
>> > > not cleanly build/apply.
>> >
>> > Totally agreed. Actually, I posted a similar report[1] before and received
>> > similar response. I promised to back-port some of those by myself. That's
>> > still in my TODO list, but I was unable to get a time to revisit it quite long
>> > time. From this, I realized that it wouldn't be easy to review, test, and
>> > backport all of the such suspicious things by myself. Scaling up to multiple
>> > stable series (the tool says there are 152 fixes and 147 mentions for 4.9.y)
>> > seems impossible.
>> >
>> > For the reason, I updated the tool to make the report to be sent to not only
>> > the stable maintainers but also the authors of the suspicious commits, because
>> > the review / test / backport of their own commits would be much easier that
>> > others. As a result, we were able to find one suspended commit:
>> > https://lore.kernel.org/stable/CAKfTPtAkOes+HmVabRazhCBBUo0M+QW38q3Zzj_O3O+Ghvc1pA@mail.gmail.com/
>>
>> That work had already been done before your email was sent.
>>
>> I too can write a tool that sends out "this patch might be for stable,
>> will you do the work for it!" emails, but that's a bit rude to ask
>> others to do your work for you, don't you agree? By asking me and
>> others to dig through this list, when you said you don't have the time
>> to do so, feels very odd to me.
>
>I thought the tool and this report are like a very simple form of the CI test
>bots like 0day, syzbot, or some kind of static analyzers. Mine has quite large
>number of false positives, though. Actually that was my only one concern.
>Therefore I thought asking the authors to check this could be a little bit
>annoying and therefore I asked them to let me know if they don't want this.
>I also thought making an explicit list of false-positive 'Fixes:' could help
>someone in the community. Also, I didn't intend to make others do my work
>instead, but I just wanted to help the community finding missed patches.
And that's a good goal, but the help we need to accomplish that is in
the manual parts of the process which we can't automate: figuring out
whether a patch really needs to be backported, and doing the actual
backport.
I'd encourage you to pick a small subset of your results and try doing
just that - it's not "all of nothing" and even doing a few of these will
help.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [5.4.y] Found 27 commits that might missed
2020-09-05 22:50 ` Sasha Levin
@ 2020-09-06 5:24 ` SeongJae Park
0 siblings, 0 replies; 11+ messages in thread
From: SeongJae Park @ 2020-09-06 5:24 UTC (permalink / raw)
To: Sasha Levin
Cc: SeongJae Park, Greg KH, SeongJae Park, Muchun Song,
Filipe Manana, Hauke Mehrtens, Alexander Tsoy, Takashi Iwai,
Arnaldo Carvalho de Melo, Michael Chan, Christophe JAILLET,
Vincent Guittot, Taehee Yoo, Fabio Estevam, Jan Kara,
Dongli Zhang, YueHaibing, Cong Wang, Chris Wilson, Mika Kuoppala,
Nicholas Johnson, Adam Ford, Tudor Ambarus, Xiaochen Shen, amit,
stable
On Sat, 5 Sep 2020 18:50:28 -0400 Sasha Levin <sashal@kernel.org> wrote:
> On Sat, Sep 05, 2020 at 10:02:20AM +0200, SeongJae Park wrote:
> >From: SeongJae Park <sjpark@amazon.com>
> >
> >On Sat, 5 Sep 2020 09:09:46 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> >> On Fri, Sep 04, 2020 at 04:17:48PM +0200, SeongJae Park wrote:
> >> > > <snip>
> >> > >
> >> > > Stopping right here, if you have fixes that will not cleanly apply, and
> >> > > you think they should be applied, please fix them and send the proper
> >> > > backport. I don't have the cycles to do these on my own.
> >> > >
> >> > > Same for anything else here that you think should be applied but does
> >> > > not cleanly build/apply.
> >> >
> >> > Totally agreed. Actually, I posted a similar report[1] before and received
> >> > similar response. I promised to back-port some of those by myself. That's
> >> > still in my TODO list, but I was unable to get a time to revisit it quite long
> >> > time. From this, I realized that it wouldn't be easy to review, test, and
> >> > backport all of the such suspicious things by myself. Scaling up to multiple
> >> > stable series (the tool says there are 152 fixes and 147 mentions for 4.9.y)
> >> > seems impossible.
> >> >
> >> > For the reason, I updated the tool to make the report to be sent to not only
> >> > the stable maintainers but also the authors of the suspicious commits, because
> >> > the review / test / backport of their own commits would be much easier that
> >> > others. As a result, we were able to find one suspended commit:
> >> > https://lore.kernel.org/stable/CAKfTPtAkOes+HmVabRazhCBBUo0M+QW38q3Zzj_O3O+Ghvc1pA@mail.gmail.com/
> >>
> >> That work had already been done before your email was sent.
> >>
> >> I too can write a tool that sends out "this patch might be for stable,
> >> will you do the work for it!" emails, but that's a bit rude to ask
> >> others to do your work for you, don't you agree? By asking me and
> >> others to dig through this list, when you said you don't have the time
> >> to do so, feels very odd to me.
> >
> >I thought the tool and this report are like a very simple form of the CI test
> >bots like 0day, syzbot, or some kind of static analyzers. Mine has quite large
> >number of false positives, though. Actually that was my only one concern.
> >Therefore I thought asking the authors to check this could be a little bit
> >annoying and therefore I asked them to let me know if they don't want this.
> >I also thought making an explicit list of false-positive 'Fixes:' could help
> >someone in the community. Also, I didn't intend to make others do my work
> >instead, but I just wanted to help the community finding missed patches.
>
> And that's a good goal, but the help we need to accomplish that is in
> the manual parts of the process which we can't automate: figuring out
> whether a patch really needs to be backported, and doing the actual
> backport.
>
> I'd encourage you to pick a small subset of your results and try doing
> just that - it's not "all of nothing" and even doing a few of these will
> help.
Thanks for the kind explnation :)
Thanks,
SeongJae Park
^ permalink raw reply [flat|nested] 11+ messages in thread