- 22 Mar, 2017 6 commits
-
-
Stefan Bader authored
This reverts commit d8028df7. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Stefan Bader authored
This reverts commit 3432cc02. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 1d96b90f. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit efe57ae3. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
This reverts commit 105517c1. BugLink: https://bugs.launchpad.net/bugs/1666897Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 08 Mar, 2017 34 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1668594 When userspace sends KVM_SET_LAPIC, KVM schedules a check between the vCPU's IRR and ISR and the IOAPIC redirection table, in order to re-establish the IOAPIC's dest_map (the list of CPUs servicing the real-time clock interrupt with the corresponding vectors). However, __rtc_irq_eoi_tracking_restore_one was forgetting to set dest_map->vectors. Because of this, the IOAPIC did not process the real-time clock interrupt EOI, ioapic->rtc_status.pending_eoi got stuck at a non-zero value, and further RTC interrupts were reported to userspace as coalesced. Fixes: 9e4aabe2 Fixes: 4d99ba89 Cc: stable@vger.kernel.org Cc: Joerg Roedel <jroedel@suse.de> Cc: David Gilbert <dgilbert@redhat.com> Reviewed-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b0eaf450) Signed-off-by:
Fabian Grünbichler <f.gruenbichler@proxmox.com>
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit 40f7a7e0. Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit 06393b1b. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit 70330b27. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
BugLink: http://bugs.launchpad.net/bugs/1669611 This reverts commit f2f5c290. Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1665211 Dell Caracalla IoT gateways sport a Redpine RS9113 WLAN-BT combo card. This patch adds Host AP mode support to the Redpine RS9113 driver. Vendor release version: 0.9.8.3 (Beta) Other fixes: - Connection drop issue with multiple APs/mobile phone hotspots Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1649292 To support unprivileged users mounting filesystems two permission checks have to be performed: a test to see if the user allowed to create a mount in the mount namespace, and a test to see if the user is allowed to access the specified filesystem. The automount case is special in that mounting the original filesystem grants permission to mount the sub-filesystems, to any user who happens to stumble across the their mountpoint and satisfies the ordinary filesystem permission checks. Attempting to handle the automount case by using override_creds almost works. It preserves the idea that permission to mount the original filesystem is permission to mount the sub-filesystem. Unfortunately using override_creds messes up the filesystems ordinary permission checks. Solve this by being explicit that a mount is a submount by introducing vfs_submount, and using it where appropriate. vfs_submount uses a new mount internal mount flags MS_SUBMOUNT, to let sget and friends know that a mount is a submount so they can take appropriate action. sget and sget_userns are modified to not perform any permission checks on submounts. follow_automount is modified to stop using override_creds as that has proven problemantic. do_mount is modified to always remove the new MS_SUBMOUNT flag so that we know userspace will never by able to specify it. autofs4 is modified to stop using current_real_cred that was put in there to handle the previous version of submount permission checking. cifs is modified to pass the mountpoint all of the way down to vfs_submount. debugfs is modified to pass the mountpoint all of the way down to trace_automount by adding a new parameter. To make this change easier a new typedef debugfs_automount_t is introduced to capture the type of the debugfs automount function. Cc: stable@vger.kernel.org Fixes: 069d5ac9 ("autofs: Fix automounts by using current_real_cred()->uid") Fixes: aeaa4a79 ("fs: Call d_automount with the filesystems creds") Reviewed-by:
Trond Myklebust <trond.myklebust@primarydata.com> Reviewed-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> (backported from commit 93faccbb linux-next) Signed-off-by:
-
Long Li authored
BugLink: http://bugs.launchpad.net/bugs/1665097 A PCI_EJECT message can arrive at the same time we are calling pci_scan_child_bus in the workqueue for the previous PCI_BUS_RELATIONS message or in create_root_hv_pci_bus(), in this case we could potentailly modify the bus from multiple places. Properly lock the bus access. Thanks Dexuan Cui <decui@microsoft.com> for pointing out the race condition in create_root_hv_pci_bus(). Signed-off-by:
Long Li <longli@microsoft.com> Reported-by:
Xiaofeng Wang <xiaofwan@redhat.com> Signed-off-by:
-
Long Li authored
BugLink: http://bugs.launchpad.net/bugs/1665097 hv_pci_devices_present is called in hv_pci_remove when we remove a PCI device from host (e.g. by disabling SRIOV on a device). In hv_pci_remove, the bus is already removed before the call, so we don't need to rescan the bus in the workqueue scheduled from hv_pci_devices_present. By introducing status hv_pcibus_removed, we can avoid this situation. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1665097 The devfn of 00:02.0 is 0x10. devfn_to_wslot(0x10) == 0x2, and wslot_to_devfn(0x2) should be 0x10, while it's 0x2 in the current code. Due to this, hv_eject_device_work() -> pci_get_domain_bus_and_slot() returns NULL and pci_stop_and_remove_bus_device() is not called. Later when the real device driver's .remove() is invoked by hv_pci_remove() -> pci_stop_root_bus(), some warnings can be noticed because the VM has lost the access to the underlying device at that time. Signed-off-by:
Jake Oshins <jakeo@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Haiyang Zhang <haiyangz@microsoft.com> CC: stable@vger.kernel.org CC: K. Y. Srinivasan <kys@microsoft.com> CC: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
Jack Morgenstein authored
BugLink: http://bugs.launchpad.net/bugs/1650058 Some Hypervisors detach VFs from VMs by instantly causing an FLR event to be generated for a VF. In the mlx4 case, this will cause that VF's comm channel to be disabled before the VM has an opportunity to invoke the VF device's "shutdown" method. The result is that the VF driver on the VM will experience a command timeout during the shutdown process when the Hypervisor does not deliver a command-completion event to the VM. To avoid FW command timeouts on the VM when the driver's shutdown method is invoked, we detect the absence of the VF's comm channel at the very start of the shutdown process. If the comm-channel has already been disabled, we cause all FW commands during the device shutdown process to immediately return success (and thus avoid all command timeouts). Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit d585df1c) Signed-off-by:
-
Jack Morgenstein authored
BugLink: http://bugs.launchpad.net/bugs/1650058 Save the qp context flags byte containing the flag disabling vlan stripping in the RESET to INIT qp transition, rather than in the INIT to RTR transition. Per the firmware spec, the flags in this byte are active in the RESET to INIT transition. As a result of saving the flags in the incorrect qp transition, when switching dynamically from VGT to VST and back to VGT, the vlan remained stripped (as is required for VST) and did not return to not-stripped (as is required for VGT). Fixes: f0f829bf ("net/mlx4_core: Add immediate activate for VGT->VST->VGT") Signed-off-by:
-
Jack Morgenstein authored
BugLink: http://bugs.launchpad.net/bugs/1650058 In function mlx4_cq_completion() and mlx4_cq_event(), the radix_tree_lookup requires a rcu_read_lock. This is mandatory: if another core frees the CQ, it could run the radix_tree_node_rcu_free() call_rcu() callback while its being used by the radix tree lookup function. Additionally, in function mlx4_cq_event(), since we are adding the rcu lock around the radix-tree lookup, we no longer need to take the spinlock. Also, the synchronize_irq() call for the async event eliminates the need for incrementing the cq reference count in mlx4_cq_event(). Other changes: 1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock: we no longer take this spinlock in the interrupt context. The spinlock here, therefore, simply protects against different threads simultaneously invoking mlx4_cq_free() for different cq's. 2. In function mlx4_cq_free(), we move the radix tree delete to before the synchronize_irq() calls. This guarantees that we will not access this cq during any subsequent interrupts, and therefore can safely free the CQ after the synchronize_irq calls. The rcu_read_lock in the interrupt handlers only needs to protect against corrupting the radix tree; the interrupt handlers may access the cq outside the rcu_read_lock due to the synchronize_irq calls which protect against premature freeing of the cq. 3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg. 4. We leave the cq reference count mechanism in place, because it is still needed for the cq completion tasklet mechanism. Fixes: 6d90aa5c ("net/mlx4_core: Make sure there are no pending async events when freeing CQ") Fixes: 225c7b1f ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters") Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Eugenia Emantayev authored
BugLink: http://bugs.launchpad.net/bugs/1650058 Single send WQE in RX buffer should be stamped with software ownership in order to prevent the flow of QP in error in FW once UPDATE_QP is called. Fixes: 9f519f68 ('mlx4_en: Not using Shared Receive Queues') Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1664960Signed-off-by:
-
Andrey Ryabinin authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 5351fbb1 upstream. page_flip_completed() dereferences 'work' variable after executing queue_work(). This is not safe as the 'work' item might be already freed by queued work: BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90 Call Trace: __asan_report_load8_noabort+0x59/0x80 page_flip_completed+0x3ff/0x490 intel_finish_page_flip_mmio+0xe3/0x130 intel_pipe_handle_vblank+0x2d/0x40 gen8_irq_handler+0x4a7/0xed0 __handle_irq_event_percpu+0xf6/0x860 handle_irq_event_percpu+0x6b/0x160 handle_irq_event+0xc7/0x1b0 handle_edge_irq+0x1f4/0xa50 handle_irq+0x41/0x70 do_IRQ+0x9a/0x200 common_interrupt+0x89/0x89 Freed: kfree+0x113/0x4d0 intel_unpin_work_fn+0x29a/0x3b0 process_one_work+0x79e/0x1b70 worker_thread+0x611/0x1460 kthread+0x241/0x3a0 ret_from_fork+0x27/0x40 Move queue_work() after trace_i915_flip_complete() to fix this. Fixes: e5510fac ("drm/i915: add tracepoints for flip requests & completions") Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com (cherry picked from commit 05c41f92) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 37a7ea4a upstream. snd_seq_pool_done() syncs with closing of all opened threads, but it aborts the wait loop with a timeout, and proceeds to the release resource even if not all threads have been closed. The timeout was 5 seconds, and if you run a crazy stuff, it can exceed easily, and may result in the access of the invalid memory address -- this is what syzkaller detected in a bug report. As a fix, let the code graduate from naiveness, simply remove the loop timeout. BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.comReported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 4842e98f upstream. When a sequencer queue is created in snd_seq_queue_alloc(),it adds the new queue element to the public list before referencing it. Thus the queue might be deleted before the call of snd_seq_queue_use(), and it results in the use-after-free error, as spotted by syzkaller. The fix is to reference the queue object at the right time. Reported-by:
-
Boris Ostrovsky authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 74470954 upstream. rx_refill_timer should be deleted as soon as we disconnect from the backend since otherwise it is possible for the timer to go off before we get to xennet_destroy_queues(). If this happens we may dereference queue->rx.sring which is set to NULL in xennet_disconnect_backend(). Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
ojab authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit ffdadd68 upstream. MPI2 controllers sometimes got lost (i.e. disappear from /sys/bus/pci/devices) if ASMP is enabled. Signed-off-by:
Slava Kardakov <ojab@ojab.ru> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60644Acked-by:
Sreekanth Reddy <Sreekanth.Reddy@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Dave Carroll authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 8af8e1c2 upstream. commit 78cbccd3 ("aacraid: Fix for KDUMP driver hang") caused a problem on older controllers which do not support MSI-x (namely ASR3405,ASR3805). This patch conditionalizes the previous patch to controllers which support MSI-x Fixes: 78cbccd3 ("aacraid: Fix for KDUMP driver hang") Reported-by:
Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by:
Dave Carroll <david.carroll@microsemi.com> Reviewed-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
-
Steffen Maier authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 2dfa6688 upstream. Dan Carpenter kindly reported: <quote> The patch d27a7cb9: "zfcp: trace on request for open and close of WKA port" from Aug 10, 2016, leads to the following static checker warning: drivers/s390/scsi/zfcp_fsf.c:1615 zfcp_fsf_open_wka_port() warn: 'req' was already freed. drivers/s390/scsi/zfcp_fsf.c 1609 zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT); 1610 retval = zfcp_fsf_req_send(req); 1611 if (retval) 1612 zfcp_fsf_req_free(req); ^^^ Freed. 1613 out: 1614 spin_unlock_irq(&qdio->req_q_lock); 1615 if (req && !IS_ERR(req)) 1616 zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id); ^^^^^^^^^^^ Use after free. 1617 return retval; 1618 } Same thing for zfcp_fsf_close_wka_port() as well. </quote> Rather than relying on req being NULL (or ERR_PTR) for all cases where we don't want to trace or should not trace, simply check retval which is unconditionally initialized with -EIO != 0 and it can only become 0 on successful retval = zfcp_fsf_req_send(req). With that we can also remove the then again unnecessary unconditional initialization of req which was introduced with that earlier commit. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Suggested-by:
Benjamin Block <bblock@linux.vnet.ibm.com> Signed-off-by:
Steffen Maier <maier@linux.vnet.ibm.com> Fixes: d27a7cb9 ("zfcp: trace on request for open and close of WKA port") Reviewed-by:
Jens Remus <jremus@linux.vnet.ibm.com> Signed-off-by:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1664960 Commit a50af86d "netvsc: reduce maximum GSO size" was wrongly backported to 4.4-stable. The maximum size needs to be set before the net device is registered, in netvsc_probe(). Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by:
-
Thorsten Horstmann authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit da7061c8 upstream. The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The return value in mesh_add_vendor_ies must therefore be checked against ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with WLAN_EID_VENDOR_SPECIFIC will be rejected. Fixes: 082ebb0c ("mac80211: fix mesh beacon format") Signed-off-by:
Thorsten Horstmann <thorsten@defutech.de> Signed-off-by:
Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> [sven@narfation.org: Add commit message] Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Alexander Sverdlin authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 97a98ae5 upstream. Asynchronous external abort is coded differently in DFSR with LPAE enabled. Fixes: 9254970c "ARM: 8447/1: catch pending imprecise abort on unmask". Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 9b2792c3 upstream. This patch addresses a long standing bug where the commit phase of COMPARE_AND_WRITE would result in a se_cmd->cmd_kref reference leak if se_cmd->scsi_status returned non SAM_STAT_GOOD. This would manifest first as a lost SCSI response, and eventual hung task during fabric driver logout or re-login, as existing shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref to reach zero. To address this bug, compare_and_write_post() has been changed to drop the incorrect !cmd->scsi_status conditional that was preventing *post_ret = 1 for being set during non SAM_STAT_GOOD status. This patch has been tested with SAM_STAT_CHECK_CONDITION status from normal target_complete_cmd() callback path, as well as the incoming __target_execute_cmd() submission failure path when se_cmd->execute_cmd() returns non zero status. Reported-by:
Donald White <dew@datera.io> Cc: Donald White <dew@datera.io> Tested-by:
Gary Guo <ghg@datera.io> Cc: Gary Guo <ghg@datera.io> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit c54eeffb upstream. This patch fixes a bug where incoming task management requests can be explicitly aborted during an active LUN_RESET, but who's struct work_struct are canceled in-flight before execution. This occurs when core_tmr_drain_tmr_list() invokes cancel_work_sync() for the incoming se_tmr_req->task_cmd->work, resulting in cmd->work for target_tmr_work() never getting invoked and the aborted TMR waiting indefinately within transport_wait_for_tasks(). To address this case, perform a CMD_T_ABORTED check early in transport_generic_handle_tmr(), and invoke the normal path via transport_cmd_check_stop_to_fabric() to complete any TMR kthreads blocked waiting for CMD_T_STOP in transport_wait_for_tasks(). Also, move the TRANSPORT_ISTATE_PROCESSING assignment earlier into transport_generic_handle_tmr() so the existing check in core_tmr_drain_tmr_list() avoids attempting abort the incoming se_tmr_req->task_cmd->work if it has already been queued into se_device->tmr_wq. Reported-by:
Rob Millner <rlm@daterainc.com> Tested-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 0583c261 upstream. This patch adds the missing target_complete_cmd() SCSI status parameter change in target_xcopy_do_work(), that was originally missing in commit 926317de. It correctly propigates up the correct SCSI status during EXTENDED_COPY exception cases, instead of always using the hardcoded SAM_STAT_CHECK_CONDITION from original code. This is required for ESX host environments that expect to hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios, and SAM_STAT_CHECK_CONDITION results in non-retriable status for these cases. Reported-by:
Nixon Vincent <nixon.vincent@calsoftinc.com> Tested-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 391e2a6d upstream. After the v4.2+ RCU conversion to se_node_acl->lun_entry_hlist, a BUG_ON() was added in core_enable_device_list_for_node() to detect when the located orig->se_lun_acl contains an existing se_lun_acl pointer reference. However, this scenario can happen when a dynamically generated NodeACL is being converted to an explicit NodeACL, when the explicit NodeACL contains a different LUN mapping than the default provided by the WWN endpoint. So instead of triggering BUG_ON(), go ahead and fail instead following the original pre RCU conversion logic. Reported-by:
Benjamin ESTRABAUD <ben.estrabaud@mpstor.com> Cc: Benjamin ESTRABAUD <ben.estrabaud@mpstor.com> Reviewed-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 228dbbfb upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Fixes: 5be6f62b ("ARM: 6883/1: ptrace: Migrate to regsets framework") Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit b3f2d07f upstream. The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use an indexed load for the register address, but it has an absolutely detrimental effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely kernel stack overflow aside from very complex object code: hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats': hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common': hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs': hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs': hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs': hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs': hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init': hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs': hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats': hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs': hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE seems safe anyway and it avoids a serious issue for some people. I have verified that with gcc-5.3.1, the object code we get is better in the new version both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte stack frame for hns_dsaf_get_regs() but otherwise have practically identical object code. With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already good either way. This patch is probably not urgent to get into 4.11 as only KASAN=y builds with certain compilers are affected, but I still think it makes sense to backport into older kernels. Fixes: 511e6bc0 ("net: add Hisilicon Network Subsystem DSAF support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Tejun Heo authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit 4d59b6cc upstream. Commit 513e3d2d ("cpumask: always use nr_cpu_ids in formatting and parsing functions") converted both cpumask printing and parsing functions to use nr_cpu_ids instead of nr_cpumask_bits. While this was okay for the printing functions as it just picked one of the two output formats that we were alternating between depending on a kernel config, doing the same for parsing wasn't okay. nr_cpumask_bits can be either nr_cpu_ids or NR_CPUS. We can always use nr_cpu_ids but that is a variable while NR_CPUS is a constant, so it can be more efficient to use NR_CPUS when we can get away with it. Converting the printing functions to nr_cpu_ids makes sense because it affects how the masks get presented to userspace and doesn't break anything; however, using nr_cpu_ids for parsing functions can incorrectly leave the higher bits uninitialized while reading in these masks from userland. As all testing and comparison functions use nr_cpumask_bits which can be larger than nr_cpu_ids, the parsed cpumasks can erroneously yield false negative results. This made the taskstats interface incorrectly return -EINVAL even when the inputs were correct. Fix it by restoring the parse functions to use nr_cpumask_bits instead of nr_cpu_ids. Link: http://lkml.kernel.org/r/20170206182442.GB31078@htj.duckdns.org Fixes: 513e3d2d ("cpumask: always use nr_cpu_ids in formatting and parsing functions") Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Martin Steigerwald <martin.steigerwald@teamix.de> Debugged-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
BugLink: http://bugs.launchpad.net/bugs/1664960 commit d966564f upstream. This reverts commit 020eb3da. Gabriel C reports that it causes his machine to not boot, and we haven't tracked down the reason for it yet. Since the bug it fixes has been around for a longish time, we're better off reverting the fix for now. Gabriel says: "It hangs early and freezes with a lot RCU warnings. I bisected it down to : > Ruslan Ruslichenko (1): > x86/ioapic: Restore IO-APIC irq_chip retrigger callback Reverting this one fixes the problem for me.. The box is a PRIMERGY TX200 S5 , 2 socket , 2 x E5520 CPU(s) installed" and Ruslan and Thomas are currently stumped. Reported-and-bisected-by:
Gabriel C <nix.or.die@gmail.com> Cc: Ruslan Ruslichenko <rruslich@cisco.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
