Update README #363
Closed
Update README #363
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
closed this
|
Sorry :') |
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 15, 2018
The fast path of get_user_pages_fast() disables IRQs and then does:
- gup_pud_range()
- gup_pmd_range()
- gup_pte_range()
- flush_dcache_page()
However, flush_dcache_page() makes a smp_call_function(), and using
smp_call_function() when IRQs are disabled is not allowed.
In order to work around this problem, this commit prevents the fast
path from get_user_pages_fast() from being used on SMP, and directly
uses the slow path, which doesn't disable interrupts.
Fixes the following warning when get_futex_key() is called:
WARNING: CPU: 1 PID: 410 at kernel/smp.c:416 smp_call_function_many+0x1fc/0x2ac
Modules linked in:
CPU: 1 PID: 410 Comm: wdc-pfmu-test Tainted: G O 4.13.0-00035-g0d3023c733a0-dirty torvalds#363
task: 97d9a120 task.stack: 97d2e000
PC is at smp_call_function_many+0x1fc/0x2ac
PR is at smp_call_function_many+0x1e2/0x2ac
PC : 88071fd4 SP : 97d2fcd4 SR : 400080f1
TEA : c06d6840
R0 : 000000f0 R1 : 00000002 R2 : 00000000 R3 : 8849c89c
R4 : 886d62c4 R5 : 886d62c4 R6 : 886db928 R7 : 884a9dec
R8 : 00000000 R9 : ffffffff R10 : 8844667c R11 : 29ee9000
R12 : 8844667c R13 : 00000001 R14 : 97d2fcd4
MACH: 000177e7 MACL: 0000018c GBR : 295742d0 PR : 88071fba
Call trace:
[<8800fe2c>] sh4_flush_dcache_page+0x0/0xa4
[<880720a2>] smp_call_function+0x1e/0x50
[<8800fe2c>] sh4_flush_dcache_page+0x0/0xa4
[<8800ecc0>] flush_dcache_page+0x34/0x74
[<88010d1c>] gup_pte_range+0xd0/0x140
[<88010e04>] gup_pmd_range+0x78/0xa8
[<88010c4c>] gup_pte_range+0x0/0x140
[<88011006>] get_user_pages_fast+0xda/0x130
[<8806f376>] get_futex_key+0x72/0x3a0
[<8806f6a4>] futex_wait_setup+0x0/0x10c
[<88055a08>] __rcu_read_unlock+0x0/0x54
[<880559c8>] __rcu_read_lock+0x0/0x1c
[<88010f2c>] get_user_pages_fast+0x0/0x130
[<8806f6de>] futex_wait_setup+0x3a/0x10c
[<8806f6a4>] futex_wait_setup+0x0/0x10c
[<8806f852>] futex_wait+0xa2/0x1b8
[<8806f6a4>] futex_wait_setup+0x0/0x10c
[<88071c00>] smp_call_function_single+0xac/0x108
[<8800e908>] cache_noop+0x0/0xc
[<8800e908>] cache_noop+0x0/0xc
[<88071018>] do_futex+0x108/0x8f8
[<880bdfe4>] finish_fault+0x38/0x70
[<880bdff2>] finish_fault+0x46/0x70
[<880bf212>] handle_mm_fault+0x2f6/0x954
[<880bf21a>] handle_mm_fault+0x2fe/0x954
[<88030e64>] resched_curr+0x54/0x6c
[<8832be9e>] _raw_spin_lock_irqsave+0xa/0x18
[<880718dc>] SyS_futex+0xd4/0x124
[<8801488e>] SyS_clone+0x16/0x24
[<8800727e>] syscall_call+0x18/0x1e
[<88071808>] SyS_futex+0x0/0x124
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 29, 2019
Currently mm_iommu_do_alloc() is called in 2 cases: - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory; - vfio_pci_nvgpu_regops::mmap() for GPU memory. One of the differences here is that the mmap() is called with mm::mmap_sem help and mm_iommu_do_alloc() locks mm::mmap_sem itself (when adjusting locked_vm and when pinning pages) which can potentially cause a deadlock. We did not hit this yet because the mmap() path does not adjust locked_vm and does not pin pages. However with CONFIG_DEBUG_LOCKDEP=y there is an annoying warning (below, it is slightly confusing). This makes a few changes to reduce the amount of time spent under a lock. This holds mem_list_mutex only when looking or changing the mem list. This means the list is checked twice now for the normal memory case - before starting pinning and before adding the item to the list. This changes mm_iommu_do_alloc() to only allocate and add an iommu memory descriptor (used to deal with both normal and GPU memory in a rather messy way). This cleans the code in a way that mm_iommu_new() and mm_iommu_do_alloc() do not need to test for (dev_hpa != MM_IOMMU_TABLE_INVALID_HPA) which makes the code simpler. This moves locked_vm decrementing from under mem_list_mutex for the same reasons. This is one of the lockdep warnings: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-rc2-le_nv2_aikATfstn1-p1 torvalds#363 Not tainted ------------------------------------------------------ qemu-system-ppc/8038 is trying to acquire lock: 000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490 but task is already holding lock: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: lock_acquire+0xf8/0x260 down_write+0x44/0xa0 mm_iommu_adjust_locked_vm.part.1+0x4c/0x190 mm_iommu_do_alloc+0x310/0x490 tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x94/0x430 [vfio] do_vfs_ioctl+0xe4/0x930 ksys_ioctl+0xc4/0x110 sys_ioctl+0x28/0x80 system_call+0x5c/0x70 -> #0 (mem_list_mutex){+.+.}: __lock_acquire+0x1484/0x1900 lock_acquire+0xf8/0x260 __mutex_lock+0x88/0xa70 mm_iommu_do_alloc+0x70/0x490 vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci] vfio_pci_mmap+0x198/0x2a0 [vfio_pci] vfio_device_fops_mmap+0x44/0x70 [vfio] mmap_region+0x5d4/0x770 do_mmap+0x42c/0x650 vm_mmap_pgoff+0x124/0x160 ksys_mmap_pgoff+0xdc/0x2f0 sys_mmap+0x40/0x80 system_call+0x5c/0x70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(mem_list_mutex); lock(&mm->mmap_sem); lock(mem_list_mutex); *** DEADLOCK *** 1 lock held by qemu-system-ppc/8038: #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 3, 2019
Currently mm_iommu_do_alloc() is called in 2 cases: - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory: this locks &mem_list_mutex and then locks mm::mmap_sem several times when adjusting locked_vm or pinning pages; - vfio_pci_nvgpu_regops::mmap() for GPU memory: this is called with mm::mmap_sem held already and it locks &mem_list_mutex. So one can craft a userspace program to do special ioctl and mmap in 2 threads concurrently and cause a deadlock which lockdep warns about (below). We did not hit this yet because QEMU constructs the machine in a single thread. This moves the overlap check next to where the new entry is added and reduces the amount of time spent with &mem_list_mutex held. This moves locked_vm adjustment from under &mem_list_mutex. This relies on mm_iommu_adjust_locked_vm() doing nothing when entries==0. This is one of the lockdep warnings: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-rc2-le_nv2_aikATfstn1-p1 torvalds#363 Not tainted ------------------------------------------------------ qemu-system-ppc/8038 is trying to acquire lock: 000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490 but task is already holding lock: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: lock_acquire+0xf8/0x260 down_write+0x44/0xa0 mm_iommu_adjust_locked_vm.part.1+0x4c/0x190 mm_iommu_do_alloc+0x310/0x490 tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x94/0x430 [vfio] do_vfs_ioctl+0xe4/0x930 ksys_ioctl+0xc4/0x110 sys_ioctl+0x28/0x80 system_call+0x5c/0x70 -> #0 (mem_list_mutex){+.+.}: __lock_acquire+0x1484/0x1900 lock_acquire+0xf8/0x260 __mutex_lock+0x88/0xa70 mm_iommu_do_alloc+0x70/0x490 vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci] vfio_pci_mmap+0x198/0x2a0 [vfio_pci] vfio_device_fops_mmap+0x44/0x70 [vfio] mmap_region+0x5d4/0x770 do_mmap+0x42c/0x650 vm_mmap_pgoff+0x124/0x160 ksys_mmap_pgoff+0xdc/0x2f0 sys_mmap+0x40/0x80 system_call+0x5c/0x70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(mem_list_mutex); lock(&mm->mmap_sem); lock(mem_list_mutex); *** DEADLOCK *** 1 lock held by qemu-system-ppc/8038: #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 Fixes: c10c21e ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19) Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 3, 2019
Currently mm_iommu_do_alloc() is called in 2 cases: - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory: this locks &mem_list_mutex and then locks mm::mmap_sem several times when adjusting locked_vm or pinning pages; - vfio_pci_nvgpu_regops::mmap() for GPU memory: this is called with mm::mmap_sem held already and it locks &mem_list_mutex. So one can craft a userspace program to do special ioctl and mmap in 2 threads concurrently and cause a deadlock which lockdep warns about (below). We did not hit this yet because QEMU constructs the machine in a single thread. This moves the overlap check next to where the new entry is added and reduces the amount of time spent with &mem_list_mutex held. This moves locked_vm adjustment from under &mem_list_mutex. This relies on mm_iommu_adjust_locked_vm() doing nothing when entries==0. This is one of the lockdep warnings: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-rc2-le_nv2_aikATfstn1-p1 torvalds#363 Not tainted ------------------------------------------------------ qemu-system-ppc/8038 is trying to acquire lock: 000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490 but task is already holding lock: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: lock_acquire+0xf8/0x260 down_write+0x44/0xa0 mm_iommu_adjust_locked_vm.part.1+0x4c/0x190 mm_iommu_do_alloc+0x310/0x490 tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x94/0x430 [vfio] do_vfs_ioctl+0xe4/0x930 ksys_ioctl+0xc4/0x110 sys_ioctl+0x28/0x80 system_call+0x5c/0x70 -> #0 (mem_list_mutex){+.+.}: __lock_acquire+0x1484/0x1900 lock_acquire+0xf8/0x260 __mutex_lock+0x88/0xa70 mm_iommu_do_alloc+0x70/0x490 vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci] vfio_pci_mmap+0x198/0x2a0 [vfio_pci] vfio_device_fops_mmap+0x44/0x70 [vfio] mmap_region+0x5d4/0x770 do_mmap+0x42c/0x650 vm_mmap_pgoff+0x124/0x160 ksys_mmap_pgoff+0xdc/0x2f0 sys_mmap+0x40/0x80 system_call+0x5c/0x70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(mem_list_mutex); lock(&mm->mmap_sem); lock(mem_list_mutex); *** DEADLOCK *** 1 lock held by qemu-system-ppc/8038: #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 Fixes: c10c21e ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19) Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
mpe
pushed a commit
to linuxppc/linux
that referenced
this pull request
Apr 21, 2019
Currently mm_iommu_do_alloc() is called in 2 cases: - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory: this locks &mem_list_mutex and then locks mm::mmap_sem several times when adjusting locked_vm or pinning pages; - vfio_pci_nvgpu_regops::mmap() for GPU memory: this is called with mm::mmap_sem held already and it locks &mem_list_mutex. So one can craft a userspace program to do special ioctl and mmap in 2 threads concurrently and cause a deadlock which lockdep warns about (below). We did not hit this yet because QEMU constructs the machine in a single thread. This moves the overlap check next to where the new entry is added and reduces the amount of time spent with &mem_list_mutex held. This moves locked_vm adjustment from under &mem_list_mutex. This relies on mm_iommu_adjust_locked_vm() doing nothing when entries==0. This is one of the lockdep warnings: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-rc2-le_nv2_aikATfstn1-p1 torvalds#363 Not tainted ------------------------------------------------------ qemu-system-ppc/8038 is trying to acquire lock: 000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490 but task is already holding lock: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: lock_acquire+0xf8/0x260 down_write+0x44/0xa0 mm_iommu_adjust_locked_vm.part.1+0x4c/0x190 mm_iommu_do_alloc+0x310/0x490 tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x94/0x430 [vfio] do_vfs_ioctl+0xe4/0x930 ksys_ioctl+0xc4/0x110 sys_ioctl+0x28/0x80 system_call+0x5c/0x70 -> #0 (mem_list_mutex){+.+.}: __lock_acquire+0x1484/0x1900 lock_acquire+0xf8/0x260 __mutex_lock+0x88/0xa70 mm_iommu_do_alloc+0x70/0x490 vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci] vfio_pci_mmap+0x198/0x2a0 [vfio_pci] vfio_device_fops_mmap+0x44/0x70 [vfio] mmap_region+0x5d4/0x770 do_mmap+0x42c/0x650 vm_mmap_pgoff+0x124/0x160 ksys_mmap_pgoff+0xdc/0x2f0 sys_mmap+0x40/0x80 system_call+0x5c/0x70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(mem_list_mutex); lock(&mm->mmap_sem); lock(mem_list_mutex); *** DEADLOCK *** 1 lock held by qemu-system-ppc/8038: #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 Fixes: c10c21e ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19) Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
ynezz
pushed a commit
to ynezz/linux
that referenced
this pull request
May 3, 2019
Currently mm_iommu_do_alloc() is called in 2 cases: - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory: this locks &mem_list_mutex and then locks mm::mmap_sem several times when adjusting locked_vm or pinning pages; - vfio_pci_nvgpu_regops::mmap() for GPU memory: this is called with mm::mmap_sem held already and it locks &mem_list_mutex. So one can craft a userspace program to do special ioctl and mmap in 2 threads concurrently and cause a deadlock which lockdep warns about (below). We did not hit this yet because QEMU constructs the machine in a single thread. This moves the overlap check next to where the new entry is added and reduces the amount of time spent with &mem_list_mutex held. This moves locked_vm adjustment from under &mem_list_mutex. This relies on mm_iommu_adjust_locked_vm() doing nothing when entries==0. This is one of the lockdep warnings: ====================================================== WARNING: possible circular locking dependency detected 5.1.0-rc2-le_nv2_aikATfstn1-p1 torvalds#363 Not tainted ------------------------------------------------------ qemu-system-ppc/8038 is trying to acquire lock: 000000002ec6c453 (mem_list_mutex){+.+.}, at: mm_iommu_do_alloc+0x70/0x490 but task is already holding lock: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++}: lock_acquire+0xf8/0x260 down_write+0x44/0xa0 mm_iommu_adjust_locked_vm.part.1+0x4c/0x190 mm_iommu_do_alloc+0x310/0x490 tce_iommu_ioctl.part.9+0xb84/0x1150 [vfio_iommu_spapr_tce] vfio_fops_unl_ioctl+0x94/0x430 [vfio] do_vfs_ioctl+0xe4/0x930 ksys_ioctl+0xc4/0x110 sys_ioctl+0x28/0x80 system_call+0x5c/0x70 -> #0 (mem_list_mutex){+.+.}: __lock_acquire+0x1484/0x1900 lock_acquire+0xf8/0x260 __mutex_lock+0x88/0xa70 mm_iommu_do_alloc+0x70/0x490 vfio_pci_nvgpu_mmap+0xc0/0x130 [vfio_pci] vfio_pci_mmap+0x198/0x2a0 [vfio_pci] vfio_device_fops_mmap+0x44/0x70 [vfio] mmap_region+0x5d4/0x770 do_mmap+0x42c/0x650 vm_mmap_pgoff+0x124/0x160 ksys_mmap_pgoff+0xdc/0x2f0 sys_mmap+0x40/0x80 system_call+0x5c/0x70 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(mem_list_mutex); lock(&mm->mmap_sem); lock(mem_list_mutex); *** DEADLOCK *** 1 lock held by qemu-system-ppc/8038: #0: 00000000fd7da97f (&mm->mmap_sem){++++}, at: vm_mmap_pgoff+0xf0/0x160 Fixes: c10c21e ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19) Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
ruscur
pushed a commit
to ruscur/linux
that referenced
this pull request
Oct 6, 2020
Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
mpe
pushed a commit
to linuxppc/linux
that referenced
this pull request
Oct 6, 2020
Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 6, 2020
Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 4, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 4, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 4, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 4, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Nov 5, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Nov 5, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Nov 5, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
heftig
pushed a commit
to zen-kernel/zen-kernel
that referenced
this pull request
Nov 5, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 8, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 8, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 10, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Nov 10, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Nov 10, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Nov 10, 2020
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chombourger
pushed a commit
to chombourger/linux
that referenced
this pull request
Feb 16, 2021
commit aea948b upstream. Every error log reported by OPAL is exported to userspace through a sysfs interface and notified using kobject_uevent(). The userspace daemon (opal_errd) then reads the error log and acknowledges the error log is saved safely to disk. Once acknowledged the kernel removes the respective sysfs file entry causing respective resources to be released including kobject. However it's possible the userspace daemon may already be scanning elog entries when a new sysfs elog entry is created by the kernel. User daemon may read this new entry and ack it even before kernel can notify userspace about it through kobject_uevent() call. If that happens then we have a potential race between elog_ack_store->kobject_put() and kobject_uevent which can lead to use-after-free of a kernfs object resulting in a kernel crash. eg: BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb Faulting instruction address: 0xc0000000008ff2a0 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty torvalds#363 ... NIP kobject_uevent_env+0xa0/0x910 LR elog_event+0x1f4/0x2d0 Call Trace: 0x5deadbeef0000122 (unreliable) elog_event+0x1f4/0x2d0 irq_thread_fn+0x4c/0xc0 irq_thread+0x1c0/0x2b0 kthread+0x1c4/0x1d0 ret_from_kernel_thread+0x5c/0x6c This patch fixes this race by protecting the sysfs file creation/notification by holding a reference count on kobject until we safely send kobject_uevent(). The function create_elog_obj() returns the elog object which if used by caller function will end up in use-after-free problem again. However, the return value of create_elog_obj() function isn't being used today and there is no need as well. Hence change it to return void to make this fix complete. Fixes: 774fea1 ("powerpc/powernv: Read OPAL error log and export it through sysfs") Cc: stable@vger.kernel.org # v3.15+ Reported-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Reviewed-by: Oliver O'Halloran <oohall@gmail.com> Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> [mpe: Rework the logic to use a single return, reword comments, add oops] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 15, 2021
This commit fixes the following checkpatch.pl errors:
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#57: FILE: ./hal/HalPhyRf_8723B.c:57:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#138: FILE: ./hal/HalPhyRf_8723B.c:138:
+static void setCCKFilterCoefficient(struct DM_ODM_T * pDM_Odm, u8 CCKSwingIndex)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#162: FILE: ./hal/HalPhyRf_8723B.c:162:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#188: FILE: ./hal/HalPhyRf_8723B.c:188:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#363: FILE: ./hal/HalPhyRf_8723B.c:363:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#371: FILE: ./hal/HalPhyRf_8723B.c:371:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#412: FILE: ./hal/HalPhyRf_8723B.c:412:
+void ConfigureTxpowerTrack_8723B(struct TXPWRTRACK_CFG * pConfig)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#440: FILE: ./hal/HalPhyRf_8723B.c:440:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#551: FILE: ./hal/HalPhyRf_8723B.c:551:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#765: FILE: ./hal/HalPhyRf_8723B.c:765:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#872: FILE: ./hal/HalPhyRf_8723B.c:872:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1095: FILE: ./hal/HalPhyRf_8723B.c:1095:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1097: FILE: ./hal/HalPhyRf_8723B.c:1097:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1175: FILE: ./hal/HalPhyRf_8723B.c:1175:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1177: FILE: ./hal/HalPhyRf_8723B.c:1177:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1250: FILE: ./hal/HalPhyRf_8723B.c:1250:
+void ODM_SetIQCbyRFpath(struct DM_ODM_T * pDM_Odm, u32 RFpath)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1253: FILE: ./hal/HalPhyRf_8723B.c:1253:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1295: FILE: ./hal/HalPhyRf_8723B.c:1295:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1313: FILE: ./hal/HalPhyRf_8723B.c:1313:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1333: FILE: ./hal/HalPhyRf_8723B.c:1333:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1363: FILE: ./hal/HalPhyRf_8723B.c:1363:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1387: FILE: ./hal/HalPhyRf_8723B.c:1387:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1492: FILE: ./hal/HalPhyRf_8723B.c:1492:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1700: FILE: ./hal/HalPhyRf_8723B.c:1700:
+static void phy_LCCalibrate_8723B(struct DM_ODM_T * pDM_Odm, bool is2T)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1787: FILE: ./hal/HalPhyRf_8723B.c:1787:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1833: FILE: ./hal/HalPhyRf_8723B.c:1833:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#2041: FILE: ./hal/HalPhyRf_8723B.c:2041:
+void PHY_LCCalibrate_8723B(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
This commit fixes the following checkpatch.pl errors:
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#285: FILE: ./hal/odm.c:285:
+void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#287: FILE: ./hal/odm.c:287:
+void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#289: FILE: ./hal/odm.c:289:
+void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#291: FILE: ./hal/odm.c:291:
+void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#305: FILE: ./hal/odm.c:305:
+void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#309: FILE: ./hal/odm.c:309:
+void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#311: FILE: ./hal/odm.c:311:
+void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#313: FILE: ./hal/odm.c:313:
+void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#315: FILE: ./hal/odm.c:315:
+void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#323: FILE: ./hal/odm.c:323:
+void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#325: FILE: ./hal/odm.c:325:
+void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#327: FILE: ./hal/odm.c:327:
+void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#330: FILE: ./hal/odm.c:330:
+void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#338: FILE: ./hal/odm.c:338:
+void odm_InitHybridAntDiv(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#341: FILE: ./hal/odm.c:341:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#349: FILE: ./hal/odm.c:349:
+void odm_SetRxIdleAnt(struct DM_ODM_T * pDM_Odm, u8 Ant, bool bDualPath);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#353: FILE: ./hal/odm.c:353:
+void odm_HwAntDiv(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#363: FILE: ./hal/odm.c:363:
+void ODM_DMInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#393: FILE: ./hal/odm.c:393:
+void ODM_DMWatchdog(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#420: FILE: ./hal/odm.c:420:
+ struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#448: FILE: ./hal/odm.c:448:
+void ODM_CmnInfoInit(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, u32 Value)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#560: FILE: ./hal/odm.c:560:
+void ODM_CmnInfoHook(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, void *pValue)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#689: FILE: ./hal/odm.c:689:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#717: FILE: ./hal/odm.c:717:
+void ODM_CmnInfoUpdate(struct DM_ODM_T * pDM_Odm, u32 CmnInfo, u64 Value)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#831: FILE: ./hal/odm.c:831:
+void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#841: FILE: ./hal/odm.c:841:
+void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#867: FILE: ./hal/odm.c:867:
+void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#888: FILE: ./hal/odm.c:888:
+void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#935: FILE: ./hal/odm.c:935:
+void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#937: FILE: ./hal/odm.c:937:
+ struct ODM_RATE_ADAPTIVE * pOdmRA = &pDM_Odm->RateAdaptive;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#953: FILE: ./hal/odm.c:953:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1083: FILE: ./hal/odm.c:1083:
+void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1094: FILE: ./hal/odm.c:1094:
+void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1131: FILE: ./hal/odm.c:1131:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1137: FILE: ./hal/odm.c:1137:
+ struct ODM_RATE_ADAPTIVE * pRA = &pDM_Odm->RateAdaptive;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1196: FILE: ./hal/odm.c:1196:
+void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1198: FILE: ./hal/odm.c:1198:
+ struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1204: FILE: ./hal/odm.c:1204:
+void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1217: FILE: ./hal/odm.c:1217:
+ struct DM_ODM_T * pDM_Odm = &(pHalData->odmpriv);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1234: FILE: ./hal/odm.c:1234:
+void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1243: FILE: ./hal/odm.c:1243:
+ struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1306: FILE: ./hal/odm.c:1306:
+static u8 getSwingIndex(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1330: FILE: ./hal/odm.c:1330:
+void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1374: FILE: ./hal/odm.c:1374:
+void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1398: FILE: ./hal/odm.c:1398:
+void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1400: FILE: ./hal/odm.c:1400:
+ struct SWAT_T * pDM_SWAT_Table = &pDM_Odm->DM_SWAT_Table;
Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2021
This commit fixes the following checkpatch.pl errors:
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#57: FILE: ./hal/HalPhyRf_8723B.c:57:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#138: FILE: ./hal/HalPhyRf_8723B.c:138:
+static void setCCKFilterCoefficient(struct DM_ODM_T * pDM_Odm, u8 CCKSwingIndex)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#162: FILE: ./hal/HalPhyRf_8723B.c:162:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#188: FILE: ./hal/HalPhyRf_8723B.c:188:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#363: FILE: ./hal/HalPhyRf_8723B.c:363:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#371: FILE: ./hal/HalPhyRf_8723B.c:371:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#412: FILE: ./hal/HalPhyRf_8723B.c:412:
+void ConfigureTxpowerTrack_8723B(struct TXPWRTRACK_CFG * pConfig)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#440: FILE: ./hal/HalPhyRf_8723B.c:440:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#551: FILE: ./hal/HalPhyRf_8723B.c:551:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#765: FILE: ./hal/HalPhyRf_8723B.c:765:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#872: FILE: ./hal/HalPhyRf_8723B.c:872:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1095: FILE: ./hal/HalPhyRf_8723B.c:1095:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1097: FILE: ./hal/HalPhyRf_8723B.c:1097:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1175: FILE: ./hal/HalPhyRf_8723B.c:1175:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1177: FILE: ./hal/HalPhyRf_8723B.c:1177:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1250: FILE: ./hal/HalPhyRf_8723B.c:1250:
+void ODM_SetIQCbyRFpath(struct DM_ODM_T * pDM_Odm, u32 RFpath)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1253: FILE: ./hal/HalPhyRf_8723B.c:1253:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1295: FILE: ./hal/HalPhyRf_8723B.c:1295:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1313: FILE: ./hal/HalPhyRf_8723B.c:1313:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1333: FILE: ./hal/HalPhyRf_8723B.c:1333:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1363: FILE: ./hal/HalPhyRf_8723B.c:1363:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1387: FILE: ./hal/HalPhyRf_8723B.c:1387:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1492: FILE: ./hal/HalPhyRf_8723B.c:1492:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1700: FILE: ./hal/HalPhyRf_8723B.c:1700:
+static void phy_LCCalibrate_8723B(struct DM_ODM_T * pDM_Odm, bool is2T)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1787: FILE: ./hal/HalPhyRf_8723B.c:1787:
+ struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1833: FILE: ./hal/HalPhyRf_8723B.c:1833:
+ struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#2041: FILE: ./hal/HalPhyRf_8723B.c:2041:
+void PHY_LCCalibrate_8723B(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-16-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
This commit fixes the following checkpatch.pl errors:
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#285: FILE: ./hal/odm.c:285:
+void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#287: FILE: ./hal/odm.c:287:
+void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#289: FILE: ./hal/odm.c:289:
+void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#291: FILE: ./hal/odm.c:291:
+void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#305: FILE: ./hal/odm.c:305:
+void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#309: FILE: ./hal/odm.c:309:
+void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#311: FILE: ./hal/odm.c:311:
+void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#313: FILE: ./hal/odm.c:313:
+void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#315: FILE: ./hal/odm.c:315:
+void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#323: FILE: ./hal/odm.c:323:
+void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#325: FILE: ./hal/odm.c:325:
+void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#327: FILE: ./hal/odm.c:327:
+void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#330: FILE: ./hal/odm.c:330:
+void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#338: FILE: ./hal/odm.c:338:
+void odm_InitHybridAntDiv(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#341: FILE: ./hal/odm.c:341:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#349: FILE: ./hal/odm.c:349:
+void odm_SetRxIdleAnt(struct DM_ODM_T * pDM_Odm, u8 Ant, bool bDualPath);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#353: FILE: ./hal/odm.c:353:
+void odm_HwAntDiv(struct DM_ODM_T * pDM_Odm);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#363: FILE: ./hal/odm.c:363:
+void ODM_DMInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#393: FILE: ./hal/odm.c:393:
+void ODM_DMWatchdog(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#420: FILE: ./hal/odm.c:420:
+ struct DIG_T * pDM_DigTable = &pDM_Odm->DM_DigTable;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#448: FILE: ./hal/odm.c:448:
+void ODM_CmnInfoInit(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, u32 Value)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#560: FILE: ./hal/odm.c:560:
+void ODM_CmnInfoHook(struct DM_ODM_T * pDM_Odm, enum ODM_CMNINFO_E CmnInfo, void *pValue)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#689: FILE: ./hal/odm.c:689:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#717: FILE: ./hal/odm.c:717:
+void ODM_CmnInfoUpdate(struct DM_ODM_T * pDM_Odm, u32 CmnInfo, u64 Value)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#831: FILE: ./hal/odm.c:831:
+void odm_CommonInfoSelfInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#841: FILE: ./hal/odm.c:841:
+void odm_CommonInfoSelfUpdate(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#867: FILE: ./hal/odm.c:867:
+void odm_CmnInfoInit_Debug(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
torvalds#888: FILE: ./hal/odm.c:888:
+void odm_BasicDbgMessage(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#935: FILE: ./hal/odm.c:935:
+void odm_RateAdaptiveMaskInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#937: FILE: ./hal/odm.c:937:
+ struct ODM_RATE_ADAPTIVE * pOdmRA = &pDM_Odm->RateAdaptive;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#953: FILE: ./hal/odm.c:953:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1083: FILE: ./hal/odm.c:1083:
+void odm_RefreshRateAdaptiveMask(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1094: FILE: ./hal/odm.c:1094:
+void odm_RefreshRateAdaptiveMaskCE(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1131: FILE: ./hal/odm.c:1131:
+ struct DM_ODM_T * pDM_Odm,
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1137: FILE: ./hal/odm.c:1137:
+ struct ODM_RATE_ADAPTIVE * pRA = &pDM_Odm->RateAdaptive;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1196: FILE: ./hal/odm.c:1196:
+void odm_RSSIMonitorInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1198: FILE: ./hal/odm.c:1198:
+ struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1204: FILE: ./hal/odm.c:1204:
+void odm_RSSIMonitorCheck(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1217: FILE: ./hal/odm.c:1217:
+ struct DM_ODM_T * pDM_Odm = &(pHalData->odmpriv);
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1234: FILE: ./hal/odm.c:1234:
+void odm_RSSIMonitorCheckCE(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1243: FILE: ./hal/odm.c:1243:
+ struct RA_T * pRA_Table = &pDM_Odm->DM_RA_Table;
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1306: FILE: ./hal/odm.c:1306:
+static u8 getSwingIndex(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1330: FILE: ./hal/odm.c:1330:
+void odm_TXPowerTrackingInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1374: FILE: ./hal/odm.c:1374:
+void ODM_TXPowerTrackingCheck(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1398: FILE: ./hal/odm.c:1398:
+void odm_SwAntDetectInit(struct DM_ODM_T * pDM_Odm)
ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
#1400: FILE: ./hal/odm.c:1400:
+ struct SWAT_T * pDM_SWAT_Table = &pDM_Odm->DM_SWAT_Table;
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marco Cesati <marcocesati@gmail.com>
Link: https://lore.kernel.org/r/20210315170618.2566-21-marcocesati@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nbdd0121
pushed a commit
to nbdd0121/linux
that referenced
this pull request
Jun 7, 2021
Disable stack probes
kyak
pushed a commit
to kyak/linux-odroid
that referenced
this pull request
Dec 16, 2022
Add: use PHY config from the next higher pixel clock on VU5A
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.