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'
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.'
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'
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'
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'
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'
Fixes not cleanly applicable ----------------------------
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'
b182a66792fe ("net: ena: remove set but not used variable 'hash_key'") # commit date: 2020-02-17, author: YueHaibing yuehaibing@huawei.com # mentions 'net: ena: rss: do not allocate key when not supported'
cbb5494ebce5 ("Revert "thunderbolt: Prevent crash if non-active NVMem file is read"") # commit date: 2020-04-16, author: Nicholas Johnson nicholas.johnson-opensource@outlook.com.au # mentions 'thunderbolt: Prevent crash if non-active NVMem file is read'
1a33e10e4a95 ("net: partially revert dynamic lockdep key changes") # commit date: 2020-05-04, author: Cong Wang xiyou.wangcong@gmail.com # mentions 'bonding: add missing netdev_update_lockdep_key()'
7e579f3a074c ("tools arch x86 uapi: Synch asm/unistd.h with the kernel sources") # commit date: 2020-06-09, author: Arnaldo Carvalho de Melo acme@redhat.com # mentions 'x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"'
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'
6d548b9e5d56 ("btrfs: fix reclaim_size counter leak after stealing from global reserve") # commit date: 2020-07-02, author: Filipe Manana fdmanana@suse.com # mentions 'btrfs: improve global reserve stealing logic'
Mentions not cleanly applicable -------------------------------
6dbd54e4154d ("Revert "tty/serial: atmel: fix out of range clock divider handling"") # commit date: 2019-12-18, author: Greg Kroah-Hartman gregkh@linuxfoundation.org # mentions 'tty/serial: atmel: fix out of range clock divider handling'
48d7fb181a91 ("drm/i915: Remove lite restore defines") # commit date: 2020-02-08, author: Mika Kuoppala mika.kuoppala@linux.intel.com # mentions 'drm/i915/gt: Detect if we miss WaIdleLiteRestore'
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'
e7511f560f54 ("bonding: remove useless stats_lock_key") # commit date: 2020-05-04, author: Cong Wang xiyou.wangcong@gmail.com # mentions 'bonding: fix lockdep warning in bond_get_stats()'
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'
8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding") # commit date: 2020-06-16, author: Chris Wilson chris@chris-wilson.co.uk # mentions 'drm/i915/execlists: Always force a context reload when rewinding RING_TAIL'
5e548b32018d ("btrfs: do not set the full sync flag on the inode during page release") # commit date: 2020-07-27, author: Filipe Manana fdmanana@suse.com # mentions 'btrfs: fix race between page release and a fast fsync'
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
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.
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/
...
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
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
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+G...
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
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+G...
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
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+G...
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
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+G...
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.
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+G...
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Jan Kara -
Muchun Song -
Sasha Levin -
SeongJae Park -
SeongJae Park -
Takashi Iwai -
Vincent Guittot