rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux v3.13.6

This commit is contained in:
Justin M. Forbes 2014-03-07 10:29:53 -06:00
parent 65415cde98
commit d6a3b15971
7 changed files with 10 additions and 418 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
cgroup-fixes.patch
View File

@ -120,7 +120,7 @@ Signed-off-by: Michal Hocko <mhocko@suse.cz>
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4410,14 +4410,6 @@ static long cgroup_create(struct cgroup
@@ -4410,16 +4410,6 @@ static long cgroup_create(struct cgroup
rcu_assign_pointer(cgrp->name, name);
/*
@ -128,8 +128,10 @@ Signed-off-by: Michal Hocko <mhocko@suse.cz>
- * a half-baked cgroup.
- */
- cgrp->id = idr_alloc(&root->cgroup_idr, NULL, 1, 0, GFP_KERNEL);
- if (cgrp->id < 0)
- if (cgrp->id < 0) {
- err = -ENOMEM;
- goto err_free_name;
- }
-
- /*
* Only live parents can have children. Note that the liveliness

149
cifs-ensure-that-uncached-writes-handle-unmapped-areas-correctly.patch
View File

@ -1,149 +0,0 @@
Path: news.gmane.org!not-for-mail
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Newsgroups: gmane.linux.kernel.cifs
Subject: [PATCH] cifs: ensure that uncached writes handle unmapped areas correctly
Date: Fri, 14 Feb 2014 07:20:35 -0500
Lines: 92
Approved: news@gmane.org
Message-ID: <1392380435-6903-1-git-send-email-jlayton@redhat.com>
NNTP-Posting-Host: plane.gmane.org
X-Trace: ger.gmane.org 1392380436 7379 80.91.229.3 (14 Feb 2014 12:20:36 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Fri, 14 Feb 2014 12:20:36 +0000 (UTC)
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
To: smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Original-X-From: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Fri Feb 14 13:20:44 2014
Return-path: <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Envelope-to: glkc-linux-cifs-wOFGN7rlS/M9smdsby/KFg@public.gmane.org
Original-Received: from vger.kernel.org ([209.132.180.67])
by plane.gmane.org with esmtp (Exim 4.69)
(envelope-from <linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>)
id 1WEHl6-0001gj-3d
for glkc-linux-cifs-wOFGN7rlS/M9smdsby/KFg@public.gmane.org; Fri, 14 Feb 2014 13:20:44 +0100
Original-Received: (majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org) by vger.kernel.org via listexpand
id S1752014AbaBNMUn (ORCPT <rfc822;glkc-linux-cifs@m.gmane.org>);
Fri, 14 Feb 2014 07:20:43 -0500
Original-Received: from mail-qa0-f41.google.com ([209.85.216.41]:53300 "EHLO
mail-qa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1751935AbaBNMUn (ORCPT
<rfc822;linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>); Fri, 14 Feb 2014 07:20:43 -0500
Original-Received: by mail-qa0-f41.google.com with SMTP id w8so18341449qac.0
for <linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; Fri, 14 Feb 2014 04:20:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:sender:from:to:cc:subject:date:message-id;
bh=U+Hg0/eYYIJkioXu/lkD6lkFJ0tCG+CokyC++yC+DQM=;
b=k0jKxn6Oe6WzaA8qsSjcTaszuxeetSkSa7zALlqcXb5ZMePVPSZXV4ceIYOs3RRg3T
ABfigeWTQiCwmRFobeOh77zBI4vsGXRx9UkDYTwNVzMIVGD+eFm90m4gB2DtSl0HqPFI
vUaBZDWNIduFFfuTEADF4FoguV+lX07T9lgAPXO6F05sC/dxQ5ffrTFrao0k1kzJO/tg
72LueH0aRcwWHxA9e+WW3KkvRZALlcqWIe+Bnomw51qdtpetKPmag3/BTtLwwUSbAU0e
uppFe/6fHJHN+SHYgVGrVLFH2OXbRSyv8R4wC1BWlau6khtclu/R0X22jk5Okd+zM8Jd
DvkA==
X-Gm-Message-State: ALoCoQlx+9xv55qz9RE2vMXqhqjy8E3xo9guNbdH3Gwu3BbXxDqM4CRvLyHWarIQK4MEnf47FoZK
X-Received: by 10.140.31.247 with SMTP id f110mr11536194qgf.58.1392380442431;
Fri, 14 Feb 2014 04:20:42 -0800 (PST)
Original-Received: from tlielax.poochiereds.net ([2001:470:8:d63:3a60:77ff:fe93:a95d])
by mx.google.com with ESMTPSA id r40sm7432383qga.23.2014.02.14.04.20.41
for <multiple recipients>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 14 Feb 2014 04:20:41 -0800 (PST)
X-Mailer: git-send-email 1.8.5.3
Original-Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Precedence: bulk
List-ID: <linux-cifs.vger.kernel.org>
X-Mailing-List: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Xref: news.gmane.org gmane.linux.kernel.cifs:9401
Archived-At: <http://permalink.gmane.org/gmane.linux.kernel.cifs/9401>
It's possible for userland to pass down an iovec via writev() that has a
bogus user pointer in it. If that happens and we're doing an uncached
write, then we can end up getting less bytes than we expect from the
call to iov_iter_copy_from_user.
cifs_iovec_write isn't set up to handle that situation however. It'll
blindly keep chugging through the page array and not filling those pages
with anything useful. Worse yet, we'll later end up with a negative
number in wdata->tailsz, which will confuse the sending routines and
cause an oops at the very least.
Fix this by having the copy phase of cifs_iovec_write stop copying data
in this situation and send the last write as a short one. At the same
time, we want to avoid sending a zero-length write to the server, so
break out of the loop and set rc to -EFAULT if that happens. This also
allows us to handle the case where no address in the iovec is valid.
[Note: Marking this for stable on v3.4+ kernels, but kernels as old as
v2.6.38 may have a similar problem and may need similar fix]
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4+
Reviewed-by: Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
Reported-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Signed-off-by: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
fs/cifs/file.c | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 03d1f454c713..ae1a4d58e672 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2387,7 +2387,7 @@ cifs_iovec_write(struct file *file, const struct iovec *iov,
unsigned long nr_segs, loff_t *poffset)
{
unsigned long nr_pages, i;
- size_t copied, len, cur_len;
+ size_t bytes, copied, len, cur_len;
ssize_t total_written = 0;
loff_t offset;
struct iov_iter it;
@@ -2442,14 +2442,45 @@ cifs_iovec_write(struct file *file, const struct iovec *iov,
save_len = cur_len;
for (i = 0; i < nr_pages; i++) {
- copied = min_t(const size_t, cur_len, PAGE_SIZE);
+ bytes = min_t(const size_t, cur_len, PAGE_SIZE);
copied = iov_iter_copy_from_user(wdata->pages[i], &it,
- 0, copied);
+ 0, bytes);
cur_len -= copied;
iov_iter_advance(&it, copied);
+ /*
+ * If we didn't copy as much as we expected, then that
+ * may mean we trod into an unmapped area. Stop copying
+ * at that point. On the next pass through the big
+ * loop, we'll likely end up getting a zero-length
+ * write and bailing out of it.
+ */
+ if (copied < bytes)
+ break;
}
cur_len = save_len - cur_len;
+ /*
+ * If we have no data to send, then that probably means that
+ * the copy above failed altogether. That's most likely because
+ * the address in the iovec was bogus. Set the rc to -EFAULT,
+ * free anything we allocated and bail out.
+ */
+ if (!cur_len) {
+ for (i = 0; i < nr_pages; i++)
+ put_page(wdata->pages[i]);
+ kfree(wdata);
+ rc = -EFAULT;
+ break;
+ }
+
+ /*
+ * i + 1 now represents the number of pages we actually used in
+ * the copy phase above. Bring nr_pages down to that, and free
+ * any pages that we didn't use.
+ */
+ for ( ; nr_pages > i + 1; nr_pages--)
+ put_page(wdata->pages[nr_pages - 1]);
+
wdata->sync_mode = WB_SYNC_ALL;
wdata->nr_pages = nr_pages;
wdata->offset = (__u64)offset;
--
1.8.5.3

138
cpufreq-powernow-k8-Initialize-per-cpu-data-structures-properly.patch
View File

@ -1,138 +0,0 @@
Bugzilla: 1054408
Upstream-status: Queued for 3.14 and CC'd to stable
Delivered-To: jwboyer@gmail.com
Received: by 10.76.82.162 with SMTP id j2csp112184oay;
Mon, 17 Feb 2014 03:01:52 -0800 (PST)
X-Received: by 10.68.164.4 with SMTP id ym4mr26078759pbb.53.1392634911720;
Mon, 17 Feb 2014 03:01:51 -0800 (PST)
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
by mx.google.com with ESMTP id xf4si14383267pab.191.2014.02.17.03.01.15
for <multiple recipients>;
Mon, 17 Feb 2014 03:01:51 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mail=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1752151AbaBQKyA (ORCPT <rfc822;gardner.ben.linux@gmail.com>
+ 99 others); Mon, 17 Feb 2014 05:54:00 -0500
Received: from e28smtp06.in.ibm.com ([122.248.162.6]:51044 "EHLO
e28smtp06.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1752134AbaBQKx6 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Mon, 17 Feb 2014 05:53:58 -0500
Received: from /spool/local
by e28smtp06.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted
for <linux-kernel@vger.kernel.org> from <srivatsa.bhat@linux.vnet.ibm.com>;
Mon, 17 Feb 2014 16:23:53 +0530
Received: from d28dlp03.in.ibm.com (9.184.220.128)
by e28smtp06.in.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;
Mon, 17 Feb 2014 16:23:50 +0530
Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58])
by d28dlp03.in.ibm.com (Postfix) with ESMTP id 80C82125805C;
Mon, 17 Feb 2014 16:25:47 +0530 (IST)
Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65])
by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s1HArhEA64749632;
Mon, 17 Feb 2014 16:23:44 +0530
Received: from d28av03.in.ibm.com (localhost [127.0.0.1])
by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s1HArkHs009945;
Mon, 17 Feb 2014 16:23:47 +0530
Received: from srivatsabhat.in.ibm.com ([9.79.254.57])
by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s1HAriQk009844;
Mon, 17 Feb 2014 16:23:45 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Subject: [PATCH] cpufreq,
powernow-k8: Initialize per-cpu data-structures properly
To: pierre-list@ossman.eu, rjw@rjwysocki.net
Cc: viresh.kumar@linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Date: Mon, 17 Feb 2014 16:18:21 +0530
Message-ID: <20140217104821.21147.71463.stgit@srivatsabhat.in.ibm.com>
User-Agent: StGIT/0.14.3
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 14021710-9574-0000-0000-00000BFDA307
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
The powernow-k8 driver maintains a per-cpu data-structure called powernow_data
that is used to perform the frequency transitions. It initializes this data-
structure only for the policy->cpu. So, accesses to this data-structure by
other CPUs results in various problems because they would have been
uninitialized.
Specifically, if a cpu (!= policy->cpu) invokes the drivers' ->get() function,
it returns 0 as the KHz value, since its per-cpu memory doesn't point to
anything valid. This causes problems during suspend/resume since
cpufreq_update_policy() tries to enforce this (0 KHz) as the current frequency
of the CPU, and this madness gets propagated to adjust_jiffies() as well.
Eventually, lots of things start breaking down, including the r8169 ethernet
card, in one particularly interesting case reported by Pierre Ossman.
https://bugzilla.kernel.org/show_bug.cgi?id=70311
Fix this by initializing the per-cpu data-structures of _all_ the CPUs
in the policy appropriately.
Cc: stable@vger.kernel.org
Reported-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
drivers/cpufreq/powernow-k8.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index e10b646..6684e03 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -1076,7 +1076,7 @@ static int powernowk8_cpu_init(struct cpufreq_policy *pol)
{
struct powernow_k8_data *data;
struct init_on_cpu init_on_cpu;
- int rc;
+ int rc, cpu;
smp_call_function_single(pol->cpu, check_supported_cpu, &rc, 1);
if (rc)
@@ -1140,7 +1140,9 @@ static int powernowk8_cpu_init(struct cpufreq_policy *pol)
pr_debug("cpu_init done, current fid 0x%x, vid 0x%x\n",
data->currfid, data->currvid);
- per_cpu(powernow_data, pol->cpu) = data;
+ /* Point all the CPUs in this policy to the same data */
+ for_each_cpu(cpu, pol->cpus)
+ per_cpu(powernow_data, cpu) = data;
return 0;
@@ -1155,6 +1157,7 @@ err_out:
static int powernowk8_cpu_exit(struct cpufreq_policy *pol)
{
struct powernow_k8_data *data = per_cpu(powernow_data, pol->cpu);
+ int cpu;
if (!data)
return -EINVAL;
@@ -1165,7 +1168,8 @@ static int powernowk8_cpu_exit(struct cpufreq_policy *pol)
kfree(data->powernow_table);
kfree(data);
- per_cpu(powernow_data, pol->cpu) = NULL;
+ for_each_cpu(cpu, pol->cpus)
+ per_cpu(powernow_data, cpu) = NULL;
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

27
kernel.spec
View File

@ -62,7 +62,7 @@ Summary: The Linux kernel
# For non-released -rc kernels, this will be appended after the rcX and
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
#
%global baserelease 202
%global baserelease 200
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@ -74,7 +74,7 @@ Summary: The Linux kernel
%if 0%{?released_kernel}
# Do we have a -stable update to apply?
%define stable_update 5
%define stable_update 6
# Is it a -stable RC?
%define stable_rc 0
# Set rpm version accordingly
@ -749,27 +749,17 @@ Patch25196: ipv6-introduce-IFA_F_NOPREFIXROUTE-and-IFA_F_MANAGETEMPADDR-flags.pa
Patch25197: ipv6-addrconf-revert-if_inet6ifa_flag-format.patch
#CVE-2014-0069 rhbz 1064253 1062584
Patch25200: cifs-ensure-that-uncached-writes-handle-unmapped-areas-correctly.patch
Patch25201: cifs-sanity-check-length-of-data-to-send-before-sending.patch
#rhbz 1068862
Patch25002: cifs-mask-off-top-byte-in-get_rfc1002_length.patch
#rhbz 1054408
Patch25203: cpufreq-powernow-k8-Initialize-per-cpu-data-structures-properly.patch
#rhbz 994438
Patch25024: e100-Fix-disabling-already-disabled-device-warning.patch
#rhbz 1056170
Patch25025: usb-ehci-fix-deadlock-when-threadirqs-option-is-used.patch
#CVE-2014-0102 rhbz 1071396
Patch25026: keyring-fix.patch
#CVE-2014-0049 rhbz 1062368 1071837
Patch25027: kvm-x86-fix-emulator-buffer-overflow.patch
#rhbz 1065087
Patch25028: tty-Fix-low_latency-BUG.patch
@ -1509,27 +1499,17 @@ ApplyPatch ipv6-introduce-IFA_F_NOPREFIXROUTE-and-IFA_F_MANAGETEMPADDR-flags.pat
ApplyPatch ipv6-addrconf-revert-if_inet6ifa_flag-format.patch
#CVE-2014-0069 rhbz 1064253 1062584
ApplyPatch cifs-ensure-that-uncached-writes-handle-unmapped-areas-correctly.patch
ApplyPatch cifs-sanity-check-length-of-data-to-send-before-sending.patch
#rhbz 1068862
ApplyPatch cifs-mask-off-top-byte-in-get_rfc1002_length.patch
#rhbz 1054408
ApplyPatch cpufreq-powernow-k8-Initialize-per-cpu-data-structures-properly.patch
#rhbz 994438
ApplyPatch e100-Fix-disabling-already-disabled-device-warning.patch
#rhbz 1056170
ApplyPatch usb-ehci-fix-deadlock-when-threadirqs-option-is-used.patch
#CVE-2014-0102 rhbz 1071396
ApplyPatch keyring-fix.patch
#CVE-2014-0049 rhbz 1062368 1071837
ApplyPatch kvm-x86-fix-emulator-buffer-overflow.patch
#rhbz 1065087
ApplyPatch tty-Fix-low_latency-BUG.patch
@ -2375,6 +2355,9 @@ fi
# ||----w |
# || ||
%changelog
* Fri Mar 07 2014 Justin M. Forbes <jforbes@fedoraproject.org>
- Linux v3.13.6
* Fri Mar 07 2014 Josh Boyer <jwboyer@fedoraproject.org>
- Add patch to fix iwldvm WARN (rhbz 1065663)
- Revert two xhci fixes that break USB mass storage (rhbz 1073180)

49
kvm-x86-fix-emulator-buffer-overflow.patch
View File

@ -1,49 +0,0 @@
Bugzilla: 1071837
Upstream-status: 3.14
From a08d3b3b99efd509133946056531cdf8f3a0c09b Mon Sep 17 00:00:00 2001
From: Andrew Honig <ahonig@google.com>
Date: Thu, 27 Feb 2014 18:35:14 +0000
Subject: kvm: x86: fix emulator buffer overflow (CVE-2014-0049)
The problem occurs when the guest performs a pusha with the stack
address pointing to an mmio address (or an invalid guest physical
address) to start with, but then extending into an ordinary guest
physical address. When doing repeated emulated pushes
emulator_read_write sets mmio_needed to 1 on the first one. On a
later push when the stack points to regular memory,
mmio_nr_fragments is set to 0, but mmio_is_needed is not set to 0.
As a result, KVM exits to userspace, and then returns to
complete_emulated_mmio. In complete_emulated_mmio
vcpu->mmio_cur_fragment is incremented. The termination condition of
vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments is never achieved.
The code bounces back and fourth to userspace incrementing
mmio_cur_fragment past it's buffer. If the guest does nothing else it
eventually leads to a a crash on a memcpy from invalid memory address.
However if a guest code can cause the vm to be destroyed in another
vcpu with excellent timing, then kvm_clear_async_pf_completion_queue
can be used by the guest to control the data that's pointed to by the
call to cancel_work_item, which can be used to gain execution.
Fixes: f78146b0f9230765c6315b2e14f56112513389ad
Signed-off-by: Andrew Honig <ahonig@google.com>
Cc: stable@vger.kernel.org (3.5+)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 39c28f09..2b85784 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6186,7 +6186,7 @@ static int complete_emulated_mmio(struct kvm_vcpu *vcpu)
frag->len -= len;
}
- if (vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments) {
+ if (vcpu->mmio_cur_fragment >= vcpu->mmio_nr_fragments) {
vcpu->mmio_needed = 0;
/* FIXME: return into emulator if single-stepping. */
--
cgit v0.9.2

2
sources
View File

@ -1,2 +1,2 @@
0ecbaf65c00374eb4a826c2f9f37606f linux-3.13.tar.xz
114c391a592131f1c12544e063173a45 patch-3.13.5.xz
a9b131a589a176b4c437b8ca4557b85e patch-3.13.6.xz

57
usb-ehci-fix-deadlock-when-threadirqs-option-is-used.patch
View File

@ -1,57 +0,0 @@
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().
This change can be reverted when hrtimer callbacks become threaded.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/usb/host/ehci-hcd.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 4711427..0bc6410 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -685,8 +685,15 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 status, masked_status, pcd_status = 0, cmd;
int bh;
+ unsigned long flags;
- spin_lock (&ehci->lock);
+ /*
+ * For threadirqs option we use spin_lock_irqsave() variant to prevent
+ * deadlock with ehci hrtimer callback, because hrtimer callbacks run
+ * in interrupt context even when threadirqs is specified. We can go
+ * back to spin_lock() variant when hrtimer callbacks become threaded.
+ */
+ spin_lock_irqsave(&ehci->lock, flags);
status = ehci_readl(ehci, &ehci->regs->status);
@@ -704,7 +711,7 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd)
/* Shared IRQ? */
if (!masked_status || unlikely(ehci->rh_state == EHCI_RH_HALTED)) {
- spin_unlock(&ehci->lock);
+ spin_unlock_irqrestore(&ehci->lock, flags);
return IRQ_NONE;
}
@@ -815,7 +822,7 @@ dead:
if (bh)
ehci_work (ehci);
- spin_unlock (&ehci->lock);
+ spin_unlock_irqrestore(&ehci->lock, flags);
if (pcd_status)
usb_hcd_poll_rh_status(hcd);
return IRQ_HANDLED;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html