From: "Liam R. Howlett" <Liam.Howlett@oracle.com>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
vbabka@suse.cz, yang@os.amperecomputing.com, riel@surriel.com,
david@redhat.com, minchan@kernel.org, jyescas@google.com,
linux@armlinux.org.uk, tsbogend@alpha.franken.de,
James.Bottomley@hansenpartnership.com,
ysato@users.sourceforge.jp, dalias@libc.org,
glaubitz@physik.fu-berlin.de, davem@davemloft.net,
andreas@gaisler.com, tglx@linutronix.de, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, chris@zankel.net,
jcmvbkbc@gmail.com, bhelgaas@google.com, jason.andryuk@amd.com,
leitao@debian.org, linux-alpha@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
loongarch@lists.linux.dev, linux-mips@vger.kernel.org,
linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
sparclinux@vger.kernel.org, linux-mm@kvack.org,
kernel-team@android.com, android-mm@google.com
Subject: Re: [PATCH mm-unstable v2 06/16] mm: csky: Introduce arch_mmap_hint()
Date: Thu, 12 Dec 2024 16:40:10 -0500 [thread overview]
Message-ID: <vc2uhcysgosapznbuookcj5677w43a4kzxbotwqub237ccawww@i3pbqiacdwsx> (raw)
In-Reply-To: <20241211232754.1583023-7-kaleshsingh@google.com>
* Kalesh Singh <kaleshsingh@google.com> [241211 18:28]:
> Introduce csky arch_mmap_hint() and define HAVE_ARCH_MMAP_HINT.
> This is a preparatory patch, no functional change is introduced.
This also looks like it has changed the validation order and potentially
introduced functional changes?
All these stem from the same cloned code (sparc32 iirc), but were not
updated when the cloned code was updated. This is why I am against
arch_* code. We should find a better way to unify the code so that
there is nothing different. You seem to have gotten some of the shared
code together, but some still exists.
In the addresses, there are upper and lower limits, and sometimes
"colours". Could we not just define the upper/lower limits in each arch
and if colour is used? Maybe this is complicated with 32/64 handled
both in the 64 bit code.
Is there any plan to unite this code further?
We have had errors for many years in cloned but not updated code. I
really wish there was more information in the cover letter on what is
going on here. I'd like to try and reduce the arch_ code to, basically
nothing.
I was also disappointed that I wasn't Cc'ed because I've spent a lot of
time in this code and this area. I am probably the last one to crawl
through and change any of this.
>
> Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
> ---
>
> Changes in v2:
> - MAP_FIXED case is also handled in arch_mmap_hint() since this is just a
> special case of the hint addr being "enforced", per Yang Shi.
> - Consolidate error handling in arch_mmap_hint().
>
> arch/csky/abiv1/inc/abi/pgtable-bits.h | 1 +
> arch/csky/abiv1/mmap.c | 68 ++++++++++++++------------
> 2 files changed, 38 insertions(+), 31 deletions(-)
>
> diff --git a/arch/csky/abiv1/inc/abi/pgtable-bits.h b/arch/csky/abiv1/inc/abi/pgtable-bits.h
> index ae7a2f76dd42..c346a9fcb522 100644
> --- a/arch/csky/abiv1/inc/abi/pgtable-bits.h
> +++ b/arch/csky/abiv1/inc/abi/pgtable-bits.h
> @@ -51,5 +51,6 @@
> ((offset) << 10)})
>
> #define HAVE_ARCH_UNMAPPED_AREA
> +#define HAVE_ARCH_MMAP_HINT
>
> #endif /* __ASM_CSKY_PGTABLE_BITS_H */
> diff --git a/arch/csky/abiv1/mmap.c b/arch/csky/abiv1/mmap.c
> index 1047865e82a9..0c5c51a081e4 100644
> --- a/arch/csky/abiv1/mmap.c
> +++ b/arch/csky/abiv1/mmap.c
> @@ -13,6 +13,39 @@
> ((((addr)+SHMLBA-1)&~(SHMLBA-1)) + \
> (((pgoff)<<PAGE_SHIFT) & (SHMLBA-1)))
>
> +unsigned long arch_mmap_hint(struct file *filp, unsigned long addr,
> + unsigned long len, unsigned long pgoff,
> + unsigned long flags)
> +{
> + bool do_align;
> +
> + if (len > TASK_SIZE)
> + return -ENOMEM;
> +
> + /*
> + * We only need to do colour alignment if either the I or D
> + * caches alias.
> + */
> + do_align = filp || (flags & MAP_SHARED);
> +
> + /*
> + * We enforce the MAP_FIXED case.
> + */
> + if (flags & MAP_FIXED) {
> + if (flags & MAP_SHARED &&
> + (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
> + return -EINVAL;
> + return addr;
> + }
> +
> + if (do_align)
> + addr = COLOUR_ALIGN(addr, pgoff);
> + else
> + addr = PAGE_ALIGN(addr);
> +
> + return generic_mmap_hint(filp, addr, len, pgoff, flags);
> +}
> +
> /*
> * We need to ensure that shared mappings are correctly aligned to
> * avoid aliasing issues with VIPT caches. We need to ensure that
> @@ -27,8 +60,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
> unsigned long flags, vm_flags_t vm_flags)
> {
> struct mm_struct *mm = current->mm;
> - struct vm_area_struct *vma;
> - int do_align = 0;
> + bool do_align;
> struct vm_unmapped_area_info info = {
> .length = len,
> .low_limit = mm->mmap_base,
> @@ -36,37 +68,11 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
> .align_offset = pgoff << PAGE_SHIFT
> };
>
> - /*
> - * We only need to do colour alignment if either the I or D
> - * caches alias.
> - */
This seems like useful information to keep around?
> - do_align = filp || (flags & MAP_SHARED);
> -
> - /*
> - * We enforce the MAP_FIXED case.
> - */
> - if (flags & MAP_FIXED) {
> - if (flags & MAP_SHARED &&
> - (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
> - return -EINVAL;
> + addr = arch_mmap_hint(filp, addr, len, pgoff, flags);
> + if (addr)
> return addr;
> - }
> -
> - if (len > TASK_SIZE)
> - return -ENOMEM;
> -
> - if (addr) {
> - if (do_align)
> - addr = COLOUR_ALIGN(addr, pgoff);
> - else
> - addr = PAGE_ALIGN(addr);
> -
> - vma = find_vma(mm, addr);
> - if (TASK_SIZE - len >= addr &&
> - (!vma || addr + len <= vm_start_gap(vma)))
> - return addr;
> - }
>
> + do_align = filp || (flags & MAP_SHARED);
> info.align_mask = do_align ? (PAGE_MASK & (SHMLBA - 1)) : 0;
> return vm_unmapped_area(&info);
> }
> --
> 2.47.0.338.g60cca15819-goog
>
>
next prev parent reply other threads:[~2024-12-12 21:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 23:27 [PATCH mm-unstable v2 00/16] mm: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 01/16] mm: Introduce generic_mmap_hint() Kalesh Singh
2024-12-12 20:08 ` Yang Shi
2024-12-11 23:27 ` [PATCH mm-unstable v2 02/16] mm: x86: Introduce arch_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 03/16] mm: arm: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 04/16] mm: alpha: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 05/16] mm: arc: Use generic_mmap_hint() Kalesh Singh
2024-12-12 21:13 ` Liam R. Howlett
2024-12-11 23:27 ` [PATCH mm-unstable v2 06/16] mm: csky: Introduce arch_mmap_hint() Kalesh Singh
2024-12-12 21:40 ` Liam R. Howlett [this message]
2024-12-13 1:39 ` Andrew Morton
2024-12-11 23:27 ` [PATCH mm-unstable v2 07/16] mm: loongarch: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 08/16] mm: mips: Introduce arch_align_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 09/16] mm: parisc: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 10/16] mm: s390: Use generic_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 11/16] mm: sh: Introduce arch_mmap_hint() Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 12/16] mm: sparc32: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 13/16] mm: sparc64: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 14/16] mm: xtensa: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 15/16] mm: powerpc: " Kalesh Singh
2024-12-11 23:27 ` [PATCH mm-unstable v2 16/16] mm: Respect mmap hint before THP alignment if allocation is possible Kalesh Singh
2024-12-12 20:11 ` Yang Shi
2024-12-12 21:02 ` [PATCH mm-unstable v2 00/16] mm: Introduce arch_mmap_hint() Liam R. Howlett
2024-12-12 22:51 ` Lorenzo Stoakes
2024-12-13 1:36 ` Andrew Morton
2024-12-13 8:59 ` Lorenzo Stoakes
2024-12-13 15:06 ` Kalesh Singh
2024-12-13 15:16 ` Lorenzo Stoakes
2024-12-13 16:45 ` Liam R. Howlett
2024-12-13 17:08 ` Kalesh Singh
2024-12-12 22:01 ` Matthew Wilcox
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=vc2uhcysgosapznbuookcj5677w43a4kzxbotwqub237ccawww@i3pbqiacdwsx \
--to=liam.howlett@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=android-mm@google.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=chris@zankel.net \
--cc=dalias@libc.org \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jason.andryuk@amd.com \
--cc=jcmvbkbc@gmail.com \
--cc=jyescas@google.com \
--cc=kaleshsingh@google.com \
--cc=kernel-team@android.com \
--cc=leitao@debian.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=lorenzo.stoakes@oracle.com \
--cc=minchan@kernel.org \
--cc=riel@surriel.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=ysato@users.sourceforge.jp \
/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