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]
Message-ID: <4dee3069-e782-4e37-a46a-ac3a9abb82fa@redhat.com>
Date: Tue, 4 Mar 2025 11:31:27 +0100
From: David Hildenbrand <david@...hat.com>
To: Brendan Jackman <jackmanb@...gle.com>,
 Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
 Johannes Weiner <hannes@...xchg.org>, kernel test robot <lkp@...el.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Oscar Salvador
 <osalvador@...e.de>, llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
 Linux Memory Management List <linux-mm@...ck.org>,
 Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/page_alloc: Add lockdep assertion for pageblock type
 change

On 04.03.25 11:18, Brendan Jackman wrote:
> On Tue, Mar 04, 2025 at 10:13:57AM +1100, Stephen Rothwell wrote:
>> Hi Andy,
>>
>> On Mon, 3 Mar 2025 13:18:42 +0200 Andy Shevchenko <andriy.shevchenko@...el.com> wrote:
>>>
>>> On Fri, Feb 28, 2025 at 01:28:04PM -0500, Johannes Weiner wrote:
>>>> On Sat, Mar 01, 2025 at 01:31:30AM +0800, kernel test robot wrote:
>>>
>>>> The patch is missing a dummy in_mem_hotplug() in the
>>>> !CONFIG_MEMORY_HOTPLUG section of <linux/memory_hotplug.h>.
>>>
>>> +1, I just stumbled over and this is not fixed in today's Linux Next. I'm
>>> wondering how this was missed during merge into Linux Next. Stephen?
>>
>> I just get what people put in their trees.  There are no conflicts
>> around this and none of my builds failed, so I didn't see the problem.
>> Has someone sent a fix patch to Andrew?  If so, if you forward it to
>> me, I will add it to linux-next today.
> 
> Andrew has backed it out of mm-unstable now. There's a v2 [0] which
> still has runtime issues but AFAIK it's not in any tree yet.
> 
> [0] https://lore.kernel.org/linux-mm/20250303-pageblock-lockdep-v2-1-3fc0c37e9532@google.com/
> 
> In case it helps calibrate expectations: I think this particular patch
> had been reviewed but in general some patches get into mm-unstable
> without any review being recorded at all. My understanding is that
> Andrew squints at it and goes "that looks like it will probably
> eventually get merged" and puts it in so that people get a view of
> likely upcoming changes.
> 
> So if an issue like this reaching linux-next is a big problem then I
> think the solution is not to merge mm-unstable. I'm not sure how
> high the bar is supposed to be for feeding into linux-next.

Last year at LSF/MM I raised that maybe we should have something 
in-between mm-unstable and mm-stable that would get merged into -next. ( 
"mm-almost-stable" / "mm-for-next" ;) )

Alternatively, we could add something like "mm-staging" before 
"mm-unstable" and "mm-stable", whereby only "mm-unstable" would get 
merged into -next.

Ideally, we'd have at least build-bots and some basic sanity checks 
going on on such a staging environment. After a couple of days (not 
more) of survival in such an environment, it could be moved to the tree 
that gets exposed to -next/

I guess the downside is that it's "yet another branch" and "yet more 
build+testing" effort; in particular, if build+testing doesn't happen it 
will be worthless. And likely, a lot of build+testing is happening on 
linux-next only.

I have pretty good results with build bots going crazy on my branches, 
so most stuff that I send (after letting is rest for a couple of days on 
a public branch) doesn't really result in build issues.

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