- 07 Oct, 2016 40 commits
-
-
Greg Kroah-Hartman authored
commit 2fae9e5a upstream. This patch fixes a NULL pointer dereference caused by a race codition in the probe function of the legousbtower driver. It re-structures the probe function to only register the interface after successfully reading the board's firmware ID. The probe function does not deregister the usb interface after an error receiving the devices firmware ID. The device file registered (/dev/usb/legousbtower%d) may be read/written globally before the probe function returns. When tower_delete is called in the probe function (after an r/w has been initiated), core dev structures are deleted while the file operation functions are still running. If the 0 address is mappable on the machine, this vulnerability can be used to create a Local Priviege Escalation exploit via a write-what-where condition by remapping dev->interrupt_out_buffer in tower_write. A forged USB device and local program execution would be required for LPE. The USB device would have to delay the control message in tower_probe and accept the control urb in tower_open whilst guest code initiated a write to the device file as tower_delete is called from the error in tower_probe. This bug has existed since 2003. Patch tested by emulated device. Reported-by:
James Patrick-Evans <james@jmp-e.com> Tested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Konstantin Shkolnyy authored
commit a377f9e9 upstream. A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS is transmit active signal" and CRTSCTS=1 => "RTS is used for receive flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS is used for receive flow control" This only happened after first having enabled CRTSCTS. Signed-off-by:
Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control") [johan: reword commit message ] Signed-off-by:
Johan Hovold <johan@kernel.org> [johan: backport to 4.4 ] Signed-off-by:
-
Mikulas Patocka authored
commit 7efb3673 upstream. bio_alloc() can allocate a bio with at most BIO_MAX_PAGES (256) vector entries. However, the incoming bio may have more vector entries if it was allocated by other means. For example, bcache submits bios with more than BIO_MAX_PAGES entries. This results in bio_alloc() failure. To avoid the failure, change the code so that it allocates bio with at most BIO_MAX_PAGES entries. If the incoming bio has more entries, bio_add_page() will fail and a new bio will be allocated - the code that handles bio_add_page() failure already exists in the dm-log-writes target. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Reviewed-by:
Josef Bacik <jbacik@fb.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Loc Ho authored
commit 0f4c7a13 upstream. In the initial fix for non-zero divider shift value, the parenthesis was missing after the negate operation. This patch adds the required parenthesis. Otherwise, lower bits may be cleared unintentionally. Signed-off-by:
Loc Ho <lho@apm.com> Acked-by:
Toan Le <toanle@apm.com> Fixes: 1382ea63 ("clk: xgene: Fix divider with non-zero shift value") Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Jann Horn authored
commit 22f6b4d3 upstream. This ensures that do_mmap() won't implicitly make AIO memory mappings executable if the READ_IMPLIES_EXEC personality flag is set. Such behavior is problematic because the security_mmap_file LSM hook doesn't catch this case, potentially permitting an attacker to bypass a W^X policy enforced by SELinux. I have tested the patch on my machine. To test the behavior, compile and run this: #define _GNU_SOURCE #include <unistd.h> #include <sys/personality.h> #include <linux/aio_abi.h> #include <err.h> #include <stdlib.h> #include <stdio.h> #include <sys/syscall.h> int main(void) { personality(READ_IMPLIES_EXEC); aio_context_t ctx = 0; if (syscall(__NR_io_setup, 1, &ctx)) err(1, "io_setup"); char cmd[1000]; sprintf(cmd, "cat /proc/%d/maps | grep -F '/[aio]'", (int)getpid()); system(cmd); return 0; } In the output, "rw-s" is good, "rwxs" is bad. Signed-off-by:
Jann Horn <jann@thejh.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Marek Lindner authored
commit d9f17987 upstream. Reported-by:
Lars Bußmann <ffsoest@kill-you.net> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> [sven@narfation.org: rewritten commit message to make clear that it is an bugfix to an user reported crash] Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Jack Morgenstein authored
commit 8ec07bf8 upstream. When sending QP1 MAD packets which use a GRH, the source GID (which consists of the 64-bit subnet prefix, and the 64 bit port GUID) must be included in the packet GRH. For SR-IOV, a GID cache is used, since the source GID needs to be the slave's source GID, and not the Hypervisor's GID. This cache also included a subnet_prefix. Unfortunately, the subnet_prefix field in the cache was never initialized (to the default subnet prefix 0xfe80::0). As a result, this field remained all zeroes. Therefore, when SR-IOV was active, all QP1 packets which included a GRH had a source GID subnet prefix of all-zeroes. However, the subnet-prefix should initially be 0xfe80::0 (the default subnet prefix). In addition, if OpenSM modifies a port's subnet prefix, the new subnet prefix must be used in the GRH when sending QP1 packets. To fix this we now initialize the subnet prefix in the SR-IOV GID cache to the default subnet prefix. We update the cached value if/when OpenSM modifies the port's subnet prefix. We take this cached value when sending QP1 packets when SR-IOV is active. Note that the value is stored as an atomic64. This eliminates any need for locking when the subnet prefix is being updated. Note also that we depend on the FW generating the "port management change" event for tracking subnet-prefix changes performed by OpenSM. If running early FW (before 2.9.4630), subnet prefix changes will not be tracked (but the default subnet prefix still will be stored in the cache; therefore users who do not modify the subnet prefix will not have a problem). IF there is a need for such tracking also for early FW, we will add that capability in a subsequent patch. Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Jack Morgenstein authored
commit baa0be70 upstream. The indentation in the QP1 GRH flow in procedure build_mlx_header is really confusing. Fix it, in preparation for a commit which touches this code. Fixes: 1ffeb2eb ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support") Signed-off-by:
-
Alex Vesker authored
commit e5ac40cd upstream. Because of an incorrect bit-masking done on the join state bits, when handling a join request we failed to detect a difference between the group join state and the request join state when joining as send only full member (0x8). This caused the MC join request not to be sent. This issue is relevant only when SRIOV is enabled and SM supports send only full member. This fix separates scope bits and join states bits a nibble each. Fixes: b9c5d6a6 ('IB/mlx4: Add multicast group (MCG) paravirtualization for SR-IOV') Signed-off-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
-
Alex Vesker authored
commit 344bacca upstream. This fix solves a race between light flush and on the fly joins. Light flush doesn't set the device to down and unset IPOIB_OPER_UP flag, this means that if while flushing we have a MC join in progress and the QP was attached to BC MGID we can have a mismatches when re-attaching a QP to the BC MGID. The light flush would set the broadcast group to NULL causing an on the fly join to rejoin and reattach to the BC MCG as well as adding the BC MGID to the multicast list. The flush process would later on remove the BC MGID and detach it from the QP. On the next flush the BC MGID is present in the multicast list but not found when trying to detach it because of the previous double attach and single detach. [18332.714265] ------------[ cut here ]------------ [18332.717775] WARNING: CPU: 6 PID: 3767 at drivers/infiniband/core/verbs.c:280 ib_dealloc_pd+0xff/0x120 [ib_core] ... [18332.775198] Hardware name: Red Hat KVM, BIOS Bochs 01/01/2011 [18332.779411] 0000000000000000 ffff8800b50dfbb0 ffffffff813fed47 0000000000000000 [18332.784960] 0000000000000000 ffff8800b50dfbf0 ffffffff8109add1 0000011832f58300 [18332.790547] ffff880226a596c0 ffff880032482000 ffff880032482830 ffff880226a59280 [18332.796199] Call Trace: [18332.798015] [<ffffffff813fed47>] dump_stack+0x63/0x8c [18332.801831] [<ffffffff8109add1>] __warn+0xd1/0xf0 [18332.805403] [<ffffffff8109aebd>] warn_slowpath_null+0x1d/0x20 [18332.809706] [<ffffffffa025d90f>] ib_dealloc_pd+0xff/0x120 [ib_core] [18332.814384] [<ffffffffa04f3d7c>] ipoib_transport_dev_cleanup+0xfc/0x1d0 [ib_ipoib] [18332.820031] [<ffffffffa04ed648>] ipoib_ib_dev_cleanup+0x98/0x110 [ib_ipoib] [18332.825220] [<ffffffffa04e62c8>] ipoib_dev_cleanup+0x2d8/0x550 [ib_ipoib] [18332.830290] [<ffffffffa04e656f>] ipoib_uninit+0x2f/0x40 [ib_ipoib] [18332.834911] [<ffffffff81772a8a>] rollback_registered_many+0x1aa/0x2c0 [18332.839741] [<ffffffff81772bd1>] rollback_registered+0x31/0x40 [18332.844091] [<ffffffff81773b18>] unregister_netdevice_queue+0x48/0x80 [18332.848880] [<ffffffffa04f489b>] ipoib_vlan_delete+0x1fb/0x290 [ib_ipoib] [18332.853848] [<ffffffffa04df1cd>] delete_child+0x7d/0xf0 [ib_ipoib] [18332.858474] [<ffffffff81520c08>] dev_attr_store+0x18/0x30 [18332.862510] [<ffffffff8127fe4a>] sysfs_kf_write+0x3a/0x50 [18332.866349] [<ffffffff8127f4e0>] kernfs_fop_write+0x120/0x170 [18332.870471] [<ffffffff81207198>] __vfs_write+0x28/0xe0 [18332.874152] [<ffffffff810e09bf>] ? percpu_down_read+0x1f/0x50 [18332.878274] [<ffffffff81208062>] vfs_write+0xa2/0x1a0 [18332.881896] [<ffffffff812093a6>] SyS_write+0x46/0xa0 [18332.885632] [<ffffffff810039b7>] do_syscall_64+0x57/0xb0 [18332.889709] [<ffffffff81883321>] entry_SYSCALL64_slow_path+0x25/0x25 [18332.894727] ---[ end trace 09ebbe31f831ef17 ]--- Fixes: ee1e2c82 ("IPoIB: Refresh paths instead of flushing them on SM change events") Signed-off-by:
-
Erez Shitrit authored
commit 68c6bcdd upstream. The function send_leave sets the member: group->query_id (group->query_id = ret) after calling the sa_query, but leave_handler can be executed before the setting and it might delete the group object, and will get a memory corruption. Additionally, this patch gets rid of group->query_id variable which is not used. Fixes: faec2f7b ('IB/sa: Track multicast join/leave requests') Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Signed-off-by:
-
Erez Shitrit authored
commit 546481c2 upstream. When a new CM connection is being requested, ipoib driver copies data from the path pointer in the CM/tx object, the path object might be invalid at the point and memory corruption will happened later when now the CM driver will try using that data. The next scenario demonstrates it: neigh_add_path --> ipoib_cm_create_tx --> queue_work (pointer to path is in the cm/tx struct) #while the work is still in the queue, #the port goes down and causes the ipoib_flush_paths: ipoib_flush_paths --> path_free --> kfree(path) #at this point the work scheduled starts. ipoib_cm_tx_start --> copy from the (invalid)path pointer: (memcpy(&pathrec, &p->path->pathrec, sizeof pathrec);) -> memory corruption. To fix that the driver now starts the CM/tx connection only if that specific path exists in the general paths database. This check is protected with the relevant locks, and uses the gid from the neigh member in the CM/tx object which is valid according to the ref count that was taken by the CM/tx. Fixes: 839fcaba ('IPoIB: Connected mode experimental support') Signed-off-by:
-
Radim Krčmář authored
commit dccbfcf5 upstream. If vmcs12 does not intercept APIC_BASE writes, then KVM will handle the write with vmcs02 as the current VMCS. This will incorrectly apply modifications intended for vmcs01 to vmcs02 and L2 can use it to gain access to L0's x2APIC registers by disabling virtualized x2APIC while using msr bitmap that assumes enabled. Postpone execution of vmx_set_virtual_x2apic_mode until vmcs01 is the current VMCS. An alternative solution would temporarily make vmcs01 the current VMCS, but it requires more care. Fixes: 8d14695f ("x86, apicv: add virtual x2apic support") Reported-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Wei Yongjun authored
commit 6a8b0c6b upstream. free_irq() expects the same device identity that was passed to corresponding request_irq(), otherwise the IRQ is not freed. Fixes: e1f7c9ee ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Michal Hocko authored
commit 735f2770 upstream. Commit fec1d011 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") has caused a subtle regression in nscd which uses CLONE_CHILD_CLEARTID to clear the nscd_certainly_running flag in the shared databases, so that the clients are notified when nscd is restarted. Now, when nscd uses a non-persistent database, clients that have it mapped keep thinking the database is being updated by nscd, when in fact nscd has created a new (anonymous) one (for non-persistent databases it uses an unlinked file as backend). The original proposal for the CLONE_CHILD_CLEARTID change claimed (https://lkml.org/lkml/2006/10/25/233): : The NPTL library uses the CLONE_CHILD_CLEARTID flag on clone() syscalls : on behalf of pthread_create() library calls. This feature is used to : request that the kernel clear the thread-id in user space (at an address : provided in the syscall) when the thread disassociates itself from the : address space, which is done in mm_release(). : : Unfortunately, when a multi-threaded process incurs a core dump (such as : from a SIGSEGV), the core-dumping thread sends SIGKILL signals to all of : the other threads, which then proceed to clear their user-space tids : before synchronizing in exit_mm() with the start of core dumping. This : misrepresents the state of process's address space at the time of the : SIGSEGV and makes it more difficult for someone to debug NPTL and glibc : problems (misleading him/her to conclude that the threads had gone away : before the fault). : : The fix below is to simply avoid the CLONE_CHILD_CLEARTID action if a : core dump has been initiated. The resulting patch from Roland (https://lkml.org/lkml/2006/10/26/269) seems to have a larger scope than the original patch asked for. It seems that limitting the scope of the check to core dumping should work for SIGSEGV issue describe above. [Changelog partly based on Andreas' description] Fixes: fec1d011 ("[PATCH] Disable CLONE_CHILD_CLEARTID for abnormal exit") Link: http://lkml.kernel.org/r/1471968749-26173-1-git-send-email-mhocko@kernel.orgSigned-off-by:
Michal Hocko <mhocko@suse.com> Tested-by:
William Preston <wpreston@suse.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Cc: Roland McGrath <roland@hack.frob.com> Cc: Andreas Schwab <schwab@suse.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Peter Ujfalusi authored
commit a8719670 upstream. Fixes: ddd17531 ("ASoC: omap-mcpdm: Clean up with devm_* function") Managed irq request will not doing any good in ASoC probe level as it is not going to free up the irq when the driver is unbound from the sound card. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by:
Russell King <linux@armlinux.org.uk> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Subash Abhinov Kasiviswanathan authored
commit e7d316a0 upstream. We have scripts which write to certain fields on 3.18 kernels but this seems to be failing on 4.4 kernels. An entry which we write to here is xfrm_aevent_rseqth which is u32. echo 4294967295 > /proc/sys/net/core/xfrm_aevent_rseqth Commit 230633d1 ("kernel/sysctl.c: detect overflows when converting to int") prevented writing to sysctl entries when integer overflow occurs. However, this does not apply to unsigned integers. Heinrich suggested that we introduce a new option to handle 64 bit limits and set min as 0 and max as UINT_MAX. This might not work as it leads to issues similar to __do_proc_doulongvec_minmax. Alternatively, we would need to change the datatype of the entry to 64 bit. static int __do_proc_doulongvec_minmax(void *data, struct ctl_table { i = (unsigned long *) data; //This cast is causing to read beyond the size of data (u32) vleft = table->maxlen / sizeof(unsigned long); //vleft is 0 because maxlen is sizeof(u32) which is lesser than sizeof(unsigned long) on x86_64. Introduce a new proc handler proc_douintvec. Individual proc entries will need to be updated to use the new handler. [akpm@linux-foundation.org: coding-style fixes] Fixes: 230633d1 ("kernel/sysctl.c:detect overflows when converting to int") Link: http://lkml.kernel.org/r/1471479806-5252-1-git-send-email-subashab@codeaurora.orgSigned-off-by:
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Kees Cook <keescook@chromium.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by:
-
Michael Ellerman authored
commit 66443efa upstream. When booting from an OpenFirmware which supports it, we use the "ibm,client-architecture-support" firmware call to communicate our capabilities to firmware. The format of the structure we pass to firmware is specified in PAPR (Power Architecture Platform Requirements), or the public version LoPAPR (Linux on Power Architecture Platform Reference). Referring to table 244 in LoPAPR v1.1, option vector 5 contains a 4 byte field at bytes 17-20 for the "Platform Facilities Enable". This is followed by a 1 byte field at byte 21 for "Sub-Processor Represenation Level". Comparing to the code, there we have the Platform Facilities options (OV5_PFO_*) at byte 17, but we fail to pad that field out to its full width of 4 bytes. This means the OV5_SUB_PROCESSORS option is incorrectly placed at byte 18. Fix it by adding zero bytes for bytes 18, 19, 20, and comment the bytes to hopefully make it clearer in future. As far as I'm aware nothing actually consumes this value at this time, so the effect of this bug is nil in practice. It does mean we've been incorrectly setting bit 15 of the "Platform Facilities Enable" option for the past ~3 1/2 years, so we should avoid allocating that bit to anything else in future. Fixes: df77c799 ("powerpc/pseries: Update ibm,architecture.vec for PAPR 2.7/POWER8") Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Florian Fainelli authored
commit f823a2aa upstream. wlc_phy_txpower_get_current() does a logical OR of power->flags, which presumes that power.flags was initiliazed earlier by the caller, unfortunately, this is not the case, so make sure we zero out the struct tx_power before calling into wlc_phy_txpower_get_current(). Reported-by: coverity (CID 146011) Fixes: 5b435de0 ("net: wireless: add brcm80211 drivers") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Florian Fainelli authored
commit 5c5fa1f4 upstream. In case dma_mapping_error() returns an error in dma_rxfill, we would be leaking a packet that we allocated with brcmu_pkt_buf_get_skb(). Reported-by: coverity (CID 1081819) Fixes: 67d0cf50 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()") Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
-
Florian Fainelli authored
commit 3bdae810 upstream. In case brcmf_sdiod_recv_chain() cannot complete a succeful call to brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we should, fix this. Reported-by: coverity (CID 1164856) Fixes: a413e39a ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support") Signed-off-by:
-
Wei Yongjun authored
commit 979cf59a upstream. Fix to return error code -ENODEV from the error handling case instead of 0, as done elsewhere in this function. Fixes: 87b2bdf0 ("ASoC: Intel: Skylake: Initialize NHLT table") Signed-off-by:
Vinod Koul <vinod.kou@intel.com> Signed-off-by:
-
Trond Myklebust authored
commit c001c87a upstream. We should always do a layoutcommit after commit to DS, except if the layout segment we're using has set FF_FLAGS_NO_LAYOUTCOMMIT. Fixes: d67ae825 ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
commit 73e6c5d8 upstream. According to the errata https://www.rfc-editor.org/errata_search.php?rfc=5661&eid=2751 we should always send layout commit after a commit to DS. Fixes: bc7d4b8f ("nfs/filelayout: set layoutcommit...") Signed-off-by:
-
Chuck Lever authored
commit a4e187d8 upstream. Before commit 778be232 ("NFS do not find client in NFSv4 pg_authenticate"), the Linux callback server replied with RPC_AUTH_ERROR / RPC_AUTH_BADCRED, instead of dropping the CB request. Let's restore that behavior so the server has a chance to do something useful about it, and provide a warning that helps admins correct the problem. Fixes: 778be232 ("NFS do not find client in NFSv4 ...") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Tested-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Chuck Lever authored
commit 0533b130 upstream. If an RPC program does not set vs_dispatch and pc_func() returns rpc_drop_reply, the server sends a reply anyway containing a single word containing the value RPC_DROP_REPLY (in network byte-order, of course). This is a nonsense RPC message. Fixes: 9e701c61 ("svcrpc: simpler request dropping") Signed-off-by:
-
Alexandre Belloni authored
commit 3935e087 upstream. mbr_ds is an integer, don't use %pad to print it. Fixes: commit 268914f4 ("dmaengine: at_xdmac: use %pad format string for dma_addr_t") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Dan Carpenter authored
commit dd7328e4 upstream. pci_dma_mapping_error() returns true on error and false on success. Fixes: fd6ddfa4 ('fnic: check pci_map_single() return value') Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Dan Carpenter authored
commit 55f1cf83 upstream. The pio_dev[] array has MAX_NR_PIO_DEVICES elements so the > should be >=. Fixes: 5f97f7f9 ('[PATCH] avr32 architecture') Signed-off-by:
-
Sven Eckelmann authored
commit aaab50fc upstream. The function ar9003_hw_apply_minccapwr_thresh takes as second parameter not a pointer to the channel but a boolean value describing whether the channel is 2.4GHz or not. This broke (according to the origin commit) the ETSI regulatory compliance on 5GHz channels. Fixes: 3533bf6b ("ath9k: Fix regulatory compliance") Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Arnd Bergmann authored
commit d7e92e15 upstream. When CONFIG_INPUT is disabled, multiple gspca backend drivers print compile-time warnings about unused variables: media/usb/gspca/cpia1.c: In function 'sd_stopN': media/usb/gspca/cpia1.c:1627:13: error: unused variable 'sd' [-Werror=unused-variable] media/usb/gspca/konica.c: In function 'sd_stopN': media/usb/gspca/konica.c:246:13: error: unused variable 'sd' [-Werror=unused-variable] This annotates the variables as __maybe_unused, to let the compiler know that they are declared intentionally. Fixes: ee186fd9 ("[media] gscpa_t613: Add support for the camera button") Fixes: c2f644ae ("[media] gspca_cpia1: Add support for button") Fixes: b517af72 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset using cams") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Dan Carpenter authored
commit e44c153b upstream. The code is checking for negative returns but it should be checking for zero. Fixes: aab3125c ('[media] em28xx: add support for registering multiple i2c buses') Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit fa1ce54e upstream. drivers/nfc/fdp/fdp.c: In function ‘fdp_nci_patch_otp’: drivers/nfc/fdp/fdp.c:373: warning: comparison is always false due to limited range of data type drivers/nfc/fdp/fdp.c: In function ‘fdp_nci_patch_ram’: drivers/nfc/fdp/fdp.c:444: warning: comparison is always false due to limited range of data type fdp_nci_create_conn() may return a negative error code, which is silently ignored by assigning it to a u8. Change conn_id from u8 to int to fix this. Fixes: a06347c0 ("NFC: Add Intel Fields Peak NFC solution driver") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
striebit authored
commit 849a9627 upstream. Currently the state sent in SF configuration is always FULL_ON. This commit sets the correct state (e.g. INIT_OFF when station is not associated). Fixes: commit f4a3ee49 ("iwlwifi: mvm: Always enable the smart FIFO") Signed-off-by:
Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
James Hogan authored
commit cdf8b463 upstream. AT_VECTOR_SIZE_ARCH should be defined with the maximum number of NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined for tile at all even though ARCH_DLINFO will contain one NEW_AUX_ENT for the VDSO address. This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for AT_BASE_PLATFORM which tile doesn't use, but lets define it now and add the comment above ARCH_DLINFO as found in several other architectures to remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to date. Fixes: 4a556f4f ("tile: implement gettimeofday() via vDSO") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Chris Metcalf <cmetcalf@mellanox.com> Signed-off-by:
Chris Metcalf <cmetcalf@mellanox.com> Signed-off-by:
-
Geliang Tang authored
commit 52d210d9 upstream. In ee1d2674 ("pstore: add pstore unregister") I added: .owner = THIS_MODULE, in both pstore_fs_type and pstore_file_operations to increase a reference count when pstore filesystem is mounted and pstore file is opened. But, it's repetitive. There is no need to increase the opened reference count. We only need to increase the mounted reference count. When a file is opened, the filesystem can't be unmounted. Hence the pstore module can't be unloaded either. So I drop the opened reference count in this patch. Fixes: ee1d2674 ("pstore: add pstore unregister") Signed-off-by:
Geliang Tang <geliangtang@163.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Omar Sandoval authored
commit 52b9c330 upstream. If ->queue_rq() returns BLK_MQ_RQ_QUEUE_OK, we use continue and skip over the rest of the loop body. However, dptr is assigned later in the loop body, and the BLK_MQ_RQ_QUEUE_OK case is exactly the case that we'd want it for. NVMe isn't actually using BLK_MQ_F_DEFER_ISSUE yet, nor is any other in-tree driver, but if the code's going to be there, it might as well work. Fixes: 74c45052 ("blk-mq: add a 'list' parameter to ->queue_rq()") Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Nishanth Menon authored
commit 61dc0a44 upstream. pm_runtime_get_sync does return a error value that must be checked for error conditions, else, due to various reasons, the device maynot be enabled and the system will crash due to lack of clock to the hardware module. Before: 12.562784] [00000000] *pgd=fe193835 12.562792] Internal error: : 1406 [#1] SMP ARM [...] 12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2 12.562867] Hardware name: Generic DRA74X (Flattened Device Tree) 12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000 12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng] 12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core] [...] After the proper checks: [ 94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info [ 94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19 [ 94.382351] omap_rng 48090000.rng: initialization failed. Fixes: 665d92fa ("hwrng: OMAP: convert to use runtime PM") Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Russell King authored
commit 06dfe5cc upstream. SA1111 PCMCIA was broken when PCMCIA switched to using dev_pm_ops for the PCMCIA socket class. PCMCIA used to handle suspend/resume via the socket hosting device, which happened at normal device suspend/resume time. However, the referenced commit changed this: much of the resume now happens much earlier, in the noirq resume handler of dev_pm_ops. However, on SA1111, the PCMCIA device is not accessible as the SA1111 has not been resumed at _noirq time. It's slightly worse than that, because the SA1111 has already been put to sleep at _noirq time, so suspend doesn't work properly. Fix this by converting the core SA1111 code to use dev_pm_ops as well, and performing its own suspend/resume at noirq time. This fixes these errors in the kernel log: pcmcia_socket pcmcia_socket0: time out after reset pcmcia_socket pcmcia_socket1: time out after reset and the resulting lack of PCMCIA cards after a S2RAM cycle. Fixes: d7646f76 ("pcmcia: use dev_pm_ops for class pcmcia_socket_class") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Wolfram Sang authored
commit c2f32112 upstream. The current implementation only works if the da9xxx devices are added before their drivers are registered. Only then it can apply the fixes to both devices. Otherwise, the driver for the first device gets probed before the fix for the second device can be applied. This is what fails when using the IP core switcher or when having the i2c master driver as a module. So, we need to disable both da9xxx once we detected one of them. We now use i2c_transfer with hardcoded i2c_messages and device addresses, so we don't need the da9xxx client devices to be instantiated. Because the fixup is used on specific boards only, the addresses are not going to change. Fixes: 663fbb52 ("ARM: shmobile: R-Car Gen2: Add da9063/da9210 regulator quirk") Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> (r8a7791/koelsch) Tested-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
