linux-kernel - Re: [PATCH 5.10 00/67] 5.10.56-rc1 review

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 Aug 2021 08:21:16 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Pavel Machek <pavel@...x.de>
Cc:     linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        akpm@...ux-foundation.org, linux@...ck-us.net, shuah@...nel.org,
        patches@...nelci.org, lkft-triage@...ts.linaro.org,
        jonathanh@...dia.com, f.fainelli@...il.com, stable@...r.kernel.org
Subject: Re: [PATCH 5.10 00/67] 5.10.56-rc1 review

On Tue, Aug 03, 2021 at 09:26:07PM +0200, Pavel Machek wrote:
> Hi!
> 
> > This is the start of the stable review cycle for the 5.10.56 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> 
> Not sure what went wrong, but 50 or so patches disappeared from the queue:
> 
> 48156f3dce81b215b9d6dd524ea34f7e5e029e6b (origin/queue/5.10) btrfs: fix lost inode on log replay after mix of fsync, rename and inode eviction
> 474a423936753742c112e265b5481dddd8c02f33 btrfs: fix race causing unnecessary inode logging during link and rename
> 2fb9fc485825505e31b634b68d4c05e193a224da Revert "drm/i915: Propagate errors on awaiting already signaled fences"
> b1c92988bfcb7aa46bdf8198541f305c9ff2df25 drm/i915: Revert "drm/i915/gem: Asynchronous cmdparser"
> 11fe69a17195cf58eff523f26f90de50660d0100 (tag: v5.10.55) Linux 5.10.55
> 984e93b8e20731f83e453dd056f8a3931b4a66e5 ipv6: ip6_finish_output2: set
> sk into newly allocated nskb

Look at commit e87bda470c72 ("move 5.10 patches back into -rc and queued
patches") as an example of what happened here.

The "queue" branches are odd and auto-generated and not all that smart
at times.  Stick to the -rc branches that I announce if you want to be
sure you are testing the proper thing.

thanks,

greg k-h