linux-kernel - Re: [PATCH v2 1/3] mm/huge_memory: do not change split_huge

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: <557fd56d-1a4c-4c65-8db6-34546c9ce8be@lucifer.local>
Date: Fri, 17 Oct 2025 15:32:13 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Zi Yan <ziy@...dia.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Wei Yang <richard.weiyang@...il.com>, linmiaohe@...wei.com,
        david@...hat.com, jane.chu@...cle.com, kernel@...kajraghav.com,
        syzbot+e6367ea2fdab6ed46056@...kaller.appspotmail.com,
        syzkaller-bugs@...glegroups.com, mcgrof@...nel.org,
        nao.horiguchi@...il.com, Baolin Wang <baolin.wang@...ux.alibaba.com>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Nico Pache <npache@...hat.com>, Ryan Roberts <ryan.roberts@....com>,
        Dev Jain <dev.jain@....com>, Barry Song <baohua@...nel.org>,
        Lance Yang <lance.yang@...ux.dev>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Pankaj Raghav <p.raghav@...sung.com>
Subject: Re: [PATCH v2 1/3] mm/huge_memory: do not change split_huge_page*()
 target order silently.

On Fri, Oct 17, 2025 at 10:16:10AM -0400, Zi Yan wrote:
> On 17 Oct 2025, at 5:10, Lorenzo Stoakes wrote:
>
> > On Fri, Oct 17, 2025 at 10:06:41AM +0100, Lorenzo Stoakes wrote:
> >> On Thu, Oct 16, 2025 at 09:03:27PM -0400, Zi Yan wrote:
> >>> On 16 Oct 2025, at 16:59, Andrew Morton wrote:
> >>>
> >>>> On Thu, 16 Oct 2025 10:32:17 -0400 Zi Yan <ziy@...dia.com> wrote:
> >>>>
> >>>>>> Do we want to cc stable?
> >>>>>
> >>>>> This only triggers a warning, so I am inclined not to.
> >>>>> But some config decides to crash on kernel warnings. If anyone thinks
> >>>>> it is worth ccing stable, please let me know.
> >>>>
> >>>> Yes please.  Kernel warnings are pretty serious and I do like to fix
> >>>> them in -stable when possible.
> >>>>
> >>>> That means this patch will have a different routing and priority than
> >>>> the other two so please split the warning fix out from the series.
> >>>
> >>> OK. Let me send this one and cc stable.
> >>
> >> You've added a bunch of confusion here, now if I review the rest of this series
>
> What confusion I have added here? Do you mind elaborating?

There's 2 series in the tree now:

v2 -> with a stale patch 1/3 + 2/3, 3/3

v3 -> 1/3 separate

If I use any tooling (b4 shazam etc.) to pull this series to review, it'll pull
the state patch.

if 2/3 or 3/3 depend on 1/3 then it's super confused.

All I'm asking is for you to resend/respin the 2 patches without the stale one.

>
> >> it looks like I'm reviewing it with this stale patch included.
> >>
> >> Can you please resend the remainder of the series as a v3 so it's clear? Thanks!
> >
> > Oh and now this entire series relies on that one landing to work :/
> >
> > What a mess - Can't we just live with one patch from a series being stable and
> > the rest not? Seems crazy otherwise.
>
> This is what Andrew told me. Please settle this with Andrew if you do not like

Didn't he just ask you to send 1/3 separately? I don't think he said send 1/3
separately and do not resend 2/3, 3/3...

> it. I will hold on sending new version of this patchset until either you or
> Andrew give me a clear guidance on how to send this patchset.

I mean if you want to delay resending this until the hotfix is sorted out then
just reply to 0/3 saying 'please drop this until that patch is merged'.

Otherwise it looks live.

>
> >
> > I guess when you resend you'll need to put explicitly in the cover letter
> > 'relies on patch xxxx'
>
> Why? I will simply wait until this patch is merged, then I can send the rest
> of two. Separate patchsets with dependency is hard for review, why would I
> send them at the same time?

So you're planning to only resend once the hotfix is upstreamed completely?

Sometimes this can be delayed a couple weeks. But fine.

As long as there's clarity.

>
> --
> Best Regards,
> Yan, Zi

Thanks, Lorenzo