Re: Upstream fixes not merged in 5.4.y

Re: Upstream fixes not merged in 5.4.y

[Greg KH]

On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote:
> Hello,
> 
> 
> With my little script, I found below commits in the mainline tree are more than
> 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not merged
> in the stable/linux-5.4.y tree.  Are those need to be merged in but missed or
> dealyed?
> 
> 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()")
> 9fecd13202f5 ("btrfs: fix a block group ref counter leak after failure to remove block group")
> 9d964e1b82d8 ("fix a braino in "sparc32: fix register window handling in genregs32_[gs]et()"")
> 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding")
> 6e2f83884c09 ("bnxt_en: Fix AER reset logic on 57500 chips.")
> efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 Display")
> ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams")
> ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams")
> 8dbe4c5d5e40 ("net: dsa: bcm_sf2: Fix node reference count")
> ca8826095e4d ("selftests/net: report etf errors correctly")
> 5a8d7f126c97 ("of: of_mdio: Correct loop scanning logic")
> d35d3660e065 ("binder: fix null deref of proc->context")
> 
> The script found several more commits but I exclude those here, because those
> seems not applicable on 5.4.y or fixing trivial problems only.  If I'm not
> following a proper process for this kind of reports, please let me know.

For commits that only have a "Fixes:" tag, and not a "cc: stable..."
tag, wait a few weeks, or a month, for us to catch up with them.  We
usually get to them eventually, but it takes us a while as we have lots
more to deal with by developers and maintainers that are properly
tagging patches for this type of thing.

Some of the above commits are queued up already, but not all of them.
I'll take a look at the list after this next round of patches go out,
and will let you know.

And yes, we do want this type of list, it's greatly appreciated.

thanks,

greg k-h

Re: Re: Upstream fixes not merged in 5.4.y

[SeongJae Park]

On Mon, 29 Jun 2020 18:15:42 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:

> On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote:
> > Hello,
> > 
> > 
> > With my little script, I found below commits in the mainline tree are more than
> > 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not merged
> > in the stable/linux-5.4.y tree.  Are those need to be merged in but missed or
> > dealyed?
> > 
> > 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()")
> > 9fecd13202f5 ("btrfs: fix a block group ref counter leak after failure to remove block group")
> > 9d964e1b82d8 ("fix a braino in "sparc32: fix register window handling in genregs32_[gs]et()"")
> > 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding")
> > 6e2f83884c09 ("bnxt_en: Fix AER reset logic on 57500 chips.")
> > efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 Display")
> > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams")
> > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams")
> > 8dbe4c5d5e40 ("net: dsa: bcm_sf2: Fix node reference count")
> > ca8826095e4d ("selftests/net: report etf errors correctly")
> > 5a8d7f126c97 ("of: of_mdio: Correct loop scanning logic")
> > d35d3660e065 ("binder: fix null deref of proc->context")
> > 
> > The script found several more commits but I exclude those here, because those
> > seems not applicable on 5.4.y or fixing trivial problems only.  If I'm not
> > following a proper process for this kind of reports, please let me know.
> 
> For commits that only have a "Fixes:" tag, and not a "cc: stable..."
> tag, wait a few weeks, or a month, for us to catch up with them.  We
> usually get to them eventually, but it takes us a while as we have lots
> more to deal with by developers and maintainers that are properly
> tagging patches for this type of thing.
> 
> Some of the above commits are queued up already, but not all of them.
> I'll take a look at the list after this next round of patches go out,
> and will let you know.
> 
> And yes, we do want this type of list, it's greatly appreciated.

Appreciate your kind explanation.  I will keep those in my mind for future
reports.


Thanks,
SeongJae Park

> 
> thanks,
> 
> greg k-h

Re: Upstream fixes not merged in 5.4.y

[Greg KH]

On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote:
> Hello,
> 
> 
> With my little script, I found below commits in the mainline tree are more than
> 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not merged
> in the stable/linux-5.4.y tree.  Are those need to be merged in but missed or
> dealyed?
> 
> 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()")

I tried this first patch, and it doesn't apply to the 5.4.y tree, so are
you sure you tried these yourself?

If so, please send a series of backported patches that you have
successfully tested, or if a patch applies cleanly, just the git id.

thanks,

greg k-h

Re: Re: Upstream fixes not merged in 5.4.y

[SeongJae Park]

On Mon, 20 Jul 2020 14:15:43 +0200 Greg KH <gregkh@linuxfoundation.org> wrote:

> On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote:
> > Hello,
> > 
> > 
> > With my little script, I found below commits in the mainline tree are more than
> > 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not merged
> > in the stable/linux-5.4.y tree.  Are those need to be merged in but missed or
> > dealyed?
> > 
> > 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()")
> 
> I tried this first patch, and it doesn't apply to the 5.4.y tree, so are
> you sure you tried these yourself?
> 
> If so, please send a series of backported patches that you have
> successfully tested, or if a patch applies cleanly, just the git id.

Yes, I backported it on the latest 5.4.y before.  I will rebase it on the
latest 5.4.y, test, and send the patch.  Nonetheless, please note that it might
take some time (say, a couple of weeks?).


Thanks,
SeongJae Park