- 27 Jan, 2015 40 commits
-
-
Tomeu Vizoso authored
commit 10cdfe54 upstream. As __clk_release could call kfree on clk and then we wouldn't have a safe way of getting the module that owns the clock. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Fixes: fcb0ee6a ("clk: Implement clk_unregister") Reviewed-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Michael Turquette <mturquette@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Boyd authored
commit 89f7e9de upstream. Commit 6314b679 (clk: Don't hold prepare_lock across debugfs creation, 2014-09-04) forgot to update one place where we hold the prepare_lock while creating debugfs directories. This means we still have the chance of a deadlock that the commit was trying to fix. Actually fix it by moving the debugfs creation outside the prepare_lock. Reported-by:
Russell King <rmk+kernel@arm.linux.org.uk> Fixes: 6314b679 "clk: Don't hold prepare_lock across debugfs creation" Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Krzysztof Kozlowski authored
commit c31844ff upstream. During driver unbind the syscore ops were not unregistered which lead to double add on syscore list: $ echo "3810000.audss-clock-controller" > /sys/bus/platform/drivers/exynos-audss-clk/unbind $ echo "3810000.audss-clock-controller" > /sys/bus/platform/drivers/exynos-audss-clk/bind [ 1463.044061] ------------[ cut here ]------------ [ 1463.047255] WARNING: CPU: 0 PID: 1 at lib/list_debug.c:36 __list_add+0x8c/0xc0() [ 1463.054613] list_add double add: new=c06e52c0, prev=c06e52c0, next=c06d5f84. [ 1463.061625] Modules linked in: [ 1463.064623] CPU: 0 PID: 1 Comm: bash Tainted: G W 3.18.0-rc5-next-20141121-00005-ga8fab06eab42-dirty #1022 [ 1463.075338] [<c0014e2c>] (unwind_backtrace) from [<c0011d80>] (show_stack+0x10/0x14) [ 1463.083046] [<c0011d80>] (show_stack) from [<c048bb70>] (dump_stack+0x70/0xbc) [ 1463.090236] [<c048bb70>] (dump_stack) from [<c00233d4>] (warn_slowpath_common+0x74/0xb0) [ 1463.098295] [<c00233d4>] (warn_slowpath_common) from [<c00234a4>] (warn_slowpath_fmt+0x30/0x40) [ 1463.106962] [<c00234a4>] (warn_slowpath_fmt) from [<c020fe80>] (__list_add+0x8c/0xc0) [ 1463.114760] [<c020fe80>] (__list_add) from [<c0282094>] (register_syscore_ops+0x30/0x3c) [ 1463.122819] [<c0282094>] (register_syscore_ops) from [<c0392f20>] (exynos_audss_clk_probe+0x36c/0x460) [ 1463.132091] [<c0392f20>] (exynos_audss_clk_probe) from [<c0283084>] (platform_drv_probe+0x48/0xa4) [ 1463.141013] [<c0283084>] (platform_drv_probe) from [<c0281a14>] (driver_probe_device+0x13c/0x37c) [ 1463.149852] [<c0281a14>] (driver_probe_device) from [<c0280560>] (bind_store+0x90/0xe0) [ 1463.157822] [<c0280560>] (bind_store) from [<c027fd10>] (drv_attr_store+0x20/0x2c) [ 1463.165363] [<c027fd10>] (drv_attr_store) from [<c0143898>] (sysfs_kf_write+0x4c/0x50) [ 1463.173252] [<c0143898>] (sysfs_kf_write) from [<c0142c80>] (kernfs_fop_write+0xbc/0x198) [ 1463.181395] [<c0142c80>] (kernfs_fop_write) from [<c00e2be0>] (vfs_write+0xa0/0x1a8) [ 1463.189104] [<c00e2be0>] (vfs_write) from [<c00e2f00>] (SyS_write+0x40/0x8c) [ 1463.196122] [<c00e2f00>] (SyS_write) from [<c000f2a0>] (ret_fast_syscall+0x0/0x48) [ 1463.203655] ---[ end trace 08f6710c9bc8d8f3 ]--- [ 1463.208244] exynos-audss-clk 3810000.audss-clock-controller: setup completed Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 1241ef94 ("clk: samsung: register audio subsystem clocks using common clock framework") Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Alan Stern authored
commit 511833ac upstream. Commit ac61d195 (scsi: set correct completion code in scsi_send_eh_cmnd()) introduced a bug. It changed the stored return value from a queuecommand call, but it didn't take into account that the return value was used again later on. This patch fixes the bug by changing the later usage. There is a big comment in the middle of scsi_send_eh_cmnd() which does a good job of explaining how the routine works. But it mentions a "rtn = FAILURE" value that doesn't exist in the code. This patch adjusts the code to match the comment (I assume the comment is right and the code is wrong). This fixes Bugzilla #88341. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Андрей Аладьев <aladjev.andrew@gmail.com> Tested-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Tony Battersby authored
commit 120bb3e1 upstream. This fixes random memory corruption triggered when all three of the following are true: * scsi-mq enabled * T10 Protection Information (DIF) enabled * SCSI host with sg_tablesize > SCSI_MAX_SG_SEGMENTS (128) The symptoms of this bug are unpredictable memory corruption, BUG()s, oopses, lockups, etc., any of which may appear to be completely unrelated to the root cause. Signed-off-by:
Tony Battersby <tonyb@cybernetics.com> Reviewed-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Martin K. Petersen authored
commit 198a956a upstream. The Microsoft iSCSI target does not support REPORT SUPPORTED OPERATION CODES. Blacklist these devices so we don't attempt to send the command. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Tested-by:
Mike Christie <michaelc@cs.wisc.edu> Reported-by: jazz@deti74.ru Signed-off-by:
-
Sreekanth Reddy authored
commit 2311ce4d upstream. This reverts commit 963ba22b ("mpt3sas: Remove phys on topology change") Reverting the previous mpt3sas drives patch changes, since we will observe below issue Issue: Drives connected Enclosure/Expander will unregister with SCSI Transport Layer, if any one remove and add expander cable with in DMD (Device Missing Delay) time period or even any one power-off and power-on the Enclosure with in the DMD period. Signed-off-by:
Sreekanth Reddy <Sreekanth.Reddy@avagotech.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Sreekanth Reddy authored
commit 81a89c2d upstream. This reverts commit 3520f9c7 ("mpt2sas: Remove phys on topology change") Reverting the previous mpt2sas drives patch changes, since we will observe below issue Issue: Drives connected Enclosure/Expander will unregister with SCSI Transport Layer, if any one remove and add expander cable with in DMD (Device Missing Delay) time period or even any one power-off and power-on the Enclosure with in the DMD period. Signed-off-by:
-
Ville Syrjälä authored
commit 01f5a626 upstream. The VGA_2X_MODE bit apparently affects the display even when the VGA plane is disabled. The bit will set by the BIOS when the panel width is at least 1280 pixels. So by preserving the bit from the BIOS we end up with corrupted display on machines with such high res panels. I only have 1024x768 panels on my gen2 machines so never ran into this problem. The original reason for preserving the VGACNTR register was to make my 830 survive S3 with acpi_sleep=s3_bios option. However after further 830 fixes that option is no longer needed to make S3 work and preserving VGACNTR doesn't seem to be necessary without it, so we can just revert the entire patch. This reverts commit 69769f9a Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Aug 15 01:22:08 2014 +0300 drm/i915: Preserve VGACNTR bits from the BIOS Cc: Bruno Prémont <bonbons@linux-vserver.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Sagi Grimberg authored
commit 23a548ee upstream. iSER will report supported protection operations based on the tpg attribute t10_pi settings and HCA PI offload capabilities. If the HCA does not support PI offload or tpg attribute t10_pi is not set, we fall to SW PI mode. In order to do that, we move iscsit_get_sup_prot_ops after connection tpg assignment. Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
-
Sagi Grimberg authored
commit 302cc7c3 upstream. Fallback to software mode DIF if HCA does not support PI (without crashing obviously). It is still possible to run with backend protection and an unprotected frontend, so looking at the command prot_op is not enough. Check device PI capability on a per-IO basis (isert_prot_cmd inline static) to determine if we need to handle protection information. Trace: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffffa037f8b1>] isert_reg_sig_mr+0x351/0x3b0 [ib_isert] Call Trace: [<ffffffff812b003a>] ? swiotlb_map_sg_attrs+0x7a/0x130 [<ffffffffa038184d>] isert_reg_rdma+0x2fd/0x370 [ib_isert] [<ffffffff8108f2ec>] ? idle_balance+0x6c/0x2c0 [<ffffffffa0382b68>] isert_put_datain+0x68/0x210 [ib_isert] [<ffffffffa02acf5b>] lio_queue_data_in+0x2b/0x30 [iscsi_target_mod] [<ffffffffa02306eb>] target_complete_ok_work+0x21b/0x310 [target_core_mod] [<ffffffff8106ece2>] process_one_work+0x182/0x3b0 [<ffffffff8106fda0>] worker_thread+0x120/0x3c0 [<ffffffff8106fc80>] ? maybe_create_worker+0x190/0x190 [<ffffffff8107594e>] kthread+0xce/0xf0 [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8159a22c>] ret_from_fork+0x7c/0xb0 [<ffffffff81075880>] ? kthread_freezable_should_stop+0x70/0x70 Reported-by:
Slava Shwartsman <valyushash@gmail.com> Signed-off-by:
-
Sagi Grimberg authored
commit 570db170 upstream. This patch converts to allocate PI contexts dynamically in order avoid a potentially bogus np->tpg_np and associated NULL pointer dereference in isert_connect_request() during iser-target endpoint shutdown with multiple network portals. Also, there is really no need to allocate these at connection establishment since it is not guaranteed that all the IOs on that connection will be to a PI formatted device. We can do it in a lazy fashion so the initial burst will have a transient slow down, but very fast all IOs will allocate a PI context. Squashed: iser-target: Centralize PI context handling code Signed-off-by:
-
Sagi Grimberg authored
commit b02efbfc upstream. In situations such as bond failover, The new session establishment implicitly invokes the termination of the old connection. So, we don't want to wait for the old connection wait_conn to completely terminate before we accept the new connection and post a login response. The solution is to deffer the comp_wait completion and the conn_put to a work so wait_conn will effectively be non-blocking (flush errors are assumed to come very fast). We allocate isert_release_wq with WQ_UNBOUND and WQ_UNBOUND_MAX_ACTIVE to spread the concurrency of release works. Reported-by:
-
Sagi Grimberg authored
commit ca6c1d82 upstream. The np listener cm_id will also get ADDR_CHANGE event upcall (in case it is bound to a specific IP). Handle it correctly by creating a new cm_id and implicitly destroy the old one. Since this is the second event a listener np cm_id may encounter, we move the np cm_id event handling to a routine. Squashed: iser-target: Move cma_id setup to a function Reported-by:
-
Sagi Grimberg authored
commit 19e2090f upstream. Take isert_conn pointer from cm_id->qp->qp_context. This will allow us to know that the cm_id context is always the network portal. This will make the cm_id event check (connection or network portal) more reliable. In order to avoid a NULL dereference in cma_id->qp->qp_context we destroy the qp after we destroy the cm_id (and make the dereference safe). session stablishment/teardown sequences can happen in parallel, we should take into account that connected_handler might race with connection teardown flow. Also, protect isert_conn->conn_device->active_qps decrement within the error patch during QP creation failure and the normal teardown path in isert_connect_release(). Squashed: iser-target: Decrement completion context active_qps in error flow Signed-off-by:
-
Sagi Grimberg authored
commit 2371e5da upstream. There is no point in accepting a new CM request only when we are completely done with the last iscsi login. Instead we accept immediately, this will also cause the CM connection to reach connected state and the initiator is allowed to send the first login. We mark that we got the initial login and let iscsi layer pick it up when it gets there. This reduces the parallel login sequence by a factor of more then 4 (and more for multi-login) and also prevents the initiator (who does all logins in parallel) from giving up on login timeout expiration. In order to support multiple login requests sequence (CHAP) we call isert_rx_login_req from isert_rx_completion insead of letting isert_get_login_rx call it. Squashed: iser-target: Use kref_get_unless_zero in connected_handler iser-target: Acquire conn_mutex when changing connection state iser-target: Reject connect request in failure path Signed-off-by:
-
Sagi Grimberg authored
commit 128e9cc8 upstream. ISER_CONN_UP state is not sufficient to know if we should wait for completion of flush errors and disconnected_handler event. Instead, split it to 2 states: - ISER_CONN_UP: Got to CM connected phase, This state indicates that we need to wait for a CM disconnect event before going to teardown. - ISER_CONN_FULL_FEATURE: Got to full feature phase after we posted login response, This state indicates that we posted recv buffers and we need to wait for flush completions before going to teardown. Also avoid deffering disconnected handler to a work, and handle it within disconnected handler. More work here is needed to handle DEVICE_REMOVAL event correctly (cleanup all resources). Squashed: iser-target: Don't deffer disconnected handler to a work Signed-off-by:
-
Sagi Grimberg authored
commit 954f2372 upstream. Since commit 0fc4ea70 ("Target/iser: Don't put isert_conn inside disconnected handler") we put the conn kref in isert_wait_conn, so we need .wait_conn to be invoked also in the error path. Introduce call to isert_conn_terminate (called under lock) which transitions the connection state to TERMINATING and calls rdma_disconnect. If the state is already teminating, just bail out back (temination started). Also, make sure to destroy the connection when getting a connect error event if didn't get to connected (state UP). Same for the handling of REJECTED and UNREACHABLE cma events. Squashed: iscsi-target: Add call to wait_conn in establishment error flow Reported-by:
-
Nicholas Bellinger authored
commit 6bf6ca75 upstream. This patch changes iscsit_do_tx_data() to fail on short writes when kernel_sendmsg() returns a value different than requested transfer length, returning -EPIPE and thus causing a connection reset to occur. This avoids a potential bug in the original code where a short write would result in kernel_sendmsg() being called again with the original iovec base + length. In practice this has not been an issue because iscsit_do_tx_data() is only used for transferring 48 byte headers + 4 byte digests, along with seldom used control payloads from NOPIN + TEXT_RSP + REJECT with less than 32k of data. So following Al's audit of iovec consumers, go ahead and fail the connection on short writes for now, and remove the bogus logic ahead of his proper upstream fix. Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Thomas Gleixner authored
commit c291ee62 upstream. Since the rework of the sparse interrupt code to actually free the unused interrupt descriptors there exists a race between the /proc interfaces to the irq subsystem and the code which frees the interrupt descriptor. CPU0 CPU1 show_interrupts() desc = irq_to_desc(X); free_desc(desc) remove_from_radix_tree(); kfree(desc); raw_spinlock_irq(&desc->lock); /proc/interrupts is the only interface which can actively corrupt kernel memory via the lock access. /proc/stat can only read from freed memory. Extremly hard to trigger, but possible. The interfaces in /proc/irq/N/ are not affected by this because the removal of the proc file is serialized in procfs against concurrent readers/writers. The removal happens before the descriptor is freed. For architectures which have CONFIG_SPARSE_IRQ=n this is a non issue as the descriptor is never freed. It's merely cleared out with the irq descriptor lock held. So any concurrent proc access will either see the old correct value or the cleared out ones. Protect the lookup and access to the irq descriptor in show_interrupts() with the sparse_irq_lock. Provide kstat_irqs_usr() which is protecting the lookup and access with sparse_irq_lock and switch /proc/stat to use it. Document the existing kstat_irqs interfaces so it's clear that the caller needs to take care about protection. The users of these interfaces are either not affected due to SPARSE_IRQ=n or already protected against removal. Fixes: 1f5a5b87 "genirq: Implement a sane sparse_irq allocator" Signed-off-by:
-
Max Gurtovoy authored
commit 6ec9d4d2 upstream. Fix a regression was introduced in commit 6df5a128 ("IB/iser: Suppress scsi command send completions"). The sig_count was wrongly set to be static variable, thus it is possible that we won't reach to (sig_count % ISER_SIGNAL_BATCH) == 0 condition (due to races) and the send queue will be overflowed. Instead keep sig_count per connection. We don't need it to be atomic as we are safe under the iscsi session frwd_lock taken by libiscsi on the queuecommand path. Fixes: 6df5a128 ("IB/iser: Suppress scsi command send completions") Signed-off-by:
Max Gurtovoy <maxg@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Hannes Reinecke authored
commit 506787a2 upstream. tcm_loop has the I_T nexus associated with the HBA. This causes commands to become misdirected if the HBA has more than one target portal group; any command is then being sent to the first target portal group instead of the correct one. The nexus needs to be associated with the target portal group instead. Signed-off-by:
-
Kyle McMartin authored
commit 3875f152 upstream. scripts/headers_install.sh will transform __packed to __attribute__((packed)), so the #ifndef is not necessary. (and, in fact, it's problematic, because we'll end up with the header containing: #ifndef __attribute__((packed)) #define __attribu... and so forth.) Signed-off-by:
Kyle McMartin <kyle@redhat.com> Signed-off-by:
-
Thomas Gleixner authored
commit a5fd9733 upstream. commit 4dbd2771 "tick: export nohz tick idle symbols for module use" was merged via the thermal tree without an explicit ack from the relevant maintainers. The exports are abused by the intel powerclamp driver which implements a fake idle state from a sched FIFO task. This causes all kinds of wreckage in the NOHZ core code which rightfully assumes that tick_nohz_idle_enter/exit() are only called from the idle task itself. Recent changes in the NOHZ core lead to a failure of the powerclamp driver and now people try to hack completely broken and backwards workarounds into the NOHZ core code. This is completely unacceptable and just papers over the real problem. There are way more subtle issues lurking around the corner. The real solution is to fix the powerclamp driver by rewriting it with a sane concept, but that's beyond the scope of this. So the only solution for now is to remove the calls into the core NOHZ code from the powerclamp trainwreck along with the exports. Fixes: d6d71ee4 "PM: Introduce Intel PowerClamp Driver" Signed-off-by:
-
Dominique Leuenberger authored
commit 6583659e upstream. HP ZBook 15 laptop needs a non-standard mapping (x_inverted). BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329Signed-off-by:
Dominique Leuenberger <dimstar@opensuse.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Hans de Goede authored
commit 841e11cc upstream. Wifi on this laptop does not work unless asus-nb-wmi.wapf=4 is specified on the kerne commandline, add a quirk for this. BugLink: https://bugs.launchpad.net/bugs/1173681Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Larry Finger authored
commit e9538cf4 upstream. These drivers use 9100-byte receive buffers, thus allocating an skb requires an O(3) memory allocation. Under heavy memory loads and fragmentation, such a request can fail. Previous versions of the driver have dropped the packet and reused the old buffer; however, the new version introduced a bug in that it released the old buffer before trying to allocate a new one. The previous method is implemented here. The skb is unmapped before any attempt is made to allocate another. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-by:
Eric Biggers <ebiggers3@gmail.com> Cc: Eric Biggers <ebiggers3@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Larry Finger authored
commit 9a1dce3a upstream. The setting of this flag was missed in previous modifications. Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Jouni Malinen authored
commit 08f6f147 upstream. The VHT supported channel width field is a two bit integer, not a bitfield. cfg80211_chandef_usable() was interpreting it incorrectly and ended up rejecting 160 MHz channel width if the driver indicated support for both 160 and 80+80 MHz channels. Fixes: 3d9d1d66 ("nl80211/cfg80211: support VHT channel configuration") (however, no real drivers had 160 MHz support it until 3.16) Signed-off-by:
Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Arik Nemtsov authored
commit 34f05f54 upstream. In the already-set and intersect case of a driver-hint, the previous wiphy regdomain was not freed before being reset with a copy of the cfg80211 regdomain. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Acked-by:
Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 70dcec5a upstream. This can happen and there is no point in added more detection code lower in the stack. Catching these in one single point (cfg80211) is enough. Stop WARNING about this case. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=89001 Fixes: 2f1c6c57 ("cfg80211: process non country IE conflicting first") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Luciano Coelho authored
commit f89f46cf upstream. If the userspace passes a malformed sched scan request (or a net detect wowlan configuration) by adding a NL80211_ATTR_SCHED_SCAN_MATCH attribute without any nested matchsets, a NULL pointer dereference will occur. Fix this by checking that we do have matchsets in our array before trying to access it. BUG: unable to handle kernel NULL pointer dereference at 0000000000000024 IP: [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] PGD 865c067 PUD 865b067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: iwlmvm(O) iwlwifi(O) mac80211(O) cfg80211(O) compat(O) [last unloaded: compat] CPU: 2 PID: 2442 Comm: iw Tainted: G O 3.17.2 #31 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff880013800790 ti: ffff880008d80000 task.ti: ffff880008d80000 RIP: 0010:[<ffffffffa002fd69>] [<ffffffffa002fd69>] nl80211_parse_sched_scan.part.67+0x6e9/0x900 [cfg80211] RSP: 0018:ffff880008d838d0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 000000000000143c RSI: 0000000000000000 RDI: ffff880008ee8dd0 RBP: ffff880008d83948 R08: 0000000000000002 R09: 0000000000000019 R10: ffff88001d1b3c40 R11: 0000000000000002 R12: ffff880019e85e00 R13: 00000000fffffed4 R14: ffff880009757800 R15: 0000000000001388 FS: 00007fa3b6d13700(0000) GS:ffff88003e200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000024 CR3: 0000000008670000 CR4: 00000000000006e0 Stack: ffff880009757800 ffff880000000001 0000000000000000 ffff880008ee84e0 0000000000000000 ffff880009757800 00000000fffffed4 ffff880008d83948 ffffffff814689c9 ffff880009757800 ffff880008ee8000 0000000000000000 Call Trace: [<ffffffff814689c9>] ? nla_parse+0xb9/0x120 [<ffffffffa00306de>] nl80211_set_wowlan+0x75e/0x960 [cfg80211] [<ffffffff810bf3d5>] ? mark_held_locks+0x75/0xa0 [<ffffffff8161a77b>] genl_family_rcv_msg+0x18b/0x360 [<ffffffff810bf66d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8161a9d4>] genl_rcv_msg+0x84/0xc0 [<ffffffff8161a950>] ? genl_family_rcv_msg+0x360/0x360 [<ffffffff81618e79>] netlink_rcv_skb+0xa9/0xd0 [<ffffffff81619458>] genl_rcv+0x28/0x40 [<ffffffff816184a5>] netlink_unicast+0x105/0x180 [<ffffffff8161886f>] netlink_sendmsg+0x34f/0x7a0 [<ffffffff8105a097>] ? kvm_clock_read+0x27/0x40 [<ffffffff815c644d>] sock_sendmsg+0x8d/0xc0 [<ffffffff811a75c9>] ? might_fault+0xb9/0xc0 [<ffffffff811a756e>] ? might_fault+0x5e/0xc0 [<ffffffff815d5d26>] ? verify_iovec+0x56/0xe0 [<ffffffff815c73e0>] ___sys_sendmsg+0x3d0/0x3e0 [<ffffffff810a7be8>] ? sched_clock_cpu+0x98/0xd0 [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580 [<ffffffff810bb39f>] ? up_read+0x1f/0x40 [<ffffffff810611b4>] ? __do_page_fault+0x254/0x580 [<ffffffff812146ed>] ? __fget_light+0x13d/0x160 [<ffffffff815c7b02>] __sys_sendmsg+0x42/0x80 [<ffffffff815c7b52>] SyS_sendmsg+0x12/0x20 [<ffffffff81751f69>] system_call_fastpath+0x16/0x1b Fixes: ea73cbce ("nl80211: fix scheduled scan RSSI matchset attribute confusion") Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Hans de Goede authored
commit 7f5c4d63 upstream. Streams do not work reliabe on Fresco Logic FL1000G xhci controllers, trying to use them results in errors like this: 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 00000000 05000000 01078001 21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring 21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 00000000 05000000 01038001 As always I've ordered a pci-e addon card with a Fresco Logic controller for myself to see if I can come up with a better fix then the big hammer, in the mean time this will make uas devices work again (in usb-storage mode) for FL1000G users. Reported-by:
Marcin Zajączkowski <mszpak@wp.pl> Signed-off-by:
-
Mathias Nyman authored
commit f161ead7 upstream. Solves xhci error cases with debug messages: xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 xhci will give a context state error if we try to set a slot in default state to the same default state with a special address device command. Turns out this happends in several cases: - retry reading the device rescriptor in hub_port_init() - usb_reset_device() is called for a slot in default state - in resume path, usb_port_resume() calls hub_port_init() The default state is usually reached from most states with a reset device command without any context state errors, but using the address device command with BSA bit set (block set address) only works from the enabled state and will otherwise cause context error. solve this by checking if we are already in the default state before issuing a address device BSA=1 command. Fixes: 48fc7dbd ("usb: xhci: change enumeration scheme to 'new scheme'") Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Ian Munsie authored
commit b123429e upstream. If we need to force detach a context (e.g. due to EEH or simply force unbinding the driver) we should prevent the userspace contexts from being able to access the Problem State Area MMIO region further, which they may have mapped with mmap(). This patch unmaps any mapped MMIO regions when detaching a userspace context. Signed-off-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Ian Munsie authored
commit a98e6e9f upstream. In the event that something goes wrong in the hardware and it is unable to complete a process element comment we would end up polling forever, effectively making the associated process unkillable. This patch adds a timeout to the process element command code path, so that we will give up if the hardware does not respond in a reasonable time. Signed-off-by:
-
Ian Munsie authored
commit ee41d11d upstream. We had a known sleep while atomic bug if a CXL device was forcefully unbound while it was in use. This could occur as a result of EEH, or manually induced with something like this while the device was in use: echo 0000:01:00.0 > /sys/bus/pci/drivers/cxl-pci/unbind The issue was that in this code path we iterated over each context and forcefully detached it with the contexts_lock spin lock held, however the detach also needed to take the spu_mutex, and call schedule. This patch changes the contexts_lock to a mutex so that we are not in atomic context while doing the detach, thereby avoiding the sleep while atomic. Also delete the related TODO comment, which suggested an alternate solution which turned out to not be workable. Signed-off-by:
-
Vineet Gupta authored
commit e8ef060b upstream. This allows the sdplite/Zebu images to run on OSCI simulation platform Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Rob Clark authored
commit 7f907bf2 upstream. Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Cc: Anand Moon <moon.linux@yahoo.com> Signed-off-by:
-
Ville Syrjälä authored
commit 7d47559e upstream. The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That means if we first call intel_prepare_page_flip() but don't call intel_finish_page_flip(), the next stall check will erroneosly think the page flip was somehow stuck. With enough debug spew emitted from the interrupt handler my 830 hangs when this happens. My theory is that the previous vblank interrupt gets sufficiently delayed that the handler will see the pending bit set in IIR, but ISR still has the bit set as well (ie. the flip was processed by CS but didn't complete yet). In this case the handler will proceed to call intel_check_page_flip() immediately after intel_prepare_page_flip(). It then tries to print a backtrace for the stuck flip WARN, which apparetly results in way too much debug spew delaying interrupt processing further. That then seems to cause an endless loop in the interrupt handler, and the machine is dead until the watchdog kicks in and reboots. At least limiting the number of iterations of the loop in the interrupt handler also prevented the hang. So it seems better to not call intel_prepare_page_flip() without immediately calling intel_finish_page_flip(). The IIR/ISR trickery avoids races here so this is a perfectly safe thing to do. v2: Fix typo in commit message (checkpatch) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
