linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "debug@rivosinc.com" <debug@rivosinc.com>,
	"luto@kernel.org" <luto@kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>, "bp@alien8.de" <bp@alien8.de>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"peterz@infradead.org" <peterz@infradead.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 01/12] mm: Switch mm->get_unmapped_area() to a flag
Date: Wed, 13 Mar 2024 14:48:30 +0000	[thread overview]
Message-ID: <9d0a0ba73438031bf60172c7126cee87d63c070e.camel@intel.com> (raw)
In-Reply-To: <21ba6b8e-b9c7-41ae-8815-46525557c687@csgroup.eu>

On Wed, 2024-03-13 at 07:19 +0000, Christophe Leroy wrote:
> This patch is quite big and un-easy to follow. Would be worth
> splitting 
> in several patches if possible. Some of the changes seem to go
> further 
> than just switching mm->get_unmapped_area() to a flag.
> 
> First patch could add the new flag and necessary helpers, then
> following 
> patches could convert sub-systems one by one then last patch would 
> remove mm->get_unmapped_area() once all users are converted.

So you are saying to do the tracking in both the new flag and mm-
>get_unmapped_area() during the conversion process and then remove the
pointer at the end? I guess it could be broken out, but most of the
conversions are trivial one line changes. Hmm, I'm not sure.

[snip]
> 
> >    #ifdef CONFIG_MMU
> > -       if (!get_area)
> > -               get_area = current->mm->get_unmapped_area;
> > +       else
> > +               return mm_get_unmapped_area(current->mm, file,
> > orig_addr,
> > +                                           len, pgoff, flags);
> >    #endif
> > -       if (get_area)
> > -               return get_area(file, orig_addr, len, pgoff,
> > flags);
> > +
> >         return orig_addr;
> >    }
> 
> The change looks unclear at first look. Ok after looking a second
> time 
> it seems to simplify things, but would be better as a separate patch.
> Don't know.

Hmm. I think the only way to do it in smaller chunks is to do both
methods of tracking the direction during the conversion process. And
then the smaller pieces would be really small. So it would probably
help for changes like this, but otherwise would generate a lot of
patches with small changes.

The steps are basically:
1. Introduce flag and helpers
2. convert arch's to use it one by one
3. convert callers to use mm_get_unmapped_area() one by one
4. remove setting get_unmapped_area in each arch
5. remove get_unmapped_area

Step 3 is where the few non-oneline changes would be, but most would
still be one liners. 1, 2, 4 and 5 seem simpler as a tree wide patch
because of the one line changes.

I don't know any other variations are a ton simpler. Hopefully others
will weigh in.



[snip]
> >    
> > +unsigned long
> > +mm_get_unmapped_area(struct mm_struct *mm, struct file *file,
> > +                    unsigned long addr, unsigned long len,
> > +                    unsigned long pgoff, unsigned long flags)
> > +{
> > +       if (test_bit(MMF_TOPDOWN, &mm->flags))
> > +               return arch_get_unmapped_area_topdown(file, addr,
> > len, pgoff, flags);
> > +       return arch_get_unmapped_area(file, addr, len, pgoff,
> > flags);
> > +}
> 
> This function seems quite simple, wouldn't it be better to make it a 
> static inline ?

Then all of the arch_get_unmapped_area() and
arch_get_unmapped_area_topdown() would need to be exported. I think it
is better to only export the higher level functions.

  reply	other threads:[~2024-03-13 14:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 22:28 [PATCH v3 00/12] Cover a guard gap corner case Rick Edgecombe
2024-03-12 22:28 ` [PATCH v3 01/12] mm: Switch mm->get_unmapped_area() to a flag Rick Edgecombe
2024-03-13  7:19   ` Christophe Leroy
2024-03-13 14:48     ` Edgecombe, Rick P [this message]
2024-03-13 17:20       ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 02/12] mm: Introduce arch_get_unmapped_area_vmflags() Rick Edgecombe
2024-03-13  7:22   ` Christophe Leroy
2024-03-13 14:51     ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 03/12] mm: Use get_unmapped_area_vmflags() Rick Edgecombe
2024-03-13  9:05   ` Christophe Leroy
2024-03-13 14:55     ` Edgecombe, Rick P
2024-03-13 16:49       ` Christophe Leroy
2024-03-13 15:55     ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 04/12] thp: Add thp_get_unmapped_area_vmflags() Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 05/12] csky: Use initializer for struct vm_unmapped_area_info Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 06/12] parisc: " Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 07/12] powerpc: " Rick Edgecombe
2024-03-13  6:44   ` Christophe Leroy
2024-03-13 14:57     ` Edgecombe, Rick P
2024-03-13 21:58       ` Michael Ellerman
2024-03-12 22:28 ` [PATCH v3 08/12] treewide: " Rick Edgecombe
2024-03-13  3:18   ` Kees Cook
2024-03-13 15:40     ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 09/12] mm: Take placement mappings gap into account Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-13 14:58     ` Edgecombe, Rick P
2024-03-13 16:51       ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 10/12] x86/mm: Implement HAVE_ARCH_UNMAPPED_AREA_VMFLAGS Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-13 16:00     ` Edgecombe, Rick P
2024-03-18  1:00       ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 11/12] x86/mm: Care about shadow stack guard gap during placement Rick Edgecombe
2024-03-12 22:28 ` [PATCH v3 12/12] selftests/x86: Add placement guard gap test for shstk Rick Edgecombe

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=9d0a0ba73438031bf60172c7126cee87d63c070e.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dave.hansen@linux.intel.com \
    --cc=debug@rivosinc.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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