Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merge pull request #1 from torvalds/master #201

Closed
wants to merge 1 commit into from
Closed

Merge pull request #1 from torvalds/master #201

wants to merge 1 commit into from

Conversation

oe5hpm
Copy link

@oe5hpm oe5hpm commented Aug 25, 2015

pull latest torvalds/linux into oe5hpm/linux

@oe5hpm
Merge pull request #1 from torvalds/master
bb187e2 
pull latest torvalds/linux into oe5hpm/linux
@oe5hpm oe5hpm closed this Aug 25, 2015
atenart pushed a commit to atenart/linux that referenced this pull request Oct 21, 2015
@vzapolskiy @computersforpeace
mtd: lpc32xx_slc: fix warnings caused by enabling unprepared clock
44cab9c 
If common clock framework is configured, the driver generates a warning,
which is fixed by this change:

    WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4()
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc2+ torvalds#201
    Hardware name: LPC32XX SoC (Flattened Device Tree)
    Backtrace:
    [<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
    [<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
    [<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
    [<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
    [<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4)
    [<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
    [<>] (clk_enable) from [<>] (lpc32xx_nand_probe+0x290/0x568)
    [<>] (lpc32xx_nand_probe) from [<>] (platform_drv_probe+0x50/0xa0)
    [<>] (platform_drv_probe) from [<>] (driver_probe_device+0x18c/0x408)
    [<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94)
    [<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98)
    [<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28)
    [<>] (driver_attach) from [<>] (bus_add_driver+0x11c/0x248)
    [<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8)
    [<>] (driver_register) from [<>] (__platform_driver_register+0x50/0x64)
    [<>] (__platform_driver_register) from [<>] (lpc32xx_nand_driver_init+0x18/0x20)
    [<>] (lpc32xx_nand_driver_init) from [<>] (do_one_initcall+0x11c/0x1dc)
    [<>] (do_one_initcall) from [<>] (kernel_init_freeable+0x10c/0x1d4)
    [<>] (kernel_init_freeable) from [<>] (kernel_init+0x10/0xec)
    [<>] (kernel_init) from [<>] (ret_from_fork+0x14/0x24)

Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 31, 2017
@kiryl
mm: sleeping function called from invalid context shmem_undo_range
33d6ee2 
On Tue, Jan 31, 2017 at 09:27:41AM +0100, Dmitry Vyukov wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> fd694aa:

This should help:

From fb85b3fe273decb11c558d56257193424b8f071a Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date: Tue, 31 Jan 2017 12:22:26 +0300
Subject: [PATCH] shmem: fix sleeping from atomic context

Syzkaller fuzzer managed to trigger this:

BUG: sleeping function called from invalid context at mm/shmem.c:852
in_atomic(): 1, irqs_disabled(): 0, pid: 529, name: khugepaged
3 locks held by khugepaged/529:
 #0:  (shrinker_rwsem){++++..}, at: [<ffffffff818d7ef1>]
shrink_slab.part.59+0x121/0xd30 mm/vmscan.c:451
 #1:  (&type->s_umount_key#29){++++..}, at: [<ffffffff81a63630>]
trylock_super+0x20/0x100 fs/super.c:392
 #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at:
[<ffffffff818fd83e>] spin_lock include/linux/spinlock.h:302 [inline]
 #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at:
[<ffffffff818fd83e>] shmem_unused_huge_shrink+0x28e/0x1490
mm/shmem.c:427
CPU: 2 PID: 529 Comm: khugepaged Not tainted 4.10.0-rc5+ torvalds#201
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
 shmem_undo_range+0xb20/0x2710 mm/shmem.c:852
 shmem_truncate_range+0x27/0xa0 mm/shmem.c:939
 shmem_evict_inode+0x35f/0xca0 mm/shmem.c:1030
 evict+0x46e/0x980 fs/inode.c:553
 iput_final fs/inode.c:1515 [inline]
 iput+0x589/0xb20 fs/inode.c:1542
 shmem_unused_huge_shrink+0xbad/0x1490 mm/shmem.c:446
 shmem_unused_huge_scan+0x10c/0x170 mm/shmem.c:512
 super_cache_scan+0x376/0x450 fs/super.c:106
 do_shrink_slab mm/vmscan.c:378 [inline]
 shrink_slab.part.59+0x543/0xd30 mm/vmscan.c:481
 shrink_slab mm/vmscan.c:2592 [inline]
 shrink_node+0x2c7/0x870 mm/vmscan.c:2592
 shrink_zones mm/vmscan.c:2734 [inline]
 do_try_to_free_pages+0x369/0xc80 mm/vmscan.c:2776
 try_to_free_pages+0x3c6/0x900 mm/vmscan.c:2982
 __perform_reclaim mm/page_alloc.c:3301 [inline]
 __alloc_pages_direct_reclaim mm/page_alloc.c:3322 [inline]
 __alloc_pages_slowpath+0xa24/0x1c30 mm/page_alloc.c:3683
 __alloc_pages_nodemask+0x544/0xae0 mm/page_alloc.c:3848
 __alloc_pages include/linux/gfp.h:426 [inline]
 __alloc_pages_node include/linux/gfp.h:439 [inline]
 khugepaged_alloc_page+0xc2/0x1b0 mm/khugepaged.c:750
 collapse_huge_page+0x182/0x1fe0 mm/khugepaged.c:955
 khugepaged_scan_pmd+0xfdf/0x12a0 mm/khugepaged.c:1208
 khugepaged_scan_mm_slot mm/khugepaged.c:1727 [inline]
 khugepaged_do_scan mm/khugepaged.c:1808 [inline]
 khugepaged+0xe9b/0x1590 mm/khugepaged.c:1853
 kthread+0x326/0x3f0 kernel/kthread.c:227
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430

The iput() from atomic context was a bad idea: if after igrab() somebody
else calls iput() and we left with the last inode reference, our iput()
would lead to inode eviction and therefore sleeping.

This patch should fix the situation.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Feb 2, 2017
@kiryl @hnaz
shmem: fix sleeping from atomic context
f46aafc 
Syzkaller fuzzer managed to trigger this:

BUG: sleeping function called from invalid context at mm/shmem.c:852
in_atomic(): 1, irqs_disabled(): 0, pid: 529, name: khugepaged
3 locks held by khugepaged/529:
 #0:  (shrinker_rwsem){++++..}, at: [<ffffffff818d7ef1>]
shrink_slab.part.59+0x121/0xd30 mm/vmscan.c:451
 #1:  (&type->s_umount_key#29){++++..}, at: [<ffffffff81a63630>]
trylock_super+0x20/0x100 fs/super.c:392
 #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at:
[<ffffffff818fd83e>] spin_lock include/linux/spinlock.h:302 [inline]
 #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at:
[<ffffffff818fd83e>] shmem_unused_huge_shrink+0x28e/0x1490
mm/shmem.c:427
CPU: 2 PID: 529 Comm: khugepaged Not tainted 4.10.0-rc5+ torvalds#201
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
 shmem_undo_range+0xb20/0x2710 mm/shmem.c:852
 shmem_truncate_range+0x27/0xa0 mm/shmem.c:939
 shmem_evict_inode+0x35f/0xca0 mm/shmem.c:1030
 evict+0x46e/0x980 fs/inode.c:553
 iput_final fs/inode.c:1515 [inline]
 iput+0x589/0xb20 fs/inode.c:1542
 shmem_unused_huge_shrink+0xbad/0x1490 mm/shmem.c:446
 shmem_unused_huge_scan+0x10c/0x170 mm/shmem.c:512
 super_cache_scan+0x376/0x450 fs/super.c:106
 do_shrink_slab mm/vmscan.c:378 [inline]
 shrink_slab.part.59+0x543/0xd30 mm/vmscan.c:481
 shrink_slab mm/vmscan.c:2592 [inline]
 shrink_node+0x2c7/0x870 mm/vmscan.c:2592
 shrink_zones mm/vmscan.c:2734 [inline]
 do_try_to_free_pages+0x369/0xc80 mm/vmscan.c:2776
 try_to_free_pages+0x3c6/0x900 mm/vmscan.c:2982
 __perform_reclaim mm/page_alloc.c:3301 [inline]
 __alloc_pages_direct_reclaim mm/page_alloc.c:3322 [inline]
 __alloc_pages_slowpath+0xa24/0x1c30 mm/page_alloc.c:3683
 __alloc_pages_nodemask+0x544/0xae0 mm/page_alloc.c:3848
 __alloc_pages include/linux/gfp.h:426 [inline]
 __alloc_pages_node include/linux/gfp.h:439 [inline]
 khugepaged_alloc_page+0xc2/0x1b0 mm/khugepaged.c:750
 collapse_huge_page+0x182/0x1fe0 mm/khugepaged.c:955
 khugepaged_scan_pmd+0xfdf/0x12a0 mm/khugepaged.c:1208
 khugepaged_scan_mm_slot mm/khugepaged.c:1727 [inline]
 khugepaged_do_scan mm/khugepaged.c:1808 [inline]
 khugepaged+0xe9b/0x1590 mm/khugepaged.c:1853
 kthread+0x326/0x3f0 kernel/kthread.c:227
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430

The iput() from atomic context was a bad idea: if after igrab() somebody
else calls iput() and we left with the last inode reference, our iput()
would lead to inode eviction and therefore sleeping.

This patch should fix the situation.

Link: http://lkml.kernel.org/r/20170131093141.GA15899@node.shutemov.name
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
torvalds pushed a commit that referenced this pull request Feb 3, 2017
@kiryl @torvalds
shmem: fix sleeping from atomic context
253fd0f 
Syzkaller fuzzer managed to trigger this:

    BUG: sleeping function called from invalid context at mm/shmem.c:852
    in_atomic(): 1, irqs_disabled(): 0, pid: 529, name: khugepaged
    3 locks held by khugepaged/529:
     #0:  (shrinker_rwsem){++++..}, at: [<ffffffff818d7ef1>] shrink_slab.part.59+0x121/0xd30 mm/vmscan.c:451
     #1:  (&type->s_umount_key#29){++++..}, at: [<ffffffff81a63630>] trylock_super+0x20/0x100 fs/super.c:392
     #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at: [<ffffffff818fd83e>] spin_lock include/linux/spinlock.h:302 [inline]
     #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at: [<ffffffff818fd83e>] shmem_unused_huge_shrink+0x28e/0x1490 mm/shmem.c:427
    CPU: 2 PID: 529 Comm: khugepaged Not tainted 4.10.0-rc5+ #201
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
       shmem_undo_range+0xb20/0x2710 mm/shmem.c:852
       shmem_truncate_range+0x27/0xa0 mm/shmem.c:939
       shmem_evict_inode+0x35f/0xca0 mm/shmem.c:1030
       evict+0x46e/0x980 fs/inode.c:553
       iput_final fs/inode.c:1515 [inline]
       iput+0x589/0xb20 fs/inode.c:1542
       shmem_unused_huge_shrink+0xbad/0x1490 mm/shmem.c:446
       shmem_unused_huge_scan+0x10c/0x170 mm/shmem.c:512
       super_cache_scan+0x376/0x450 fs/super.c:106
       do_shrink_slab mm/vmscan.c:378 [inline]
       shrink_slab.part.59+0x543/0xd30 mm/vmscan.c:481
       shrink_slab mm/vmscan.c:2592 [inline]
       shrink_node+0x2c7/0x870 mm/vmscan.c:2592
       shrink_zones mm/vmscan.c:2734 [inline]
       do_try_to_free_pages+0x369/0xc80 mm/vmscan.c:2776
       try_to_free_pages+0x3c6/0x900 mm/vmscan.c:2982
       __perform_reclaim mm/page_alloc.c:3301 [inline]
       __alloc_pages_direct_reclaim mm/page_alloc.c:3322 [inline]
       __alloc_pages_slowpath+0xa24/0x1c30 mm/page_alloc.c:3683
       __alloc_pages_nodemask+0x544/0xae0 mm/page_alloc.c:3848
       __alloc_pages include/linux/gfp.h:426 [inline]
       __alloc_pages_node include/linux/gfp.h:439 [inline]
       khugepaged_alloc_page+0xc2/0x1b0 mm/khugepaged.c:750
       collapse_huge_page+0x182/0x1fe0 mm/khugepaged.c:955
       khugepaged_scan_pmd+0xfdf/0x12a0 mm/khugepaged.c:1208
       khugepaged_scan_mm_slot mm/khugepaged.c:1727 [inline]
       khugepaged_do_scan mm/khugepaged.c:1808 [inline]
       khugepaged+0xe9b/0x1590 mm/khugepaged.c:1853
       kthread+0x326/0x3f0 kernel/kthread.c:227
       ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430

The iput() from atomic context was a bad idea: if after igrab() somebody
else calls iput() and we left with the last inode reference, our iput()
would lead to inode eviction and therefore sleeping.

This patch should fix the situation.

Link: http://lkml.kernel.org/r/20170131093141.GA15899@node.shutemov.name
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Feb 6, 2017
@tiwai
sound: unable to handle kernel paging request snd_seq_prioq_cell_out
c3bc5b4 
On Tue, 31 Jan 2017 11:04:46 +0100,
Dmitry Vyukov wrote:
>
> Hello,
>
> The following program triggers wild memory access in snd_seq_prioq_cell_out:
> https://gist.githubusercontent.com/dvyukov/e0bfb47caf577217b3b0550866cba00b/raw/111473e99109fc96a1d3e252c3b8f982e8eaa265/gistfile1.txt
>
> BUG: unable to handle kernel paging request at ffffc9000392ddb8
> IP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231
> PGD 6cc6f067
> PUD 6cc70067
> PMD 5f94c067
> PTE 0
> Oops: 0000 [#1] SMP KASAN
> Modules linked in:
> CPU: 2 PID: 375 Comm: syz-executor Not tainted 4.10.0-rc5+ torvalds#201
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff880066f92500 task.stack: ffff88005f740000
> RIP: 0010:snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231
> RSP: 0018:ffff88005f7470b8 EFLAGS: 00010046
> RAX: dffffc0000000000 RBX: 1ffff1000bee8e18 RCX: ffffc90000c22000
> RDX: 1ffff92000725bb7 RSI: ffffffff8348787e RDI: ffffc9000392ddb8
> RBP: ffff88005f747208 R08: 0000000000000001 R09: 0000000000000001
> R10: dffffc0000000000 R11: 0000000000000004 R12: ffff8800673cbe80
> R13: ffff88005f7471e0 R14: ffffc9000392dd90 R15: ffff8800673cbe98
> FS:  00007f5262fee700(0000) GS:ffff88006d100000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffc9000392ddb8 CR3: 0000000066209000 CR4: 00000000001406e0
> Call Trace:
>  snd_seq_prioq_delete+0x8b/0xf0 sound/core/seq/seq_prioq.c:90
>  queue_delete+0x77/0xb0 sound/core/seq/seq_queue.c:152
>  snd_seq_queue_client_leave+0x34/0x130 sound/core/seq/seq_queue.c:595
>  seq_free_client1.part.5+0x10a/0x410 sound/core/seq/seq_clientmgr.c:258
>  seq_free_client1 sound/core/seq/seq_clientmgr.c:255 [inline]
>  seq_free_client+0x6f/0x170 sound/core/seq/seq_clientmgr.c:284
>  snd_seq_release+0x51/0xe0 sound/core/seq/seq_clientmgr.c:366
>  __fput+0x332/0x7f0 fs/file_table.c:208
>  ____fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x18a/0x260 kernel/task_work.c:116
>  get_signal+0x148f/0x1820 kernel/signal.c:2143
>  do_signal+0xd2/0x2190 arch/x86/kernel/signal.c:807
>  exit_to_usermode_loop+0x200/0x2a0 arch/x86/entry/common.c:156
>  prepare_exit_to_usermode arch/x86/entry/common.c:190 [inline]
>  syscall_return_slowpath+0x4d3/0x570 arch/x86/entry/common.c:259
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x4457d9
> RSP: 002b:00007f5262fedb58 EFLAGS: 00000286 ORIG_RAX: 0000000000000010
> RAX: 0000000000000000 RBX: 00000000007080a8 RCX: 00000000004457d9
> RDX: 0000000020001000 RSI: 000000004058534c RDI: 0000000000000005
> RBP: 0000000000002250 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000286 R12: 00000000006e0310
> R13: 0000000000000005 R14: 000000004058534c R15: 0000000020001000
> Code: f6 0f 84 90 00 00 00 e8 02 1e 2a fe 49 8d 7e 28 48 b8 00 00 00
> 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 1f 01 00 00 <49>
> 8b 46 28 49 8d 7c 24 08 48 89 fa 49 89 04 24 48 c1 ea 03 48
> RIP: snd_seq_prioq_cell_out+0x11d/0x260 sound/core/seq/seq_prioq.c:231
> RSP: ffff88005f7470b8
> CR2: ffffc9000392ddb8
> ---[ end trace cbaec69c4a9fdbfc ]---
>
> On commit fd694aa (Jan 26).

This is due to a forced resource release after the loop timeout.
You must have seen a message like
  ALSA: snd_seq_pool_done timeout: 1 cells remain
before the Oops.

Below is a simple fix.  I'm going to queue it to for-linus branch.

thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: seq: Don't handle loop timeout at snd_seq_pool_done()

snd_seq_pool_done() syncs with closing of all opened threads, but it
aborts the wait loop with a timeout, and proceeds to the release
resource even if not all threads have been closed.  The timeout was 5
seconds, and if you run a crazy stuff, it can exceed easily, and may
result in the access of the invalid memory address -- this is what
syzkaller detected in a bug report.

As a fix, let the code graduate from naiveness, simply remove the loop
timeout.

BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.com
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Feb 8, 2017
@tiwai
sound: use-after-free in snd_seq_queue_alloc
2f4c63e 
On Wed, 08 Feb 2017 10:41:14 +0100,
Dmitry Vyukov wrote:
>
> Hello,
>
>
> I've got the following report while running syzkaller fuzzer on
> 8b1b41e:
>
> BUG: KASAN: use-after-free in snd_seq_queue_alloc+0x663/0x690
> sound/core/seq/seq_queue.c:200 at addr ffff880086ba1d00
> Read of size 4 by task syz-executor2/31851
> CPU: 2 PID: 31851 Comm: syz-executor2 Not tainted 4.10.0-rc5+ torvalds#201
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>
> Call Trace:
>  __asan_report_load4_noabort+0x3e/0x40 mm/kasan/report.c:327
>  snd_seq_queue_alloc+0x663/0x690 sound/core/seq/seq_queue.c:200
>  snd_seq_ioctl_create_queue+0xad/0x310 sound/core/seq/seq_clientmgr.c:1508
>  snd_seq_ioctl+0x2da/0x4d0 sound/core/seq/seq_clientmgr.c:2130
>  vfs_ioctl fs/ioctl.c:43 [inline]
>  do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
>  SYSC_ioctl fs/ioctl.c:698 [inline]
>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> Allocated:
> PID = 31851
> [<ffffffff83483a17>] kzalloc include/linux/slab.h:490 [inline]
> [<ffffffff83483a17>] queue_new sound/core/seq/seq_queue.c:113 [inline]
> [<ffffffff83483a17>] snd_seq_queue_alloc+0x107/0x690
> sound/core/seq/seq_queue.c:191
> [<ffffffff834748dd>] snd_seq_ioctl_create_queue+0xad/0x310
> sound/core/seq/seq_clientmgr.c:1508
> [<ffffffff8347878a>] snd_seq_ioctl+0x2da/0x4d0
> sound/core/seq/seq_clientmgr.c:2130
> [<ffffffff81aa41cf>] vfs_ioctl fs/ioctl.c:43 [inline]
> [<ffffffff81aa41cf>] do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
> [<ffffffff81aa582f>] SYSC_ioctl fs/ioctl.c:698 [inline]
> [<ffffffff81aa582f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
> [<ffffffff841c9c81>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> Freed:
> PID = 31854
> [<ffffffff81a0b5c3>] kfree+0xd3/0x250 mm/slab.c:3822
> [<ffffffff834817e0>] queue_delete+0x90/0xb0 sound/core/seq/seq_queue.c:156
> [<ffffffff834826cc>] snd_seq_queue_delete+0x3c/0x50
> sound/core/seq/seq_queue.c:213
> [<ffffffff8347480a>] snd_seq_ioctl_delete_queue+0x6a/0x90
> sound/core/seq/seq_clientmgr.c:1534
> [<ffffffff8347878a>] snd_seq_ioctl+0x2da/0x4d0
> sound/core/seq/seq_clientmgr.c:2130
> [<ffffffff81aa41cf>] vfs_ioctl fs/ioctl.c:43 [inline]
> [<ffffffff81aa41cf>] do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
> [<ffffffff81aa582f>] SYSC_ioctl fs/ioctl.c:698 [inline]
> [<ffffffff81aa582f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
>
>
>
> Looking at the code:
>
> int snd_seq_queue_alloc(int client, int locked, unsigned int info_flags)
> {
>         struct snd_seq_queue *q;
>
>         q = queue_new(client, locked);
>         if (q == NULL)
>                 return -ENOMEM;
>         q->info_flags = info_flags;
>         if (queue_list_add(q) < 0) {
>                 queue_delete(q);
>                 return -ENOMEM;
>         }
>         snd_seq_queue_use(q->queue, client, 1); /* use this queue */
>         return q->queue;
> }
>
> After queue_list_add(q) q can be deleted by another thread, so
> snd_seq_queue_use(q->queue, client, 1) already potentially operates on
> deleted object.

A good catch!  The fix patch is below.

thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: seq: Fix race at creating a queue

When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it.  Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.

The fix is to reference the queue object at the right time.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Noltari pushed a commit to Noltari/linux that referenced this pull request Jun 17, 2017
@kiryl @gregkh
shmem: fix sleeping from atomic context
8936b74 
[ Upstream commit 253fd0f ]

Syzkaller fuzzer managed to trigger this:

    BUG: sleeping function called from invalid context at mm/shmem.c:852
    in_atomic(): 1, irqs_disabled(): 0, pid: 529, name: khugepaged
    3 locks held by khugepaged/529:
     #0:  (shrinker_rwsem){++++..}, at: [<ffffffff818d7ef1>] shrink_slab.part.59+0x121/0xd30 mm/vmscan.c:451
     #1:  (&type->s_umount_key#29){++++..}, at: [<ffffffff81a63630>] trylock_super+0x20/0x100 fs/super.c:392
     #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at: [<ffffffff818fd83e>] spin_lock include/linux/spinlock.h:302 [inline]
     #2:  (&(&sbinfo->shrinklist_lock)->rlock){+.+.-.}, at: [<ffffffff818fd83e>] shmem_unused_huge_shrink+0x28e/0x1490 mm/shmem.c:427
    CPU: 2 PID: 529 Comm: khugepaged Not tainted 4.10.0-rc5+ torvalds#201
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
       shmem_undo_range+0xb20/0x2710 mm/shmem.c:852
       shmem_truncate_range+0x27/0xa0 mm/shmem.c:939
       shmem_evict_inode+0x35f/0xca0 mm/shmem.c:1030
       evict+0x46e/0x980 fs/inode.c:553
       iput_final fs/inode.c:1515 [inline]
       iput+0x589/0xb20 fs/inode.c:1542
       shmem_unused_huge_shrink+0xbad/0x1490 mm/shmem.c:446
       shmem_unused_huge_scan+0x10c/0x170 mm/shmem.c:512
       super_cache_scan+0x376/0x450 fs/super.c:106
       do_shrink_slab mm/vmscan.c:378 [inline]
       shrink_slab.part.59+0x543/0xd30 mm/vmscan.c:481
       shrink_slab mm/vmscan.c:2592 [inline]
       shrink_node+0x2c7/0x870 mm/vmscan.c:2592
       shrink_zones mm/vmscan.c:2734 [inline]
       do_try_to_free_pages+0x369/0xc80 mm/vmscan.c:2776
       try_to_free_pages+0x3c6/0x900 mm/vmscan.c:2982
       __perform_reclaim mm/page_alloc.c:3301 [inline]
       __alloc_pages_direct_reclaim mm/page_alloc.c:3322 [inline]
       __alloc_pages_slowpath+0xa24/0x1c30 mm/page_alloc.c:3683
       __alloc_pages_nodemask+0x544/0xae0 mm/page_alloc.c:3848
       __alloc_pages include/linux/gfp.h:426 [inline]
       __alloc_pages_node include/linux/gfp.h:439 [inline]
       khugepaged_alloc_page+0xc2/0x1b0 mm/khugepaged.c:750
       collapse_huge_page+0x182/0x1fe0 mm/khugepaged.c:955
       khugepaged_scan_pmd+0xfdf/0x12a0 mm/khugepaged.c:1208
       khugepaged_scan_mm_slot mm/khugepaged.c:1727 [inline]
       khugepaged_do_scan mm/khugepaged.c:1808 [inline]
       khugepaged+0xe9b/0x1590 mm/khugepaged.c:1853
       kthread+0x326/0x3f0 kernel/kthread.c:227
       ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430

The iput() from atomic context was a bad idea: if after igrab() somebody
else calls iput() and we left with the last inode reference, our iput()
would lead to inode eviction and therefore sleeping.

This patch should fix the situation.

Link: http://lkml.kernel.org/r/20170131093141.GA15899@node.shutemov.name
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Dec 11, 2018
@mwbringmann @intel-lab-lkp
powerpc/mobility: Fix node detach/rename problem
73d6cee 
The PPC mobility code receives RTAS requests to delete nodes with
platform-/hardware-specific attributes when restarting the kernel
after a migration.  My example is for migration between a P8 Alpine
and a P8 Brazos.   Nodes to be deleted include 'ibm,random-v1',
'ibm,platform-facilities', 'ibm,sym-encryption-v1', and,
'ibm,compression-v1'.

The mobility.c code calls 'of_detach_node' for the nodes and their
children.  This makes calls to detach the properties and to remove
the associated sysfs/kernfs files.

Then new copies of the same nodes are next provided by the PHYP,
local copies are built, and a pointer to the 'struct device_node'
is passed to of_attach_node.  Before the call to of_attach_node,
the phandle is initialized to 0 when the data structure is alloced.
During the call to of_attach_node, it calls __of_attach_node which
pulls the actual name and phandle from just created sub-properties
named something like 'name' and 'ibm,phandle'.

This is all fine for the first migration.  The problem occurs with
the second and subsequent migrations when the PHYP on the new system
wants to replace the same set of nodes again, referenced with the
same names and phandle values.

On the second and subsequent migrations, the PHYP tells the system
to again delete the nodes 'ibm,platform-facilities', 'ibm,random-v1',
'ibm,compression-v1', 'ibm,sym-encryption-v1'.  It specifies these
nodes by its known set of phandle values -- the same handles used
by the PHYP on the source system are known on the target system.
The mobility.c code calls of_find_node_by_phandle() with these values
and ends up locating the first instance of each node that was added
during the original boot, instead of the second instance of each node
created after the first migration.  The detach during the second
migration fails with errors like,

[ 4565.030704] WARNING: CPU: 3 PID: 4787 at drivers/of/dynamic.c:252 __of_detach_node+0x8/0xa0
[ 4565.030708] Modules linked in: nfsv3 nfs_acl nfs tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag lockd grace fscache sunrpc xts vmx_crypto sg pseries_rng binfmt_misc ip_tables xfs libcrc32c sd_mod ibmveth ibmvscsi scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod
[ 4565.030733] CPU: 3 PID: 4787 Comm: drmgr Tainted: G        W         4.18.0-rc1-wi107836-v05-120+ torvalds#201
[ 4565.030737] NIP:  c0000000007c1ea8 LR: c0000000007c1fb4 CTR: 0000000000655170
[ 4565.030741] REGS: c0000003f302b690 TRAP: 0700   Tainted: G        W          (4.18.0-rc1-wi107836-v05-120+)
[ 4565.030745] MSR:  800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 22288822  XER: 0000000a
[ 4565.030757] CFAR: c0000000007c1fb0 IRQMASK: 1
[ 4565.030757] GPR00: c0000000007c1fa4 c0000003f302b910 c00000000114bf00 c0000003ffff8e68
[ 4565.030757] GPR04: 0000000000000001 ffffffffffffffff 800000c008e0b4b8 ffffffffffffffff
[ 4565.030757] GPR08: 0000000000000000 0000000000000001 0000000080000003 0000000000002843
[ 4565.030757] GPR12: 0000000000008800 c00000001ec9ae00 0000000040000000 0000000000000000
[ 4565.030757] GPR16: 0000000000000000 0000000000000008 0000000000000000 00000000f6ffffff
[ 4565.030757] GPR20: 0000000000000007 0000000000000000 c0000003e9f1f034 0000000000000001
[ 4565.030757] GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 4565.030757] GPR28: c000000001549d28 c000000001134828 c0000003ffff8e68 c0000003f302b930
[ 4565.030804] NIP [c0000000007c1ea8] __of_detach_node+0x8/0xa0
[ 4565.030808] LR [c0000000007c1fb4] of_detach_node+0x74/0xd0
[ 4565.030811] Call Trace:
[ 4565.030815] [c0000003f302b910] [c0000000007c1fa4] of_detach_node+0x64/0xd0 (unreliable)
[ 4565.030821] [c0000003f302b980] [c0000000000c33c4] dlpar_detach_node+0xb4/0x150
[ 4565.030826] [c0000003f302ba10] [c0000000000c3ffc] delete_dt_node+0x3c/0x80
[ 4565.030831] [c0000003f302ba40] [c0000000000c4380] pseries_devicetree_update+0x150/0x4f0
[ 4565.030836] [c0000003f302bb70] [c0000000000c479c] post_mobility_fixup+0x7c/0xf0
[ 4565.030841] [c0000003f302bbe0] [c0000000000c4908] migration_store+0xf8/0x130
[ 4565.030847] [c0000003f302bc70] [c000000000998160] kobj_attr_store+0x30/0x60
[ 4565.030852] [c0000003f302bc90] [c000000000412f14] sysfs_kf_write+0x64/0xa0
[ 4565.030857] [c0000003f302bcb0] [c000000000411cac] kernfs_fop_write+0x16c/0x240
[ 4565.030862] [c0000003f302bd00] [c000000000355f20] __vfs_write+0x40/0x220
[ 4565.030867] [c0000003f302bd90] [c000000000356358] vfs_write+0xc8/0x240
[ 4565.030872] [c0000003f302bde0] [c0000000003566cc] ksys_write+0x5c/0x100
[ 4565.030880] [c0000003f302be30] [c00000000000b288] system_call+0x5c/0x70
[ 4565.030884] Instruction dump:
[ 4565.030887] 38210070 38600000 e8010010 eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8
[ 4565.030895] 7c0803a6 4e800020 e9230098 7929f7e2 <0b090000> 2f890000 4cde0020 e9030040
[ 4565.030903] ---[ end trace 5bd54cb1df9d2976 ]---

The mobility.c code continues on during the second migration, accepts
the definitions of the new nodes from the PHYP and ends up renaming
the new properties e.g.

[ 4565.827296] Duplicate name in base, renamed to "ibm,platform-facilities#1"

There is no check like 'of_node_check_flag(np, OF_DETACHED)' within
of_find_node_by_phandle to skip nodes that are detached, but still
present due to caching or use count considerations.  Also, note that
of_find_node_by_phandle also uses a 'phandle_cache' which does not
appear to be updated when of_detach_node() is invoked.

We don't appear to have anything that invalidates the phandle_cache
when a node is removed.

The right solution may be for __of_detach_node() to invalidate
phandle_cache for the node being detached.  Alternatively, we can
manually invalidate / rebuild the phandle_cache at the point of
LPAR migration.  The latter solution is presented here.

Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
fbertux pushed a commit to OSSystems/linux that referenced this pull request Feb 1, 2021
@otavio
Merge pull request torvalds#201 from zandrey/5.10.x+fslc
a6a4e1a 
Update 5.10.x+fslc to v5.10.3
chombourger pushed a commit to chombourger/linux that referenced this pull request Feb 16, 2021
Merge pull request torvalds#201 in PROCESSOR-SDK/processor-sdk-linux …
971cc5a 
…from ~A0400828/processor-sdk-linux:for-6.2/prueth-fixes to processor-sdk-linux-4.19.y

* commit '5c44c1766d950231a28defc725ea4b944f4f44b2':
  net: ethernet: ti: icssg-prueth: fix TX descriptor not available case
  net: ethernet: ti: icssg-prueth: optimize napi rx during netif down
  net: ethernet: ti: icssg-prueth: add missed stats counters prueth_dma_rx_push() fail
  net: ti: icssg_prueth: implement shutdown command
  dmaengine: ti: clear pkt_info2 pkt type before setting
  net: ethernet: ti: icssg-prueth: remove redundant disable FT1
  net: ethernet: ti: icssg-prueth: Simplify promiscuous mode
  net: ti: icssg-prueth: Add allmulti support
  net: ti: icssg-prueth: Fix non promiscuous mode
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 15, 2021
@intel-lab-lkp
Staging: rtl8723bs: fix spaces in odm_RegConfig8723B.c
ca02f59 
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#11: FILE: ./hal/odm_RegConfig8723B.c:11:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#109: FILE: ./hal/odm_RegConfig8723B.c:109:
    +void odm_ConfigRF_RadioA_8723B(struct DM_ODM_T * pDM_Odm, u32 Addr, u32 Data)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#134: FILE: ./hal/odm_RegConfig8723B.c:134:
    +void odm_ConfigMAC_8723B(struct DM_ODM_T * pDM_Odm, u32 Addr, u8 Data)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#150: FILE: ./hal/odm_RegConfig8723B.c:150:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#173: FILE: ./hal/odm_RegConfig8723B.c:173:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#201: FILE: ./hal/odm_RegConfig8723B.c:201:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#229: FILE: ./hal/odm_RegConfig8723B.c:229:
    +	struct DM_ODM_T * pDM_Odm,

Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 15, 2021
@intel-lab-lkp
Staging: rtl8723bs: fix spaces in hal_com_phycfg.h
4abd675 
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#75: FILE: ./include/hal_com_phycfg.h:75:
    +struct adapter *	Adapter,

    ERROR:POINTER_LOCATION: "foo*		bar" should be "foo *bar"
    torvalds#95: FILE: ./include/hal_com_phycfg.h:95:
    +	u8*		RateIndex,

    ERROR:POINTER_LOCATION: "foo*		bar" should be "foo *bar"
    torvalds#96: FILE: ./include/hal_com_phycfg.h:96:
    +	s8*		PwrByRateVal,

    ERROR:POINTER_LOCATION: "foo*		bar" should be "foo *bar"
    torvalds#97: FILE: ./include/hal_com_phycfg.h:97:
    +	u8*		RateNum

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#107: FILE: ./include/hal_com_phycfg.h:107:
    +struct adapter *	padapter,

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#141: FILE: ./include/hal_com_phycfg.h:141:
    +struct adapter *	padapter,

    ERROR:POINTER_LOCATION: "foo*			bar" should be "foo *bar"
    torvalds#145: FILE: ./include/hal_com_phycfg.h:145:
    +u8*			Rates,

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#167: FILE: ./include/hal_com_phycfg.h:167:
    +	struct adapter *		padapter

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#172: FILE: ./include/hal_com_phycfg.h:172:
    +struct adapter *	padapter,

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#189: FILE: ./include/hal_com_phycfg.h:189:
    +struct adapter *		Adapter,

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#201: FILE: ./include/hal_com_phycfg.h:201:
    +struct adapter *		Adapter

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#206: FILE: ./include/hal_com_phycfg.h:206:
    +struct adapter *		Adapter

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#218: FILE: ./include/hal_com_phycfg.h:218:
    +struct adapter *	Adapter,

Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 16, 2021
@gregkh
Staging: rtl8723bs: fix spaces in odm_RegConfig8723B.c
37237d9 
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#11: FILE: ./hal/odm_RegConfig8723B.c:11:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#109: FILE: ./hal/odm_RegConfig8723B.c:109:
    +void odm_ConfigRF_RadioA_8723B(struct DM_ODM_T * pDM_Odm, u32 Addr, u32 Data)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#134: FILE: ./hal/odm_RegConfig8723B.c:134:
    +void odm_ConfigMAC_8723B(struct DM_ODM_T * pDM_Odm, u32 Addr, u8 Data)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#150: FILE: ./hal/odm_RegConfig8723B.c:150:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#173: FILE: ./hal/odm_RegConfig8723B.c:173:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#201: FILE: ./hal/odm_RegConfig8723B.c:201:
    +	struct DM_ODM_T * pDM_Odm,

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#229: FILE: ./hal/odm_RegConfig8723B.c:229:
    +	struct DM_ODM_T * pDM_Odm,

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marco Cesati <marcocesati@gmail.com>
Link: https://lore.kernel.org/r/20210315170618.2566-32-marcocesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 16, 2021
@gregkh
Staging: rtl8723bs: fix spaces in hal_com_phycfg.h
d9faf10 
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#75: FILE: ./include/hal_com_phycfg.h:75:
    +struct adapter *	Adapter,

    ERROR:POINTER_LOCATION: "foo*		bar" should be "foo *bar"
    torvalds#95: FILE: ./include/hal_com_phycfg.h:95:
    +	u8*		RateIndex,

    ERROR:POINTER_LOCATION: "foo*		bar" should be "foo *bar"
    torvalds#96: FILE: ./include/hal_com_phycfg.h:96:
    +	s8*		PwrByRateVal,

    ERROR:POINTER_LOCATION: "foo*		bar" should be "foo *bar"
    torvalds#97: FILE: ./include/hal_com_phycfg.h:97:
    +	u8*		RateNum

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#107: FILE: ./include/hal_com_phycfg.h:107:
    +struct adapter *	padapter,

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#141: FILE: ./include/hal_com_phycfg.h:141:
    +struct adapter *	padapter,

    ERROR:POINTER_LOCATION: "foo*			bar" should be "foo *bar"
    torvalds#145: FILE: ./include/hal_com_phycfg.h:145:
    +u8*			Rates,

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#167: FILE: ./include/hal_com_phycfg.h:167:
    +	struct adapter *		padapter

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#172: FILE: ./include/hal_com_phycfg.h:172:
    +struct adapter *	padapter,

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#189: FILE: ./include/hal_com_phycfg.h:189:
    +struct adapter *		Adapter,

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#201: FILE: ./include/hal_com_phycfg.h:201:
    +struct adapter *		Adapter

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#206: FILE: ./include/hal_com_phycfg.h:206:
    +struct adapter *		Adapter

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#218: FILE: ./include/hal_com_phycfg.h:218:
    +struct adapter *	Adapter,

Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marco Cesati <marcocesati@gmail.com>
Link: https://lore.kernel.org/r/20210315170618.2566-44-marcocesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Apr 5, 2021
@intel-lab-lkp
i2c: amd8111: Fix coding style issues
7dd5d04 
Fix the following checkpatch errors:

  ERROR: "foo * bar" should be "foo *bar"
  torvalds#189: FILE: drivers/i2c/busses/i2c-amd8111.c:189:

  ERROR: "foo * bar" should be "foo *bar"
  torvalds#191: FILE: drivers/i2c/busses/i2c-amd8111.c:191:

  ERROR: switch and case should be at the same indent
  torvalds#201: FILE: drivers/i2c/busses/i2c-amd8111.c:201:

  ERROR: switch and case should be at the same indent
  torvalds#359: FILE: drivers/i2c/busses/i2c-amd8111.c:359:

No functional changes.

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Zihao Tang <tangzihao1@hisilicon.com>
Cc: Jean Delvare <jdelvare@suse.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Apr 16, 2021
@wsakernel
i2c: amd8111: Fix coding style issues
5e77a61 
Fix the following checkpatch errors:

  ERROR: "foo * bar" should be "foo *bar"
  torvalds#189: FILE: drivers/i2c/busses/i2c-amd8111.c:189:

  ERROR: "foo * bar" should be "foo *bar"
  torvalds#191: FILE: drivers/i2c/busses/i2c-amd8111.c:191:

  ERROR: switch and case should be at the same indent
  torvalds#201: FILE: drivers/i2c/busses/i2c-amd8111.c:201:

  ERROR: switch and case should be at the same indent
  torvalds#359: FILE: drivers/i2c/busses/i2c-amd8111.c:359:

No functional changes.

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Zihao Tang <tangzihao1@hisilicon.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
akiernan pushed a commit to zuma-array/linux that referenced this pull request Nov 3, 2022
@akiernan
amlvideo2: fix unuse code and bad compare
dd2561d 
PD#150094: driver defect clean up:
torvalds#32
torvalds#86
torvalds#90
torvalds#92
torvalds#97
torvalds#101
torvalds#103
torvalds#152
torvalds#155
torvalds#157~torvalds#158
torvalds#164
torvalds#167
torvalds#169~torvalds#179
torvalds#187~torvalds#191
torvalds#193~torvalds#199
torvalds#201~torvalds#210
torvalds#212~torvalds#213
torvalds#316~torvalds#319
torvalds#385
torvalds#572
torvalds#693~torvalds#694
torvalds#696~torvalds#697

Change-Id: I9669e5c0d717ee2287faf57a271ff27692039802
Signed-off-by: Guosong Zhou <guosong.zhou@amlogic.com>
akiernan pushed a commit to zuma-array/linux that referenced this pull request Nov 4, 2022
@akiernan
amlvideo2: fix unuse code and bad compare
ac8d5fa 
PD#150094: driver defect clean up:
torvalds#32
torvalds#86
torvalds#90
torvalds#92
torvalds#97
torvalds#101
torvalds#103
torvalds#152
torvalds#155
torvalds#157~torvalds#158
torvalds#164
torvalds#167
torvalds#169~torvalds#179
torvalds#187~torvalds#191
torvalds#193~torvalds#199
torvalds#201~torvalds#210
torvalds#212~torvalds#213
torvalds#316~torvalds#319
torvalds#385
torvalds#572
torvalds#693~torvalds#694
torvalds#696~torvalds#697

Change-Id: I9669e5c0d717ee2287faf57a271ff27692039802
Signed-off-by: Guosong Zhou <guosong.zhou@amlogic.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 6, 2023
@yonghong-song @intel-lab-lkp
selftests/bpf: Fix sockopt_sk selftest
ce6a23c 
Commit f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
fixed NETLINK_LIST_MEMBERSHIPS length report which caused
selftest sockopt_sk failure. The failure log looks like

  test_sockopt_sk:PASS:join_cgroup /sockopt_sk 0 nsec
  run_test:PASS:skel_load 0 nsec
  run_test:PASS:setsockopt_link 0 nsec
  run_test:PASS:getsockopt_link 0 nsec
  getsetsockopt:FAIL:Unexpected NETLINK_LIST_MEMBERSHIPS value unexpected Unexpected NETLINK_LIST_MEMBERSHIPS value: actual 8 != expected 4
  run_test:PASS:getsetsockopt 0 nsec
  torvalds#201     sockopt_sk:FAIL

In net/netlink/af_netlink.c, function netlink_getsockopt(), for NETLINK_LIST_MEMBERSHIPS,
nlk->ngroups equals to 36. Before Commit f4e4534, the optlen is calculated as
  ALIGN(nlk->ngroups / 8, sizeof(u32)) = 4
After that commit, the optlen is
  ALIGN(BITS_TO_BYTES(nlk->ngroups), sizeof(u32)) = 8

Fix the test by setting the expected optlen to be 8.

Fixes: f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
Signed-off-by: Yonghong Song <yhs@fb.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Jun 6, 2023
@yonghong-song @anakryiko
selftests/bpf: Fix sockopt_sk selftest
69844e3 
Commit f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
fixed NETLINK_LIST_MEMBERSHIPS length report which caused
selftest sockopt_sk failure. The failure log looks like

  test_sockopt_sk:PASS:join_cgroup /sockopt_sk 0 nsec
  run_test:PASS:skel_load 0 nsec
  run_test:PASS:setsockopt_link 0 nsec
  run_test:PASS:getsockopt_link 0 nsec
  getsetsockopt:FAIL:Unexpected NETLINK_LIST_MEMBERSHIPS value unexpected Unexpected NETLINK_LIST_MEMBERSHIPS value: actual 8 != expected 4
  run_test:PASS:getsetsockopt 0 nsec
  torvalds#201     sockopt_sk:FAIL

In net/netlink/af_netlink.c, function netlink_getsockopt(), for NETLINK_LIST_MEMBERSHIPS,
nlk->ngroups equals to 36. Before Commit f4e4534, the optlen is calculated as
  ALIGN(nlk->ngroups / 8, sizeof(u32)) = 4
After that commit, the optlen is
  ALIGN(BITS_TO_BYTES(nlk->ngroups), sizeof(u32)) = 8

Fix the test by setting the expected optlen to be 8.

Fixes: f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230606172202.1606249-1-yhs@fb.com
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Jun 14, 2023
@yonghong-song @gregkh
selftests/bpf: Fix sockopt_sk selftest
34d67ec 
[ Upstream commit 69844e3 ]

Commit f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
fixed NETLINK_LIST_MEMBERSHIPS length report which caused
selftest sockopt_sk failure. The failure log looks like

  test_sockopt_sk:PASS:join_cgroup /sockopt_sk 0 nsec
  run_test:PASS:skel_load 0 nsec
  run_test:PASS:setsockopt_link 0 nsec
  run_test:PASS:getsockopt_link 0 nsec
  getsetsockopt:FAIL:Unexpected NETLINK_LIST_MEMBERSHIPS value unexpected Unexpected NETLINK_LIST_MEMBERSHIPS value: actual 8 != expected 4
  run_test:PASS:getsetsockopt 0 nsec
  torvalds#201     sockopt_sk:FAIL

In net/netlink/af_netlink.c, function netlink_getsockopt(), for NETLINK_LIST_MEMBERSHIPS,
nlk->ngroups equals to 36. Before Commit f4e4534, the optlen is calculated as
  ALIGN(nlk->ngroups / 8, sizeof(u32)) = 4
After that commit, the optlen is
  ALIGN(BITS_TO_BYTES(nlk->ngroups), sizeof(u32)) = 8

Fix the test by setting the expected optlen to be 8.

Fixes: f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230606172202.1606249-1-yhs@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
1054009064 pushed a commit to 1054009064/linux that referenced this pull request Jun 14, 2023
@yonghong-song @gregkh
selftests/bpf: Fix sockopt_sk selftest
81e11b6 
[ Upstream commit 69844e3 ]

Commit f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
fixed NETLINK_LIST_MEMBERSHIPS length report which caused
selftest sockopt_sk failure. The failure log looks like

  test_sockopt_sk:PASS:join_cgroup /sockopt_sk 0 nsec
  run_test:PASS:skel_load 0 nsec
  run_test:PASS:setsockopt_link 0 nsec
  run_test:PASS:getsockopt_link 0 nsec
  getsetsockopt:FAIL:Unexpected NETLINK_LIST_MEMBERSHIPS value unexpected Unexpected NETLINK_LIST_MEMBERSHIPS value: actual 8 != expected 4
  run_test:PASS:getsetsockopt 0 nsec
  torvalds#201     sockopt_sk:FAIL

In net/netlink/af_netlink.c, function netlink_getsockopt(), for NETLINK_LIST_MEMBERSHIPS,
nlk->ngroups equals to 36. Before Commit f4e4534, the optlen is calculated as
  ALIGN(nlk->ngroups / 8, sizeof(u32)) = 4
After that commit, the optlen is
  ALIGN(BITS_TO_BYTES(nlk->ngroups), sizeof(u32)) = 8

Fix the test by setting the expected optlen to be 8.

Fixes: f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230606172202.1606249-1-yhs@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Jun 14, 2023
@yonghong-song @gregkh
selftests/bpf: Fix sockopt_sk selftest
235325b 
[ Upstream commit 69844e3 ]

Commit f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
fixed NETLINK_LIST_MEMBERSHIPS length report which caused
selftest sockopt_sk failure. The failure log looks like

  test_sockopt_sk:PASS:join_cgroup /sockopt_sk 0 nsec
  run_test:PASS:skel_load 0 nsec
  run_test:PASS:setsockopt_link 0 nsec
  run_test:PASS:getsockopt_link 0 nsec
  getsetsockopt:FAIL:Unexpected NETLINK_LIST_MEMBERSHIPS value unexpected Unexpected NETLINK_LIST_MEMBERSHIPS value: actual 8 != expected 4
  run_test:PASS:getsetsockopt 0 nsec
  torvalds#201     sockopt_sk:FAIL

In net/netlink/af_netlink.c, function netlink_getsockopt(), for NETLINK_LIST_MEMBERSHIPS,
nlk->ngroups equals to 36. Before Commit f4e4534, the optlen is calculated as
  ALIGN(nlk->ngroups / 8, sizeof(u32)) = 4
After that commit, the optlen is
  ALIGN(BITS_TO_BYTES(nlk->ngroups), sizeof(u32)) = 8

Fix the test by setting the expected optlen to be 8.

Fixes: f4e4534 ("net/netlink: fix NETLINK_LIST_MEMBERSHIPS length report")
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20230606172202.1606249-1-yhs@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
RadxaStephen added a commit to RadxaStephen/linux that referenced this pull request Mar 6, 2024
@RadxaStephen
Merge pull request torvalds#201 from Radxa-Alvin/linux-5.10-gen-rkr4.1
03417e8 
Changes:
  * Radxa Zero 3W: add fusb302 support

Signed-off-by: Stephen Chen <stephen@radxa.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Nov 12, 2024
@geertu @intel-lab-lkp
dma-mapping: Save base/size instead of pointer to shared DMA pool
432ab6c 
On RZ/Five, which is non-coherent, and uses CONFIG_DMA_GLOBAL_POOL=y:

    Oops - store (or AMO) access fault [#1]
    CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-rc1-00015-g8a6e02d0c00e torvalds#201
    Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT)
    epc : __memset+0x60/0x100
     ra : __dma_alloc_from_coherent+0x150/0x17a
    epc : ffffffff8062d2bc ra : ffffffff80053a94 sp : ffffffc60000ba20
     gp : ffffffff812e9938 tp : ffffffd601920000 t0 : ffffffc6000d0000
     t1 : 0000000000000000 t2 : ffffffffe9600000 s0 : ffffffc60000baa0
     s1 : ffffffc6000d0000 a0 : ffffffc6000d0000 a1 : 0000000000000000
     a2 : 0000000000001000 a3 : ffffffc6000d1000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : ffffffd601adacc0 a7 : ffffffd601a841a8
     s2 : ffffffd6018573c0 s3 : 0000000000001000 s4 : ffffffd6019541e0
     s5 : 0000000200000022 s6 : ffffffd6018f8410 s7 : ffffffd6018573e8
     s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000010
     s11: 0000000000000000 t3 : 0000000000000000 t4 : ffffffffdefe62d1
     t5 : 000000001cd6a3a9 t6 : ffffffd601b2aad6
    status: 0000000200000120 badaddr: ffffffc6000d0000 cause: 0000000000000007
    [<ffffffff8062d2bc>] __memset+0x60/0x100
    [<ffffffff80053e1a>] dma_alloc_from_global_coherent+0x1c/0x28
    [<ffffffff80053056>] dma_direct_alloc+0x98/0x112
    [<ffffffff8005238c>] dma_alloc_attrs+0x78/0x86
    [<ffffffff8035fdb4>] rz_dmac_probe+0x3f6/0x50a
    [<ffffffff803a0694>] platform_probe+0x4c/0x8a

If CONFIG_DMA_GLOBAL_POOL=y, the reserved_mem structure passed to
rmem_dma_setup() is saved for later use, by saving the passed pointer.
However, when dma_init_reserved_memory() is called later, the pointer
has become stale, causing a crash.

E.g. in the RZ/Five case, the referenced memory now contains the
reserved_mem structure for the "mmode_resv0@30000" node (with base
0x30000 and size 0x10000), instead of the correct "pma_resv0@58000000"
node (with base 0x58000000 and size 0x8000000).

Fix this by saving the needed reserved_mem structure's contents instead.

Fixes: 8a6e02d ("of: reserved_mem: Restructure how the reserved memory regions are processed")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
bjoto pushed a commit to linux-riscv/linux-riscv that referenced this pull request Nov 12, 2024
@geertu @bjorn-rivos
dma-mapping: Save base/size instead of pointer to shared DMA pool
be5c09d 
On RZ/Five, which is non-coherent, and uses CONFIG_DMA_GLOBAL_POOL=y:

    Oops - store (or AMO) access fault [#1]
    CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-rc1-00015-g8a6e02d0c00e torvalds#201
    Hardware name: Renesas SMARC EVK based on r9a07g043f01 (DT)
    epc : __memset+0x60/0x100
     ra : __dma_alloc_from_coherent+0x150/0x17a
    epc : ffffffff8062d2bc ra : ffffffff80053a94 sp : ffffffc60000ba20
     gp : ffffffff812e9938 tp : ffffffd601920000 t0 : ffffffc6000d0000
     t1 : 0000000000000000 t2 : ffffffffe9600000 s0 : ffffffc60000baa0
     s1 : ffffffc6000d0000 a0 : ffffffc6000d0000 a1 : 0000000000000000
     a2 : 0000000000001000 a3 : ffffffc6000d1000 a4 : 0000000000000000
     a5 : 0000000000000000 a6 : ffffffd601adacc0 a7 : ffffffd601a841a8
     s2 : ffffffd6018573c0 s3 : 0000000000001000 s4 : ffffffd6019541e0
     s5 : 0000000200000022 s6 : ffffffd6018f8410 s7 : ffffffd6018573e8
     s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000010
     s11: 0000000000000000 t3 : 0000000000000000 t4 : ffffffffdefe62d1
     t5 : 000000001cd6a3a9 t6 : ffffffd601b2aad6
    status: 0000000200000120 badaddr: ffffffc6000d0000 cause: 0000000000000007
    [<ffffffff8062d2bc>] __memset+0x60/0x100
    [<ffffffff80053e1a>] dma_alloc_from_global_coherent+0x1c/0x28
    [<ffffffff80053056>] dma_direct_alloc+0x98/0x112
    [<ffffffff8005238c>] dma_alloc_attrs+0x78/0x86
    [<ffffffff8035fdb4>] rz_dmac_probe+0x3f6/0x50a
    [<ffffffff803a0694>] platform_probe+0x4c/0x8a

If CONFIG_DMA_GLOBAL_POOL=y, the reserved_mem structure passed to
rmem_dma_setup() is saved for later use, by saving the passed pointer.
However, when dma_init_reserved_memory() is called later, the pointer
has become stale, causing a crash.

E.g. in the RZ/Five case, the referenced memory now contains the
reserved_mem structure for the "mmode_resv0@30000" node (with base
0x30000 and size 0x10000), instead of the correct "pma_resv0@58000000"
node (with base 0x58000000 and size 0x8000000).

Fix this by saving the needed reserved_mem structure's contents instead.

Fixes: 8a6e02d ("of: reserved_mem: Restructure how the reserved memory regions are processed")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@oe5hpm