- 20 Aug, 2016 40 commits
-
-
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Rabin Vincent authored
commit b782fcc1 upstream. adfeb3e0 ("cifs: Make echo interval tunable") added a comparison of vol->echo_interval to server->echo_interval as a criterium to match_server(), but: (1) A default value is set for server->echo_interval but not for vol->echo_interval, meaning these can never match if the echo_interval option is not specified. (2) vol->echo_interval is in seconds but server->echo_interval is in jiffies, meaning these can never match even if the echo_interval option is specified. This broke TCP session reuse since match_server() can never return 1. Fix it. Fixes: adfeb3e0 ("cifs: Make echo interval tunable") 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:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Vladimir Kondratiev authored
commit b4dff287 upstream. page should be calculated using physical address. If platform uses non-trivial dma-to-phys memory translation, dma_handle should be converted to physicval address before calculation of page. Failing to do so results in struct page * pointing to wrong or non-existent memory. Fixes: f2e3d553 ("ARC: dma: reintroduce platform specific dma<->phys") Signed-off-by:
Vladimir Kondratiev <vladimir.kondratiev@intel.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> 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:
-
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:
-
Sumit Saxena authored
commit d9083160 upstream. There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue reported, megaraid_sas driver goes into an infinite error reporting loop as soon as there is a change in the status of one of the arrays (degrade, resync online etc ). Below are the error logs reported continuously- Jun 25 08:49:30 ns8 kernel: [ 757.757017] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.778017] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.799017] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.820018] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.841018] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 This issue is very much specific to controllers which do not support DCMD- MR_DCMD_PD_LIST_QUERY. In case of any hotplugging/rescanning of drives, AEN thread will be scheduled by driver and fire DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will fail this event processing and will not go ahead for further events. This will cause infinite loop of same event getting retried infinitely and causing above mentioned logs. Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for controllers which do not support it and send DCMD SUCCESS status to AEN function so that it can go ahead with other event processing. Reported-by:
Lucz Geza <geza@lucz.com> Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> 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:
-
Dmitry Tunin authored
commit 12d86896 upstream. T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=05 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3490 Rev=00.01 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb BugLink: https://bugs.launchpad.net/bugs/1600623Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
-
Arend Van Spriel authored
commit 82bc9ab6 upstream. When the host-interface bus has hard time handling transmit packets it informs higher layer about this and it would stop the netdev queue when needed. However, since commit 9cd18359 ("brcmfmac: Make FWS queueing configurable.") this was broken. With this patch the behaviour is restored. Fixes: 9cd18359 ("brcmfmac: Make FWS queueing configurable.") Tested-by:
Per Förlin <per.forlin@gmail.com> Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.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:
-
Rafał Miłecki authored
commit 1bea0512 upstream. After discovering there are 2 very different 14e4:4365 PCI devices we made ID tables less generic. Back then we believed there are only 2 such devices: 1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset 2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset >From the recent report it appears there is also 14e4:4365 105b:e092 which should be claimed by bcma. Add back support for it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=121881 Fixes: 515b399c ("bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142") Reported-by:
Igor Mammedov <imammedo@redhat.com> Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Tested-by:
-
Oren Givon authored
commit f24bbae5 upstream. Add 6 new 8265 series PCI IDs: - (0x24FD, 0x1130) - (0x24FD, 0x0130) - (0x24FD, 0x0910) - (0x24FD, 0x0930) - (0x24FD, 0x0950) - (0x24FD, 0x0850) Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
David Spinadel <david.spinadel@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Oren Givon authored
commit 4b79deec upstream. Add 3 new 8260 series PCI IDs: - (0x24F3, 0x10B0) - (0x24F3, 0xD0B0) - (0x24F3, 0xB0B0) Signed-off-by:
-
Emmanuel Grumbach authored
commit f16c3ebf upstream. Upon firmware load interrupt (FH_TX), the ISR re-enables the firmware load interrupt only to avoid races with other flows as described in the commit below. When the firmware is completely loaded, the thread that is loading the firmware will enable all the interrupts to make sure that the driver gets the ALIVE interrupt. The problem with that is that the thread that is loading the firmware is actually racing against the ISR and we can get to the following situation: CPU0 CPU1 iwl_pcie_load_given_ucode ... iwl_pcie_load_firmware_chunk wait_for_interrupt <interrupt> ISR handles CSR_INT_BIT_FH_TX ISR wakes up the thread on CPU0 /* enable all the interrupts * to get the ALIVE interrupt */ iwl_enable_interrupts ISR re-enables CSR_INT_BIT_FH_TX only /* start the firmware */ iwl_write32(trans, CSR_RESET, 0); BUG! ALIVE interrupt will never arrive since it has been masked by CPU1. In order to fix that, change the ISR to first check if STATUS_INT_ENABLED is set. If so, re-enable all the interrupts. If STATUS_INT_ENABLED is clear, then we can check what specific interrupt happened and re-enable only that specific interrupt (RFKILL or FH_TX). All the credit for the analysis goes to Kirtika who did the actual debugging work. Fixes: a6bd005f ("iwlwifi: pcie: fix RF-Kill vs. firmware load race") Signed-off-by:
-
Emmanuel Grumbach authored
commit 2aabdbdc upstream. The NIC's CPU gets started after the firmware has been written to its memory. The first thing it does is to send an interrupt to let the driver know that it is running. In order to get that interrupt, the driver needs to make sure it is not masked. Of course, the interrupt needs to be enabled in the driver before the CPU starts to run. I mistakenly inversed those two steps leading to races which prevented the driver from getting the alive interrupt from the firmware. Fix that. Fixes: a6bd005f ("iwlwifi: pcie: fix RF-Kill vs. firmware load race") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Sami Tolvanen authored
commit 602d1657 upstream. do_div was replaced with div64_u64 at some point, causing a bug with block calculation due to incompatible semantics of the two functions. Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Fixes: a739ff3f ("dm verity: add support for forward error correction") Signed-off-by:
Mike Snitzer <snitzer@redhat.com> 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:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-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:
-
Dave Chinner authored
commit 28b783e4 upstream. In xfs_finish_page_writeback(), we have a loop that looks like this: do { if (off < bvec->bv_offset) goto next_bh; if (off > end) break; bh->b_end_io(bh, !error); next_bh: off += bh->b_size; } while ((bh = bh->b_this_page) != head); The b_end_io function is end_buffer_async_write(), which will call end_page_writeback() once all the buffers have marked as no longer under IO. This issue here is that the only thing currently protecting both the bufferhead chain and the page from being reclaimed is the PageWriteback state held on the page. While we attempt to limit the loop to just the buffers covered by the IO, we still read from the buffer size and follow the next pointer in the bufferhead chain. There is no guarantee that either of these are valid after the PageWriteback flag has been cleared. Hence, loops like this are completely unsafe, and result in use-after-free issues. One such problem was caught by Calvin Owens with KASAN: ..... INFO: Freed in 0x103fc80ec age=18446651500051355200 cpu=2165122683 pid=-1 free_buffer_head+0x41/0x90 __slab_free+0x1ed/0x340 kmem_cache_free+0x270/0x300 free_buffer_head+0x41/0x90 try_to_free_buffers+0x171/0x240 xfs_vm_releasepage+0xcb/0x3b0 try_to_release_page+0x106/0x190 shrink_page_list+0x118e/0x1a10 shrink_inactive_list+0x42c/0xdf0 shrink_zone_memcg+0xa09/0xfa0 shrink_zone+0x2c3/0xbc0 ..... Call Trace: <IRQ> [<ffffffff81e8b8e4>] dump_stack+0x68/0x94 [<ffffffff8153a995>] print_trailer+0x115/0x1a0 [<ffffffff81541174>] object_err+0x34/0x40 [<ffffffff815436e7>] kasan_report_error+0x217/0x530 [<ffffffff81543b33>] __asan_report_load8_noabort+0x43/0x50 [<ffffffff819d651f>] xfs_destroy_ioend+0x3bf/0x4c0 [<ffffffff819d69d4>] xfs_end_bio+0x154/0x220 [<ffffffff81de0c58>] bio_endio+0x158/0x1b0 [<ffffffff81dff61b>] blk_update_request+0x18b/0xb80 [<ffffffff821baf57>] scsi_end_request+0x97/0x5a0 [<ffffffff821c5558>] scsi_io_completion+0x438/0x1690 [<ffffffff821a8d95>] scsi_finish_command+0x375/0x4e0 [<ffffffff821c3940>] scsi_softirq_done+0x280/0x340 Where the access is occuring during IO completion after the buffer had been freed from direct memory reclaim. Prevent use-after-free accidents in this end_io processing loop by pre-calculating the loop conditionals before calling bh->b_end_io(). The loop is already limited to just the bufferheads covered by the IO in progress, so the offset checks are sufficient to prevent accessing buffers in the chain after end_page_writeback() has been called by the the bh->b_end_io() callout. Yet another example of why Bufferheads Must Die. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reported-and-Tested-by:
Calvin Owens <calvinowens@fb.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.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:
-
Tahsin Erdogan authored
commit bd9f55ea upstream. Commit d548b34b ("dm: reduce the queue delay used in dm_request_fn from 100ms to 10ms") always intended the value to be 10 msecs -- it just expressed it in jiffies because earlier commit 7eaceacc ("block: remove per-queue plugging") did. Signed-off-by:
Tahsin Erdogan <tahsin@google.com> Signed-off-by:
-
Alim Akhtar authored
commit 04c16b84 upstream. This patch fixes some of the LDOs and BUCKs voltage range as per user manual of s2mps15 (REV0.4). Fixes: 51af2067 ("regulator: s2mps11: Add support for S2MPS15 regulators") Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.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:
-
Heiner Kallweit authored
commit 5cac1f67 upstream. If a system configures the Nuvoton chip to use the alternative EFM IO address (CR_EFIR2) then after probing the primary EFM IO address (CR_EFIR) this region is not released. If a driver for another function of the Nuvoton Super I/O chip uses the same probing mechanism then it will hang if loaded after the nuvoton-cir driver. This was reported for the nct6775 hwmon driver. Fix this by properly releasing the region after probing CR_EFIR. This regression was introduced with kernel 4.6 so cc it to stable. Reported-by:
Antti Seppälä <a.seppala@gmail.com> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Tested-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:
-
Paul Gortmaker authored
commit 5cada174 upstream. To fix: Untracked files: (use "git add <file>..." to include in what will be committed) tools/objtool/fixdep Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/a4571f6893caf737d05524cfa3829c2abc1fb240.1469452729.git.jpoimboe@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
