linux-kernel - Re: Re: Upstream fixes not merged in 5.4.y

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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