On Fri, Dec 13, 2024 at 10:06:55AM -0500, Kalesh Singh wrote:
> On Fri, Dec 13, 2024 at 4:00 AM Lorenzo Stoakes
> wrote:
> >
> > On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote:
> > > On Thu, 12 Dec 2024 22:51:34 + Lorenzo Stoakes
> &g
On Thu, Dec 12, 2024 at 05:36:09PM -0800, Andrew Morton wrote:
> On Thu, 12 Dec 2024 22:51:34 +0000 Lorenzo Stoakes
> wrote:
>
> > You've fundamentally violated kernel process and etiquette. I'd be more
> > forgiving, but this is at v2 and you've not cc'
NACK.
Resend this _as an RFC_, _with the correct maintainers and reviewers cc'd_.
You've fundamentally violated kernel process and etiquette. I'd be more
forgiving, but this is at v2 and you've not cc'd KEY people. Twice. This is
totally unacceptable. See [0] if you are unsure of how to do so.
Y
On Thu, Sep 26, 2024 at 01:54:09PM +, Arnd Bergmann wrote:
> On Thu, Sep 26, 2024, at 08:46, David Hildenbrand wrote:
> > On 25.09.24 23:06, Arnd Bergmann wrote:
> >
> > The first, uncontroversial step could indeed be to make
> > MAP_UNINITIALIZED a nop, but still leave the definitions in mman.
tents.
>
> Signed-off-by: Arnd Bergmann
Lovely! Look at all that red :) Great work!
Reviewed-by: Lorenzo Stoakes
> ---
> arch/alpha/include/uapi/asm/mman.h | 68 +++---
> arch/parisc/include/uapi/asm/mman.h| 66 +
> include/u
On Wed, Sep 25, 2024 at 09:06:12PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> powerpc and sparc include asm-generic/mman-common.h to get the MAP_* flags
> 0x008000 through 0x400, but those flags are all different on alpha,
> mips, parisc and xtensa.
>
> Add duplicate definitions for
this looks good to me - thanks very much
for taking a look at this!)
Acked-by: Lorenzo Stoakes
> ---
> arch/alpha/include/uapi/asm/mman.h | 53 ---
> arch/mips/include/uapi/asm/mman.h | 72 --
> arch/parisc/include/ua
On Wed, Sep 11, 2024 at 11:18:12PM GMT, Charlie Jenkins wrote:
> On Wed, Sep 11, 2024 at 07:21:27PM +0100, Catalin Marinas wrote:
> > On Tue, Sep 10, 2024 at 05:45:07PM -0700, Charlie Jenkins wrote:
> > > On Tue, Sep 10, 2024 at 03:08:14PM -0400, Liam R. Howlett wrote:
> > > > * Catalin Marinas [2
(Sorry having issues with my IPv6 setup that duplicated the original email...
On Fri, Sep 06, 2024 at 09:14:08AM GMT, Arnd Bergmann wrote:
> On Fri, Sep 6, 2024, at 08:14, Lorenzo Stoakes wrote:
> > On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote:
> >> On Thu, Sep
On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote:
> On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote:
> > Create a personality flag ADDR_LIMIT_47BIT to support applications
> > that wish to transition from running in environments that support at
> > most 47-bit VAs to environments th
On Fri, Sep 06, 2024 at 07:17:44AM GMT, Arnd Bergmann wrote:
> On Thu, Sep 5, 2024, at 21:15, Charlie Jenkins wrote:
> > Create a personality flag ADDR_LIMIT_47BIT to support applications
> > that wish to transition from running in environments that support at
> > most 47-bit VAs to environments th
On Tue, Sep 03, 2024 at 07:20:02PM GMT, Mark Brown wrote:
> On Tue, Sep 03, 2024 at 06:49:46PM +0100, Lorenzo Stoakes wrote:
> > On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
>
> > > On x86 there is a custom arch_get_unmapped_area() which was updated by the
> &
On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
> As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow
> stack guard gap during placement") our current mmap() implementation does
> not take care to ensure that a new mapping isn't placed with existing
> mappings inside
t; trivially wrapping the generic implementation in the radix_enabled() case.
>
> Signed-off-by: Mark Brown
Acked-by: Lorenzo Stoakes (for mm/mmap.c part)
> ---
> arch/powerpc/mm/book3s64/slice.c | 4 ++--
> include/linux/sched/mm.h | 4 ++--
> mm/mmap.c
_get_unmapped_area(), as for the x86 implementation and the wrapper used
> on other architectures this is modified to supply no flags.
>
> No functional changes.
>
> Signed-off-by: Mark Brown
mm/mmap.c bit looks reasonable to me! Nice cleanup! :)
Acked-by: Lorenzo Stoakes (for mm/mmap.
On Fri, Aug 30, 2024 at 08:03:25AM GMT, Dave Hansen wrote:
> On 8/29/24 01:42, Lorenzo Stoakes wrote:
> >> These applications work on x86 because x86 does an implicit 47-bit
> >> restriction of mmap() address that contain a hint address that is less
> >> than 48 b
On Thu, Aug 29, 2024 at 03:16:53PM GMT, Charlie Jenkins wrote:
> On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote:
> > On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> > > On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > &g
On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 12:15:57AM GMT, Charlie Jenkins wrote:
> > Some applications rely on placing data in free bits addresses allocated
> > by mmap. Various architectures (eg. x86, arm64, powerpc) restrict the
>
iller
> To: Andreas Larsson
> To: Thomas Gleixner
> To: Ingo Molnar
> To: Borislav Petkov
> To: Dave Hansen
> To: x...@kernel.org
> To: H. Peter Anvin
> To: Andy Lutomirski
> To: Peter Zijlstra
> To: Muchun Song
> To: Andrew Morton
> To: Liam R. Howl
On Thu, Aug 29, 2024 at 12:15:59AM GMT, Charlie Jenkins wrote:
[snip]
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d0dfc85b209b..34ba0db23678 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1796,6 +1796,9 @@ generic_get_unmapped_area(struct file *filp, unsigned
> long addr,
> struct vm_un
On Tue, Aug 27, 2024 at 10:49:22PM GMT, Charlie Jenkins wrote:
> Add a selftest for MAP_BELOW_HINT that maps until it runs out of space
> below the hint address.
>
> Signed-off-by: Charlie Jenkins
> ---
> tools/testing/selftests/mm/Makefile | 1 +
> tools/testing/selftests/mm/map_below_h
gt; To: Paul Walmsley
> To: Palmer Dabbelt
> To: Albert Ou
> To: Catalin Marinas
> To: Will Deacon
> To: Michael Ellerman
> To: Nicholas Piggin
> To: Christophe Leroy
> To: Naveen N Rao
> To: Muchun Song
> To: Andrew Morton
> To: Liam R. Howlett
> To: Vlasti
fy_mm(mm, start, end)))
> return -EPERM;
>
> - arch_unmap(mm, start, end);
> return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock);
> }
>
> --
> 2.43.0
>
I hope we can find a way to eliminate these kind of hooks altogether as
they reduce our control over how VMA operations are performed.
LGTM,
Reviewed-by: Lorenzo Stoakes
On Wed, Jul 10, 2024 at 10:28:01PM GMT, Michael Ellerman wrote:
> Lorenzo Stoakes writes:
> > On Mon, Jul 08, 2024 at 04:43:15PM GMT, Liam R. Howlett wrote:
> >>
> ...
> >> The functionality here has changed
> >> --- from ---
> >> may_expand_vm()
On Tue, Oct 17, 2023 at 02:46:07PM +0530, Sachin Sant wrote:
> While running LTP tests (getpid02) on a Power10 server booted with
> 6.6.0-rc6-next-20231016 following crash was seen:
>
> [ 76.386628] Kernel attempted to read user page (d8) - exploit attempt?
> (uid: 0)
> [ 76.386649] BUG: Kerne
t_hugetlb(folio))
> - set_huge_pte_at(mm, address, pvmw.pte,
> pteval);
> + set_huge_pte_at(mm, address, pvmw.pte,
> + pteval, hsz);
> else
> set_pte_at(mm, address, pvmw.pte,
> pteval);
> ret = false;
> @@ -2058,7 +2069,8 @@ static bool try_to_migrate_one(struct folio *folio,
> struct vm_area_struct *vma,
> if (anon_exclusive &&
> page_try_share_anon_rmap(subpage)) {
> if (folio_test_hugetlb(folio))
> - set_huge_pte_at(mm, address, pvmw.pte,
> pteval);
> + set_huge_pte_at(mm, address, pvmw.pte,
> + pteval, hsz);
> else
> set_pte_at(mm, address, pvmw.pte,
> pteval);
> ret = false;
> @@ -2090,7 +2102,8 @@ static bool try_to_migrate_one(struct folio *folio,
> struct vm_area_struct *vma,
> if (pte_uffd_wp(pteval))
> swp_pte = pte_swp_mkuffd_wp(swp_pte);
> if (folio_test_hugetlb(folio))
> - set_huge_pte_at(mm, address, pvmw.pte, swp_pte);
> + set_huge_pte_at(mm, address, pvmw.pte, swp_pte,
> + hsz);
> else
> set_pte_at(mm, address, pvmw.pte, swp_pte);
> trace_set_migration_pte(address, pte_val(swp_pte),
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index ef8599d394fd..a3fedb3ee0db 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -111,7 +111,7 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr,
> unsigned long end,
> pte_t entry = pfn_pte(pfn, prot);
>
> entry = arch_make_huge_pte(entry, ilog2(size), 0);
> - set_huge_pte_at(&init_mm, addr, pte, entry);
> + set_huge_pte_at(&init_mm, addr, pte, entry, size);
> pfn += PFN_DOWN(size);
> continue;
> }
> --
> 2.25.1
>
Looks good to me, vmalloc-wise.
Reviewed-by: Lorenzo Stoakes (for vmalloc change)
qib)
Reviewed-by: Christoph Hellwig
Acked-by: Sakari Ailus (for drivers/media)
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm/book3s64/iommu_api.c | 2 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/infiniband/sw/siw
qib)
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm/book3s64/iommu_api.c | 2 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/infiniband/sw/siw/siw_mem.c| 2 +-
drivers/media/v4l2-core/videobuf-dma-sg.c | 2
qib)
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm/book3s64/iommu_api.c | 2 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/infiniband/sw/siw/siw_mem.c| 2 +-
drivers/media/v4l2-core/videobuf-dma-sg.c | 2
After the introduction of FOLL_SAME_FILE we no longer require vmas for any
invocation of pin_user_pages(), so eliminate this parameter from the
function and all callers.
This clears the way to removing the vmas parameter from GUP altogether.
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm
After the introduction of FOLL_SAME_FILE we no longer require vmas for any
invocation of pin_user_pages(), so eliminate this parameter from the
function and all callers.
This clears the way to removing the vmas parameter from GUP altogether.
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm
After the introduction of FOLL_SAME_FILE we no longer require vmas for any
invocation of pin_user_pages(), so eliminate this parameter from the
function and all callers.
This clears the way to removing the vmas parameter from GUP altogether.
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm
On Fri, Mar 24, 2023 at 05:34:18AM +0800, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 7c4a254d78f89546d0e74a40617ef24c6151c8d1 Add linux-next
> specific files for 20230323
>
> Error/Warning reports:
>
> https
On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> yes this is the desirable and expected behavior.
>
> > wonder if this is desirable behaviour or whether this ought to be limited to
> > ptrace system calls. Regardless, by making the flag more visible it makes it
> > easier to see that
On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> I am wondering whether we can go further. E.g. it is not really clear to
> me whether we need an explicit FOLL_REMOTE when we can in fact check
> mm != current->mm and imply that. Maybe there are some contexts which
> wouldn't work, I
On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > This patch removes the write parameter from __access_remote_vm() and
> > > replaces it
> > >
On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned
> > long nr_pages,
> > int write, int force, struct page **pages,
> > struct vm_area_struct **vmas);
> > long get_u
behaviour
(and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
arch/alpha/kernel/ptrace.c | 9 ++---
arch/blackfin/kernel/ptrace.c | 5 +++--
arch/cris/arch-v32/kernel/ptrace.c | 4 ++--
arch/ia64/kernel/ptrace.c | 14 +-
arch/m32r
behaviour
(and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
fs/proc/base.c | 19 +--
include/linux/mm.h | 2 +-
mm/memory.c| 11 +++
mm/nommu.c | 7 +++
4 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/fs/proc
behaviour
(and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
mm/memory.c | 23 +++
mm/nommu.c | 9 ++---
2 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 20a9adb..79ebed3 100644
--- a/mm/memory.c
+++ b
This patch removes the write and force parameters from get_user_pages_remote()
and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo
This patch removes the write and force parameters from get_user_pages() and
replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit
in callers as use of this flag can result in surprising behaviour (and hence
bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
This patch removes the write and force parameters from get_vaddr_frames() and
replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit
in callers as use of this flag can result in surprising behaviour (and hence
bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
This patch removes the write and force parameters from get_user_pages_locked()
and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo
This patch removes the write and force parameters from get_user_pages_unlocked()
and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo
This patch removes the write and force parameters from
__get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in callers as
use of this flag can result in surprising behaviour (and hence bugs) within the
mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
include/linux/mm.h | 3
This patch removes the write and force parameters from __get_user_pages_locked()
to make the use of FOLL_FORCE explicit in callers as use of this flag can result
in surprising behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes
---
mm/gup.c | 47
where this assumption did not hold.
See https://marc.info/?l=linux-mm&m=147585445805166 for the patch proposal.
Lorenzo Stoakes (10):
mm: remove write/force parameters from __get_user_pages_locked()
mm: remove write/force parameters from __get_user_pages_unlocked()
mm: rep
48 matches
Mail list logo
