1. 01 5月, 2021 1 次提交
  2. 25 2月, 2021 1 次提交
  3. 30 1月, 2021 3 次提交
  4. 16 12月, 2020 3 次提交
    • D
      mm: forbid splitting special mappings · 871402e0
      Dmitry Safonov 提交于
      Don't allow splitting of vm_special_mapping's.  It affects vdso/vvar
      areas.  Uprobes have only one page in xol_area so they aren't affected.
      
      Those restrictions were enforced by checks in .mremap() callbacks.
      Restrict resizing with generic .split() callback.
      
      Link: https://lkml.kernel.org/r/20201013013416.390574-7-dima@arista.comSigned-off-by: NDmitry Safonov <dima@arista.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Brian Geffon <bgeffon@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      871402e0
    • D
      vm_ops: rename .split() callback to .may_split() · dd3b614f
      Dmitry Safonov 提交于
      Rename the callback to reflect that it's not called *on* or *after* split,
      but rather some time before the splitting to check if it's possible.
      
      Link: https://lkml.kernel.org/r/20201013013416.390574-5-dima@arista.comSigned-off-by: NDmitry Safonov <dima@arista.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Brian Geffon <bgeffon@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd3b614f
    • D
      mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio · cd544fd1
      Dmitry Safonov 提交于
      As kernel expect to see only one of such mappings, any further operations
      on the VMA-copy may be unexpected by the kernel.  Maybe it's being on the
      safe side, but there doesn't seem to be any expected use-case for this, so
      restrict it now.
      
      Link: https://lkml.kernel.org/r/20201013013416.390574-4-dima@arista.com
      Fixes: commit e346b381 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()")
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Brian Geffon <bgeffon@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Ralph Campbell <rcampbell@nvidia.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vishal Verma <vishal.l.verma@intel.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Will Deacon <will@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd544fd1
  5. 07 12月, 2020 1 次提交
  6. 19 11月, 2020 1 次提交
  7. 06 11月, 2020 2 次提交
  8. 05 11月, 2020 2 次提交
  9. 19 10月, 2020 2 次提交
  10. 17 10月, 2020 2 次提交
  11. 14 10月, 2020 8 次提交
  12. 12 10月, 2020 1 次提交
    • M
      mm: mmap: Fix general protection fault in unlink_file_vma() · bc4fe4cd
      Miaohe Lin 提交于
      The syzbot reported the below general protection fault:
      
        general protection fault, probably for non-canonical address
        0xe00eeaee0000003b: 0000 [#1] PREEMPT SMP KASAN
        KASAN: maybe wild-memory-access in range [0x00777770000001d8-0x00777770000001df]
        CPU: 1 PID: 10488 Comm: syz-executor721 Not tainted 5.9.0-rc3-syzkaller #0
        RIP: 0010:unlink_file_vma+0x57/0xb0 mm/mmap.c:164
        Call Trace:
           free_pgtables+0x1b3/0x2f0 mm/memory.c:415
           exit_mmap+0x2c0/0x530 mm/mmap.c:3184
           __mmput+0x122/0x470 kernel/fork.c:1076
           mmput+0x53/0x60 kernel/fork.c:1097
           exit_mm kernel/exit.c:483 [inline]
           do_exit+0xa8b/0x29f0 kernel/exit.c:793
           do_group_exit+0x125/0x310 kernel/exit.c:903
           get_signal+0x428/0x1f00 kernel/signal.c:2757
           arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811
           exit_to_user_mode_loop kernel/entry/common.c:136 [inline]
           exit_to_user_mode_prepare+0x1ae/0x200 kernel/entry/common.c:167
           syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:242
           entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      It's because the ->mmap() callback can change vma->vm_file and fput the
      original file.  But the commit d70cec89 ("mm: mmap: merge vma after
      call_mmap() if possible") failed to catch this case and always fput()
      the original file, hence add an extra fput().
      
      [ Thanks Hillf for pointing this extra fput() out. ]
      
      Fixes: d70cec89 ("mm: mmap: merge vma after call_mmap() if possible")
      Reported-by: syzbot+c5d5a51dcbb558ca0cb5@syzkaller.appspotmail.com
      Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Christian König <ckoenig.leichtzumerken@gmail.com>
      Cc: Hongxiang Lou <louhongxiang@huawei.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
      Cc: John Hubbard <jhubbard@nvidia.com>
      Link: https://lkml.kernel.org/r/20200916090733.31427-1-linmiaohe@huawei.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bc4fe4cd
  13. 25 9月, 2020 1 次提交
  14. 04 9月, 2020 1 次提交
  15. 08 8月, 2020 3 次提交
  16. 25 7月, 2020 1 次提交
  17. 30 6月, 2020 1 次提交
    • P
      mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls · 0a3b3c25
      Paul E. McKenney 提交于
      A large process running on a heavily loaded system can encounter the
      following RCU CPU stall warning:
      
        rcu: INFO: rcu_sched self-detected stall on CPU
        rcu: 	3-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190
        	(t=21013 jiffies g=1005461 q=132576)
        NMI backtrace for cpu 3
        CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1
        Hardware name: Wiwynn   HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016
        Call Trace:
         <IRQ>
         dump_stack+0x46/0x60
         nmi_cpu_backtrace.cold.3+0x13/0x50
         ? lapic_can_unplug_cpu.cold.27+0x34/0x34
         nmi_trigger_cpumask_backtrace+0xba/0xca
         rcu_dump_cpu_stacks+0x99/0xc7
         rcu_sched_clock_irq.cold.87+0x1aa/0x397
         ? tick_sched_do_timer+0x60/0x60
         update_process_times+0x28/0x60
         tick_sched_timer+0x37/0x70
         __hrtimer_run_queues+0xfe/0x270
         hrtimer_interrupt+0xf4/0x210
         smp_apic_timer_interrupt+0x5e/0x120
         apic_timer_interrupt+0xf/0x20
         </IRQ>
        RIP: 0010:kmem_cache_free+0x223/0x300
        Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65
        RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
        RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030
        RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18
        RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff
        R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f
        R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00
         ? remove_vma+0x4f/0x60
         remove_vma+0x4f/0x60
         exit_mmap+0xd6/0x160
         mmput+0x4a/0x110
         do_exit+0x278/0xae0
         ? syscall_trace_enter+0x1d3/0x2b0
         ? handle_mm_fault+0xaa/0x1c0
         do_group_exit+0x3a/0xa0
         __x64_sys_exit_group+0x14/0x20
         do_syscall_64+0x42/0x100
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run
      for a very long time given a large process.  This commit therefore adds
      a cond_resched() to this loop, providing RCU any needed quiescent states.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: <linux-mm@kvack.org>
      Reviewed-by: NShakeel Butt <shakeelb@google.com>
      Reviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
      0a3b3c25
  18. 10 6月, 2020 4 次提交
  19. 05 6月, 2020 1 次提交
  20. 11 4月, 2020 1 次提交
    • A
      mm/vma: introduce VM_ACCESS_FLAGS · 6cb4d9a2
      Anshuman Khandual 提交于
      There are many places where all basic VMA access flags (read, write,
      exec) are initialized or checked against as a group.  One such example
      is during page fault.  Existing vma_is_accessible() wrapper already
      creates the notion of VMA accessibility as a group access permissions.
      
      Hence lets just create VM_ACCESS_FLAGS (VM_READ|VM_WRITE|VM_EXEC) which
      will not only reduce code duplication but also extend the VMA
      accessibility concept in general.
      Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Reviewed-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Ley Foon Tan <ley.foon.tan@intel.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Rob Springer <rspringer@google.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Link: http://lkml.kernel.org/r/1583391014-8170-3-git-send-email-anshuman.khandual@arm.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6cb4d9a2
新手
引导
客服 返回
顶部