[5.4.y] Found 27 commits that might missed

[5.4.y] Found 27 commits that might missed

[SeongJae Park]

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'

Re: [5.4.y] Found 27 commits that might missed

[Jan Kara]

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

Re: [External] [5.4.y] Found 27 commits that might missed

[Muchun Song]

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

Re: [5.4.y] Found 27 commits that might missed

[Vincent Guittot]

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/

>
...

Re: [5.4.y] Found 27 commits that might missed

[Takashi Iwai]

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

Re: [5.4.y] Found 27 commits that might missed

[Greg KH]

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

Re: [5.4.y] Found 27 commits that might missed

[SeongJae Park]

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

Re: [5.4.y] Found 27 commits that might missed

[Greg KH]

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

Re: [5.4.y] Found 27 commits that might missed

[SeongJae Park]

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

Re: [5.4.y] Found 27 commits that might missed

[Sasha Levin]

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

Re: [5.4.y] Found 27 commits that might missed

[SeongJae Park]

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