- 16 Oct, 2016 2 commits
-
-
Andrew Donnellan authored
commit 6f38a8b9 upstream. When cxl removes a vPHB, it's possible that the pci_controller may be freed before all references to the devices on the vPHB have been released. This in turn causes an invalid memory access when the devices are eventually released, as pcibios_release_device() attempts to call the phb's release_device hook. In cxl_pci_vphb_remove(), remove the existing call to pcibios_free_controller(). Instead, use pcibios_free_controller_deferred() to free the pci_controller after all devices have been released. Export pci_set_host_bridge_release() so we can do this. Signed-off-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mauricio Faria de Oliveira authored
commit 2dd9c11b upstream. This patch leverages 'struct pci_host_bridge' from the PCI subsystem in order to free the pci_controller only after the last reference to its devices is dropped (avoiding an oops in pcibios_release_device() if the last reference is dropped after pcibios_free_controller()). The patch relies on pci_host_bridge.release_fn() (and .release_data), which is called automatically by the PCI subsystem when the root bus is released (i.e., the last reference is dropped). Those fields are set via pci_set_host_bridge_release() (e.g. in the platform-specific implementation of pcibios_root_bridge_prepare()). It introduces the 'pcibios_free_controller_deferred()' .release_fn() and it expects .release_data to hold a pointer to the pci_controller. The function implictly calls 'pcibios_free_controller()', so an user must *NOT* explicitly call it if using the new _deferred() callback. The functionality is enabled for pseries (although it isn't platform specific, and may be used by cxl). Details on not-so-elegant design choices: - Use 'pci_host_bridge.release_data' field as pointer to associated 'struct pci_controller' so *not* to 'pci_bus_to_host(bridge->bus)' in pcibios_free_controller_deferred(). That's because pci_remove_root_bus() sets 'host_bridge->bus = NULL' (so, if the last reference is released after pci_remove_root_bus() runs, which eventually reaches pcibios_free_controller_deferred(), that would hit a null pointer dereference). The cxl/vphb.c code calls pci_remove_root_bus(), and the cxl folks are interested in this fix. Test-case #1 (hold references) # ls -ld /sys/block/sd* | grep -m1 0021:01:00.0 <...> /sys/block/sdaa -> ../devices/pci0021:01/0021:01:00.0/<...> # ls -ld /sys/block/sd* | grep -m1 0021:01:00.1 <...> /sys/block/sdab -> ../devices/pci0021:01/0021:01:00.1/<...> # cat >/dev/sdaa & pid1=$! # cat >/dev/sdab & pid2=$! # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r Validating PHB DLPAR capability...yes. [ 594.306719] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01 [ 594.306738] pci_hp_remove_devices: Removing 0021:01:00.0... ... [ 598.236381] pci_hp_remove_devices: Removing 0021:01:00.1... ... [ 611.972077] pci_bus 0021:01: busn_res: [bus 01-ff] is released [ 611.972140] rpadlpar_io: slot PHB 33 removed # kill -9 $pid1 # kill -9 $pid2 [ 632.918088] pcibios_free_controller_deferred: domain 33, dynamic 1 Test-case #2 (don't hold references) # drmgr -w 5 -d 1 -c phb -s 'PHB 33' -r Validating PHB DLPAR capability...yes. [ 916.357363] pci_hp_remove_devices: PCI: Removing devices on bus 0021:01 [ 916.357386] pci_hp_remove_devices: Removing 0021:01:00.0... ... [ 920.566527] pci_hp_remove_devices: Removing 0021:01:00.1... ... [ 933.955873] pci_bus 0021:01: busn_res: [bus 01-ff] is released [ 933.955977] pcibios_free_controller_deferred: domain 33, dynamic 1 [ 933.955999] rpadlpar_io: slot PHB 33 removed Suggested-By:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Reviewed-by:
-
- 07 Oct, 2016 38 commits
-
-
Greg Kroah-Hartman authored
-
Takashi Iwai authored
commit 0eec8809 upstream. HP Spectre x360 with CX20724 codec has two speaker outputs while the BIOS sets up only the bottom one (NID 0x17) and disables the top one (NID 0x1d). This patch adds a fixup simply defining the proper pincfg for NID 0x1d so that the top speaker works as is. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=169071Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
commit 3f640970 upstream. One of the laptops has the codec ALC256 on it, applying the ALC255_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem, the rest of laptops have the codec ALC295 on them, they are similar to machines with ALC225, applying the ALC269_FIXUP_DELL1_MIC_NO_PRESENCE can fix the problem. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Hui Wang authored
commit 392c9da2 upstream. We have two new Dell laptop models, they have the same ALC255 pin definition, but not in the pin quirk table yet, as a result, the headset microphone can't work. After adding the definition in the table, the headset microphone works well. Signed-off-by:
-
Greg Kroah-Hartman authored
commit ab21b63e upstream. This reverts commit e6c7efdc. Turns out it was totally wrong. The memory is supposed to be bound to the kref, as the original code was doing correctly, not the device/driver binding as the devm_kzalloc() would cause. This fixes an oops when read would be called after the device was unbound from the driver. Reported-by:
Ladislav Michl <ladis@linux-mips.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Kyle Jones authored
commit decc5360 upstream. Signed-off-by:
Kyle Jones <kyle@kf5jwc.us> Signed-off-by:
-
Nicolas Iooss authored
commit 238b7bd9 upstream. In v_recv_cmd_submit(), urb_p->urb->pipe has the type unsigned int (which is 32-bit long on x86_64) but 11<<30 results in a 34-bit integer. Therefore the 2 leading bits are truncated and urb_p->urb->pipe &= ~(11 << 30); has the same meaning as urb_p->urb->pipe &= ~(3 << 30); This second statement seems to be how the code was intended to be written, as PIPE_ constants have values between 0 and 3. The overflow has been detected with a clang warning: drivers/usb/usbip/vudc_rx.c:145:27: warning: signed shift result (0x2C0000000) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] urb_p->urb->pipe &= ~(11 << 30); ~~ ^ ~~ Fixes: 79c02cb1 ("usbip: vudc: Add vudc_rx") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
Ksenija Stanojevic authored
commit fc1e2c8e upstream. Commit 367e8560 introduced a bug in fbtft-core where fps is always 0, this is because variable update_time is not assigned correctly. Signed-off-by:
Ksenija Stanojevic <ksenija.stanojevic@gmail.com> Fixes: 367e8560 ("Staging: fbtbt: Replace timespec with ktime_t") Signed-off-by:
-
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:
-
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:
-
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:
-
Jarkko Sakkinen authored
commit 422eac3f upstream. On my Lenovo x250 the following situation occurs: [18697.813871] tpm_crb MSFT0101:00: can't request region for resource [mem 0xacdff080-0xacdfffff] The mapping of the control area overlaps the mapping of the command buffer. The control area is mapped over page, which is not right. It should mapped over sizeof(struct crb_control_area). Fixing this issue unmasks another issue. Command and response buffers can overlap and they do interleave on this machine. According to the PTP specification the overlapping means that they are mapped to the same buffer. The commit has been also on a Haswell NUC where things worked before applying this fix so that the both code paths for response buffer initialization are tested. Cc: stable@vger.kernel.org Fixes: 1bd047be ("tpm_crb: Use devm_ioremap_resource") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Jarkko Sakkinen authored
commit 14ddfbf4 upstream. The iomem resource is needed only temporarily so it is better to pass it on instead of storing it permanently. Named the variable as io_res so that the code better documents itself. Signed-off-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by:
-
Marek Lindner authored
commit d9f17987 upstream. Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Maor Gottlieb authored
commit ee3da804 upstream. Set the source mac address in the FTE when L2 specification is provided. Fixes: 038d2ef8 ('IB/mlx5: Add flow steering support') Signed-off-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Noa Osherovich authored
commit 7fae6655 upstream. MAD_IFC command is supported only for physical functions (PF) and when physical port is IB. The proposed fix enforces it. Fixes: d603c809 ("IB/mlx5: Fix decision on using MAD_IFC") Reported-by:
David Chang <dchang@suse.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> 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:
-
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:
-
Johannes Thumshirn authored
commit 835831c5 upstream. Use scsi_is_sas_rphy() instead of is_sas_attached() to decide whether we should obtain the SAS address from a scsi device or not. This will prevent us from tripping on the BUG_ON() in sas_sdev_to_rdev() if the rphy isn't attached to the SAS transport class, like it is with hpsa's logical devices. Fixes: 3f8d6f2a ('ses: fix discovery of SATA devices in SAS enclosures') Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
James E.J. Bottomley <jejb@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Johannes Thumshirn authored
commit c1a23f6d upstream. Provide a stub implementation for scsi_is_sas_rphy for kernel configurations which do not have CONFIG_SCSI_SAS_ATTRS defined. Reported-by:
kbuild test robot <lkp@intel.com> Suggested-by:
-
Lars-Peter Clausen authored
commit 1bc8da4e upstream. When searching for a suitable node that should be used for inserting a new register, which does not fall within the range of any existing node, we not only looks for nodes which are directly adjacent to the new register, but for nodes within a certain proximity. This is done to avoid creating lots of small nodes with just a few registers spacing in between, which would increase memory usage as well as tree traversal time. This means there might be multiple node candidates which fall within the proximity range of the new register. If we choose the first node we encounter, under certain register insertion patterns it is possible to end up with overlapping ranges. This will break order in the rbtree and can cause the cached register value to become corrupted. E.g. take the simplified example where the proximity range is 2 and the register insertion sequence is 1, 4, 2, 3, 5. * Insert of register 1 creates a new node, this is the root of the rbtree * Insert of register 4 creates a new node, which is inserted to the right of the root. * Insert of register 2 gets inserted to the first node * Insert of register 3 gets inserted to the first node * Insert of register 5 also gets inserted into the first node since this is the first node encountered and it is within the proximity range. Now there are two overlapping nodes. To avoid this always choose the node that is closest to the new register. This will ensure that nodes will not overlap. The tree traversal is still done as a binary search, we just don't stop at the first node found. So the complexity of the algorithm stays within the same order. Ideally if a new register is in the range of two adjacent blocks those blocks should be merged, but that is a much more invasive change and left for later. The issue was initially introduced in commit 472fdec7 ("regmap: rbtree: Reduce number of nodes, take 2"), but became much more exposed by commit 6399aea6 ("regmap: rbtree: When adding a reg do a bsearch for target node") which changed the order in which nodes are looked-up. Fixes: 6399aea6 ("regmap: rbtree: When adding a reg do a bsearch for target node") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Mark Brown <broonie@kernel.org> 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:
-
Ashok Raj Nagarajan authored
commit 237e15df upstream. On handling amsdu on rx path, get the rx_status from htt context. Without this fix, we are seeing warnings when running DBDC traffic like this. WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4105 ieee80211_rx_napi+0x88/0x7d8 [mac80211]() [ 1715.878248] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 3.18.21 #1 [ 1715.878273] [<c001d3f4>] (unwind_backtrace) from [<c001a4b0>] (show_stack+0x10/0x14) [ 1715.878293] [<c001a4b0>] (show_stack) from [<c01bee64>] (dump_stack+0x70/0xbc) [ 1715.878315] [<c01bee64>] (dump_stack) from [<c002a61c>] (warn_slowpath_common+0x64/0x88) [ 1715.878339] [<c002a61c>] (warn_slowpath_common) from [<c002a6d0>] (warn_slowpath_null+0x18/0x20) [ 1715.878395] [<c002a6d0>] (warn_slowpath_null) from [<bf4caa98>] (ieee80211_rx_napi+0x88/0x7d8 [mac80211]) [ 1715.878474] [<bf4caa98>] (ieee80211_rx_napi [mac80211]) from [<bf568658>] (ath10k_htt_t2h_msg_handler+0xb48/0xbfc [ath10k_core]) [ 1715.878535] [<bf568658>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [<bf568708>] (ath10k_htt_t2h_msg_handler+0xbf8/0xbfc [ath10k_core]) [ 1715.878597] [<bf568708>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from [<bf569160>] (ath10k_htt_txrx_compl_task+0xa54/0x1170 [ath10k_core]) [ 1715.878639] [<bf569160>] (ath10k_htt_txrx_compl_task [ath10k_core]) from [<c002db14>] (tasklet_action+0xb4/0x130) [ 1715.878659] [<c002db14>] (tasklet_action) from [<c002d110>] (__do_softirq+0xe0/0x210) [ 1715.878678] [<c002d110>] (__do_softirq) from [<c002d4b4>] (irq_exit+0x84/0xe0) [ 1715.878700] [<c002d4b4>] (irq_exit) from [<c005a544>] (__handle_domain_irq+0x98/0xd0) [ 1715.878722] [<c005a544>] (__handle_domain_irq) from [<c00085f4>] (gic_handle_irq+0x38/0x5c) [ 1715.878741] [<c00085f4>] (gic_handle_irq) from [<c0009680>] (__irq_svc+0x40/0x74) [ 1715.878753] Exception stack(0xc05f9f50 to 0xc05f9f98) [ 1715.878767] 9f40: ffffffed 00000000 00399e1e c000a220 [ 1715.878786] 9f60: 00000000 c05f6780 c05f8000 00000000 c05f5db8 ffffffed c05f8000 c04d1980 [ 1715.878802] 9f80: 00000000 c05f9f98 c0018110 c0018114 60000013 ffffffff [ 1715.878822] [<c0009680>] (__irq_svc) from [<c0018114>] (arch_cpu_idle+0x2c/0x50) [ 1715.878844] [<c0018114>] (arch_cpu_idle) from [<c00530d4>] (cpu_startup_entry+0x108/0x234) [ 1715.878866] [<c00530d4>] (cpu_startup_entry) from [<c05c7be0>] (start_kernel+0x33c/0x3b8) [ 1715.878879] ---[ end trace 6d5e1cc0fef8ed6a ]--- [ 1715.878899] ------------[ cut here ]------------ Fixes: 18235664 ("ath10k: cleanup amsdu processing for rx indication") Signed-off-by:
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.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:
-
Nicolas Iooss authored
commit 0f5aa88a upstream. Commit f3c4ebe6 ("ceph: using hash value to compose dentry offset") modified "if (fpos_frag(new_pos) != fi->frag)" to "if (fi->frag |= fpos_frag(new_pos))" in need_reset_readdir(), thus replacing a comparison operator with an assignment one. This looks like a typo which is reported by clang when building the kernel with some warning flags: fs/ceph/dir.c:600:22: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses] } else if (fi->frag |= fpos_frag(new_pos)) { ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~ fs/ceph/dir.c:600:22: note: place parentheses around the assignment to silence this warning } else if (fi->frag |= fpos_frag(new_pos)) { ^ ( ) fs/ceph/dir.c:600:22: note: use '!=' to turn this compound assignment into an inequality comparison } else if (fi->frag |= fpos_frag(new_pos)) { ^~ != Fixes: f3c4ebe6 ("ceph: using hash value to compose dentry offset") Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> 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:
-
Geert Uytterhoeven authored
commit e6173ba4 upstream. Some versions of gcc don't like tests for the value of an undefined preprocessor symbol, even in the #else branch of an #ifndef: lib/test_hash.c:224:7: warning: "HAVE_ARCH__HASH_32" is not defined [-Wundef] #elif HAVE_ARCH__HASH_32 != 1 ^ lib/test_hash.c:229:7: warning: "HAVE_ARCH_HASH_32" is not defined [-Wundef] #elif HAVE_ARCH_HASH_32 != 1 ^ lib/test_hash.c:234:7: warning: "HAVE_ARCH_HASH_64" is not defined [-Wundef] #elif HAVE_ARCH_HASH_64 != 1 ^ Seen with gcc 4.9, not seen with 4.1.2. Change the logic to only check the value inside an #ifdef to fix this. Fixes: 468a9428 ("<linux/hash.h>: Add support for architecture-specific functions") Link: http://lkml.kernel.org/r/20160829214952.1334674-4-arnd@arndb.deSigned-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
George Spelvin <linux@sciencehorizons.net> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
commit 1c8d477a upstream. Putting the periodicity timer in the mirror instances is causing non-scalable reporting behaviour and missed reporting intervals. When you recall layouts and/or implement client side mirroring, it leads to consecutive reports with only a few ms between RPC calls. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Fixes: d0379a5d ("pNFS/flexfiles: Support server-supplied...") Signed-off-by:
-
Chuck Lever authored
commit 16590a22 upstream. Using NFSv4.1 on RDMA should be safe, so broaden the new checks in rpc_create(). WARN_ON_ONCE is used, matching most other WARN call sites in clnt.c. Fixes: 39a9beab ("rpc: share one xps between all backchannels") Fixes: d50039ea ("nfsd4/rpc: move backchannel create logic...") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Reviewed-by:
J. Bruce Fields <bfields@fieldses.org> 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:
-
Wei Yongjun authored
commit 23d70503 upstream. 'work' and 'route->path_rec' are malloced in cma_resolve_iboe_route() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: 20029832 ('IB/core: Validate route when we init ah') Signed-off-by:
Haggai Eran <haggaie@mellanox.com> 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:
-
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:
-
Phil Turnbull authored
commit c71f20ee upstream. The CMDF_ROUND_DOWN case falls through and so always returns -EINVAL. Fixes: 14b93bb6 ("staging: comedi: adv_pci_dio: separate out PCI-1760 support") Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
