linux-toradex.git/arch/x86/kernel/ldt.c, branch v5.18

memcg: enable accounting for ldt_struct objects

2021-09-03T16:58:13+00:00

Each task can request own LDT and force the kernel to allocate up to 64Kb
memory per-mm.

There are legitimate workloads with hundreds of processes and there can be
hundreds of workloads running on large machines.  The unaccounted memory
can cause isolation issues between the workloads particularly on highly
utilized machines.

It makes sense to account for this objects to restrict the host's memory
consumption from inside the memcg-limited container.

Link: https://lkml.kernel.org/r/38010594-50fe-c06d-7cb0-d1f77ca422f3@virtuozzo.com
Signed-off-by: Vasily Averin 
Acked-by: Borislav Petkov 
Reviewed-by: Shakeel Butt 
Cc: Alexander Viro 
Cc: Alexey Dobriyan 
Cc: Andrei Vagin 
Cc: Borislav Petkov 
Cc: Christian Brauner 
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: "Eric W. Biederman" 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: "J. Bruce Fields" 
Cc: Jeff Layton 
Cc: Jens Axboe 
Cc: Jiri Slaby 
Cc: Johannes Weiner 
Cc: Kirill Tkhai 
Cc: Michal Hocko 
Cc: Oleg Nesterov 
Cc: Roman Gushchin 
Cc: Serge Hallyn 
Cc: Tejun Heo 
Cc: Thomas Gleixner 
Cc: Vladimir Davydov 
Cc: Yutian Yang 
Cc: Zefan Li 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/ldt: Use tlb_gather_mmu_fullmm() when freeing LDT page-tables

2021-01-29T19:02:29+00:00

free_ldt_pgtables() uses the MMU gather API for batching TLB flushes
over the call to free_pgd_range(). However, tlb_gather_mmu() expects
to operate on user addresses and so passing LDT_{BASE,END}_ADDR will
confuse the range setting logic in __tlb_adjust_range(), causing the
gather to identify a range starting at TASK_SIZE. Such a large range
will be converted into a 'fullmm' flush by the low-level invalidation
code, so change the caller to invoke tlb_gather_mmu_fullmm() directly.

Signed-off-by: Will Deacon 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Yu Zhao 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Linus Torvalds 
Link: https://lkml.kernel.org/r/20210127235347.1402-7-will@kernel.org

tlb: mmu_gather: Remove start/end arguments from tlb_gather_mmu()

2021-01-29T19:02:29+00:00

The 'start' and 'end' arguments to tlb_gather_mmu() are no longer
needed now that there is a separate function for 'fullmm' flushing.

Remove the unused arguments and update all callers.

Suggested-by: Linus Torvalds 
Signed-off-by: Will Deacon 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Yu Zhao 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Linus Torvalds 
Link: https://lore.kernel.org/r/CAHk-=wjQWa14_4UpfDf=fiineNP+RH74kZeDMo_f1D35xNzq9w@mail.gmail.com

tlb: mmu_gather: Remove unused start/end arguments from tlb_finish_mmu()

2021-01-29T19:02:28+00:00

