# Re: \[PATCH 00/13\] mm: continue vma\_flags\_t conversion

- From: David Hildenbrand (Arm) \<david@kernel.org\>
- Date: 2026-11-09 17:48:36 
- List: linux-security-module
- Page: https://ratatoskr.run/linux-security-module/2026/11/17899086
- Thread: https://ratatoskr.run/linux-mm/2026/11/17874173/t.md

```text
On 11/9/26 18:44, Andrew Morton wrote:
> On Mon, 9 Nov 2026 14:40:48 +0100 "David Hildenbrand (Arm)" [ref] wrote:
> 
>> On 11/7/26 21:09, Lorenzo Stoakes (ARM) wrote:
>>> I think we're slightly talking across purposes, so to be clear - I am totally
>>> fine with you taking any of this through your tree or whatever works for you and
>>> Andrew to avoid merge pain :)
>>>
>>> I was just talking more generally about how to merge series that touch a lot of
>>> subsystems and maintainers-who-may-never-reply, etc.
>>>
>>> These are the edge cases that make things... fun :)
>>>
>>> Anyway, I guess easiest resolution here is for you to take the bits that belong
>>> to your trees and Andrew takes the bits that belong elsewhere?
>>
>> Yes, that's what I did now, applying #1,#3,#4,#5,#6
> 
> Cool.
> 
> I'll remove the whole series from mm.git immediately for
> collision-avoidance reasons - let's sort things out later.

The mm-next merge today still worked (minor conflict on #7 due to one
unnecessary ksm.c hunk I commented on), so you could have likely just kept all
but the above patches.

> 
> I'll get better/more accurate about this soon - I need to set up
> infrastructure to fetch everyone else's trees, do test merges and
> figure out what should be removed/fixed in mm.git.  I might just base
> mm.git on everyone-else and always route its stuff ->david.  I need to
> spend a bit of time on this and discuss with the mm-next peeps.

Ack!

-- 
Cheers,

David
```
