Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220919082105.73c0e270@canb.auug.org.au> <YyiBF5V6I7SYHqJy@google.com>
 <20220919140401.c63f8a81b239e9b8139f54d8@linux-foundation.org>
In-Reply-To: <20220919140401.c63f8a81b239e9b8139f54d8@linux-foundation.org>
From:   "Zach O'Keefe" <zokeefe@google.com>
Date:   Wed, 21 Sep 2022 11:24:14 -0700
Message-ID: <CAAa6QmSxX_dMpueoSau+1w=A1JTs1mDMWAN7m6Q5k_WKDrF_pQ@mail.gmail.com>
Subject: Re: linux-next: Fixes tag needs some work in the mm tree
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Sep 19, 2022 at 2:04 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 19 Sep 2022 07:47:51 -0700 "Zach O'Keefe" <zokeefe@google.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.
>

Roger that, thanks Andrew.

> > 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.

Sounds good, and hopefully I will have that out later today.

Best, and thanks for your help here,
Zach