Since commit 7a30df49f63a ("mm: mmu_gather: remove __tlb_reset_range()
for force flush"), the 'start' and 'end' arguments to tlb_finish_mmu()
are no longer used, since we flush the whole mm in case of a nested
invalidation.

Remove the unused arguments and update all callers.

Signed-off-by: Will Deacon 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Yu Zhao 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Linus Torvalds 
Link: https://lkml.kernel.org/r/20210127235347.1402-3-will@kernel.org

x86/ldt: use "pr_info_once()" instead of open-coding it badly

2020-07-05T19:50:20+00:00

Using a mutex for "print this warning only once" is so overdesigned as
to be actively offensive to my sensitive stomach.

Just use "pr_info_once()" that already does this, although in a
(harmlessly) racy manner that can in theory cause the message to be
printed twice if more than one CPU races on that "is this the first
time" test.

[ If somebody really cares about that harmless data race (which sounds
  very unlikely indeed), that person can trivially fix printk_once() by
  using a simple atomic access, preferably with an optimistic non-atomic
  test first before even bothering to treat the pointless "make sure it
  is _really_ just once" case.

  A mutex is most definitely never the right primitive to use for
  something like this. ]

Yes, this is a small and meaningless detail in a code path that hardly
matters.  But let's keep some code quality standards here, and not
accept outrageously bad code.

Link: https://lore.kernel.org/lkml/CAHk-=wgV9toS7GU3KmNpj8hCS9SeF+A0voHS8F275_mgLhL4Lw@mail.gmail.com/
Cc: Andy Lutomirski 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra (Intel) 
Signed-off-by: Linus Torvalds

x86/ldt: Disable 16-bit segments on Xen PV

2020-07-04T17:47:26+00:00

Xen PV doesn't implement ESPFIX64, so they don't work right.  Disable
them.  Also print a warning the first time anyone tries to use a
16-bit segment on a Xen PV guest that would otherwise allow it
to help people diagnose this change in behavior.

This gets us closer to having all x86 selftests pass on Xen PV.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/92b2975459dfe5929ecf34c3896ad920bd9e3f2d.1593795633.git.luto@kernel.org

mmap locking API: convert mmap_sem comments

2020-06-09T16:39:14+00:00

Convert comments that reference mmap_sem to reference mmap_lock instead.

[akpm@linux-foundation.org: fix up linux-next leftovers]
[akpm@linux-foundation.org: s/lockaphore/lock/, per Vlastimil]
[akpm@linux-foundation.org: more linux-next fixups, per Michel]

Signed-off-by: Michel Lespinasse 
Signed-off-by: Andrew Morton 
Reviewed-by: Vlastimil Babka 
Reviewed-by: Daniel Jordan 
Cc: Davidlohr Bueso 
Cc: David Rientjes 
Cc: Hugh Dickins 
Cc: Jason Gunthorpe 
Cc: Jerome Glisse 
Cc: John Hubbard 
Cc: Laurent Dufour 
Cc: Liam Howlett 
Cc: Matthew Wilcox 
Cc: Peter Zijlstra 
Cc: Ying Han 
Link: http://lkml.kernel.org/r/20200520052908.204642-13-walken@google.com
Signed-off-by: Linus Torvalds

x86: Remove unneeded includes

2020-03-21T15:03:25+00:00

Clean up includes of and in 

Signed-off-by: Brian Gerst 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20200313195144.164260-19-brgerst@gmail.com

mm, x86/mm: Untangle address space layout definitions from basic pgtable type definitions

2019-12-10T09:12:55+00:00

- Untangle the somewhat incestous way of how VMALLOC_START is used all across the
  kernel, but is, on x86, defined deep inside one of the lowest level page table headers.
  It doesn't help that vmalloc.h only includes a single asm header:

     #include            /* pgprot_t */

  So there was no existing cross-arch way to decouple address layout
  definitions from page.h details. I used this:

   #ifndef VMALLOC_START
   # include 
   #endif

  This way every architecture that wants to simplify page.h can do so.

- Also on x86 we had a couple of LDT related inline functions that used
  the late-stage address space layout positions - but these could be
  uninlined without real trouble - the end result is cleaner this way as
  well.

Signed-off-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Rik van Riel 
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Signed-off-by: Ingo Molnar

x86: Convert some slow-path static_cpu_has() callers to boot_cpu_has()

2019-04-08T10:13:34+00:00

Using static_cpu_has() is pointless on those paths, convert them to the
boot_cpu_has() variant.

No functional changes.

Reported-by: Nadav Amit 
Signed-off-by: Borislav Petkov 
Reviewed-by: Rik van Riel 
Reviewed-by: Juergen Gross  # for paravirt
Cc: Aubrey Li 
Cc: Dave Hansen 
Cc: Dominik Brodowski 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jann Horn 
Cc: Joerg Roedel 
Cc: "Kirill A. Shutemov" 
Cc: Konrad Rzeszutek Wilk 
Cc: Thomas Lendacky 
Cc: linux-edac@vger.kernel.org
Cc: Masami Hiramatsu 
Cc: Peter Zijlstra 
Cc: "Rafael J. Wysocki" 
Cc: Sebastian Andrzej Siewior 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: virtualization@lists.linux-foundation.org
Cc: x86@kernel.org
Link: https://lkml.kernel.org/r/20190330112022.28888-3-bp@alien8.de