Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: dqd7N/pkCAiROI/QrABbRhv/XE2hXrBdFbrnKkiJRP+PEUwrdUFkEiJFLlMGx0DlrkbAiqzet2
 OXV8+8X/xE6Q==
From:   SeongJae Park <sjpark@amazon.com>
To:     Greg KH <gregkh@linuxfoundation.org>
CC:     SeongJae Park <sjpark@amazon.com>, <sj38.park@gmail.com>,
        <sashal@kernel.org>, <stable@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: Re: Upstream fixes not merged in 5.4.y
Date:   Tue, 30 Jun 2020 08:29:35 +0200
Message-ID: <20200630062935.15087-1-sjpark@amazon.com>
In-Reply-To: <20200629161542.GA683634@kroah.com> (raw)
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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