[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200630062935.15087-1-sjpark@amazon.com>
Date: Tue, 30 Jun 2020 08:29:35 +0200
From: SeongJae Park <sjpark@...zon.com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: SeongJae Park <sjpark@...zon.com>, <sj38.park@...il.com>,
<sashal@...nel.org>, <stable@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: Re: Upstream fixes not merged in 5.4.y
On Mon, 29 Jun 2020 18:15:42 +0200 Greg KH <gregkh@...uxfoundation.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
Powered by blists - more mailing lists