linux-kernel - Re: linux-next: Fixes tag needs some work in the mm tree

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]

Message-Id: <20220919140401.c63f8a81b239e9b8139f54d8@linux-foundation.org>
Date:   Mon, 19 Sep 2022 14:04:01 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     "Zach O'Keefe" <zokeefe@...gle.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: Fixes tag needs some work in the mm tree

On Mon, 19 Sep 2022 07:47:51 -0700 "Zach O'Keefe" <zokeefe@...gle.com> wrote:

> Apologies here.  Yes, the correct Fixes tag should be, based off latest
> mm-unstable,
> 
> Fixes: 8d88fef0b3d8 ("selftests/vm: add thp collapse file and tmpfs testing")
> 
> Now, I'm quite confused as to has this happened as I've been generating
> citations using something similar to the --format string you reference, but
> perhaps this time I chose to do it manually and messed it up.  Anyways, will
> write something to catch these mistakes in the future.

The hashes in mm-unstable change every day.

Doesn't matter, I'll queue fixes against mm-unstable's foo.patch as
foo-fix.patch and I'll squash foo-fix.patch into foo.patch before
moving f.patch into mm-stable.


> Andrew, there are a few changes incoming to the "mm: add file/shmem support to
> MADV_COLLAPSE" series based off recent reviews (including another patch with
> a commit description change).  Perhaps it's easier for me to send a new (v4)
> series to mm-unstable to address these?  Otherwise, I'm not sure how to
> request these metadata changes.

As described above, the metadata gets fixed at this end.  mm-unstable
is called "unstable" for a reason ;)

But yes, I think a replacement series would be best in this case.