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

Code for RTL8188EU available #363

Closed
lwfinger opened this issue Aug 24, 2013 · 7 comments
Closed

Code for RTL8188EU available #363

lwfinger opened this issue Aug 24, 2013 · 7 comments

Comments

@lwfinger
Copy link
Contributor

I have just committed the code for an RTL8188EU driver to the linux-staging tree, and it was accepted by GregKH.

I have also modified it to apply to the 3.6.y branch of this repo, and I would like to submit those patches to the repo. What would be the best way to do so?

Thanks, Larry
@popcornmix
Copy link
Collaborator

I assume there is no overlap between your driver and the existing rtl8192cu and rtlwifi drivers?

Can you point me at the upstream linux commit? If it applies cleanly, I can just cherry-pick it.

@lwfinger
Copy link
Contributor Author

This is a totally new driver. It has no overlap with any driver presently in the kernel. When I stripped out the KERNELVERSION tests, that made the new driver work only for kernels 3.6 and newer. It will not work on the 3.2.27 branch.

The upstream commit is at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git, but that version will not apply cleanly. I cloned raspberrypi/linux and pushed my changes into the rpi-3.6.y branch at
http://github.com/lwfinger/linux.

I have also modified the rpi-3.8.y branch there, but ignore that code for the moment as the new driver has not yet been tested. I will also generate and test on the 3.9 and 3.10 branches ASAP.

BTW, are the standard .config files for the 3.8, 3.9, and 3.10 branches available somewhere. I tried to build 3.8, but the 39 different varieties of ARM CPUs stopped me as I did not know which to select.

@popcornmix
Copy link
Collaborator

arch/arm/config/bcmrpi_defconfig
is the .config used to build official firmware.

Can you provide a link to the commit, and any upstream discussion?

@lwfinger
Copy link
Contributor Author

The submission can be found at http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-August/thread.html. There were a total of 33 RFC/RFT submissions. The only discussion was by GregKH who stated "Looks good enough to me, now applied, thanks for doing this work!" and one off-list message from Dan Carpenter asking why I split it into separate hunks rather than putting all the new code into one submission. My reply was that I did it for review purposes.

@popcornmix
Copy link
Collaborator

I assume it should be appearing on:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
and then
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

I'm not sure what has to happen between gregkh's tree and next or torvalds tree.
I suspect that may require more review.

@lwfinger
Copy link
Contributor Author

Greg will let it reside in staging for a while and then push to next and ultimately to the torvalds mainline tree. From my previous experience, there will be no further review. I would expect the driver to be in the 3.12 kernel.

@GeofP GeofP mentioned this issue Feb 6, 2014
Closed
@Ruffio
Copy link

Ruffio commented Aug 10, 2016

@lwfinger has this issue been resolved? If yes, then please close this issue.

davet321 pushed a commit to davet321/rpi-linux that referenced this issue Aug 17, 2016
@sfjro
aufs: possible bugfix, temporary lockdep_off for debugfs_create_file
a1e4589 
The plain i_mutex lock under si_rwsem acquired may cause a lockdep
message. I've seen it on aufs4.1 for linux-v4.1-rc1, and I am afraid it
is a false positive. The message shows the lockdep chain of
namespace_sem -- si_resem -- i_mutex. Investigating the changes between
v4.0 and v4.1-rc1, I could not find the related commit in it. It may be
related to automount too. I'm afraid it could happen before v4.1-rc1.

======================================================
[ INFO: possible circular locking dependency detected ]
4.1.0aufsD+ raspberrypi#363 Not tainted
-------------------------------------------------------
perf/4110 is trying to acquire lock:
 (namespace_sem){++++++}, at: [<ffffffff811f597e>] lock_mount+0x8e/0x1e0

