Commit graph

1029903 commits

Author SHA1 Message Date
Xiaoliang Yang
81c52c42af net: stmmac: separate the tas basetime calculation function
Separate the TAS basetime calculation function so that it can be
called by other functions.

Signed-off-by: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-05 10:16:17 -07:00
Yangbo Lu
f6a175cfcc ptp: fix format string mismatch in ptp_sysfs.c
Fix format string mismatch in ptp_sysfs.c. Use %u for unsigned int.

Fixes: 73f37068d5 ("ptp: support ptp physical/virtual clocks conversion")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-05 10:10:41 -07:00
Yangbo Lu
55eac20617 ptp: fix NULL pointer dereference in ptp_clock_register
Fix NULL pointer dereference in ptp_clock_register. The argument
"parent" of ptp_clock_register may be NULL pointer.

Fixes: 73f37068d5 ("ptp: support ptp physical/virtual clocks conversion")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-07-05 10:09:29 -07:00
Stephen Boyd
40ba55e40d PM: domains: Shrink locking area of the gpd_list_lock
On trogdor devices I see the following lockdep splat when stopping
youtube with lockdep enabled in the kernel.

 ======================================================
 WARNING: possible circular locking dependency detected
 5.13.0-rc2 #71 Not tainted
 ------------------------------------------------------
 ThreadPoolSingl/3969 is trying to acquire lock:
 ffffff80d4d5c080 (&inst->lock#3){+.+.}-{3:3}, at: vdec_buf_cleanup+0x3c/0x17c [venus_dec]

 but task is already holding lock:
 ffffff80d3c3c4f8 (&q->mmap_lock){+.+.}-{3:3}, at: vb2_core_reqbufs+0xe4/0x390 [videobuf2_common]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #5 (&q->mmap_lock){+.+.}-{3:3}:
        __mutex_lock_common+0xcc/0xb88
        mutex_lock_nested+0x5c/0x68
        vb2_mmap+0xf4/0x290 [videobuf2_common]
        v4l2_m2m_fop_mmap+0x44/0x50 [v4l2_mem2mem]
        v4l2_mmap+0x5c/0xa4
        mmap_region+0x310/0x5a4
        do_mmap+0x348/0x43c
        vm_mmap_pgoff+0xfc/0x178
        ksys_mmap_pgoff+0x84/0xfc
        __arm64_compat_sys_aarch32_mmap2+0x2c/0x38
        invoke_syscall+0x54/0x110
        el0_svc_common+0x88/0xf0
        do_el0_svc_compat+0x28/0x34
        el0_svc_compat+0x24/0x34
        el0_sync_compat_handler+0xc0/0xf0
        el0_sync_compat+0x19c/0x1c0

 -> #4 (&mm->mmap_lock){++++}-{3:3}:
        __might_fault+0x60/0x88
        filldir64+0x124/0x3a0
        dcache_readdir+0x7c/0x1ec
        iterate_dir+0xc4/0x184
        __arm64_sys_getdents64+0x78/0x170
        invoke_syscall+0x54/0x110
        el0_svc_common+0xa8/0xf0
        do_el0_svc_compat+0x28/0x34
        el0_svc_compat+0x24/0x34
        el0_sync_compat_handler+0xc0/0xf0
        el0_sync_compat+0x19c/0x1c0

 -> #3 (&sb->s_type->i_mutex_key#3){++++}-{3:3}:
        down_write+0x94/0x1f4
        start_creating+0xb0/0x174
        debugfs_create_dir+0x28/0x138
        opp_debug_register+0x88/0xc0
        _add_opp_dev+0x84/0x9c
        _add_opp_table_indexed+0x16c/0x310
        _of_add_table_indexed+0x70/0xb5c
        dev_pm_opp_of_add_table_indexed+0x20/0x2c
        of_genpd_add_provider_onecell+0xc4/0x1c8
        rpmhpd_probe+0x21c/0x278
        platform_probe+0xb4/0xd4
        really_probe+0x140/0x35c
        driver_probe_device+0x90/0xcc
        __device_attach_driver+0xa4/0xc0
        bus_for_each_drv+0x8c/0xd8
        __device_attach+0xc4/0x150
        device_initial_probe+0x20/0x2c
        bus_probe_device+0x40/0xa4
        device_add+0x22c/0x3fc
        of_device_add+0x44/0x54
        of_platform_device_create_pdata+0xb0/0xf4
        of_platform_bus_create+0x1d0/0x350
        of_platform_populate+0x80/0xd4
        devm_of_platform_populate+0x64/0xb0
        rpmh_rsc_probe+0x378/0x3dc
        platform_probe+0xb4/0xd4
        really_probe+0x140/0x35c
        driver_probe_device+0x90/0xcc
        __device_attach_driver+0xa4/0xc0
        bus_for_each_drv+0x8c/0xd8
        __device_attach+0xc4/0x150
        device_initial_probe+0x20/0x2c
        bus_probe_device+0x40/0xa4
        device_add+0x22c/0x3fc
        of_device_add+0x44/0x54
        of_platform_device_create_pdata+0xb0/0xf4
        of_platform_bus_create+0x1d0/0x350
        of_platform_bus_create+0x21c/0x350
        of_platform_populate+0x80/0xd4
        of_platform_default_populate_init+0xb8/0xd4
        do_one_initcall+0x1b4/0x400
        do_initcall_level+0xa8/0xc8
        do_initcalls+0x5c/0x9c
        do_basic_setup+0x2c/0x38
        kernel_init_freeable+0x1a4/0x1ec
        kernel_init+0x20/0x118
        ret_from_fork+0x10/0x30

 -> #2 (gpd_list_lock){+.+.}-{3:3}:
        __mutex_lock_common+0xcc/0xb88
        mutex_lock_nested+0x5c/0x68
        __genpd_dev_pm_attach+0x70/0x18c
        genpd_dev_pm_attach_by_id+0xe4/0x158
        genpd_dev_pm_attach_by_name+0x48/0x60
        dev_pm_domain_attach_by_name+0x2c/0x38
        dev_pm_opp_attach_genpd+0xac/0x160
        vcodec_domains_get+0x94/0x14c [venus_core]
        core_get_v4+0x150/0x188 [venus_core]
        venus_probe+0x138/0x444 [venus_core]
        platform_probe+0xb4/0xd4
        really_probe+0x140/0x35c
        driver_probe_device+0x90/0xcc
        device_driver_attach+0x58/0x7c
        __driver_attach+0xc8/0xe0
        bus_for_each_dev+0x88/0xd4
        driver_attach+0x30/0x3c
        bus_add_driver+0x10c/0x1e0
        driver_register+0x70/0x108
        __platform_driver_register+0x30/0x3c
        0xffffffde113e1044
        do_one_initcall+0x1b4/0x400
        do_init_module+0x64/0x1fc
        load_module+0x17f4/0x1958
        __arm64_sys_finit_module+0xb4/0xf0
        invoke_syscall+0x54/0x110
        el0_svc_common+0x88/0xf0
        do_el0_svc_compat+0x28/0x34
        el0_svc_compat+0x24/0x34
        el0_sync_compat_handler+0xc0/0xf0
        el0_sync_compat+0x19c/0x1c0

 -> #1 (&opp_table->genpd_virt_dev_lock){+.+.}-{3:3}:
        __mutex_lock_common+0xcc/0xb88
        mutex_lock_nested+0x5c/0x68
        _set_required_opps+0x74/0x120
        _set_opp+0x94/0x37c
        dev_pm_opp_set_rate+0xa0/0x194
        core_clks_set_rate+0x28/0x58 [venus_core]
        load_scale_v4+0x228/0x2b4 [venus_core]
        session_process_buf+0x160/0x198 [venus_core]
        venus_helper_vb2_buf_queue+0xcc/0x130 [venus_core]
        vdec_vb2_buf_queue+0xc4/0x140 [venus_dec]
        __enqueue_in_driver+0x164/0x188 [videobuf2_common]
        vb2_core_qbuf+0x13c/0x47c [videobuf2_common]
        vb2_qbuf+0x88/0xec [videobuf2_v4l2]
        v4l2_m2m_qbuf+0x84/0x15c [v4l2_mem2mem]
        v4l2_m2m_ioctl_qbuf+0x24/0x30 [v4l2_mem2mem]
        v4l_qbuf+0x54/0x68
        __video_do_ioctl+0x2bc/0x3bc
        video_usercopy+0x558/0xb04
        video_ioctl2+0x24/0x30
        v4l2_ioctl+0x58/0x68
        v4l2_compat_ioctl32+0x84/0xa0
        __arm64_compat_sys_ioctl+0x12c/0x140
        invoke_syscall+0x54/0x110
        el0_svc_common+0x88/0xf0
        do_el0_svc_compat+0x28/0x34
        el0_svc_compat+0x24/0x34
        el0_sync_compat_handler+0xc0/0xf0
        el0_sync_compat+0x19c/0x1c0

 -> #0 (&inst->lock#3){+.+.}-{3:3}:
        __lock_acquire+0x248c/0x2d6c
        lock_acquire+0x240/0x314
        __mutex_lock_common+0xcc/0xb88
        mutex_lock_nested+0x5c/0x68
        vdec_buf_cleanup+0x3c/0x17c [venus_dec]
        __vb2_queue_free+0x98/0x204 [videobuf2_common]
        vb2_core_reqbufs+0x14c/0x390 [videobuf2_common]
        vb2_reqbufs+0x58/0x74 [videobuf2_v4l2]
        v4l2_m2m_reqbufs+0x58/0x90 [v4l2_mem2mem]
        v4l2_m2m_ioctl_reqbufs+0x24/0x30 [v4l2_mem2mem]
        v4l_reqbufs+0x58/0x6c
        __video_do_ioctl+0x2bc/0x3bc
        video_usercopy+0x558/0xb04
        video_ioctl2+0x24/0x30
        v4l2_ioctl+0x58/0x68
        v4l2_compat_ioctl32+0x84/0xa0
        __arm64_compat_sys_ioctl+0x12c/0x140
        invoke_syscall+0x54/0x110
        el0_svc_common+0x88/0xf0
        do_el0_svc_compat+0x28/0x34
        el0_svc_compat+0x24/0x34
        el0_sync_compat_handler+0xc0/0xf0
        el0_sync_compat+0x19c/0x1c0

 other info that might help us debug this:

 Chain exists of:
   &inst->lock#3 --> &mm->mmap_lock --> &q->mmap_lock

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&q->mmap_lock);
                                lock(&mm->mmap_lock);
                                lock(&q->mmap_lock);
   lock(&inst->lock#3);

  *** DEADLOCK ***

 1 lock held by ThreadPoolSingl/3969:
  #0: ffffff80d3c3c4f8 (&q->mmap_lock){+.+.}-{3:3}, at: vb2_core_reqbufs+0xe4/0x390 [videobuf2_common]

 stack backtrace:
 CPU: 2 PID: 3969 Comm: ThreadPoolSingl Not tainted 5.13.0-rc2 #71
 Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
 Call trace:
  dump_backtrace+0x0/0x1b4
  show_stack+0x24/0x30
  dump_stack+0xe0/0x15c
  print_circular_bug+0x32c/0x388
  check_noncircular+0x138/0x140
  __lock_acquire+0x248c/0x2d6c
  lock_acquire+0x240/0x314
  __mutex_lock_common+0xcc/0xb88
  mutex_lock_nested+0x5c/0x68
  vdec_buf_cleanup+0x3c/0x17c [venus_dec]
  __vb2_queue_free+0x98/0x204 [videobuf2_common]
  vb2_core_reqbufs+0x14c/0x390 [videobuf2_common]
  vb2_reqbufs+0x58/0x74 [videobuf2_v4l2]
  v4l2_m2m_reqbufs+0x58/0x90 [v4l2_mem2mem]
  v4l2_m2m_ioctl_reqbufs+0x24/0x30 [v4l2_mem2mem]
  v4l_reqbufs+0x58/0x6c
  __video_do_ioctl+0x2bc/0x3bc
  video_usercopy+0x558/0xb04
  video_ioctl2+0x24/0x30
  v4l2_ioctl+0x58/0x68
  v4l2_compat_ioctl32+0x84/0xa0
  __arm64_compat_sys_ioctl+0x12c/0x140
  invoke_syscall+0x54/0x110
  el0_svc_common+0x88/0xf0
  do_el0_svc_compat+0x28/0x34
  el0_svc_compat+0x24/0x34
  el0_sync_compat_handler+0xc0/0xf0
  el0_sync_compat+0x19c/0x1c0

The 'gpd_list_lock' is nominally named as such to protect the 'gpd_list'
from concurrent access and mutation. Unfortunately, holding that mutex
around various OPP framework calls leads to lockdep splats because now
we're doing various operations in OPP core such as registering with
debugfs while holding the list lock. We don't need to hold any list
mutex while we're calling into OPP, so let's shrink the locking area of
the 'gpd_list_lock' so that lockdep isn't triggered. This also helps
reduce contention on this lock, which probably doesn't matter much but
at least is nice to have.

Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-pm@vger.kernel.org>
Cc: Viresh Kumar <vireshk@kernel.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-07-05 18:27:18 +02:00
Steve French
90810c25cf smb3: fix typo in header file
Although it compiles, the test robot correctly noted:
  'cifsacl.h' file not found with <angled> include; use "quotes" instead

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
2021-07-05 10:59:53 -05:00
Randy Dunlap
97e488073c mips: disable branch profiling in boot/decompress.o
Use DISABLE_BRANCH_PROFILING for arch/mips/boot/compressed/decompress.o
to prevent linkage errors.

mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `LZ4_decompress_fast_extDict':
decompress.c:(.text+0x8c): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0xf4): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x200): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x230): undefined reference to `ftrace_likely_update'
mips64-linux-ld: decompress.c:(.text+0x320): undefined reference to `ftrace_likely_update'
mips64-linux-ld: arch/mips/boot/compressed/decompress.o:decompress.c:(.text+0x3f4): more undefined references to `ftrace_likely_update' follow

Fixes: e76e1fdfa8 ("lib: add support for LZ4-compressed kernel")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: linux-mips@vger.kernel.org
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-07-05 17:04:01 +02:00
Arnd Bergmann
cddc40f561 mips: always link byteswap helpers into decompressor
My series to clean up the unaligned access implementation
across architectures caused some mips randconfig builds to
fail with:

   mips64-linux-ld: arch/mips/boot/compressed/decompress.o: in function `decompress_kernel':
   decompress.c:(.text.decompress_kernel+0x54): undefined reference to `__bswapsi2'

It turns out that this problem has already been fixed for the XZ
decompressor but now it also shows up in (at least) LZO and LZ4.  From my
analysis I concluded that the compiler could always have emitted those
calls, but the different implementation allowed it to make otherwise
better decisions about not inlining the byteswap, which results in the
link error when the out-of-line code is missing.

While it could be addressed by adding it to the two decompressor
implementations that are known to be affected, but as this only adds
112 bytes to the kernel, the safer choice is to always add them.

Fixes: c50ec67875 ("MIPS: zboot: Fix the build with XZ compression on older GCC versions")
Fixes: 0652035a57 ("asm-generic: unaligned: remove byteshift helpers")
Link: https://lore.kernel.org/linux-mm/202106301304.gz2wVY9w-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202106260659.TyMe8mjr-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202106172016.onWT6Tza-lkp@intel.com/
Link: https://lore.kernel.org/linux-mm/202105231743.JJcALnhS-lkp@intel.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2021-07-05 17:03:11 +02:00
Cédric Le Goater
3f601608b7 powerpc/xive: Fix error handling when allocating an IPI
This is a smatch warning:

  arch/powerpc/sysdev/xive/common.c:1161 xive_request_ipi() warn: unsigned 'xid->irq' is never less than zero.

Fixes: fd6db2892e ("powerpc/xive: Modernize XIVE-IPI domain with an 'alloc' handler")
Cc: stable@vger.kernel.org # v5.13
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210701152412.1507612-1-clg@kaod.org
2021-07-05 22:23:25 +10:00
Naveen N. Rao
307e5042c7 powerpc/bpf: Reject atomic ops in ppc32 JIT
Commit 91c960b005 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and updated all JIT
implementations to reject JIT'ing instructions with an immediate value
different from BPF_ADD. However, ppc32 BPF JIT was implemented around
the same time and didn't include the same change. Update the ppc32 JIT
accordingly.

Fixes: 51c66ad849 ("powerpc/bpf: Implement extended BPF on PPC32")
Cc: stable@vger.kernel.org # v5.13+
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/426699046d89fe50f66ecf74bd31c01eda976ba5.1625145429.git.naveen.n.rao@linux.vnet.ibm.com
2021-07-05 22:23:25 +10:00
Naveen N. Rao
419ac82176 powerpc/bpf: Fix detecting BPF atomic instructions
Commit 91c960b005 ("bpf: Rename BPF_XADD and prepare to encode other
atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to
distinguish instructions based on the immediate field. Existing JIT
implementations were updated to check for the immediate field and to
reject programs utilizing anything more than BPF_ADD (such as BPF_FETCH)
in the immediate field.

However, the check added to powerpc64 JIT did not look at the correct
BPF instruction. Due to this, such programs would be accepted and
incorrectly JIT'ed resulting in soft lockups, as seen with the atomic
bounds test. Fix this by looking at the correct immediate value.

Fixes: 91c960b005 ("bpf: Rename BPF_XADD and prepare to encode other atomics in .imm")
Reported-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/4117b430ffaa8cd7af042496f87fd7539e4f17fd.1625145429.git.naveen.n.rao@linux.vnet.ibm.com
2021-07-05 22:23:25 +10:00
Christophe Leroy
cd5d5e602f powerpc/mm: Fix lockup on kernel exec fault
The powerpc kernel is not prepared to handle exec faults from kernel.
Especially, the function is_exec_fault() will return 'false' when an
exec fault is taken by kernel, because the check is based on reading
current->thread.regs->trap which contains the trap from user.

For instance, when provoking a LKDTM EXEC_USERSPACE test,
current->thread.regs->trap is set to SYSCALL trap (0xc00), and
the fault taken by the kernel is not seen as an exec fault by
set_access_flags_filter().

Commit d7df2443cd ("powerpc/mm: Fix spurious segfaults on radix
with autonuma") made it clear and handled it properly. But later on
commit d3ca587404 ("powerpc/mm: Fix reporting of kernel execute
faults") removed that handling, introducing test based on error_code.
And here is the problem, because on the 603 all upper bits of SRR1
get cleared when the TLB instruction miss handler bails out to ISI.

Until commit cbd7e6ca02 ("powerpc/fault: Avoid heavy
search_exception_tables() verification"), an exec fault from kernel
at a userspace address was indirectly caught by the lack of entry for
that address in the exception tables. But after that commit the
kernel mainly relies on KUAP or on core mm handling to catch wrong
user accesses. Here the access is not wrong, so mm handles it.
It is a minor fault because PAGE_EXEC is not set,
set_access_flags_filter() should set PAGE_EXEC and voila.
But as is_exec_fault() returns false as explained in the beginning,
set_access_flags_filter() bails out without setting PAGE_EXEC flag,
which leads to a forever minor exec fault.

As the kernel is not prepared to handle such exec faults, the thing to
do is to fire in bad_kernel_fault() for any exec fault taken by the
kernel, as it was prior to commit d3ca587404.

Fixes: d3ca587404 ("powerpc/mm: Fix reporting of kernel execute faults")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/024bb05105050f704743a0083fe3548702be5706.1625138205.git.christophe.leroy@csgroup.eu
2021-07-05 22:23:24 +10:00
Alex Sverdlin
6fa630bf47 ARM: 9098/1: ftrace: MODULE_PLT: Fix build problem without DYNAMIC_FTRACE
FTRACE_ADDR is only defined when CONFIG_DYNAMIC_FTRACE is defined, the
latter is even stronger requirement than CONFIG_FUNCTION_TRACER (which is
enough for MCOUNT_ADDR).

Link: https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org/thread/ZUVCQBHDMFVR7CCB7JPESLJEWERZDJ3T/

Fixes: 1f12fb25c5c5d22f ("ARM: 9079/1: ftrace: Add MODULE_PLTS support")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2021-07-05 11:52:26 +01:00
Harald Freudenberger
bd39654a22 s390/AP: support new dynamic AP bus size limit
This patch provides support for new dynamic AP bus message limit
with the existing zcrypt device driver and AP bus core code.

There is support for a new field 'ml' from TAPQ query. The field
gives if != 0 the AP bus limit for this card in 4k chunk units.
The actual message size limit per card is shown as a new read-only
sysfs attribute. The sysfs attribute

  /sys/devices/ap/cardxx/max_msg_size

shows the upper limit in bytes used by the AP bus and zcrypt device
driver for requests and replies send to and received from this card.
Currently up to CEX7 support only max 12kB msg size and thus the field
shows 12288 meaning the upper limit of a valid msg for this card is
12kB. Please note that the usable payload is somewhat lower and
depends on the msg type and thus the header struct which is to be
prepended by the zcrypt dd.

The dispatcher responsible for choosing the right card and queue is
aware of the individual card AP bus message limit. So a request is
only assigned to a queue of a card which is able to handle the size of
the request (e.g. a 14kB request will never go to a max 12kB card).
If no such card is found the ioctl will fail with ENODEV.

The reply buffer held by the device driver is determined by the ml
field of the TAPQ for this card. If a response from the card exceeds
this limit however, the response is not truncated but the ioctl for
this request will fail with errno EMSGSIZE to indicate that the device
driver has dropped the response because it would overflow the buffer
limit.

If the request size does not indicate to the dispatcher that an
adapter with extended limit is to be used, a random card will be
chosen when no specific card is addressed (ANY addressing). This may
result in an ioctl failure when the reply size needs an adapter with
extended limit but the randomly chosen one is not capable of handling
the broader reply size. The user space application needs to use
dedicated addressing to forward such a request only to suitable cards
to get requests like this processed properly.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Tuchscherer <ingo.tuchscherer@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Heiko Carstens
a0ae5cd235 s390/lib,string: fix strcat() inline asm constraint modifier
"dummy" is not only used as output but also as input. Therefore use
the correct "+" constraint modifier.

Fixes: 8cf23c8e1f ("s390/lib,string: get rid of register asm")
Reported-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Thomas Richter
a029a4eab3 s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility
Commit cf6acb8bdb ("s390/cpumf: Add support for complete counter set extraction")
allows access to the CPU Measurement Counter Facility via character
device /dev/hwctr. The access was exclusive via this device or
via perf_event_open() system call. Only one path at a time was
permitted. The CPU Measurement Counter Facility device driver blocked
access to other processes.

This patch removes this restriction and allows concurrent access to
the CPU Measurement Counter Facility from multiple processes at the same
time via perf_event_open() SVC and via /dev/hwctr device. The access
via /dev/hwctr device is still exclusive, only one process is allowed to
access this device.

This patch
- moves the /dev/hwctr device access from file perf_cpum_cf_diag.c.
  to file perf_cpum_cf.c.
- use only one trace buffer .../s390dbf/cpum_cf.
- remove cfset_csd structure and includes its members it into the
  structure cpu_cf_events. This results in one data structure and
  simplifies the access.
- rework function familiy ctr_set_enable, ctr_set_disable, ctr_set_start
  and ctr_set_stop which operate on a counter set number.
  Now they operate on a counter set bit mask.
- move CF_DIAG event functionality to file perf_cpum_cf.c. It now
  contains the complete functionality of the CPU Measurement Counter
  Facility:
  - Performance measurement support for counters using perf stat.
  - Support for complete counter set extraction with device /dev/hwctr.
  - Support for counter set extraction event CF_DIAG attached to
    samples using perf record.
- removes file perf_cpum_cf_diag.c

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Gordeev
5fa2ea0714 s390/mcck: move register validation to C code
This update partially reverts commit 3037a52f98 ("s390/nmi:
do register validation as early as possible").

Storage error checks and control registers validation are left
in the assembler code, since correct ASCEs and page tables are
required to enable DAT - which is done before the C handler is
entered.

System damage, kernel instruction address and PSW MWP checks
are left in the assembler code as well, since there is no way
to proceed if one of these checks is failed.

The getcpu vdso syscall reads CPU number from the programmable
field of the TOD clock. Disregard the TOD programmable register
validity bit and load the CPU number into the TOD programmable
field unconditionally.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Egorenkov
9f744abb46 s390/boot: replace magic string check with a bootdata flag
The magic string "S390EP" at offset 0x10008 indicated to the decompressed
kernel that it was booted by the decompressor. Introduce a new bootdata
flag instead which conveys the same information in an explicit and
a cleaner way. But keep the magic string because it is a kernel ABI.

Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Gordeev
549abb7f36 s390/mcck: keep machine check interruption codes sorted
This update puts in order MCCK_CODE_CPU_TIMER_VALID code definition.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Gordeev
d35925b349 s390/mcck: move storage error checks to assembler
The current storage errors tackling is wrong - the DAT is
enabled in assembler code before the actual storage checks
in C half are executed. In case the page tables themselves
are damaged such approach is not going to work.

With this update unrecoverable storage errors are not
passed to C code for handling, but rather the machine
is stopped right away. The only exception to this flow
is when a machine check occurred in KVM guest - in this
case the errors are reinjected by the handler.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Gordeev
7f6dc8d4c8 s390/mcck: always enter C handler with DAT enabled
The machine check handler must be entered with DAT disabled
in case control registers are corrupted or a storage error
happened and we can not tell if such error corresponds to a
page table.

Both of described conditions end up in stopping all CPUs and
entering the disabled wait in C half of the handler. However,
the storage errors are still checked after the DAT is enabled
and C code is entered. In case a page table is damaged such
flow is not expected to work.

This update paves the way for moving the storage error checks
from C to assembler half. All fatal errors that can only be
handled with DAT disabled are handled in assembler half also.
As result, the C half is only entered if the DAT is secured.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Gordeev
e2c13d6420 s390/mcck: optimize user mode check in case of !CONFIG_KVM
In case of the !CONFIG_KVM use "jz" instead of "jnz" when
detecting user mode and get rid of unnecessary jump as result.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Christia Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Alexander Gordeev
fbbdfca5c5 s390/entry.S: factor out SIEEXIT macro
Factor out SIEEXIT macro and use it instead of cleanup_sie
routine. As a side effect %r13 and %r14 are spared.

Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Christia Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Heiko Carstens
07f3a35df1 s390/lib,uaccess: fix copy_in_user_mvcos() inline asm clobber list
General register 0 is clobbered within the inline assembly and
therefore must be listed in the clobber list.

Fixes:  d1e18efa8f ("s390/lib,uaccess: get rid of register asm")
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Janosch Frank
85b18d7b5e s390: mm: Fix secure storage access exception handling
Turns out that the bit 61 in the TEID is not always 1 and if that's
the case the address space ID and the address are
unpredictable. Without an address and its address space ID we can't
export memory and hence we can only send a SIGSEGV to the process or
panic the kernel depending on who caused the exception.

Unfortunately bit 61 is only reliable if we have the "misc" UV feature
bit.

Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Fixes: 084ea4d611 ("s390/mm: add (non)secure page access exceptions handlers")
Cc: stable@vger.kernel.org
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Kefeng Wang
47f7c6cf00 s390/kprobes: use is_kernel() helper
Use is_kernel() helper instead of is_kernel_addr().

[hca@linux.ibm.com: add missing unsigned long cast]
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-07-05 12:44:23 +02:00
Peter Zijlstra
fa68bd09fc kprobe/static_call: Restore missing static_call_text_reserved()
Restore two hunks from commit:

  6333e8f73b ("static_call: Avoid kprobes on inline static_call()s")

that went walkabout in a Git merge commit.

Fixes: 76d4acf22b ("Merge tag 'perf-kprobes-2020-12-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20210628113045.167127609@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2021-07-05 10:47:16 +02:00
Peter Zijlstra
2bee6d16e4 static_call: Fix static_call_text_reserved() vs __init
It turns out that static_call_text_reserved() was reporting __init
text as being reserved past the time when the __init text was freed
and re-used.

This is mostly harmless and will at worst result in refusing a kprobe.

Fixes: 6333e8f73b ("static_call: Avoid kprobes on inline static_call()s")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20210628113045.106211657@infradead.org
2021-07-05 10:46:33 +02:00
Peter Zijlstra
9e667624c2 jump_label: Fix jump_label_text_reserved() vs __init
It turns out that jump_label_text_reserved() was reporting __init text
as being reserved past the time when the __init text was freed and
re-used.

For a long time, this resulted in, at worst, not being able to kprobe
text that happened to land at the re-used address. However a recent
commit e7bf1ba97a ("jump_label, x86: Emit short JMP") made it a
fatal mistake because it now needs to read the instruction in order to
determine the conflict -- an instruction that's no longer there.

Fixes: 4c3ef6d793 ("jump label: Add jump_label_text_reserved() to reserve jump points")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20210628113045.045141693@infradead.org
2021-07-05 10:46:20 +02:00
Xiongwei Song
4840ce2267 locking/lockdep: Fix meaningless /proc/lockdep output of lock classes on !CONFIG_PROVE_LOCKING
When enabling CONFIG_LOCK_STAT=y, then CONFIG_LOCKDEP=y is forcedly enabled,
but CONFIG_PROVE_LOCKING is disabled.

We can get output from /proc/lockdep, which currently includes usages of
lock classes. But the usages are meaningless, see the output below:

	/ # cat /proc/lockdep
	all lock classes:
	ffffffff9af63350 ....: cgroup_mutex

	ffffffff9af54eb8 ....: (console_sem).lock

	ffffffff9af54e60 ....: console_lock

	ffffffff9ae74c38 ....: console_owner_lock

	ffffffff9ae74c80 ....: console_owner

	ffffffff9ae66e60 ....: cpu_hotplug_lock

Only one usage context for each lock, this is because each usage is only
changed in mark_lock() that is in the CONFIG_PROVE_LOCKING=y section,
however in the test situation, it's not.

The fix is to move the usages reading and seq_print from the
!CONFIG_PROVE_LOCKING section to its defined section.

Also, locks_after list of lock_class is empty when !CONFIG_PROVE_LOCKING,
so do the same thing as what have done for usages of lock classes.

With this patch with !CONFIG_PROVE_LOCKING we can get the results below:

	/ # cat /proc/lockdep
	all lock classes:
	ffffffff85163290: cgroup_mutex
	ffffffff85154dd8: (console_sem).lock
	ffffffff85154d80: console_lock
	ffffffff85074b58: console_owner_lock
	ffffffff85074ba0: console_owner
	ffffffff85066d60: cpu_hotplug_lock

... a class key and the relevant class name each line.

Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Waiman Long <longman@redhat.com>
Link: https://lore.kernel.org/r/20210629135916.308210-1-sxwjean@me.com
2021-07-05 10:44:52 +02:00
Maurizio Lombardi
0755d3be2d nvme-tcp: can't set sk_user_data without write_lock
The sk_user_data pointer is supposed to be modified only while
holding the write_lock "sk_callback_lock", otherwise
we could race with other threads and crash the kernel.

we can't take the write_lock in nvmet_tcp_state_change()
because it would cause a deadlock, but the release_work queue
will set the pointer to NULL later so we can simply remove
the assignment.

Fixes: b5332a9f3f ("nvmet-tcp: fix incorrect locking in state_change sk callback")

Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-07-05 10:14:44 +02:00
Juergen Gross
629a5d87e2 xen: sync include/xen/interface/io/ring.h with Xen's newest version
Sync include/xen/interface/io/ring.h with Xen's newest version in
order to get the RING_COPY_RESPONSE() and RING_RESPONSE_PROD_OVERFLOW()
macros.

Note that this will correct the wrong license info by adding the
missing original copyright notice.

Signed-off-by: Juergen Gross <jgross@suse.com>
2021-07-05 09:49:45 +02:00
YueHaibing
2060061767 xen: Use DEVICE_ATTR_*() macro
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR(),
which makes the code a bit shorter and easier to read.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/20210526141019.13752-1-yuehaibing@huawei.com
Signed-off-by: Juergen Gross <jgross@suse.com>
2021-07-05 09:23:31 +02:00
Dmitry Torokhov
818b265889 Merge branch 'next' into for-linus
Prepare input updates for 5.14 merge window.
2021-07-04 23:05:31 -07:00
Alexander Larkin
f8f84af5da Input: joydev - prevent use of not validated data in JSIOCSBTNMAP ioctl
Even though we validate user-provided inputs we then traverse past
validated data when applying the new map. The issue was originally
discovered by Murray McAllister with this simple POC (if the following
is executed by an unprivileged user it will instantly panic the system):

int main(void) {
	int fd, ret;
	unsigned int buffer[10000];

	fd = open("/dev/input/js0", O_RDONLY);
	if (fd == -1)
		printf("Error opening file\n");

	ret = ioctl(fd, JSIOCSBTNMAP & ~IOCSIZE_MASK, &buffer);
	printf("%d\n", ret);
}

The solution is to traverse internal buffer which is guaranteed to only
contain valid date when constructing the map.

Fixes: 182d679b22 ("Input: joydev - prevent potential read overflow in ioctl")
Fixes: 999b874f4a ("Input: joydev - validate axis/button maps before clobbering current ones")
Reported-by: Murray McAllister <murray.mcallister@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Alexander Larkin <avlarkin82@gmail.com>
Link: https://lore.kernel.org/r/20210620120030.1513655-1-avlarkin82@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-07-04 23:02:10 -07:00
Masahiro Yamada
a0e781a2a3 sparc: syscalls: use pattern rules to generate syscall headers
Use pattern rules to unify similar build rules between 32-bit and 64-bit.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-07-05 14:15:12 +09:00
Masahiro Yamada
e2a86a29ea parisc: syscalls: use pattern rules to generate syscall headers
Use pattern rules to unify similar build rules between 32-bit and 64-bit.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-07-05 14:15:12 +09:00
Masahiro Yamada
c1ba79ece8 nds32: add arch/nds32/boot/.gitignore
Ignore arch/nds32/boot/Image.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-07-05 14:15:11 +09:00
Linus Torvalds
a180bd1d7e iov_iter: remove uaccess_kernel() warning from iov_iter_init()
This warning was there to catch any architectures that still use
CONFIG_SET_FS, and that would mis-use iov_iter_init() for anything that
wasn't a proper user space pointer.  So that

        WARN_ON_ONCE(uaccess_kernel());

makes perfect conceptual sense: you really shouldn't use a kernel
pointer with set_fs(KERNEL_DS) and then pass it to iov_iter_init().

HOWEVER.

Guenter Roeck reports that this warning actually triggers in no-mmu
configurations of both ARM and m68k.  And the reason isn't that they
pass in a kernel pointer under set_fs(KERNEL_DS) at all: the reason is
that in those configurations, "uaccess_kernel()" is simply not reliable.

Those no-mmu setups set USER_DS and KERNEL_DS to the same values, so you
can't test for the difference.

In particular, the no-mmu case for ARM does

   #define USER_DS                 KERNEL_DS
   #define uaccess_kernel()        (true)

so USER_DS and KERNEL_DS have the same value, and uaccess_kernel() is
always trivially true.

The m68k case is slightly different and not quite as obvious.  It does
(spread out over multiple header files just to be extra exciting:
asm/processor.h, asm/segment.h and asm-generic/uaccess.h):

   #define TASK_SIZE       (0xFFFFFFFFUL)
   #define USER_DS         MAKE_MM_SEG(TASK_SIZE)
   #define KERNEL_DS       MAKE_MM_SEG(~0UL)
   #define get_fs()        (current_thread_info()->addr_limit)
   #define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)

but the end result is the same: uaccess_kernel() will always be true,
because USER_DS and KERNEL_DS end up having the same value, even if that
value is defined differently.

This is very arguably a misfeature in those implementations, but in the
end we don't really care.  All modern architectures have gotten rid of
set_fs() already, and generic kernel code never uses it.  And while the
sanity check was a nice idea, an architecture would have to go the extra
mile to actually break this.

So this well-intentioned warning isn't really all that likely to find
anything but these known false positives, and as such just isn't worth
maintaining.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Fixes: 8cd54c1c84 ("iov_iter: separate direction from flavour")
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-04 16:12:42 -07:00
Linus Torvalds
28e92f9903 Merge branch 'core-rcu-2021.07.04' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull RCU updates from Paul McKenney:

 - Bitmap parsing support for "all" as an alias for all bits

 - Documentation updates

 - Miscellaneous fixes, including some that overlap into mm and lockdep

 - kvfree_rcu() updates

 - mem_dump_obj() updates, with acks from one of the slab-allocator
   maintainers

 - RCU NOCB CPU updates, including limited deoffloading

 - SRCU updates

 - Tasks-RCU updates

 - Torture-test updates

* 'core-rcu-2021.07.04' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu: (78 commits)
  tasks-rcu: Make show_rcu_tasks_gp_kthreads() be static inline
  rcu-tasks: Make ksoftirqd provide RCU Tasks quiescent states
  rcu: Add missing __releases() annotation
  rcu: Remove obsolete rcu_read_unlock() deadlock commentary
  rcu: Improve comments describing RCU read-side critical sections
  rcu: Create an unrcu_pointer() to remove __rcu from a pointer
  srcu: Early test SRCU polling start
  rcu: Fix various typos in comments
  rcu/nocb: Unify timers
  rcu/nocb: Prepare for fine-grained deferred wakeup
  rcu/nocb: Only cancel nocb timer if not polling
  rcu/nocb: Delete bypass_timer upon nocb_gp wakeup
  rcu/nocb: Cancel nocb_timer upon nocb_gp wakeup
  rcu/nocb: Allow de-offloading rdp leader
  rcu/nocb: Directly call __wake_nocb_gp() from bypass timer
  rcu: Don't penalize priority boosting when there is nothing to boost
  rcu: Point to documentation of ordering guarantees
  rcu: Make rcu_gp_cleanup() be noinline for tracing
  rcu: Restrict RCU_STRICT_GRACE_PERIOD to at most four CPUs
  rcu: Make show_rcu_gp_kthreads() dump rcu_node structures blocking GP
  ...
2021-07-04 12:58:33 -07:00
Linus Torvalds
da803f82fa Merge branch 'lkmm.2021.05.10c' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull lkmm fixlet from Paul E McKenney.

Fix missing underscore in Linux-kernel memory model docs.

* 'lkmm.2021.05.10c' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
  tools/memory-model: Fix smp_mb__after_spinlock() spelling
2021-07-04 12:33:31 -07:00
Linus Torvalds
b97efd5e98 Merge branch 'kcsan.2021.05.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull KCSAN updates from Paul McKenney.

* 'kcsan.2021.05.18a' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
  kcsan: Use URL link for pointing access-marking.txt
  kcsan: Document "value changed" line
  kcsan: Report observed value changes
  kcsan: Remove kcsan_report_type
  kcsan: Remove reporting indirection
  kcsan: Refactor access_info initialization
  kcsan: Fold panic() call into print_report()
  kcsan: Refactor passing watchpoint/other_info
  kcsan: Distinguish kcsan_report() calls
  kcsan: Simplify value change detection
  kcsan: Add pointer to access-marking.txt to data_race() bullet
2021-07-04 12:29:16 -07:00
Linus Torvalds
a412897fb5 memblock, arm: fix crashes caused by holes in the memory map
The coordination between freeing of unused memory map, pfn_valid() and core
 mm assumptions about validity of the memory map in various ranges was not
 designed for complex layouts of the physical memory with a lot of holes all
 over the place.
 
 Kefen Wang reported crashes in move_freepages() on a system with the
 following memory layout [1]:
 
   node   0: [mem 0x0000000080a00000-0x00000000855fffff]
   node   0: [mem 0x0000000086a00000-0x0000000087dfffff]
   node   0: [mem 0x000000008bd00000-0x000000008c4fffff]
   node   0: [mem 0x000000008e300000-0x000000008ecfffff]
   node   0: [mem 0x0000000090d00000-0x00000000bfffffff]
   node   0: [mem 0x00000000cc000000-0x00000000dc9fffff]
   node   0: [mem 0x00000000de700000-0x00000000de9fffff]
   node   0: [mem 0x00000000e0800000-0x00000000e0bfffff]
   node   0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
   node   0: [mem 0x00000000fda00000-0x00000000ffffefff]
 
 These crashes can be mitigated by enabling CONFIG_HOLES_IN_ZONE on ARM and
 essentially turning pfn_valid_within() to pfn_valid() instead of having it
 hardwired to 1 on that architecture, but this would require to keep
 CONFIG_HOLES_IN_ZONE solely for this purpose.
 
 A cleaner approach is to update ARM's implementation of pfn_valid() to take
 into accounting rounding of the freed memory map to pageblock boundaries
 and make sure it returns true for PFNs that have memory map entries even if
 there is no physical memory backing those PFNs.
 
 [1] https://lore.kernel.org/lkml/2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com
 -----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCAAxFiEEeOVYVaWZL5900a/pOQOGJssO/ZEFAmDhzQQTHHJwcHRAbGlu
 dXguaWJtLmNvbQAKCRA5A4Ymyw79kXeUCACS0lssuKbaBxFk6OkEe0nbmbwN/n9z
 zKd2AWzw9xFxYZkLfOCmi5EPUMI0IeDYjOyZmnj8YDDd7wRLVxZ51LSdyFDZafXY
 j6SVYprSmwUjLkuajmqifY5DLbZYeGuI6WFvNVLljltHc0i/GIzx1Tld2yO/M0Jk
 NzHQ0/5nXmU74PvvY8LrWk+rRjTYqMuolHvbbl4nNId5e/FYEWNxEqNO5gq6aG5g
 +5t1BjyLf1NMp67uc5aLoLmr2ZwK8/UmZeSZ7i9z03gU/5B1srLluhoBsYBPVHFY
 hRNRKwWUDRUmqjJnu5/EzI+iQnj7t6zV1hyt+E5B1gb89vuSVcJNOPQt
 =wCcY
 -----END PGP SIGNATURE-----

Merge tag 'memblock-v5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock

Pull memblock updates from Mike Rapoport:
 "Fix arm crashes caused by holes in the memory map.

  The coordination between freeing of unused memory map, pfn_valid() and
  core mm assumptions about validity of the memory map in various ranges
  was not designed for complex layouts of the physical memory with a lot
  of holes all over the place.

  Kefen Wang reported crashes in move_freepages() on a system with the
  following memory layout [1]:

	node 0: [mem 0x0000000080a00000-0x00000000855fffff]
	node 0: [mem 0x0000000086a00000-0x0000000087dfffff]
	node 0: [mem 0x000000008bd00000-0x000000008c4fffff]
	node 0: [mem 0x000000008e300000-0x000000008ecfffff]
	node 0: [mem 0x0000000090d00000-0x00000000bfffffff]
	node 0: [mem 0x00000000cc000000-0x00000000dc9fffff]
	node 0: [mem 0x00000000de700000-0x00000000de9fffff]
	node 0: [mem 0x00000000e0800000-0x00000000e0bfffff]
	node 0: [mem 0x00000000f4b00000-0x00000000f6ffffff]
	node 0: [mem 0x00000000fda00000-0x00000000ffffefff]

  These crashes can be mitigated by enabling CONFIG_HOLES_IN_ZONE on ARM
  and essentially turning pfn_valid_within() to pfn_valid() instead of
  having it hardwired to 1 on that architecture, but this would require
  to keep CONFIG_HOLES_IN_ZONE solely for this purpose.

  A cleaner approach is to update ARM's implementation of pfn_valid() to
  take into accounting rounding of the freed memory map to pageblock
  boundaries and make sure it returns true for PFNs that have memory map
  entries even if there is no physical memory backing those PFNs"

Link: https://lore.kernel.org/lkml/2a1592ad-bc9d-4664-fd19-f7448a37edc0@huawei.com [1]

* tag 'memblock-v5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock:
  arm: extend pfn_valid to take into account freed memory map alignment
  memblock: ensure there is no overflow in memblock_overlaps_region()
  memblock: align freed memory map on pageblock boundaries with SPARSEMEM
  memblock: free_unused_memmap: use pageblock units instead of MAX_ORDER
2021-07-04 12:23:05 -07:00
Linus Torvalds
2bb919b62f s390 updates for the 5.14 merge window
- Rework inline asm to get rid of error prone "register asm" constructs,
   which are problematic especially when code instrumentation is enabled. In
   particular introduce and use register pair union to allocate even/odd
   register pairs. Unfortunately this breaks compatibility with older
   clang compilers and minimum clang version for s390 has been raised to 13.
   https://lore.kernel.org/linux-next/CAK7LNARuSmPCEy-ak0erPrPTgZdGVypBROFhtw+=3spoGoYsyw@mail.gmail.com/
 
 - Fix gcc 11 warnings, which triggered various minor reworks all over
   the code.
 
 - Add zstd kernel image compression support.
 
 - Rework boot CPU lowcore handling.
 
 - De-duplicate and move kernel memory layout setup logic earlier.
 
 - Few fixes in preparation for FORTIFY_SOURCE performing compile-time
   and run-time field bounds checking for mem functions.
 
 - Remove broken and unused power management support leftovers in s390
   drivers.
 
 - Disable stack-protector for decompressor and purgatory to fix buildroot
   build.
 
 - Fix vt220 sclp console name to match the char device name.
 
 - Enable HAVE_IOREMAP_PROT and add zpci_set_irq()/zpci_clear_irq() in
   zPCI code.
 
 - Remove some implausible WARN_ON_ONCEs and remove arch specific counter
   transaction call backs in favour of default transaction handling in
   perf code.
 
 - Extend/add new uevents for online/config/mode state changes of
   AP card / queue device in zcrypt.
 
 - Minor entry and ccwgroup code improvements.
 
 - Other small various fixes and improvements all over the code.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCAAdFiEE3QHqV+H2a8xAv27vjYWKoQLXFBgFAmDhuTEACgkQjYWKoQLX
 FBjVlggAgDFBkDjlyfvrm4xzmHi7BJMmhrTJIONsSz+3tcA4/u5kE+Hrdrqxm0Uh
 ZH4MXBxn4q4Fmoomhu5w5ZDe8o2ip0aN9fFNdsBoP8hurmQbL/IbdTnBETKMrKpV
 XpogU2G7p+2nQ0+9+o6PS/vWlZhI88NVh8dWyRd2+5/XdMycgLv2Qm7NpQoACVw1
 CbUvxP2PlpZ0wltLvNBKPg1xXMZa3GS0wbVUsS2jiWcr/3VzCqfTHenZJ/RadoE6
 axG99QXCbLDMsJgVQcXtlI8K6Z461fAwbNtWZWC+Uq7o5pYuUFW1dovMg9WWF+7T
 lFNqXyyNy5wwITRkvuzjlVTE8yzYYg==
 =ADZ4
 -----END PGP SIGNATURE-----

Merge tag 's390-5.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 updates from Vasily Gorbik:

 - Rework inline asm to get rid of error prone "register asm"
   constructs, which are problematic especially when code
   instrumentation is enabled.

   In particular introduce and use register pair union to allocate
   even/odd register pairs. Unfortunately this breaks compatibility with
   older clang compilers and minimum clang version for s390 has been
   raised to 13.

     https://lore.kernel.org/linux-next/CAK7LNARuSmPCEy-ak0erPrPTgZdGVypBROFhtw+=3spoGoYsyw@mail.gmail.com/

 - Fix gcc 11 warnings, which triggered various minor reworks all over
   the code.

 - Add zstd kernel image compression support.

 - Rework boot CPU lowcore handling.

 - De-duplicate and move kernel memory layout setup logic earlier.

 - Few fixes in preparation for FORTIFY_SOURCE performing compile-time
   and run-time field bounds checking for mem functions.

 - Remove broken and unused power management support leftovers in s390
   drivers.

 - Disable stack-protector for decompressor and purgatory to fix
   buildroot build.

 - Fix vt220 sclp console name to match the char device name.

 - Enable HAVE_IOREMAP_PROT and add zpci_set_irq()/zpci_clear_irq() in
   zPCI code.

 - Remove some implausible WARN_ON_ONCEs and remove arch specific
   counter transaction call backs in favour of default transaction
   handling in perf code.

 - Extend/add new uevents for online/config/mode state changes of AP
   card / queue device in zcrypt.

 - Minor entry and ccwgroup code improvements.

 - Other small various fixes and improvements all over the code.

* tag 's390-5.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (91 commits)
  s390/dasd: use register pair instead of register asm
  s390/qdio: get rid of register asm
  s390/ioasm: use symbolic names for asm operands
  s390/ioasm: get rid of register asm
  s390/cmf: get rid of register asm
  s390/lib,string: get rid of register asm
  s390/lib,uaccess: get rid of register asm
  s390/string: get rid of register asm
  s390/cmpxchg: use register pair instead of register asm
  s390/mm,pages-states: get rid of register asm
  s390/lib,xor: get rid of register asm
  s390/timex: get rid of register asm
  s390/hypfs: use register pair instead of register asm
  s390/zcrypt: Switch to flexible array member
  s390/speculation: Use statically initialized const for instructions
  virtio/s390: get rid of open-coded kvm hypercall
  s390/pci: add zpci_set_irq()/zpci_clear_irq()
  scripts/min-tool-version.sh: Raise minimum clang version to 13.0.0 for s390
  s390/ipl: use register pair instead of register asm
  s390/mem_detect: fix tprot() program check new psw handling
  ...
2021-07-04 12:17:38 -07:00
Linus Torvalds
0d4d4c6ff6 arch/csky patches for 5.14-rc1
Two small cleanup & fixup.
 -----BEGIN PGP SIGNATURE-----
 
 iQJGBAABCgAwFiEE2KAv+isbWR/viAKHAXH1GYaIxXsFAmDhgrsSHGd1b3JlbkBr
 ZXJuZWwub3JnAAoJEAFx9RmGiMV7AfcP/22iiQMXB4ktH2GrVXlKPvjObhn0q8aS
 9+LKjdn49W8+5O6ZNvHi7GMHtrexoCR1Zv8hWL0NRBh/zh7J7+azLELSSXs8/LAj
 XPH8OXJ/RN1Xf//+O4tDxpyHQhKvAHoJLdhRB2CaI6WzZh1pV7rS5iYZ+/mXIQIQ
 Bn8xSEMC25JZfan7tTE+caxnDOW+KwbPhzeCjPwDJJR7Ow9D+4+dCcWUm1zm3Ooq
 elaXhFx8TPZjRnpw1jxCLxJXy1Q+o2eGuHjKmV7+SIfH2J3V3bBjIZGwVSxvIYAf
 OliUCmVD/XermM1E+hCiPNXjVxV5GqTqmZr0BKJvkutkiAaRAYnYxJxx7mR4kxN/
 eJwRIHT4BaiCw64SiUAr8mJMsWHaDp8HBhjbTeU9w0m85afMdtIVnQCgpNJKGaGm
 Fi1A6hnA2A/HYAKPNJRYeqbCR2r3fHS1hvY9V4vMsC31u64+k6jmph0qFxgljLjk
 IIP4CSdgiQ/2vWNR6qWVx0hnKE+lj6hh7D1hA8CjS3+Ym2/TMi6fEqlCEZhZB97a
 wB1TJGWIOQl8UwNeEeAe6dZz7qsUUqN9lIzAwZjY0pgk0Vw5IMv8BRS6o9NiFz3u
 MY8GPz2q6Sl/eP+KhuWT7brUJtzW+Jm7t1F0IJbP4+G8jVRTs7+js9IQhlkp0tvH
 y0+/Zidsf/uq
 =lAc+
 -----END PGP SIGNATURE-----

Merge tag 'csky-for-linus-5.14-rc1' of git://github.com/c-sky/csky-linux

Pull arch/csky updates from Guo Ren:
 "A small cleanup and a fixup"

* tag 'csky-for-linus-5.14-rc1' of git://github.com/c-sky/csky-linux:
  csky: Kconfig: Remove unused selects
  csky: syscache: Fixup duplicate cache flush
2021-07-04 12:07:54 -07:00
Linus Torvalds
0c66a95c7e cxl for 5.14
- Add support for the CXL Fixed Memory Window Structure, a recent
   extension of the ACPI CEDT (CXL Early Discovery Table)
 
 - Add infrastructure for component registers
 
 - Add HDM (Host-managed device memory) decoder definitions
 
 - Define a device model for an HDM decoder tree
 
 - Bridge CXL persistent memory capabilities to an NVDIMM bus /
   device-model
 
 - Switch to fine grained mapping of CXL MMIO registers to allow
   different drivers / system software to own individual register blocks
 
 - Enable media provisioning commands, and publish the label storage area
   size in sysfs
 
 - Miscellaneous cleanups and fixes
 -----BEGIN PGP SIGNATURE-----
 
 iHUEABYIAB0WIQSbo+XnGs+rwLz9XGXfioYZHlFsZwUCYOB2lAAKCRDfioYZHlFs
 ZyyaAP9O+SnYflFX+3gpoU4pK92VbIUl9KzzHdvJdW2CqtEVMgD9GO4V2Ng17WFg
 /Mzn9Mj9S+YaHYvOsN6qEF1V0QvqNQ4=
 =+X3m
 -----END PGP SIGNATURE-----

Merge tag 'cxl-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl

Pull CXL (Compute Express Link) updates from Dan Williams:
 "This subsystem is still in the build-out phase as the bulk of the
  update is improvements to enumeration and fleshing out the device
  model. In terms of new features, more mailbox commands have been added
  to the allowed-list in support of persistent memory provisioning
  support targeting v5.15.

  The critical update from an enumeration perspective is support for the
  CXL Fixed Memory Window Structure that indicates to Linux which system
  physical address ranges decode to the CXL Host Bridges in the system.
  This allows the driver to detect which address ranges have been mapped
  by firmware and what address ranges are available for future hotplug.

  So, again, mostly skeleton this round, with more meat targeting v5.15.

  Summary:

   - Add support for the CXL Fixed Memory Window Structure, a recent
     extension of the ACPI CEDT (CXL Early Discovery Table)

   - Add infrastructure for component registers

   - Add HDM (Host-managed device memory) decoder definitions

   - Define a device model for an HDM decoder tree

   - Bridge CXL persistent memory capabilities to an NVDIMM bus /
     device-model

   - Switch to fine grained mapping of CXL MMIO registers to allow
     different drivers / system software to own individual register
     blocks

   - Enable media provisioning commands, and publish the label storage
     area size in sysfs

   - Miscellaneous cleanups and fixes"

* tag 'cxl-for-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: (34 commits)
  cxl/pci: Rename CXL REGLOC ID
  cxl/acpi: Use the ACPI CFMWS to create static decoder objects
  cxl/acpi: Add the Host Bridge base address to CXL port objects
  cxl/pmem: Register 'pmem' / cxl_nvdimm devices
  libnvdimm: Drop unused device power management support
  libnvdimm: Export nvdimm shutdown helper, nvdimm_delete()
  cxl/pmem: Add initial infrastructure for pmem support
  cxl/core: Add cxl-bus driver infrastructure
  cxl/pci: Add media provisioning required commands
  cxl/component_regs: Fix offset
  cxl/hdm: Fix decoder count calculation
  cxl/acpi: Introduce cxl_decoder objects
  cxl/acpi: Enumerate host bridge root ports
  cxl/acpi: Add downstream port data to cxl_port instances
  cxl/Kconfig: Default drivers to CONFIG_CXL_BUS
  cxl/acpi: Introduce the root of a cxl_port topology
  cxl/pci: Fixup devm_cxl_iomap_block() to take a 'struct device *'
  cxl/pci: Add HDM decoder capabilities
  cxl/pci: Reserve individual register block regions
  cxl/pci: Map registers based on capabilities
  ...
2021-07-04 11:55:13 -07:00
Linus Torvalds
855ff900b8 Merge branch 'i2c/for-mergewindow' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c updates from Wolfram Sang:

 - core supports now bus regulators controlling power for SCL/SDA

 - quite some DT binding conversions to YAML

 - added a seperate DT binding for the optional SMBus Alert feature

 - documentation with examples how to deal with I2C sysfs files

 - some bigger rework for the i801 driver

 - and a few usual driver updates

* 'i2c/for-mergewindow' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (42 commits)
  i2c: ali1535: mention that the device should not be disabled
  i2c: mpc: Restore reread of I2C status register
  i2c: core-smbus: Expose PEC calculate function for generic use
  Documentation: i2c: Add doc for I2C sysfs
  i2c: core: Disable client irq on reboot/shutdown
  dt-bindings: i2c: update bindings for MT8195 SoC
  i2c: imx: Fix some checkpatch warnings
  i2c: davinci: Simplify with dev_err_probe()
  i2c: cadence: Simplify with dev_err_probe()
  i2c: xiic: Simplify with dev_err_probe()
  i2c: cadence: Clear HOLD bit before xfer_size register rolls over
  dt-bindings: i2c: ce4100: Replace "ti,pcf8575" by "nxp,pcf8575"
  i2c: i801: Improve i801_setup_hstcfg
  i2c: i801: Use driver name constant instead of function dev_driver_string
  i2c: i801: Simplify initialization of i2c_board_info in i801_probe_optional_slaves
  i2c: i801: Improve status polling
  i2c: cht-wc: Replace of_node by NULL
  i2c: riic: Add RZ/G2L support
  dt-bindings: i2c: renesas,riic: Document RZ/G2L I2C controller
  dt-bindings: i2c: renesas,iic: Convert to json-schema
  ...
2021-07-04 11:47:18 -07:00
Martin K. Petersen
d2500a0c0e scsi: blkcg: Fix application ID config options
Commit d2bcbeab42 ("scsi: blkcg: Add app identifier support for
blkcg") introduced an FC_APPID config option under SCSI. However, the
added config option is not used anywhere. Simply remove it.

The block layer BLK_CGROUP_FC_APPID config option is what actually
controls whether the application ID code should be built or not. Make
this option dependent on NVMe over FC since that is currently the only
transport which supports the capability.

Fixes: d2bcbeab42 ("scsi: blkcg: Add app identifier support for blkcg")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-04 11:44:22 -07:00
Dennis Zhou
93274f1dd6 percpu: flush tlb in pcpu_reclaim_populated()
Prior to "percpu: implement partial chunk depopulation",
pcpu_depopulate_chunk() was called only on the destruction path. This
meant the virtual address range was on its way back to vmalloc which
will handle flushing the tlbs for us.

However, with pcpu_reclaim_populated(), we are now calling
pcpu_depopulate_chunk() during the active lifecycle of a chunk.
Therefore, we need to flush the tlb as well otherwise we can end up
accessing the wrong page through an invalid tlb mapping as reported in
[1].

[1] https://lore.kernel.org/lkml/20210702191140.GA3166599@roeck-us.net/

Fixes: f183324133 ("percpu: implement partial chunk depopulation")
Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dennis Zhou <dennis@kernel.org>
2021-07-04 18:30:17 +00:00
Srinivas Pandruvada
fe6a6de669 thermal/drivers/int340x/processor_thermal: Fix tcc setting
The following fixes are done for tcc sysfs interface:
- TCC is 6 bits only from bit 29-24
- TCC of 0 is valid
- When BIT(31) is set, this register is read only
- Check for invalid tcc value
- Error for negative values

Fixes: fdf4f2fb8e ("drivers: thermal: processor_thermal_device: Export sysfs interface for TCC offset")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: stable@vger.kernel.org
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210628215803.75038-1-srinivas.pandruvada@linux.intel.com
2021-07-04 18:28:04 +02:00
Srinivas Pandruvada
ad079d981d thermal/drivers/int340x/processor_thermal: Fix warning for return value
Fix smatch warnings:
drivers/thermal/intel/int340x_thermal/processor_thermal_device_pci.c:258 proc_thermal_pci_probe() warn: missing error code 'ret'

Use PTR_ERR to return failure of thermal_zone_device_register().

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210628183232.62877-1-srinivas.pandruvada@linux.intel.com
2021-07-04 18:28:04 +02:00