[ Upstream commit e40b801 ]
There is a certain chance to trigger the following panic:
PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48"
 #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7
 friendlyarm#1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a
 friendlyarm#2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60
 friendlyarm#3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7
 friendlyarm#4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715
 friendlyarm#5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654
 friendlyarm#6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62
 [exception RIP: ib_alloc_mr+19]
 RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202
 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004
 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20
 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00
 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
 friendlyarm#7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]
 friendlyarm#8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]
 friendlyarm#9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]
The reason here is that when the server tries to create a second link,
smc_llc_srv_add_link() has no protection and may add a new link to
link group. This breaks the security environment protected by
llc_conf_mutex.
Fixes: 2d2209f ("net/smc: first part of add link processing as SMC server")
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 91621be ]
When --overwrite and --max-size options of perf record are used
together, a segmentation fault occurs. The following is an example:
 # perf record -e sched:sched* --overwrite --max-size 1K -a -- sleep 1
 [ perf record: Woken up 1 times to write data ]
 perf: Segmentation fault
 Obtained 12 stack frames.
 ./perf/perf(+0x197673) [0x55f99710b673]
 /lib/x86_64-linux-gnu/libc.so.6(+0x3ef0f) [0x7fa45f3cff0f]
 ./perf/perf(+0x8eb40) [0x55f997002b40]
 ./perf/perf(+0x1f6882) [0x55f99716a882]
 ./perf/perf(+0x794c2) [0x55f996fed4c2]
 ./perf/perf(+0x7b7c7) [0x55f996fef7c7]
 ./perf/perf(+0x9074b) [0x55f99700474b]
 ./perf/perf(+0x12e23c) [0x55f9970a223c]
 ./perf/perf(+0x12e54a) [0x55f9970a254a]
 ./perf/perf(+0x7db60) [0x55f996ff1b60]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe6) [0x7fa45f3b2c86]
 ./perf/perf(+0x7dfe9) [0x55f996ff1fe9]
 Segmentation fault (core dumped)
backtrace of the core file is as follows:
 (gdb) bt
 #0 record__bytes_written (rec=0x55f99755a200 <record>) at builtin-record.c:234
 friendlyarm#1 record__output_max_size_exceeded (rec=0x55f99755a200 <record>) at builtin-record.c:242
 friendlyarm#2 record__write (map=0x0, size=12816, bf=0x55f9978da2e0, rec=0x55f99755a200 <record>) at builtin-record.c:263
 friendlyarm#3 process_synthesized_event (tool=tool@entry=0x55f99755a200 <record>, event=event@entry=0x55f9978da2e0, sample=sample@entry=0x0, machine=machine@entry=0x55f997893658) at builtin-record.c:618
 friendlyarm#4 0x000055f99716a883 in __perf_event__synthesize_id_index (tool=tool@entry=0x55f99755a200 <record>, process=process@entry=0x55f997002aa0 <process_synthesized_event>, evlist=0x55f9978928b0, machine=machine@entry=0x55f997893658,
 from=from@entry=0) at util/synthetic-events.c:1895
 friendlyarm#5 0x000055f99716a91f in perf_event__synthesize_id_index (tool=tool@entry=0x55f99755a200 <record>, process=process@entry=0x55f997002aa0 <process_synthesized_event>, evlist=<optimized out>, machine=machine@entry=0x55f997893658)
 at util/synthetic-events.c:1905
 friendlyarm#6 0x000055f996fed4c3 in record__synthesize (tail=tail@entry=true, rec=0x55f99755a200 <record>) at builtin-record.c:1997
 friendlyarm#7 0x000055f996fef7c8 in __cmd_record (argc=argc@entry=2, argv=argv@entry=0x7ffc67551260, rec=0x55f99755a200 <record>) at builtin-record.c:2802
 friendlyarm#8 0x000055f99700474c in cmd_record (argc=<optimized out>, argv=0x7ffc67551260) at builtin-record.c:4258
 friendlyarm#9 0x000055f9970a223d in run_builtin (p=0x55f997564d88 <commands+264>, argc=10, argv=0x7ffc67551260) at perf.c:330
 #10 0x000055f9970a254b in handle_internal_command (argc=10, argv=0x7ffc67551260) at perf.c:384
 #11 0x000055f996ff1b61 in run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:428
 #12 main (argc=<optimized out>, argv=0x7ffc67551260) at perf.c:562
