[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4be39304-6719-4b95-9484-7936124bdb73@lucifer.local>
Date: Thu, 30 Oct 2025 13:45:04 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        Muchun Song <muchun.song@...ux.dev>,
        Oscar Salvador <osalvador@...e.de>,
        David Hildenbrand <david@...hat.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
        Peter Xu <peterx@...hat.com>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
        Mel Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
        Kees Cook <kees@...nel.org>, Matthew Wilcox <willy@...radead.org>,
        John Hubbard <jhubbard@...dia.com>, Leon Romanovsky <leon@...nel.org>,
        Zi Yan <ziy@...dia.com>, Baolin Wang <baolin.wang@...ux.alibaba.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>, Xu Xin <xu.xin16@....com.cn>,
        Chengming Zhou <chengming.zhou@...ux.dev>,
        Jann Horn <jannh@...gle.com>, Matthew Brost <matthew.brost@...el.com>,
        Joshua Hahn <joshua.hahnjy@...il.com>, Rakie Kim <rakie.kim@...com>,
        Byungchul Park <byungchul@...com>, Gregory Price <gourry@...rry.net>,
        Ying Huang <ying.huang@...ux.alibaba.com>,
        Alistair Popple <apopple@...dia.com>, Pedro Falcato <pfalcato@...e.de>,
        Shakeel Butt <shakeel.butt@...ux.dev>,
        David Rientjes <rientjes@...gle.com>, Rik van Riel <riel@...riel.com>,
        Harry Yoo <harry.yoo@...cle.com>,
        Kemeng Shi <shikemeng@...weicloud.com>,
        Kairui Song <kasong@...cent.com>, Nhat Pham <nphamcs@...il.com>,
        Baoquan He <bhe@...hat.com>, Chris Li <chrisl@...nel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Qi Zheng <zhengqi.arch@...edance.com>, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 1/4] mm: declare VMA flags by bit
On Thu, Oct 30, 2025 at 09:55:21AM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 30, 2025 at 09:07:19AM +0000, Lorenzo Stoakes wrote:
> > > >  fs/proc/task_mmu.c               |   4 +-
> > > >  include/linux/mm.h               | 286 +++++++++++++++++---------
> > > >  tools/testing/vma/vma_internal.h | 341 +++++++++++++++++++++++++++----
> > >
> > > Maybe take the moment to put them in some vma_flags.h and then can
> > > that be included from tools/testing to avoid this copying??
> >
> > It sucks to have this copy/paste yeah. The problem is to make the VMA
> > userland testing work, we intentionally isolate vma.h/vma.c dependencies
> > into vma_internal.h in mm/ and also do the same in the userland component,
> > so we can #include vma.c/h in the userland code.
> >
> > So we'd have to have a strict requirement that vma_flags.h doesn't import
> > any other headers or at least none which aren't substituted somehow in the
> > tools/include directory.
>
> I think that's fine, much better than copying it like this..
Ack will give it a go!
>
> > The issue is people might quite reasonably update include/linux/vma_flags.h
> > to do more later and then break all of the VMA userland testing...
>
> If only the selftest build system wasn't such a PITA maybe more people
> would run it :(
This isn't a selftest thing :)
So it's literally:
$ cd tools/testing/vma
$ make && ./vma
>
> Jason
Cheers, Lorenzo
Powered by blists - more mailing lists
 
