Skip to content
This repository has been archived by the owner on Jun 19, 2024. It is now read-only.

Adding kernel parameters #11

Closed
macvenez opened this issue Oct 24, 2023 · 2 comments
Closed

Adding kernel parameters #11

macvenez opened this issue Oct 24, 2023 · 2 comments

Comments

@macvenez
Copy link

Hi! I'd like to add some kernel parameters in order to be able to run Docker in Termux but I don't know which files to edit and whether there's something like a menuconfig where we can see all the features that can be enabled.

OT: Is it possible to flash this Kernel and use it with the stock Samsung ROM?

Thanks!
@ratatouille100
Copy link

ratatouille100 commented Nov 7, 2023 •
edited
Loading

Hello there. It's possible to use it with the stock ROM. There are two versions: for AOSP and OneUI. There's menuconfig, you have to set two variable ARCH and CROSS_COMPILE and then write something like that:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

Gojikovi pushed a commit to Gojikovi/kernel_samsung_universal9611 that referenced this issue Nov 7, 2023
@davidhildenbrand @Gojikovi
fs/proc/page.c: don't access uninitialized memmaps in fs/proc/page.c
0d08254 
commit aad5f69bc161af489dbb5934868bd347282f0764 upstream.

There are three places where we access uninitialized memmaps, namely:
- /proc/kpagecount
- /proc/kpageflags
- /proc/kpagecgroup

We have initialized memmaps either when the section is online or when the
page was initialized to the ZONE_DEVICE.  Uninitialized memmaps contain
garbage and in the worst case trigger kernel BUGs, especially with
CONFIG_PAGE_POISONING.