The reason is that record__bytes_written accesses the freed memory rec->thread_data,
The process is as follows:
 __cmd_record
 -> record__free_thread_data
 -> zfree(&rec->thread_data) // free rec->thread_data
 -> record__synthesize
 -> perf_event__synthesize_id_index
 -> process_synthesized_event
 -> record__write
 -> record__bytes_written // access rec->thread_data
We add a member variable "thread_bytes_written" in the struct "record"
to save the data size written by the threads.
Fixes: 6d57581 ("perf record: Add support for limit perf output file size")
Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Jiwei Sun <jiwei.sun@windriver.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/CAM9d7ci_TRrqBQVQNW8=GwakUr7SsZpYxaaty-S4bxF8zJWyqw@mail.gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 60eed1e upstream.
code path:
ocfs2_ioctl_move_extents
 ocfs2_move_extents
 ocfs2_defrag_extent
 __ocfs2_move_extent
 + ocfs2_journal_access_di
 + ocfs2_split_extent //sub-paths call jbd2_journal_restart
 + ocfs2_journal_dirty //crash by jbs2 ASSERT
crash stacks:
PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2"
 #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01
 friendlyarm#1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d
 friendlyarm#2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d
 friendlyarm#3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f
 friendlyarm#4 [ffffb25d8dad3a58] do_trap at ffffffff83833205
 friendlyarm#5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6
 friendlyarm#6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18
 [exception RIP: jbd2_journal_dirty_metadata+0x2ba]
 RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207
 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000
 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250
 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000
 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28
 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250
 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
 friendlyarm#7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]
 friendlyarm#8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]
 friendlyarm#9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]
Analysis
This bug has the same root cause of 'commit 7f27ec9 ("ocfs2: call
ocfs2_journal_access_di() before ocfs2_journal_dirty() in
ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is
called by ocfs2_split_extent() during defragmenting.
How to fix
For ocfs2_split_extent() can handle journal operations totally by itself.
Caller doesn't need to call journal access/dirty pair, and caller only
needs to call journal start/stop pair. The fix method is to remove
journal access/dirty from __ocfs2_move_extent().
The discussion for this patch:
https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
Link: https://lkml.kernel.org/r/20230217003717.32469-1-heming.zhao@suse.com
Signed-off-by: Heming Zhao <heming.zhao@suse.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 2508708 ]
GCC warns about the pattern sizeof(void*)/sizeof(void), as it looks like
the abuse of a pattern to calculate the array size. This pattern appears
in the unevaluated part of the ternary operator in _INTC_ARRAY if the
parameter is NULL.
The replacement uses an alternate approach to return 0 in case of NULL
which does not generate the pattern sizeof(void*)/sizeof(void), but still
emits the warning if _INTC_ARRAY is called with a nonarray parameter.
This patch is required for successful compilation with -Werror enabled.
The idea to use _Generic for type distinction is taken from Comment friendlyarm#7
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Link: https://lore.kernel.org/r/619fa552-c988-35e5-b1d7-fe256c46a272@mkarcher.dialup.fu-berlin.de
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 4e264be ]
When a system with E810 with existing VFs gets rebooted the following
hang may be observed.
 Pid 1 is hung in iavf_remove(), part of a network driver:
 PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow"
 #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb
 friendlyarm#1 [ffffaad04005fae8] schedule at ffffffff8b323e2d
 friendlyarm#2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc
 friendlyarm#3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930
 friendlyarm#4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf]
 friendlyarm#5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513
 friendlyarm#6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa
 friendlyarm#7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc
 friendlyarm#8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e
 friendlyarm#9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429
 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4
 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice]
 #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice]
 #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice]
 #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1
 #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386
 #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870
 #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6
 #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159
 #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc
 #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d
 #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169
 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b
 RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202
 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7
 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead
 RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90
 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005
 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000
 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b
During reboot all drivers PM shutdown callbacks are invoked.
In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE.
In ice_shutdown() the call chain above is executed, which at some point
calls iavf_remove(). However iavf_remove() expects the VF to be in one
of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If
that's not the case it sleeps forever.
So if iavf_shutdown() gets invoked before iavf_remove() the system will
hang indefinitely because the adapter is already in state __IAVF_REMOVE.
Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE,
as we already went through iavf_shutdown().
Fixes: 9745780 ("iavf: Add waiting so the port is initialized in remove")
Fixes: a841733 ("iavf: Fix race condition between iavf_shutdown and iavf_remove")
Reported-by: Marius Cornea <mcornea@redhat.com>
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>