- 20 Aug, 2016 40 commits
-
-
Joerg Roedel authored
commit cda7005b upstream. This domain type is not yet handled in the iommu_ops->domain_free() call-back. Fix that. Fixes: 0bb6e243 ('iommu/amd: Support IOMMU_DOMAIN_DMA type allocation') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wei Yang authored
commit 5c365d18 upstream. In 'commit <55d94043> ("iommu/vt-d: Get rid of domain->iommu_lock")', the error handling path is changed a little, which makes the function always return 0. This path fixes this. Signed-off-by:
Wei Yang <richard.weiyang@gmail.com> Fixes: 55d94043 ('iommu/vt-d: Get rid of domain->iommu_lock') Signed-off-by:
-
Marek Szyprowski authored
commit b54b874f upstream. Removal of IOMMU driver cannot be done reliably, so Exynos IOMMU driver doesn't support this operation. It is essential for system operation, so it makes sense to prevent unbinding by disabling bind/unbind sysfs feature for SYSMMU controller driver to avoid kernel ops or trashing memory caused by such operation. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Daniel Vetter authored
commit 78c3d5fa upstream. Another CI fail we have for no reason. Totally unjustified since nothing fails at all. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590806-23886-1-git-send-email-daniel.vetter@ffwll.chAcked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jeff Layton authored
commit dd257933 upstream. nfsd4_lock will take the st_mutex before working with the stateid it gets, but between the time when we drop the cl_lock and take the mutex, the stateid could become unhashed (a'la FREE_STATEID). If that happens the lock stateid returned to the client will be forgotten. Fix this by first moving the st_mutex acquisition into lookup_or_create_lock_state. Then, have it check to see if the lock stateid is still hashed after taking the mutex. If it's not, then put the stateid and try the find/create again. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Tested-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Chuck Lever authored
commit 42691398 upstream. When running LTP's nfslock01 test, the Linux client can send a LOCK and a FREE_STATEID request at the same time. The outcome is: Frame 324 R OPEN stateid [2,O] Frame 115004 C LOCK lockowner_is_new stateid [2,O] offset 672000 len 64 Frame 115008 R LOCK stateid [1,L] Frame 115012 C WRITE stateid [0,L] offset 672000 len 64 Frame 115016 R WRITE NFS4_OK Frame 115019 C LOCKU stateid [1,L] offset 672000 len 64 Frame 115022 R LOCKU NFS4_OK Frame 115025 C FREE_STATEID stateid [2,L] Frame 115026 C LOCK lockowner_is_new stateid [2,O] offset 672128 len 64 Frame 115029 R FREE_STATEID NFS4_OK Frame 115030 R LOCK stateid [3,L] Frame 115034 C WRITE stateid [0,L] offset 672128 len 64 Frame 115038 R WRITE NFS4ERR_BAD_STATEID In other words, the server returns stateid L in a successful LOCK reply, but it has already released it. Subsequent uses of stateid L fail. To address this, protect the generation check in nfsd4_free_stateid with the st_mutex. This should guarantee that only one of two outcomes occurs: either LOCK returns a fresh valid stateid, or FREE_STATEID returns NFS4ERR_LOCKS_HELD. Reported-by:
Chuck Lever <chuck.lever@oracle.com> Tested-by:
-
Benjamin Coddington authored
commit 149a4fdd upstream. NFS doesn't expect requests with wb_bytes set to zero and may make unexpected decisions about how to handle that request at the page IO layer. Skip request creation if we won't have any wb_bytes in the request. Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by:
Weston Andros Adamson <dros@primarydata.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
James Hogan authored
commit 9b731bcf upstream. Propagate errors from kvm_mips_handle_kseg0_tlb_fault() and kvm_mips_handle_mapped_seg_tlb_fault(), usually triggering an internal error since they normally indicate the guest accessed bad physical memory or the commpage in an unexpected way. Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Fixes: e685c689 ("KVM/MIPS32: Privileged instruction/target branch emulation.") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> [james.hogan@imgtec.com: Backport to v3.17.y - v4.4.y] Signed-off-by:
-
James Hogan authored
commit 0741f52d upstream. Two consecutive gfns are loaded into host TLB, so ensure the range check isn't off by one if guest_pmap_npages is odd. Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by:
-
James Hogan authored
commit 8985d503 upstream. kvm_mips_handle_mapped_seg_tlb_fault() calculates the guest frame number based on the guest TLB EntryLo values, however it is not range checked to ensure it lies within the guest_pmap. If the physical memory the guest refers to is out of range then dump the guest TLB and emit an internal error. Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by:
-
James Hogan authored
commit c604cffa upstream. kvm_mips_handle_mapped_seg_tlb_fault() appears to map the guest page at virtual address 0 to PFN 0 if the guest has created its own mapping there. The intention is unclear, but it may have been an attempt to protect the zero page from being mapped to anything but the comm page in code paths you wouldn't expect from genuine commpage accesses (guest kernel mode cache instructions on that address, hitting trapping instructions when executing from that address with a coincidental TLB eviction during the KVM handling, and guest user mode accesses to that address). Fix this to check for mappings exactly at KVM_GUEST_COMMPAGE_ADDR (it may not be at address 0 since commit 42aa12e7 ("MIPS: KVM: Move commpage so 0x0 is unmapped")), and set the corresponding EntryLo to be interpreted as 0 (invalid). Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by:
-
Stephan Mueller authored
commit 4b44f2d1 upstream. The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy collector is not triggered. This patch adds the interrupt entropy collection callback into the VMBus interrupt handler function. Signed-off-by:
Stephan Mueller <stephan.mueller@atsec.com> Signed-off-by:
Stephan Mueller <smueller@chronox.de> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
commit 9b4d0087 upstream. Since systemd is consistently using /dev/urandom before it is initialized, we can't see the other potentially dangerous users of /dev/urandom immediately after boot. So print the first ten such complaints instead. Signed-off-by:
-
Theodore Ts'o authored
commit 3371f3da upstream. If we have a hardware RNG and are using the in-kernel rngd, we should use this to initialize the non-blocking pool so that getrandom(2) doesn't block unnecessarily. Signed-off-by:
-
Pavel Shilovsky authored
commit 7893242e upstream. During following a symbolic link we received err_buf from SMB2_open(). While the validity of SMB2 error response is checked previously in smb2_check_message() a symbolic link payload is not checked at all. Fix it by adding such checks. Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Pavel Shilovsky <pshilovsky@samba.org> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Rabin Vincent authored
commit bd975d1e upstream. The secmech hmac(md5) structures are present in the TCP_Server_Info struct and can be shared among multiple CIFS sessions. However, the server mutex is not currently held when these structures are allocated and used, which can lead to a kernel crashes, as in the scenario below: mount.cifs(8) #1 mount.cifs(8) #2 Is secmech.sdeschmaccmd5 allocated? // false Is secmech.sdeschmaccmd5 allocated? // false secmech.hmacmd = crypto_alloc_shash.. secmech.sdeschmaccmd5 = kzalloc.. sdeschmaccmd5->shash.tfm = &secmec.hmacmd; secmech.sdeschmaccmd5 = kzalloc // sdeschmaccmd5->shash.tfm // not yet assigned crypto_shash_update() deref NULL sdeschmaccmd5->shash.tfm Unable to handle kernel paging request at virtual address 00000030 epc : 8027ba34 crypto_shash_update+0x38/0x158 ra : 8020f2e8 setup_ntlmv2_rsp+0x4bc/0xa84 Call Trace: crypto_shash_update+0x38/0x158 setup_ntlmv2_rsp+0x4bc/0xa84 build_ntlmssp_auth_blob+0xbc/0x34c sess_auth_rawntlmssp_authenticate+0xac/0x248 CIFS_SessSetup+0xf0/0x178 cifs_setup_session+0x4c/0x84 cifs_get_smb_ses+0x2c8/0x314 cifs_mount+0x38c/0x76c cifs_do_mount+0x98/0x440 mount_fs+0x20/0xc0 vfs_kern_mount+0x58/0x138 do_mount+0x1e8/0xccc SyS_mount+0x88/0xd4 syscall_common+0x30/0x54 Fix this by locking the srv_mutex around the code which uses these hmac(md5) structures. All the other secmech algos already have similar locking. Fixes: 95dc8dd1 ("Limit allocation of crypto mechanisms to dialect which requires") Signed-off-by:
Rabin Vincent <rabinv@axis.com> Acked-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
-
Sachin Prabhu authored
commit 8d9535b6 upstream. When opening a file with O_CREAT flag, check to see if the file opened is an existing directory. This prevents the directory from being opened which subsequently causes a crash when the close function for directories cifs_closedir() is called which frees up the file->private_data memory while the file is still listed on the open file list for the tcon. Signed-off-by:
Xiaoli Feng <xifeng@redhat.com> Signed-off-by:
-
Aurelien Aptel authored
commit a6b5058f upstream. if, when mounting //HOST/share/sub/dir/foo we can query /sub/dir/foo but not any of the path components above: - store the /sub/dir/foo prefix in the cifs super_block info - in the superblock, set root dentry to the subpath dentry (instead of the share root) - set a flag in the superblock to remember it - use prefixpath when building path from a dentry fixes bso#8950 Signed-off-by:
Aurelien Aptel <aaptel@suse.com> Reviewed-by:
-
Arnd Bergmann authored
commit abcfb5d9 upstream. The jbd2 journal stores the commit time in 64-bit seconds and 32-bit nanoseconds, which avoids an overflow in 2038, but it gets the numbers from current_kernel_time(), which uses 'long' seconds on 32-bit architectures. This simply changes the code to call current_kernel_time64() so we use 64-bit seconds consistently. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Vineet Gupta authored
commit 3925a16a upstream. LTP madvise05 was generating mm splat | [ARCLinux]# /sd/ltp/testcases/bin/madvise05 | BUG: Bad page map in process madvise05 pte:80e08211 pmd:9f7d4000 | page:9fdcfc90 count:1 mapcount:-1 mapping: (null) index:0x0 flags: 0x404(referenced|reserved) | page dumped because: bad pte | addr:200b8000 vm_flags:00000070 anon_vma: (null) mapping: (null) index:1005c | file: (null) fault: (null) mmap: (null) readpage: (null) | CPU: 2 PID: 6707 Comm: madvise05 And for newer kernels, the system was rendered unusable afterwards. The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is set to identify the special zero page wired to the pte). When pte was finally unmapped, special casing for zero page was not done, and instead it was treated as a "normal" page, tripping on the map counts etc. This fixes ARC STAR 9001053308 Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Dave Gerlach authored
commit d2e12e66 upstream. rproc_add adds the newly created remoteproc to a list for use by rproc_get_by_phandle and then does some additional processing to finish adding the remoteproc. This leaves a small window of time in which the rproc is available in the list but not yet fully initialized, so if another driver comes along and gets a handle to the rproc, it will be invalid. Rearrange the code in rproc_add to make sure the rproc is added to the list only after it has been successfuly initialized. Fixes: fec47d86 ("remoteproc: introduce rproc_get_by_phandle API") Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Miklos Szeredi authored
commit 76bc8e28 upstream. This does not work and does not make sense. So instead of fixing it (probably not hard) just disallow. Reported-by:
Andrei Vagin <avagin@gmail.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Roderick Colenbrander authored
commit 67f8ecc5 upstream. Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination with uhid. If any of these stacks is used with a HID device for which the driver performs a HID request as part .probe (or technically another HID operation), this results in a deadlock situation. The deadlock results in a 5 second timeout for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations have a chance of succeeding. The root cause for the problem is that uhid only allows for one request to be processed at a time per uhid instance and locks out other operations. This means that if a user space is creating a new HID device through 'UHID_CREATE', which ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a read for calibration data would trigger a HID operation on uhid again, but it won't go out to userspace, because it is still stuck in UHID_CREATE. In addition bluetooth stacks are typically single threaded, so they wouldn't be able to handle any requests while waiting on uhid. Lucikly the UHID spec is somewhat flexible and allows for fixing the issue, without breaking user space. The idea which the patch implements as discussed with David Herrmann is to decouple adding of a hid device (which triggers .probe) from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or else will wait a tiny bit of time in .probe for a lock). A HID driver has to call HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which triggers UHID_START to user space. Any HID operations should function now within .probe and won't deadlock because userspace is stuck on UHID_CREATE. We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with BlueZ stacks. Prior to the patch they had the deadlock issue. [jkosina@suse.cz: reword subject] Signed-off-by:
Roderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Borislav Petkov authored
commit bba14295 upstream. c44696ff ("EDAC: Remove arbitrary limit on number of channels") lifted the arbitrary limit on memory controller channels in EDAC. However, the dynamic channel attributes dynamic_csrow_dimm_attr and dynamic_csrow_ce_count_attr remained 6. This wasn't a problem except channels 6 and 7 weren't visible in sysfs on machines with more than 6 channels after the conversion to static attr groups with 2c1946b6 ("EDAC: Use static attribute groups for managing sysfs entries") [ without that, we're exploding in edac_create_sysfs_mci_device() because we're dereferencing out of the bounds of the dynamic_csrow_dimm_attr array. ] Add attributes for channels 6 and 7 along with a guard for the future, should more channels be required and/or to sanity check for misconfigured machines. We still need to check against the number of channels present on the MC first, as Thor reported. Signed-off-by:
Borislav Petkov <bp@suse.de> Reported-by:
Hironobu Ishii <ishii.hironobu@jp.fujitsu.com> Tested-by:
Thor Thayer <tthayer@opensource.altera.com> Signed-off-by:
-
Amadeusz Sławiński authored
commit 23bc6ab0 upstream. When we retrieve imtu value from userspace we should use 16 bit pointer cast instead of 32 as it's defined that way in headers. Fixes setsockopt calls on big-endian platforms. Signed-off-by:
Amadeusz Sławiński <amadeusz.slawinski@tieto.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Andy Shevchenko authored
commit 152bc19e upstream. It seems the commit e5262d05 ("spi: spi-pxa2xx: SPI support for Intel Quark X1000") misses one place to be adapted for Intel Quark, i.e. in reset_sccr1(). Clear all RFT bits when call reset_sccr1() on Intel Quark. Fixes: e5262d05 ("spi: spi-pxa2xx: SPI support for Intel Quark X1000") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Alexey Khoroshilov authored
commit 7dd91d52 upstream. There is the only failure path in efm32_i2c_probe(), where clk_disable_unprepare() is missed. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Fixes: 1b5b2371 ("i2c: efm32: new bus driver") Signed-off-by:
-
Javier Martinez Canillas authored
commit 6311f126 upstream. When s5p_mfc_remove() calls put_device() for the reserved memory region devs, the driver core warns that the dev doesn't have a release callback: WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90 Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed. Also, the declared DMA memory using dma_declare_coherent_memory() isn't relased so add a dev .release that calls dma_release_declared_memory(). Fixes: 6e83e6e2 ("[media] s5p-mfc: Fix kernel warning on memory init") Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Tested-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
commit 29debab0 upstream. The devices don't have a name set, so makes dev_name() returns NULL which makes harder to identify the devices that are causing issues, for example: WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90 Device '(null)' does not have a release() function, it is broken and must be fixed. And after setting the device name: WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90 Device 's5p-mfc-l' does not have a release() function, it is broken and must be fixed. Fixes: 6e83e6e2 ("[media] s5p-mfc: Fix kernel warning on memory init") Signed-off-by:
-
Alex Hung authored
commit fc8a601e upstream. Several users reported wifi cannot be unblocked as discussed in [1]. This patch removes the use of the 2009 flag by BIOS but uses the actual WMI function calls - it will be skipped if WMI reports unsupported. [1] https://bugzilla.kernel.org/show_bug.cgi?id=69131Signed-off-by:
Alex Hung <alex.hung@canonical.com> Tested-by:
Evgenii Shatokhin <eugene.shatokhin@yandex.ru> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Mike Snitzer authored
commit eaf9a736 upstream. Otherwise, there is potential for both DMF_SUSPENDED* and DMF_NOFLUSH_SUSPENDING to not be set during dm_suspend() -- which is definitely _not_ a valid state. This fix, in conjuction with "dm rq: fix the starting and stopping of blk-mq queues", addresses the potential for request-based DM multipath's __multipath_map() to see !dm_noflush_suspending() during suspend. Reported-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Florian Echtler authored
commit 6a858815 upstream. Closing the V4L2 device sometimes triggers a kernel oops. Present patch fixes this. Signed-off-by:
Martin Kaltenbrunner <modin@yuri.at> Signed-off-by:
Florian Echtler <floe@butterbrot.org> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Florian Echtler authored
commit af766ee0 upstream. The framerate sometimes drops below 60 Hz if the poll interval is too high. Lowering it to the minimum of 1 ms fixes this. Signed-off-by:
-
Jonathan McDowell authored
commit bbdb34c9 upstream. Fix RC5 decoding with Fintek CIR chipset Commit e87b540b tightened up the RC5 decoding by adding a check for trailing silence to ensure a valid RC5 command had been received. Unfortunately the trailer length checked was 10 units and the Fintek CIR device does not want to provide details of a space longer than 6350us. This meant that RC5 remotes working on a Fintek setup on 3.16 failed on 3.17 and later. Fix this by shortening the trailer check to 6 units (allowing for a previous space in the received remote command). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117221Signed-off-by:
Jonathan McDowell <noodles@earth.li> Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
-
Sakari Ailus authored
commit 126f4029 upstream. An earlier patch fixing an input validation issue introduced another issue: vb2_core_dqbuf() is called with pb argument value NULL in some cases, causing a NULL pointer dereference. Fix this by skipping the verification as there's nothing to verify. Fixes: e7e0c3e2 ("[media] videobuf2-core: Check user space planes array in dqbuf") Signed-off-by:
David R <david@unsolicited.net> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
-
Sakari Ailus authored
commit 83934b75 upstream. When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer which will be dequeued is not known until the buffer has been removed from the queue. The number of planes is specific to a buffer, not to the queue. This does lead to the situation where multi-plane buffers may be requested and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument struct with fewer planes. __fill_v4l2_buffer() however uses the number of planes from the dequeued videobuf2 buffer, overwriting kernel memory (the m.planes array allocated in video_usercopy() in v4l2-ioctl.c) if the user provided fewer planes than the dequeued buffer had. Oops! Fixes: b0e0e1f8 ("[media] media: videobuf2: Prepare to divide videobuf2") Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Soeren Moch authored
commit ca6e6126 upstream. Implement memory barriers according to Documentation/circular-buffers.txt: - use smp_store_release() to update ringbuffer read/write pointers - use smp_load_acquire() to load write pointer on reader side - use ACCESS_ONCE() to load read pointer on writer side This fixes data stream corruptions observed e.g. on an ARM Cortex-A9 quad core system with different types (PCI, USB) of DVB tuners. Signed-off-by:
Soeren Moch <smoch@web.de> Signed-off-by:
-
Matthew Leach authored
commit 2a00932f upstream. When disconnecting the usbtv device, the sound card is unregistered from ALSA and the snd member of the usbtv struct is set to NULL. If the usbtv snd_trigger work is running, this can cause a race condition where the kernel will attempt to access free'd resources, shown in [1]. This patch fixes the disconnection code by cancelling any snd_trigger work before unregistering the sound card from ALSA and checking that the snd member still exists in the work function. [1]: usb 3-1.2: USB disconnect, device number 6 BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffff81093850>] process_one_work+0x30/0x480 PGD 405bbf067 PUD 405bbe067 PMD 0 Call Trace: [<ffffffff81093ce8>] worker_thread+0x48/0x4e0 [<ffffffff81093ca0>] ? process_one_work+0x480/0x480 [<ffffffff81093ca0>] ? process_one_work+0x480/0x480 [<ffffffff81099998>] kthread+0xd8/0xf0 [<ffffffff815c73c2>] ret_from_fork+0x22/0x40 [<ffffffff810998c0>] ? kthread_worker_fn+0x170/0x170 ---[ end trace 0f3dac5c1a38e610 ]--- Signed-off-by:
Matthew Leach <matthew@mattleach.net> Tested-by:
Peter Sutton <foxxy@foxdogstudios.com> Signed-off-by:
-
Linus Walleij authored
commit f37be01e upstream. The RPM has two sets of selectors (IPC bit fields): request and acknowledge. Apparently, some models use 4*32 bit words for select and some use 7*32 bit words for request, but all use 7*32 words for acknowledge bits. So apparently you can on the models with requests of 4*32 select bits send 4*32 messages and get 7*32 different replies, so on ACK interrupt, 7*32 bit words need to be read. This is how the vendor code apparently works. Reported-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Linus Walleij authored
commit 9835f1b7 upstream. The RPM in MSM8660/APQ8060 has different offsets to the selector ACK and request context ACK registers. Make all these register offsets part of the per-SoC data and assign the right values. The bug was found by verifying backwards to the vendor tree in the out-of-tree files <mach/rpm-[8660|8064|8960]>: all were using offsets 3,11,15,23 and a select size of 4, except the MSM8660/APQ8060 which was using offsets 3,11,19,27 and a select size of 7. All other platforms apart from msm8660 were affected by reading excess registers, since 7 was hardcoded as the number of select words, this patch makes also this part dynamic so we only write/read as many select words as the platform actually use. Symptoms of this bug when using msm8660: the first RPM transaction would work, but the next would stall or raise an error since the previous transaction was not properly ACKed as the ACK words were read at the wrong offset. Fixes: 58e21438 ("mfd: qcom-rpm: Driver for the Qualcomm RPM") Signed-off-by:
-