but task is already holding lock:
 (&sb->s_type->i_mutex_key#2){+.+.+.}, at: [<ffffffff811f5927>] lock_mount+0x37/0x1e0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> raspberrypi#2 (&sb->s_type->i_mutex_key#2){+.+.+.}:
       [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
       [<ffffffff8179b563>] mutex_lock_nested+0x63/0x510
       [<ffffffff8130f900>] start_creating+0xa0/0x1a0
       [<ffffffff8130fa5d>] debugfs_create_file+0x5d/0x1f0
       [<ffffffffa00dc74c>] dbgaufs_brs_add+0x9c/0x240 [aufs]
       [<ffffffffa00db705>] sysaufs_brs_add+0x25/0x200 [aufs]
       [<ffffffffa009ee7c>] aufs_mount+0x8c/0x1b0 [aufs]
       [<ffffffff811ced88>] mount_fs+0x48/0x260
       [<ffffffff811f434b>] vfs_kern_mount+0x7b/0x190
       [<ffffffff811f6f88>] do_mount+0x228/0xca0
       [<ffffffff811f7e39>] SyS_mount+0xe9/0x110
       [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

-> raspberrypi#1 (&sbinfo->si_rwsem){++++++}:
       [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
       [<ffffffff8179d4d7>] down_read+0x47/0x60
       [<ffffffffa009efe7>] aufs_show_options+0x47/0x7e0 [aufs]
       [<ffffffff8121b670>] show_vfsmnt+0x110/0x160
       [<ffffffff811f2b56>] m_show+0x16/0x20
       [<ffffffff811f9c61>] seq_read+0x3b1/0x4a0
       [<ffffffff811c9fb8>] __vfs_read+0x18/0x40
       [<ffffffff811cb392>] vfs_read+0x122/0x190
       [<ffffffff811cb452>] SyS_read+0x52/0xb0
       [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

-> #0 (namespace_sem){++++++}:
       [<ffffffff810b349b>] __lock_acquire+0x181b/0x1e30
       [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
       [<ffffffff8179d454>] down_write+0x44/0x80
       [<ffffffff811f597e>] lock_mount+0x8e/0x1e0
       [<ffffffff811f6012>] do_add_mount+0x32/0x130
       [<ffffffff811f6afc>] finish_automount+0x6c/0xe0
       [<ffffffff811d78f6>] follow_managed+0x1c6/0x320
       [<ffffffff811d987f>] lookup_fast+0x4ff/0x560
       [<ffffffff811dbf37>] path_lookupat+0xc7/0x8a0
       [<ffffffff811dc745>] filename_lookup+0x35/0x170
       [<ffffffff811dfd46>] user_path_at_empty+0x96/0xe0
       [<ffffffff811dfda1>] user_path_at+0x11/0x20
       [<ffffffff8120c034>] user_statfs+0x34/0x90
       [<ffffffff8120c10b>] SYSC_statfs+0x1b/0x40
       [<ffffffff8120c24e>] SyS_statfs+0xe/0x10
       [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

other info that might help us debug this:

Chain exists of:
  namespace_sem --> &sbinfo->si_rwsem --> &sb->s_type->i_mutex_key#2

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&sb->s_type->i_mutex_key#2);
                               lock(&sbinfo->si_rwsem);
                               lock(&sb->s_type->i_mutex_key#2);
  lock(namespace_sem);

 *** DEADLOCK ***

1 lock held by perf/4110:
 #0:  (&sb->s_type->i_mutex_key#2){+.+.+.}, at: [<ffffffff811f5927>] lock_mount+0x37/0x1e0

stack backtrace:
CPU: 0 PID: 4110 Comm: perf Not tainted 4.1.0aufsD+ raspberrypi#363
Hardware name: Pegatron Pegatron/IPM41, BIOS 0001 02/05/2009
 ffffffff85f22880 ffff880021e93908 ffffffff81793ee6 0000000000000000
 ffffffff85eed2a0 ffff880021e93958 ffffffff8178fece ffff880021e93958
 ffff880021e939c8 ffff880021e8e510 ffff880021e8ec58 ffff880021e8e510
Call Trace:
 [<ffffffff81793ee6>] dump_stack+0x4f/0xa2
 [<ffffffff8178fece>] print_circular_bug+0x1fb/0x20c
 [<ffffffff810b349b>] __lock_acquire+0x181b/0x1e30
 [<ffffffff810b4248>] lock_acquire+0xc8/0x2a0
 [<ffffffff811f597e>] ? lock_mount+0x8e/0x1e0
 [<ffffffff8179d454>] down_write+0x44/0x80
 [<ffffffff811f597e>] ? lock_mount+0x8e/0x1e0
 [<ffffffff811f597e>] lock_mount+0x8e/0x1e0
 [<ffffffff811f6012>] do_add_mount+0x32/0x130
 [<ffffffff813b7708>] ? find_next_bit+0x18/0x20
 [<ffffffff811f6afc>] finish_automount+0x6c/0xe0
 [<ffffffff811d78f6>] follow_managed+0x1c6/0x320
 [<ffffffff811d987f>] lookup_fast+0x4ff/0x560
 [<ffffffff811da64f>] ? path_init+0xbf/0x8d0
 [<ffffffff811dbe00>] ? complete_walk+0x1e0/0x250
 [<ffffffff811dbf37>] path_lookupat+0xc7/0x8a0
 [<ffffffff811dc745>] filename_lookup+0x35/0x170
 [<ffffffff811dfd46>] user_path_at_empty+0x96/0xe0
 [<ffffffff8118dce8>] ? might_fault+0xa8/0xb0
 [<ffffffff8118dc9f>] ? might_fault+0x5f/0xb0
 [<ffffffff8120bf27>] ? do_statfs_native+0xa7/0xc0
 [<ffffffff811dfda1>] user_path_at+0x11/0x20
 [<ffffffff8120c034>] user_statfs+0x34/0x90
 [<ffffffff8120c10b>] SYSC_statfs+0x1b/0x40
 [<ffffffff813ae808>] ? lockdep_sys_exit_thunk+0x12/0x14
 [<ffffffff8120c24e>] SyS_statfs+0xe/0x10
 [<ffffffff8179fed7>] system_call_fastpath+0x12/0x6f

Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
(cherry picked from commit f440be7d4ac14d1ae004adaee072114fd31e8d83)
popcornmix pushed a commit that referenced this issue Apr 30, 2019
@aik @mpe
powerpc/mm_iommu: Fix potential deadlock
eb9d7a6 
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 #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>
sigmaris pushed a commit to sigmaris/linux that referenced this issue Nov 7, 2020
@maheshsal @gregkh
powerpc/powernv/elog: Fix race while processing OPAL error log event.
0797686 
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 [raspberrypi#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 raspberrypi#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>
popcornmix pushed a commit that referenced this issue Nov 9, 2020
@maheshsal @gregkh
powerpc/powernv/elog: Fix race while processing OPAL error log event.
61ed8c1 
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 #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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@popcornmix @Ruffio @lwfinger