1. 27 Jul, 2022 7 commits
    • Leo Yan's avatar
      perf symbol: Skip symbols if SHF_ALLOC flag is not set · 882528d2
      Leo Yan authored
      Some symbols are observed with the 'st_value' field zeroed.  E.g.
      libc.so.6 in Ubuntu contains a symbol '__evoke_link_warning_getwd' which
      resides in the '.gnu.warning.getwd' section.
      
      Unlike normal sections, such kind of sections are used for linker
      warning when a file calls deprecated functions, but they are not part of
      memory images, the symbols in these sections should be dropped.
      
      This patch checks the section attribute SHF_ALLOC bit, if the bit is not
      set, it skips symbols to avoid spurious ones.
      Suggested-by: default avatarFangrui Song <maskray@google.com>
      Signed-off-by: default avatarLeo Yan <leo.yan@linaro.org>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chang Rui <changruinj@gmail.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20220724060013.171050-3-leo.yan@linaro.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      882528d2
    • Leo Yan's avatar
      perf symbol: Correct address for bss symbols · 2d86612a
      Leo Yan authored
      When using 'perf mem' and 'perf c2c', an issue is observed that tool
      reports the wrong offset for global data symbols.  This is a common
      issue on both x86 and Arm64 platforms.
      
      Let's see an example, for a test program, below is the disassembly for
      its .bss section which is dumped with objdump:
      
        ...
      
        Disassembly of section .bss:
      
        0000000000004040 <completed.0>:
        	...
      
        0000000000004080 <buf1>:
        	...
      
        00000000000040c0 <buf2>:
        	...
      
        0000000000004100 <thread>:
        	...
      
      First we used 'perf mem record' to run the test program and then used
      'perf --debug verbose=4 mem report' to observe what's the symbol info
      for 'buf1' and 'buf2' structures.
      
        # ./perf mem record -e ldlat-loads,ldlat-stores -- false_sharing.exe 8
        # ./perf --debug verbose=4 mem report
          ...
          dso__load_sym_internal: adjusting symbol: st_value: 0x40c0 sh_addr: 0x4040 sh_offset: 0x3028
          symbol__new: buf2 0x30a8-0x30e8
          ...
          dso__load_sym_internal: adjusting symbol: st_value: 0x4080 sh_addr: 0x4040 sh_offset: 0x3028
          symbol__new: buf1 0x3068-0x30a8
          ...
      
      The perf tool relies on libelf to parse symbols, in executable and
      shared object files, 'st_value' holds a virtual address; 'sh_addr' is
      the address at which section's first byte should reside in memory, and
      'sh_offset' is the byte offset from the beginning of the file to the
      first byte in the section.  The perf tool uses below formula to convert
      a symbol's memory address to a file address:
      
        file_address = st_value - sh_addr + sh_offset
                          ^
                          ` Memory address
      
      We can see the final adjusted address ranges for buf1 and buf2 are
      [0x30a8-0x30e8) and [0x3068-0x30a8) respectively, apparently this is
      incorrect, in the code, the structure for 'buf1' and 'buf2' specifies
      compiler attribute with 64-byte alignment.
      
      The problem happens for 'sh_offset', libelf returns it as 0x3028 which
      is not 64-byte aligned, combining with disassembly, it's likely libelf
      doesn't respect the alignment for .bss section, therefore, it doesn't
      return the aligned value for 'sh_offset'.
      
      Suggested by Fangrui Song, ELF file contains program header which
      contains PT_LOAD segments, the fields p_vaddr and p_offset in PT_LOAD
      segments contain the execution info.  A better choice for converting
      memory address to file address is using the formula:
      
        file_address = st_value - p_vaddr + p_offset
      
      This patch introduces elf_read_program_header() which returns the
      program header based on the passed 'st_value', then it uses the formula
      above to calculate the symbol file address; and the debugging log is
      updated respectively.
      
      After applying the change:
      
        # ./perf --debug verbose=4 mem report
          ...
          dso__load_sym_internal: adjusting symbol: st_value: 0x40c0 p_vaddr: 0x3d28 p_offset: 0x2d28
          symbol__new: buf2 0x30c0-0x3100
          ...
          dso__load_sym_internal: adjusting symbol: st_value: 0x4080 p_vaddr: 0x3d28 p_offset: 0x2d28
          symbol__new: buf1 0x3080-0x30c0
          ...
      
      Fixes: f17e04af ("perf report: Fix ELF symbol parsing")
      Reported-by: default avatarChang Rui <changruinj@gmail.com>
      Suggested-by: default avatarFangrui Song <maskray@google.com>
      Signed-off-by: default avatarLeo Yan <leo.yan@linaro.org>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20220724060013.171050-2-leo.yan@linaro.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2d86612a
    • Leo Yan's avatar
      perf scripts python: Let script to be python2 compliant · b2265219
      Leo Yan authored
      The mainline kernel can be used for relative old distros, e.g. RHEL 7.
      The distro doesn't upgrade from python2 to python3, this causes the
      building error that the python script is not python2 compliant.
      
      To fix the building failure, this patch changes from the python f-string
      format to traditional string format.
      
      Fixes: 12fdd6c0 ("perf scripts python: Support Arm CoreSight trace data disassembly")
      Reported-by: default avatarAkemi Yagi <toracat@elrepo.org>
      Signed-off-by: default avatarLeo Yan <leo.yan@linaro.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: ElRepo <contact@elrepo.org>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20220725104220.1106663-1-leo.yan@linaro.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b2265219
    • Arnaldo Carvalho de Melo's avatar
      tools headers cpufeatures: Sync with the kernel sources · 553de6e1
      Arnaldo Carvalho de Melo authored
      To pick the changes from:
      
        28a99e95 ("x86/amd: Use IBPB for firmware calls")
      
      This only causes these perf files to be rebuilt:
      
        CC       /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
        CC       /tmp/build/perf/bench/mem-memset-x86-64-asm.o
      
      And addresses this perf build warning:
      
        Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
        diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org
      Link: https://lore.kernel.org/lkml/Yt6oWce9UDAmBAtX@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      553de6e1
    • Linus Torvalds's avatar
      Merge tag 'mm-hotfixes-stable-2022-07-26' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm · 39c3c396
      Linus Torvalds authored
      Pull misc fixes from Andrew Morton:
       "Thirteen hotfixes.
      
        Eight are cc:stable and the remainder are for post-5.18 issues or are
        too minor to warrant backporting"
      
      * tag 'mm-hotfixes-stable-2022-07-26' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
        mailmap: update Gao Xiang's email addresses
        userfaultfd: provide properly masked address for huge-pages
        Revert "ocfs2: mount shared volume without ha stack"
        hugetlb: fix memoryleak in hugetlb_mcopy_atomic_pte
        fs: sendfile handles O_NONBLOCK of out_fd
        ntfs: fix use-after-free in ntfs_ucsncmp()
        secretmem: fix unhandled fault in truncate
        mm/hugetlb: separate path for hwpoison entry in copy_hugetlb_page_range()
        mm: fix missing wake-up event for FSDAX pages
        mm: fix page leak with multiple threads mapping the same page
        mailmap: update Seth Forshee's email address
        tmpfs: fix the issue that the mount and remount results are inconsistent.
        mm: kfence: apply kmemleak_ignore_phys on early allocated pool
      39c3c396
    • Gao Xiang's avatar
      mailmap: update Gao Xiang's email addresses · 1f7ea547
      Gao Xiang authored
      I've been in Alibaba Cloud for more than one year, mainly to address
      cloud-native challenges (such as high-performance container images) for
      open source communities.
      
      Update my email addresses on behalf of my current employer (Alibaba Cloud)
      to support all my (team) work in this area.  Also add an outdated
      @redhat.com address of me.
      
      Link: https://lkml.kernel.org/r/20220719154246.62970-1-xiang@kernel.orgSigned-off-by: default avatarGao Xiang <xiang@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      1f7ea547
    • Nadav Amit's avatar
      userfaultfd: provide properly masked address for huge-pages · d172b1a3
      Nadav Amit authored
      Commit 824ddc60 ("userfaultfd: provide unmasked address on
      page-fault") was introduced to fix an old bug, in which the offset in the
      address of a page-fault was masked.  Concerns were raised - although were
      never backed by actual code - that some userspace code might break because
      the bug has been around for quite a while.  To address these concerns a
      new flag was introduced, and only when this flag is set by the user,
      userfaultfd provides the exact address of the page-fault.
      
      The commit however had a bug, and if the flag is unset, the offset was
      always masked based on a base-page granularity.  Yet, for huge-pages, the
      behavior prior to the commit was that the address is masked to the
      huge-page granulrity.
      
      While there are no reports on real breakage, fix this issue.  If the flag
      is unset, use the address with the masking that was done before.
      
      Link: https://lkml.kernel.org/r/20220711165906.2682-1-namit@vmware.com
      Fixes: 824ddc60 ("userfaultfd: provide unmasked address on page-fault")
      Signed-off-by: default avatarNadav Amit <namit@vmware.com>
      Reported-by: default avatarJames Houghton <jthoughton@google.com>
      Reviewed-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Reviewed-by: default avatarJames Houghton <jthoughton@google.com>
      Cc: David Hildenbrand <david@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      d172b1a3
  2. 26 Jul, 2022 2 commits
  3. 24 Jul, 2022 6 commits
  4. 23 Jul, 2022 2 commits
  5. 22 Jul, 2022 15 commits
  6. 21 Jul, 2022 8 commits
    • Ben Dooks's avatar
      riscv: add as-options for modules with assembly compontents · c1f6eff3
      Ben Dooks authored
      When trying to load modules built for RISC-V which include assembly files
      the kernel loader errors with "unexpected relocation type 'R_RISCV_ALIGN'"
      due to R_RISCV_ALIGN relocations being generated by the assembler.
      
      The R_RISCV_ALIGN relocations can be removed at the expense of code space
      by adding -mno-relax to gcc and as.  In commit 7a8e7da4
      ("RISC-V: Fixes to module loading") -mno-relax is added to the build
      variable KBUILD_CFLAGS_MODULE. See [1] for more info.
      
      The issue is that when kbuild builds a .S file, it invokes gcc with
      the -mno-relax flag, but this is not being passed through to the
      assembler. Adding -Wa,-mno-relax to KBUILD_AFLAGS_MODULE ensures that
      the assembler is invoked correctly. This may have now been fixed in
      gcc[2] and this addition should not stop newer gcc and as from working.
      
      [1] https://github.com/riscv/riscv-elf-psabi-doc/issues/183
      [2] https://github.com/gcc-mirror/gcc/commit/3b0a7d624e64eeb81e4d5e8c62c46d86ef521857Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Reviewed-by: default avatarBin Meng <bmeng.cn@gmail.com>
      Link: https://lore.kernel.org/r/20220529152200.609809-1-ben.dooks@codethink.co.uk
      Fixes: ab1ef68e ("RISC-V: Add sections of PLT and GOT for kernel module")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      c1f6eff3
    • Linus Torvalds's avatar
      Merge tag 'mtd/fixes-for-5.19-final' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux · 68e77ffb
      Linus Torvalds authored
      Pull MTD fix from Richard Weinberger:
       "A aingle NAND controller fix:
      
         - gpmi: Fix busy timeout setting (wrong calculation, yes again)"
      
      * tag 'mtd/fixes-for-5.19-final' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
        mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times
      68e77ffb
    • Linus Torvalds's avatar
      Merge tag 'net-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 7ca433dc
      Linus Torvalds authored
      Pull networking fixes from Paolo Abeni:
       "Including fixes from can.
      
        Still no major regressions, most of the changes are still due to data
        races fixes, plus the usual bunch of drivers fixes.
      
        Previous releases - regressions:
      
         - tcp/udp: make early_demux back namespacified.
      
         - dsa: fix issues with vlan_filtering_is_global
      
        Previous releases - always broken:
      
         - ip: fix data-races around ipv4_net_table (round 2, 3 & 4)
      
         - amt: fix validation and synchronization bugs
      
         - can: fix detection of mcp251863
      
         - eth: iavf: fix handling of dummy receive descriptors
      
         - eth: lan966x: fix issues with MAC table
      
         - eth: stmmac: dwmac-mediatek: fix clock issue
      
        Misc:
      
         - dsa: update documentation"
      
      * tag 'net-5.19-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (107 commits)
        mlxsw: spectrum_router: Fix IPv4 nexthop gateway indication
        net/sched: cls_api: Fix flow action initialization
        tcp: Fix data-races around sysctl_tcp_max_reordering.
        tcp: Fix a data-race around sysctl_tcp_abort_on_overflow.
        tcp: Fix a data-race around sysctl_tcp_rfc1337.
        tcp: Fix a data-race around sysctl_tcp_stdurg.
        tcp: Fix a data-race around sysctl_tcp_retrans_collapse.
        tcp: Fix data-races around sysctl_tcp_slow_start_after_idle.
        tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts.
        tcp: Fix data-races around sysctl_tcp_recovery.
        tcp: Fix a data-race around sysctl_tcp_early_retrans.
        tcp: Fix data-races around sysctl knobs related to SYN option.
        udp: Fix a data-race around sysctl_udp_l3mdev_accept.
        ip: Fix data-races around sysctl_ip_prot_sock.
        ipv4: Fix data-races around sysctl_fib_multipath_hash_fields.
        ipv4: Fix data-races around sysctl_fib_multipath_hash_policy.
        ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh.
        can: rcar_canfd: Add missing of_node_put() in rcar_canfd_probe()
        can: mcp251xfd: fix detection of mcp251863
        Documentation: fix udp_wmem_min in ip-sysctl.rst
        ...
      7ca433dc
    • Harald Freudenberger's avatar
      s390/archrandom: prevent CPACF trng invocations in interrupt context · 918e75f7
      Harald Freudenberger authored
      This patch slightly reworks the s390 arch_get_random_seed_{int,long}
      implementation: Make sure the CPACF trng instruction is never
      called in any interrupt context. This is done by adding an
      additional condition in_task().
      
      Justification:
      
      There are some constrains to satisfy for the invocation of the
      arch_get_random_seed_{int,long}() functions:
      - They should provide good random data during kernel initialization.
      - They should not be called in interrupt context as the TRNG
        instruction is relatively heavy weight and may for example
        make some network loads cause to timeout and buck.
      
      However, it was not clear what kind of interrupt context is exactly
      encountered during kernel init or network traffic eventually calling
      arch_get_random_seed_long().
      
      After some days of investigations it is clear that the s390
      start_kernel function is not running in any interrupt context and
      so the trng is called:
      
      Jul 11 18:33:39 t35lp54 kernel:  [<00000001064e90ca>] arch_get_random_seed_long.part.0+0x32/0x70
      Jul 11 18:33:39 t35lp54 kernel:  [<000000010715f246>] random_init+0xf6/0x238
      Jul 11 18:33:39 t35lp54 kernel:  [<000000010712545c>] start_kernel+0x4a4/0x628
      Jul 11 18:33:39 t35lp54 kernel:  [<000000010590402a>] startup_continue+0x2a/0x40
      
      The condition in_task() is true and the CPACF trng provides random data
      during kernel startup.
      
      The network traffic however, is more difficult. A typical call stack
      looks like this:
      
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b5600fc>] extract_entropy.constprop.0+0x23c/0x240
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b560136>] crng_reseed+0x36/0xd8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b5604b8>] crng_make_state+0x78/0x340
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b5607e0>] _get_random_bytes+0x60/0xf8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b56108a>] get_random_u32+0xda/0x248
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008aefe7a8>] kfence_guarded_alloc+0x48/0x4b8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008aeff35e>] __kfence_alloc+0x18e/0x1b8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008aef7f10>] __kmalloc_node_track_caller+0x368/0x4d8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b611eac>] kmalloc_reserve+0x44/0xa0
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b611f98>] __alloc_skb+0x90/0x178
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b6120dc>] __napi_alloc_skb+0x5c/0x118
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b8f06b4>] qeth_extract_skb+0x13c/0x680
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b8f6526>] qeth_poll+0x256/0x3f8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b63d76e>] __napi_poll.constprop.0+0x46/0x2f8
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b63dbec>] net_rx_action+0x1cc/0x408
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b937302>] __do_softirq+0x132/0x6b0
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008abf46ce>] __irq_exit_rcu+0x13e/0x170
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008abf531a>] irq_exit_rcu+0x22/0x50
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b922506>] do_io_irq+0xe6/0x198
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b935826>] io_int_handler+0xd6/0x110
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b9358a6>] psw_idle_exit+0x0/0xa
      Jul 06 17:37:07 t35lp54 kernel: ([<000000008ab9c59a>] arch_cpu_idle+0x52/0xe0)
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b933cfe>] default_idle_call+0x6e/0xd0
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008ac59f4e>] do_idle+0xf6/0x1b0
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008ac5a28e>] cpu_startup_entry+0x36/0x40
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008abb0d90>] smp_start_secondary+0x148/0x158
      Jul 06 17:37:07 t35lp54 kernel:  [<000000008b935b9e>] restart_int_handler+0x6e/0x90
      
      which confirms that the call is in softirq context. So in_task() covers exactly
      the cases where we want to have CPACF trng called: not in nmi, not in hard irq,
      not in soft irq but in normal task context and during kernel init.
      Signed-off-by: default avatarHarald Freudenberger <freude@linux.ibm.com>
      Acked-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: default avatarJuergen Christ <jchrist@linux.ibm.com>
      Link: https://lore.kernel.org/r/20220713131721.257907-1-freude@linux.ibm.com
      Fixes: e4f74400 ("s390/archrandom: simplify back to earlier design and initialize earlier")
      [agordeev@linux.ibm.com changed desc, added Fixes and Link, removed -stable]
      Signed-off-by: default avatarAlexander Gordeev <agordeev@linux.ibm.com>
      918e75f7
    • Peter Zijlstra's avatar
      mmu_gather: Force tlb-flush VM_PFNMAP vmas · b67fbebd
      Peter Zijlstra authored
      Jann reported a race between munmap() and unmap_mapping_range(), where
      unmap_mapping_range() will no-op once unmap_vmas() has unlinked the
      VMA; however munmap() will not yet have invalidated the TLBs.
      
      Therefore unmap_mapping_range() will complete while there are still
      (stale) TLB entries for the specified range.
      
      Mitigate this by force flushing TLBs for VM_PFNMAP ranges.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b67fbebd
    • Peter Zijlstra's avatar
      mmu_gather: Let there be one tlb_{start,end}_vma() implementation · 18ba064e
      Peter Zijlstra authored
      Now that architectures are no longer allowed to override
      tlb_{start,end}_vma() re-arrange code so that there is only one
      implementation for each of these functions.
      
      This much simplifies trying to figure out what they actually do.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      18ba064e
    • Peter Zijlstra's avatar
      csky/tlb: Remove tlb_flush() define · 1d7708e7
      Peter Zijlstra authored
      The previous patch removed the tlb_flush_end() implementation which
      used tlb_flush_range(). This means:
      
       - csky did double invalidates, a range invalidate per vma and a full
         invalidate at the end
      
       - csky actually has range invalidates and as such the generic
         tlb_flush implementation is more efficient for it.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Tested-by: default avatarGuo Ren <guoren@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1d7708e7
    • Peter Zijlstra's avatar
      mmu_gather: Remove per arch tlb_{start,end}_vma() · 1e9fdf21
      Peter Zijlstra authored
      Scattered across the archs are 3 basic forms of tlb_{start,end}_vma().
      Provide two new MMU_GATHER_knobs to enumerate them and remove the per
      arch tlb_{start,end}_vma() implementations.
      
       - MMU_GATHER_NO_FLUSH_CACHE indicates the arch has flush_cache_range()
         but does *NOT* want to call it for each VMA.
      
       - MMU_GATHER_MERGE_VMAS indicates the arch wants to merge the
         invalidate across multiple VMAs if possible.
      
      With these it is possible to capture the three forms:
      
        1) empty stubs;
           select MMU_GATHER_NO_FLUSH_CACHE and MMU_GATHER_MERGE_VMAS
      
        2) start: flush_cache_range(), end: empty;
           select MMU_GATHER_MERGE_VMAS
      
        3) start: flush_cache_range(), end: flush_tlb_range();
           default
      
      Obviously, if the architecture does not have flush_cache_range() then
      it also doesn't need to select MMU_GATHER_NO_FLUSH_CACHE.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Cc: David Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1e9fdf21