For example, not onlining a DIMM during boot and calling /proc/kpagecount
with CONFIG_PAGE_POISONING:

  :/# cat /proc/kpagecount > tmp.test
  BUG: unable to handle page fault for address: fffffffffffffffe
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 114616067 P4D 114616067 PUD 114618067 PMD 0
  Oops: 0000 [Roynas-Android-Playground#1] SMP NOPTI
  CPU: 0 PID: 469 Comm: cat Not tainted 5.4.0-rc1-next-20191004+ Roynas-Android-Playground#11
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.4
  RIP: 0010:kpagecount_read+0xce/0x1e0
  Code: e8 09 83 e0 3f 48 0f a3 02 73 2d 4c 89 e7 48 c1 e7 06 48 03 3d ab 51 01 01 74 1d 48 8b 57 08 480
  RSP: 0018:ffffa14e409b7e78 EFLAGS: 00010202
  RAX: fffffffffffffffe RBX: 0000000000020000 RCX: 0000000000000000
  RDX: 0000000000000001 RSI: 00007f76b5595000 RDI: fffff35645000000
  RBP: 00007f76b5595000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000140000
  R13: 0000000000020000 R14: 00007f76b5595000 R15: ffffa14e409b7f08
  FS:  00007f76b577d580(0000) GS:ffff8f41bd400000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: fffffffffffffffe CR3: 0000000078960000 CR4: 00000000000006f0
  Call Trace:
   proc_reg_read+0x3c/0x60
   vfs_read+0xc5/0x180
   ksys_read+0x68/0xe0
   do_syscall_64+0x5c/0xa0
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

For now, let's drop support for ZONE_DEVICE from the three pseudo files
in order to fix this.  To distinguish offline memory (with garbage
memmap) from ZONE_DEVICE memory with properly initialized memmaps, we
would have to check get_dev_pagemap() and pfn_zone_device_reserved()
right now.  The usage of both (especially, special casing devmem) is
frowned upon and needs to be reworked.

The fundamental issue we have is:

	if (pfn_to_online_page(pfn)) {
		/* memmap initialized */
	} else if (pfn_valid(pfn)) {
		/*
		 * ???
		 * a) offline memory. memmap garbage.
		 * b) devmem: memmap initialized to ZONE_DEVICE.
		 * c) devmem: reserved for driver. memmap garbage.
		 * (d) devmem: memmap currently initializing - garbage)
		 */
	}

We'll leave the pfn_zone_device_reserved() check in stable_page_flags()
in place as that function is also used from memory failure.  We now no
longer dump information about pages that are not in use anymore -
offline.

Link: http://lkml.kernel.org/r/20191009142435.3975-2-david@redhat.com
Fixes: f1dd2cd ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e86b319]
Signed-off-by: David Hildenbrand <david@redhat.com>
Reported-by: Qian Cai <cai@lca.pw>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Toshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
Cc: Pankaj gupta <pagupta@redhat.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Anthony Yznaga <anthony.yznaga@oracle.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: <stable@vger.kernel.org>	[4.13+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@ThePolishLemon
Copy link
Contributor

Hello there. It's possible to use it with the stock ROM. There are two versions: for AOSP and OneUI. There's menuconfig, you have to set two variable ARCH and CROSS_COMPILE and then write something like that:

make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig

Hey, i'm kind of a noob, said command generates a .config file, but the Makefile doesn't allow you to build the kernel with said config file present, is there a way to work around that ?
also trying to run docker in termux XD

ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 2, 2023
@ratatouille100
tools lib traceevent: Fix memory leak in process_dynamic_array_len
1ecc479 
[ Upstream commit e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ]

I compiled with AddressSanitizer and I had these memory leaks while I
was using the tep_parse_format function:

    Direct leak of 28 byte(s) in 4 object(s) allocated from:
        #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
        Roynas-Android-Playground#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
        Roynas-Android-Playground#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
        Roynas-Android-Playground#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
        Roynas-Android-Playground#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
        Roynas-Android-Playground#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
        Roynas-Android-Playground#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
        Roynas-Android-Playground#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
        Roynas-Android-Playground#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
        Roynas-Android-Playground#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
        Roynas-Android-Playground#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
        Roynas-Android-Playground#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
        Roynas-Android-Playground#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
        Roynas-Android-Playground#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
        Roynas-Android-Playground#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
        Roynas-Android-Playground#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
        Roynas-Android-Playground#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
        Roynas-Android-Playground#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
        Roynas-Android-Playground#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
        Roynas-Android-Playground#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
        Roynas-Android-Playground#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
        Roynas-Android-Playground#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
        Roynas-Android-Playground#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
        Roynas-Android-Playground#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
        Roynas-Android-Playground#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
        Roynas-Android-Playground#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
        Roynas-Android-Playground#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

The token variable in the process_dynamic_array_len function is
allocated in the read_expect_type function, but is not freed before
calling the read_token function.

Free the token variable before calling read_token in order to plug the
leak.

Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 2, 2023
@namhyung @ratatouille100
perf test: Free formats for perf pmu parse test
79f91ea 
[ Upstream commit d26383dcb2b4b8629fde05270b4e3633be9e3d4b ]

The following leaks were detected by ASAN:

  Indirect leak of 360 byte(s) in 9 object(s) allocated from:
    #0 0x7fecc305180e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
    Roynas-Android-Playground#1 0x560578f6dce5 in perf_pmu__new_format util/pmu.c:1333
    Roynas-Android-Playground#2 0x560578f752fc in perf_pmu_parse util/pmu.y:59
    Roynas-Android-Playground#3 0x560578f6a8b7 in perf_pmu__format_parse util/pmu.c:73
    Roynas-Android-Playground#4 0x560578e07045 in test__pmu tests/pmu.c:155
    Roynas-Android-Playground#5 0x560578de109b in run_test tests/builtin-test.c:410
    Roynas-Android-Playground#6 0x560578de109b in test_and_print tests/builtin-test.c:440
    Roynas-Android-Playground#7 0x560578de401a in __cmd_test tests/builtin-test.c:661
    Roynas-Android-Playground#8 0x560578de401a in cmd_test tests/builtin-test.c:807
    Roynas-Android-Playground#9 0x560578e49354 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
    Roynas-Android-Playground#10 0x560578ce71a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
    Roynas-Android-Playground#11 0x560578ce71a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
    Roynas-Android-Playground#12 0x560578ce71a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
    Roynas-Android-Playground#13 0x7fecc2b7acc9 in __libc_start_main ../csu/libc-start.c:308

Fixes: cff7f95 ("perf tests: Move pmu tests into separate object")
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20200915031819.386559-12-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 17, 2023
@namhyung @ratatouille100
perf test: Fix unaligned access in sample parsing test
a8a3ae9 
[ Upstream commit c5c97cadd7ed13381cb6b4bef5c841a66938d350 ]

The ubsan reported the following error.  It was because sample's raw
data missed u32 padding at the end.  So it broke the alignment of the
array after it.

The raw data contains an u32 size prefix so the data size should have
an u32 padding after 8-byte aligned data.

27: Sample parsing  :util/synthetic-events.c:1539:4:
  runtime error: store to misaligned address 0x62100006b9bc for type
  '__u64' (aka 'unsigned long long'), which requires 8 byte alignment
0x62100006b9bc: note: pointer points here
  00 00 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
              ^
    #0 0x561532a9fc96 in perf_event__synthesize_sample util/synthetic-events.c:1539:13
    Roynas-Android-Playground#1 0x5615327f4a4f in do_test tests/sample-parsing.c:284:8
    Roynas-Android-Playground#2 0x5615327f3f50 in test__sample_parsing tests/sample-parsing.c:381:9
    Roynas-Android-Playground#3 0x56153279d3a1 in run_test tests/builtin-test.c:424:9
    Roynas-Android-Playground#4 0x56153279c836 in test_and_print tests/builtin-test.c:454:9
    Roynas-Android-Playground#5 0x56153279b7eb in __cmd_test tests/builtin-test.c:675:4
    Roynas-Android-Playground#6 0x56153279abf0 in cmd_test tests/builtin-test.c:821:9
    Roynas-Android-Playground#7 0x56153264e796 in run_builtin perf.c:312:11
    Roynas-Android-Playground#8 0x56153264cf03 in handle_internal_command perf.c:364:8
    Roynas-Android-Playground#9 0x56153264e47d in run_argv perf.c:408:2
    Roynas-Android-Playground#10 0x56153264c9a9 in main perf.c:538:3
    Roynas-Android-Playground#11 0x7f137ab6fbbc in __libc_start_main (/lib64/libc.so.6+0x38bbc)
    Roynas-Android-Playground#12 0x561532596828 in _start ...

SUMMARY: UndefinedBehaviorSanitizer: misaligned-pointer-use
 util/synthetic-events.c:1539:4 in

Fixes: 045f8cd ("perf tests: Add a sample parsing test")
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: https://lore.kernel.org/r/20210214091638.519643-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 18, 2023
@Wengang-oracle @ratatouille100
ocfs2: fix deadlock between setattr and dio_end_io_write
7876026 
commit 90bd070aae6c4fb5d302f9c4b9c88be60c8197ec upstream.

The following deadlock is detected:

  truncate -> setattr path is waiting for pending direct IO to be done (inode->i_dio_count become zero) with inode->i_rwsem held (down_write).

  PID: 14827  TASK: ffff881686a9af80  CPU: 20  COMMAND: "ora_p005_hrltd9"
   #0  __schedule at ffffffff818667cc
   Roynas-Android-Playground#1  schedule at ffffffff81866de6
   Roynas-Android-Playground#2  inode_dio_wait at ffffffff812a2d04
   Roynas-Android-Playground#3  ocfs2_setattr at ffffffffc05f322e [ocfs2]
   Roynas-Android-Playground#4  notify_change at ffffffff812a5a09
   Roynas-Android-Playground#5  do_truncate at ffffffff812808f5
   Roynas-Android-Playground#6  do_sys_ftruncate.constprop.18 at ffffffff81280cf2
   Roynas-Android-Playground#7  sys_ftruncate at ffffffff81280d8e
   Roynas-Android-Playground#8  do_syscall_64 at ffffffff81003949
   Roynas-Android-Playground#9  entry_SYSCALL_64_after_hwframe at ffffffff81a001ad

dio completion path is going to complete one direct IO (decrement
inode->i_dio_count), but before that it hung at locking inode->i_rwsem:

   #0  __schedule+700 at ffffffff818667cc
   Roynas-Android-Playground#1  schedule+54 at ffffffff81866de6
   Roynas-Android-Playground#2  rwsem_down_write_failed+536 at ffffffff8186aa28
   Roynas-Android-Playground#3  call_rwsem_down_write_failed+23 at ffffffff8185a1b7
   Roynas-Android-Playground#4  down_write+45 at ffffffff81869c9d
   Roynas-Android-Playground#5  ocfs2_dio_end_io_write+180 at ffffffffc05d5444 [ocfs2]
   Roynas-Android-Playground#6  ocfs2_dio_end_io+85 at ffffffffc05d5a85 [ocfs2]
   Roynas-Android-Playground#7  dio_complete+140 at ffffffff812c873c
   Roynas-Android-Playground#8  dio_aio_complete_work+25 at ffffffff812c89f9
   Roynas-Android-Playground#9  process_one_work+361 at ffffffff810b1889
  Roynas-Android-Playground#10  worker_thread+77 at ffffffff810b233d
  Roynas-Android-Playground#11  kthread+261 at ffffffff810b7fd5
  Roynas-Android-Playground#12  ret_from_fork+62 at ffffffff81a0035e

Thus above forms ABBA deadlock.  The same deadlock was mentioned in
upstream commit 28f5a8a7c033 ("ocfs2: should wait dio before inode lock
in ocfs2_setattr()").  It seems that that commit only removed the
cluster lock (the victim of above dead lock) from the ABBA deadlock
party.

End-user visible effects: Process hang in truncate -> ocfs2_setattr path
and other processes hang at ocfs2_dio_end_io_write path.

This is to fix the deadlock itself.  It removes inode_lock() call from
dio completion path to remove the deadlock and add ip_alloc_sem lock in
setattr path to synchronize the inode modifications.

[wen.gang.wang@oracle.com: remove the "had_alloc_lock" as suggested]
  Link: https://lkml.kernel.org/r/20210402171344.1605-1-wen.gang.wang@oracle.com

Link: https://lkml.kernel.org/r/20210331203654.3911-1-wen.gang.wang@oracle.com
Signed-off-by: Wengang Wang <wen.gang.wang@oracle.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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 18, 2023
@sunnanyong @ratatouille100
net: encx24j600: check error in devm_regmap_init_encx24j600
93368c0 
commit f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream.

devm_regmap_init may return error which caused by like out of memory,
this will results in null pointer dereference later when reading
or writing register:

general protection fault in encx24j600_spi_probe
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty Roynas-Android-Playground#11 9c53a778c1306b1b02359f3c2bbedc0222cba652
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540
Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00
RSP: 0018:ffffc900010476b8 EFLAGS: 00010207
RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000
RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094
RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a
R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001
R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08
FS:  00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459
 spi_probe drivers/spi/spi.c:397
 really_probe drivers/base/dd.c:517
 __driver_probe_device drivers/base/dd.c:751
 driver_probe_device drivers/base/dd.c:782
 __device_attach_driver drivers/base/dd.c:899
 bus_for_each_drv drivers/base/bus.c:427
 __device_attach drivers/base/dd.c:971
 bus_probe_device drivers/base/bus.c:487
 device_add drivers/base/core.c:3364
 __spi_add_device drivers/spi/spi.c:599
 spi_add_device drivers/spi/spi.c:641
 spi_new_device drivers/spi/spi.c:717
 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]
 dev_attr_store drivers/base/core.c:2074
 sysfs_kf_write fs/sysfs/file.c:139
 kernfs_fop_write_iter fs/kernfs/file.c:300
 new_sync_write fs/read_write.c:508 (discriminator 4)
 vfs_write fs/read_write.c:594
 ksys_write fs/read_write.c:648
 do_syscall_64 arch/x86/entry/common.c:50
 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113

Add error check in devm_regmap_init_encx24j600 to avoid this situation.

Fixes: 04fbfce ("net: Microchip encx24j600 driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Nanyong Sun <sunnanyong@huawei.com>
Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 19, 2023
@ratatouille100
misc: lattice-ecp3-config: Fix task hung when firmware load failed
c99a82b 
[ Upstream commit fcee5ce50bdb21116711e38635e3865594af907e ]

When firmware load failed, kernel report task hung as follows:

INFO: task xrun:5191 blocked for more than 147 seconds.
      Tainted: G        W         5.16.0-rc5-next-20211220+ Roynas-Android-Playground#11
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:xrun            state:D stack:    0 pid: 5191 ppid:   270 flags:0x00000004
Call Trace:
 __schedule+0xc12/0x4b50 kernel/sched/core.c:4986
 schedule+0xd7/0x260 kernel/sched/core.c:6369 (discriminator 1)
 schedule_timeout+0x7aa/0xa80 kernel/time/timer.c:1857
 wait_for_completion+0x181/0x290 kernel/sched/completion.c:85
 lattice_ecp3_remove+0x32/0x40 drivers/misc/lattice-ecp3-config.c:221
 spi_remove+0x72/0xb0 drivers/spi/spi.c:409

lattice_ecp3_remove() wait for signals from firmware loading, but when
load failed, firmware_load() does not send this signal. This cause
device remove hung. Fix it by sending signal even if load failed.

Fixes: 781551d ("misc: Add Lattice ECP3 FPGA configuration via SPI")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Link: https://lore.kernel.org/r/20211228125522.3122284-1-weiyongjun1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 19, 2023
@suresh2514 @ratatouille100
net-sysfs: add check for netdevice being present to speed_show
f00b91f 
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]

When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.

    [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
    [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
    ...
    [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280

    crash> bt
    ...
    PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
    ...
     Roynas-Android-Playground#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
        [exception RIP: dma_pool_alloc+0x1ab]
        RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
        RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
        RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
        RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
        R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
        R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    Roynas-Android-Playground#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
    Roynas-Android-Playground#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
    Roynas-Android-Playground#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
    Roynas-Android-Playground#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
    Roynas-Android-Playground#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
    Roynas-Android-Playground#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
    Roynas-Android-Playground#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
    Roynas-Android-Playground#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
    Roynas-Android-Playground#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
    Roynas-Android-Playground#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
    Roynas-Android-Playground#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
    Roynas-Android-Playground#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
    Roynas-Android-Playground#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
    Roynas-Android-Playground#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
    Roynas-Android-Playground#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
    Roynas-Android-Playground#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
    Roynas-Android-Playground#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92

    crash> net_device.state ffff89443b0c0000
      state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)

To prevent this scenario, we also make sure that the netdevice is present.

Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 19, 2023
@liuhangbin @ratatouille100
net/tunnel: wait until all sk_user_data reader finish before releasin…
e3a7306 
…g the sock

[ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ]

There is a race condition in vxlan that when deleting a vxlan device
during receiving packets, there is a possibility that the sock is
released after getting vxlan_sock vs from sk_user_data. Then in
later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got
NULL pointer dereference. e.g.

   #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757
   Roynas-Android-Playground#1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d
   Roynas-Android-Playground#2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48
   Roynas-Android-Playground#3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b
   Roynas-Android-Playground#4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb
   Roynas-Android-Playground#5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542
   Roynas-Android-Playground#6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62
      [exception RIP: vxlan_ecn_decapsulate+0x3b]
      RIP: ffffffffc1014e7b  RSP: ffffa25ec6978cb0  RFLAGS: 00010246
      RAX: 0000000000000008  RBX: ffff8aa000888000  RCX: 0000000000000000
      RDX: 000000000000000e  RSI: ffff8a9fc7ab803e  RDI: ffff8a9fd1168700
      RBP: ffff8a9fc7ab803e   R8: 0000000000700000   R9: 00000000000010ae
      R10: ffff8a9fcb748980  R11: 0000000000000000  R12: ffff8a9fd1168700
      R13: ffff8aa000888000  R14: 00000000002a0000  R15: 00000000000010ae
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
   Roynas-Android-Playground#7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]
   Roynas-Android-Playground#8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507
   Roynas-Android-Playground#9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45
  Roynas-Android-Playground#10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807
  Roynas-Android-Playground#11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951
  Roynas-Android-Playground#12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde
  Roynas-Android-Playground#13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b
  Roynas-Android-Playground#14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139
  Roynas-Android-Playground#15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a
  Roynas-Android-Playground#16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3
  Roynas-Android-Playground#17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca
  Roynas-Android-Playground#18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3

Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh

Fix this by waiting for all sk_user_data reader to finish before
releasing the sock.

Reported-by: Jianlin Shi <jishi@redhat.com>
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ratatouille100 pushed a commit to ratatouille100/kernel_samsung_universal9611 that referenced this issue Dec 19, 2023
@biger410 @ratatouille100
scsi: target: core: Fix deadlock due to recursive locking
8329d4a 
[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ]

The following call trace shows a deadlock issue due to recursive locking of
mutex "device_mutex". First lock acquire is in target_for_each_device() and
second in target_free_device().

 PID: 148266   TASK: ffff8be21ffb5d00  CPU: 10   COMMAND: "iscsi_ttx"
  #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f
  Roynas-Android-Playground#1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224
  Roynas-Android-Playground#2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee
  Roynas-Android-Playground#3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7
  Roynas-Android-Playground#4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3
  Roynas-Android-Playground#5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c
  Roynas-Android-Playground#6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod]
  Roynas-Android-Playground#7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod]
  Roynas-Android-Playground#8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f
  Roynas-Android-Playground#9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583
 Roynas-Android-Playground#10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod]
 Roynas-Android-Playground#11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc
 Roynas-Android-Playground#12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod]
 Roynas-Android-Playground#13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod]
 Roynas-Android-Playground#14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod]
 Roynas-Android-Playground#15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod]
 Roynas-Android-Playground#16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07
 Roynas-Android-Playground#17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod]
 Roynas-Android-Playground#18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod]
 Roynas-Android-Playground#19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080
 Roynas-Android-Playground#20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364

Fixes: 36d4cb460bcb ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion")
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Link: https://lore.kernel.org/r/20230918225848.66463-1-junxiao.bi@oracle.com
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@macvenez @Royna2544 @ThePolishLemon @ratatouille100