public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Liam Howlett <liam.howlett@oracle.com>
Cc: Will Deacon <will@kernel.org>,
	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>
Subject: Re: [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator
Date: Wed, 23 Feb 2022 09:39:17 +0000	[thread overview]
Message-ID: <YhYAxb85oDSYJyw0@arm.com> (raw)
In-Reply-To: <20220222185401.jntcd4g62pamfxvr@revolver>

On Tue, Feb 22, 2022 at 06:54:38PM +0000, Liam Howlett wrote:
> * Catalin Marinas <catalin.marinas@arm.com> [220222 12:26]:
> > On Tue, Feb 22, 2022 at 04:20:16PM +0000, Will Deacon wrote:
> > > On Tue, Feb 22, 2022 at 02:26:03PM +0000, Liam Howlett wrote:
> > > > The vma iterator uses the maple tree, so this patch would resolve the
> > > > conflict but both branches are needed.
> > > 
> > > I'm not really sure what to do here, then. I think the conflict is nasty
> > > enough that we should resolve it before the trees reach Linus, but there
> > > doesn't seem to be a way forward other than one of us merging the other
> > > branch. I'd like to avoid having MTE coredump support depend on the maple
> > > tree work.
> > > 
> > > Is there some way you could provide a branch which implements
> > > for_each_vma() using the old vma list, and then the maple tree series
> > > could switch that over to the maple tree without breaking things?
> > 
> > Without a branch, we could apply something like below on top of Liam's
> > patch and revert it once the maple tree is upstream:
> > 
> > diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> > index 930a0bc4cac4..400ec7a902df 100644
> > --- a/arch/arm64/kernel/elfcore.c
> > +++ b/arch/arm64/kernel/elfcore.c
> > @@ -8,6 +8,13 @@
> >  #include <asm/cpufeature.h>
> >  #include <asm/mte.h>
> > 
> > +#ifndef VMA_ITERATOR
> > +#define VMA_ITERATOR(name, mm, addr) \
> > +	struct mm_struct *name = mm
> > +#define for_each_vma(vmi, vma) \
> > +	for (vma = vmi->mmap; vma; vma = vma->vm_next)
> > +#endif
> > +
> >  #define for_each_mte_vma(vmi, vma)					\
> >  	if (system_supports_mte())					\
> >  		for_each_vma(vmi, vma)					\
> 
> Note that the current VMA_ITERATOR takes a new type and not the mm.

Well, in you proposed fix, it does take current->mm.

> Since I am removing the linked list (mm->mmap and vma->vm_next), then
> the build will fail if this patch and the maple tree branch exist
> together.  The iterator may also not start at the start of the list (but
> usually does) and may not run through the entire list; see
> vma_for_each_range() in the patch set.

My hack above is only temporary to allow building the arm64 tree on its
own (no maple tree branch) and with your patch on top. In -next, when
merged with the maple tree branch, the VMA_ITERATOR macro is already
defined and the above hack skipped. We'll revert this hack around -rc1.

Note that the hack above is only in the arm64 elfcore.c, not a generic
API solution.

-- 
Catalin

  reply	other threads:[~2022-02-23  9:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17  8:18 linux-next: build failure after merge of the maple tree Stephen Rothwell
2022-02-17 19:24 ` Will Deacon
2022-02-18  1:46   ` Liam Howlett
2022-02-18  2:37     ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator Liam Howlett
2022-02-21 18:06       ` Catalin Marinas
2022-02-22 14:26         ` Liam Howlett
2022-02-22 16:20           ` Will Deacon
2022-02-22 17:26             ` Catalin Marinas
2022-02-22 18:54               ` Liam Howlett
2022-02-23  9:39                 ` Catalin Marinas [this message]
2022-02-23 13:57                   ` Liam Howlett
2022-02-23 11:37                 ` Catalin Marinas
2022-02-23 14:11                   ` Liam Howlett
2022-02-24  2:00                     ` Liam Howlett
2022-02-25 15:50       ` Will Deacon
  -- strict thread matches above, loose matches on Subject: below --
2022-02-23  2:32 linux-next: build failure after merge of the maple tree Liam Howlett
2022-02-23 12:47 ` [PATCH] arm64: Change elfcore for_each_mte_vma() to use VMA iterator kernel test robot
2022-02-23 13:08 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YhYAxb85oDSYJyw0@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox