This is a note to let you know that I've just added the patch titled
netfilter: restart search if moved to other chain
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-restart-search-if-moved-to-other-chain.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 95a8d19f28e6b29377a880c6264391a62e07fccc Mon Sep 17 00:00:00 2001
From: Florian Westphal <fw(a)strlen.de>
Date: Thu, 25 Aug 2016 15:33:29 +0200
Subject: netfilter: restart search if moved to other chain
From: Florian Westphal <fw(a)strlen.de>
commit 95a8d19f28e6b29377a880c6264391a62e07fccc upstream.
In case nf_conntrack_tuple_taken did not find a conflicting entry
check that all entries in this hash slot were tested and restart
in case an entry was moved to another chain.
Reported-by: Eric Dumazet <edumazet(a)google.com>
Fixes: ea781f197d6a ("netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu()")
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Acked-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Acked-by: Michal Kubecek <mkubecek(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_conntrack_core.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -695,6 +695,7 @@ nf_conntrack_tuple_taken(const struct nf
* least once for the stats anyway.
*/
rcu_read_lock_bh();
+ begin:
hlist_nulls_for_each_entry_rcu(h, n, &net->ct.hash[hash], hnnode) {
ct = nf_ct_tuplehash_to_ctrack(h);
if (ct != ignored_conntrack &&
@@ -706,6 +707,12 @@ nf_conntrack_tuple_taken(const struct nf
}
NF_CT_STAT_INC(net, searched);
}
+
+ if (get_nulls_value(n) != hash) {
+ NF_CT_STAT_INC(net, search_restart);
+ goto begin;
+ }
+
rcu_read_unlock_bh();
return 0;
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-3.18/netfilter-restart-search-if-moved-to-other-chain.patch
This is a note to let you know that I've just added the patch titled
netfilter: use fwmark_reflect in nf_send_reset
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-use-fwmark_reflect-in-nf_send_reset.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cc31d43b4154ad5a7d8aa5543255a93b7e89edc2 Mon Sep 17 00:00:00 2001
From: Pau Espin Pedrol <pau.espin(a)tessares.net>
Date: Fri, 6 Jan 2017 20:33:27 +0100
Subject: netfilter: use fwmark_reflect in nf_send_reset
From: Pau Espin Pedrol <pau.espin(a)tessares.net>
commit cc31d43b4154ad5a7d8aa5543255a93b7e89edc2 upstream.
Otherwise, RST packets generated by ipt_REJECT always have mark 0 when
the routing is checked later in the same code path.
Fixes: e110861f8609 ("net: add a sysctl to reflect the fwmark on replies")
Cc: Lorenzo Colitti <lorenzo(a)google.com>
Signed-off-by: Pau Espin Pedrol <pau.espin(a)tessares.net>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Acked-by: Michal Kubecek <mkubecek(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/netfilter/nf_reject_ipv4.c | 2 ++
net/ipv6/netfilter/nf_reject_ipv6.c | 3 +++
2 files changed, 5 insertions(+)
--- a/net/ipv4/netfilter/nf_reject_ipv4.c
+++ b/net/ipv4/netfilter/nf_reject_ipv4.c
@@ -122,6 +122,8 @@ void nf_send_reset(struct sk_buff *oldsk
/* ip_route_me_harder expects skb->dst to be set */
skb_dst_set_noref(nskb, skb_dst(oldskb));
+ nskb->mark = IP4_REPLY_MARK(net, oldskb->mark);
+
skb_reserve(nskb, LL_MAX_HEADER);
niph = nf_reject_iphdr_put(nskb, oldskb, IPPROTO_TCP,
ip4_dst_hoplimit(skb_dst(nskb)));
--- a/net/ipv6/netfilter/nf_reject_ipv6.c
+++ b/net/ipv6/netfilter/nf_reject_ipv6.c
@@ -155,6 +155,7 @@ void nf_send_reset6(struct net *net, str
fl6.daddr = oip6h->saddr;
fl6.fl6_sport = otcph->dest;
fl6.fl6_dport = otcph->source;
+ fl6.flowi6_mark = IP6_REPLY_MARK(net, oldskb->mark);
security_skb_classify_flow(oldskb, flowi6_to_flowi(&fl6));
dst = ip6_route_output(net, NULL, &fl6);
if (dst == NULL || dst->error) {
@@ -178,6 +179,8 @@ void nf_send_reset6(struct net *net, str
skb_dst_set(nskb, dst);
+ nskb->mark = fl6.flowi6_mark;
+
skb_reserve(nskb, hh_len + dst->header_len);
ip6h = nf_reject_ip6hdr_put(nskb, oldskb, IPPROTO_TCP,
ip6_dst_hoplimit(dst));
Patches currently in stable-queue which might be from pau.espin(a)tessares.net are
queue-3.18/netfilter-use-fwmark_reflect-in-nf_send_reset.patch
This is a note to let you know that I've just added the patch titled
netfilter: nfnetlink_cthelper: Add missing permission checks
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-nfnetlink_cthelper-add-missing-permission-checks.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 4b380c42f7d00a395feede754f0bc2292eebe6e5 Mon Sep 17 00:00:00 2001
From: Kevin Cernekee <cernekee(a)chromium.org>
Date: Sun, 3 Dec 2017 12:12:45 -0800
Subject: netfilter: nfnetlink_cthelper: Add missing permission checks
From: Kevin Cernekee <cernekee(a)chromium.org>
commit 4b380c42f7d00a395feede754f0bc2292eebe6e5 upstream.
The capability check in nfnetlink_rcv() verifies that the caller
has CAP_NET_ADMIN in the namespace that "owns" the netlink socket.
However, nfnl_cthelper_list is shared by all net namespaces on the
system. An unprivileged user can create user and net namespaces
in which he holds CAP_NET_ADMIN to bypass the netlink_net_capable()
check:
$ nfct helper list
nfct v1.4.4: netlink error: Operation not permitted
$ vpnns -- nfct helper list
{
.name = ftp,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 6,
.priv_data_len = 24,
.status = enabled,
};
Add capable() checks in nfnetlink_cthelper, as this is cleaner than
trying to generalize the solution.
Signed-off-by: Kevin Cernekee <cernekee(a)chromium.org>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Acked-by: Michal Kubecek <mkubecek(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nfnetlink_cthelper.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -17,6 +17,7 @@
#include <linux/types.h>
#include <linux/list.h>
#include <linux/errno.h>
+#include <linux/capability.h>
#include <net/netlink.h>
#include <net/sock.h>
@@ -392,6 +393,9 @@ nfnl_cthelper_new(struct sock *nfnl, str
struct nfnl_cthelper *nlcth;
int ret = 0;
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
if (!tb[NFCTH_NAME] || !tb[NFCTH_TUPLE])
return -EINVAL;
@@ -595,6 +599,9 @@ nfnl_cthelper_get(struct sock *nfnl, str
struct nfnl_cthelper *nlcth;
bool tuple_set = false;
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_flags & NLM_F_DUMP) {
struct netlink_dump_control c = {
.dump = nfnl_cthelper_dump_table,
@@ -661,6 +668,9 @@ nfnl_cthelper_del(struct sock *nfnl, str
struct nfnl_cthelper *nlcth, *n;
int j = 0, ret;
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+
if (tb[NFCTH_NAME])
helper_name = nla_data(tb[NFCTH_NAME]);
Patches currently in stable-queue which might be from cernekee(a)chromium.org are
queue-3.18/netfilter-xt_osf-add-missing-permission-checks.patch
queue-3.18/netfilter-nfnetlink_cthelper-add-missing-permission-checks.patch
This is a note to let you know that I've just added the patch titled
netfilter: nf_ct_expect: remove the redundant slash when policy name is empty
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-nf_ct_expect-remove-the-redundant-slash-when-policy-name-is-empty.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b173a28f62cf929324a8a6adcc45adadce311d16 Mon Sep 17 00:00:00 2001
From: Liping Zhang <liping.zhang(a)spreadtrum.com>
Date: Mon, 8 Aug 2016 21:57:58 +0800
Subject: netfilter: nf_ct_expect: remove the redundant slash when policy name is empty
From: Liping Zhang <liping.zhang(a)spreadtrum.com>
commit b173a28f62cf929324a8a6adcc45adadce311d16 upstream.
The 'name' filed in struct nf_conntrack_expect_policy{} is not a
pointer, so check it is NULL or not will always return true. Even if the
name is empty, slash will always be displayed like follows:
# cat /proc/net/nf_conntrack_expect
297 l3proto = 2 proto=6 src=1.1.1.1 dst=2.2.2.2 sport=1 dport=1025 ftp/
^
Fixes: 3a8fc53a45c4 ("netfilter: nf_ct_helper: allocate 16 bytes for the helper and policy names")
Signed-off-by: Liping Zhang <liping.zhang(a)spreadtrum.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Acked-by: Michal Kubecek <mkubecek(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_conntrack_expect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netfilter/nf_conntrack_expect.c
+++ b/net/netfilter/nf_conntrack_expect.c
@@ -557,7 +557,7 @@ static int exp_seq_show(struct seq_file
helper = rcu_dereference(nfct_help(expect->master)->helper);
if (helper) {
seq_printf(s, "%s%s", expect->flags ? " " : "", helper->name);
- if (helper->expect_policy[expect->class].name)
+ if (helper->expect_policy[expect->class].name[0])
seq_printf(s, "/%s",
helper->expect_policy[expect->class].name);
}
Patches currently in stable-queue which might be from liping.zhang(a)spreadtrum.com are
queue-3.18/netfilter-nf_ct_expect-remove-the-redundant-slash-when-policy-name-is-empty.patch
This is a note to let you know that I've just added the patch titled
netfilter: nf_conntrack_sip: extend request line validation
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
netfilter-nf_conntrack_sip-extend-request-line-validation.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 444f901742d054a4cd5ff045871eac5131646cfb Mon Sep 17 00:00:00 2001
From: Ulrich Weber <ulrich.weber(a)riverbed.com>
Date: Mon, 24 Oct 2016 18:07:23 +0200
Subject: netfilter: nf_conntrack_sip: extend request line validation
From: Ulrich Weber <ulrich.weber(a)riverbed.com>
commit 444f901742d054a4cd5ff045871eac5131646cfb upstream.
on SIP requests, so a fragmented TCP SIP packet from an allow header starting with
INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE
Content-Length: 0
will not bet interpreted as an INVITE request. Also Request-URI must start with an alphabetic character.
Confirm with RFC 3261
Request-Line = Method SP Request-URI SP SIP-Version CRLF
Fixes: 30f33e6dee80 ("[NETFILTER]: nf_conntrack_sip: support method specific request/response handling")
Signed-off-by: Ulrich Weber <ulrich.weber(a)riverbed.com>
Acked-by: Marco Angaroni <marcoangaroni(a)gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Acked-by: Michal Kubecek <mkubecek(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_conntrack_sip.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -1434,9 +1434,12 @@ static int process_sip_request(struct sk
handler = &sip_handlers[i];
if (handler->request == NULL)
continue;
- if (*datalen < handler->len ||
+ if (*datalen < handler->len + 2 ||
strncasecmp(*dptr, handler->method, handler->len))
continue;
+ if ((*dptr)[handler->len] != ' ' ||
+ !isalpha((*dptr)[handler->len+1]))
+ continue;
if (ct_sip_get_header(ct, *dptr, 0, *datalen, SIP_HDR_CSEQ,
&matchoff, &matchlen) <= 0) {
Patches currently in stable-queue which might be from ulrich.weber(a)riverbed.com are
queue-3.18/netfilter-nf_conntrack_sip-extend-request-line-validation.patch
This is a note to let you know that I've just added the patch titled
mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mm-mmap.c-do-not-blow-on-prot_none-map_fixed-holes-in-the-stack.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 561b5e0709e4a248c67d024d4d94b6e31e3edf2f Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)suse.com>
Date: Mon, 10 Jul 2017 15:49:51 -0700
Subject: mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
From: Michal Hocko <mhocko(a)suse.com>
commit 561b5e0709e4a248c67d024d4d94b6e31e3edf2f upstream.
Commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas") has
introduced a regression in some rust and Java environments which are
trying to implement their own stack guard page. They are punching a new
MAP_FIXED mapping inside the existing stack Vma.
This will confuse expand_{downwards,upwards} into thinking that the
stack expansion would in fact get us too close to an existing non-stack
vma which is a correct behavior wrt safety. It is a real regression on
the other hand.
Let's work around the problem by considering PROT_NONE mapping as a part
of the stack. This is a gros hack but overflowing to such a mapping
would trap anyway an we only can hope that usespace knows what it is
doing and handle it propely.
Fixes: 1be7107fbe18 ("mm: larger stack guard gap, between vmas")
Link: http://lkml.kernel.org/r/20170705182849.GA18027@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Debugged-by: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Ben Hutchings <ben(a)decadent.org.uk>
Cc: Willy Tarreau <w(a)1wt.eu>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Hugh Dickins <hughd(a)google.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/mmap.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2191,7 +2191,8 @@ int expand_upwards(struct vm_area_struct
gap_addr = TASK_SIZE;
next = vma->vm_next;
- if (next && next->vm_start < gap_addr) {
+ if (next && next->vm_start < gap_addr &&
+ (next->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
if (!(next->vm_flags & VM_GROWSUP))
return -ENOMEM;
/* Check that both stack segments have the same anon_vma? */
@@ -2271,7 +2272,8 @@ int expand_downwards(struct vm_area_stru
if (gap_addr > address)
return -ENOMEM;
prev = vma->vm_prev;
- if (prev && prev->vm_end > gap_addr) {
+ if (prev && prev->vm_end > gap_addr &&
+ (prev->vm_flags & (VM_WRITE|VM_READ|VM_EXEC))) {
if (!(prev->vm_flags & VM_GROWSDOWN))
return -ENOMEM;
/* Check that both stack segments have the same anon_vma? */
Patches currently in stable-queue which might be from mhocko(a)suse.com are
queue-3.18/hwpoison-memcg-forcibly-uncharge-lru-pages.patch
queue-3.18/mm-mmap.c-do-not-blow-on-prot_none-map_fixed-holes-in-the-stack.patch
This is a note to let you know that I've just added the patch titled
ipc: msg, make msgrcv work with LONG_MIN
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipc-msg-make-msgrcv-work-with-long_min.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 999898355e08ae3b92dfd0a08db706e0c6703d30 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby(a)suse.cz>
Date: Wed, 14 Dec 2016 15:06:07 -0800
Subject: ipc: msg, make msgrcv work with LONG_MIN
From: Jiri Slaby <jslaby(a)suse.cz>
commit 999898355e08ae3b92dfd0a08db706e0c6703d30 upstream.
When LONG_MIN is passed to msgrcv, one would expect to recieve any
message. But convert_mode does *msgtyp = -*msgtyp and -LONG_MIN is
undefined. In particular, with my gcc -LONG_MIN produces -LONG_MIN
again.
So handle this case properly by assigning LONG_MAX to *msgtyp if
LONG_MIN was specified as msgtyp to msgrcv.
This code:
long msg[] = { 100, 200 };
int m = msgget(IPC_PRIVATE, IPC_CREAT | 0644);
msgsnd(m, &msg, sizeof(msg), 0);
msgrcv(m, &msg, sizeof(msg), LONG_MIN, 0);
produces currently nothing:
msgget(IPC_PRIVATE, IPC_CREAT|0644) = 65538
msgsnd(65538, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0
msgrcv(65538, ...
Except a UBSAN warning:
UBSAN: Undefined behaviour in ipc/msg.c:745:13
negation of -9223372036854775808 cannot be represented in type 'long int':
With the patch, I see what I expect:
msgget(IPC_PRIVATE, IPC_CREAT|0644) = 0
msgsnd(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, 0) = 0
msgrcv(0, {100, "\310\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16, -9223372036854775808, 0) = 16
Link: http://lkml.kernel.org/r/20161024082633.10148-1-jslaby@suse.cz
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Cc: Davidlohr Bueso <dave(a)stgolabs.net>
Cc: Manfred Spraul <manfred(a)colorfullife.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
ipc/msg.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -740,7 +740,10 @@ static inline int convert_mode(long *msg
if (*msgtyp == 0)
return SEARCH_ANY;
if (*msgtyp < 0) {
- *msgtyp = -*msgtyp;
+ if (*msgtyp == LONG_MIN) /* -LONG_MIN is undefined */
+ *msgtyp = LONG_MAX;
+ else
+ *msgtyp = -*msgtyp;
return SEARCH_LESSEQUAL;
}
if (msgflg & MSG_EXCEPT)
Patches currently in stable-queue which might be from jslaby(a)suse.cz are
queue-3.18/ipc-msg-make-msgrcv-work-with-long_min.patch
This is a note to let you know that I've just added the patch titled
hwpoison, memcg: forcibly uncharge LRU pages
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hwpoison-memcg-forcibly-uncharge-lru-pages.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 18365225f0440d09708ad9daade2ec11275c3df9 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko(a)suse.com>
Date: Fri, 12 May 2017 15:46:26 -0700
Subject: hwpoison, memcg: forcibly uncharge LRU pages
From: Michal Hocko <mhocko(a)suse.com>
commit 18365225f0440d09708ad9daade2ec11275c3df9 upstream.
Laurent Dufour has noticed that hwpoinsoned pages are kept charged. In
his particular case he has hit a bad_page("page still charged to
cgroup") when onlining a hwpoison page. While this looks like something
that shouldn't happen in the first place because onlining hwpages and
returning them to the page allocator makes only little sense it shows a
real problem.
hwpoison pages do not get freed usually so we do not uncharge them (at
least not since commit 0a31bc97c80c ("mm: memcontrol: rewrite uncharge
API")). Each charge pins memcg (since e8ea14cc6ead ("mm: memcontrol:
take a css reference for each charged page")) as well and so the
mem_cgroup and the associated state will never go away. Fix this leak
by forcibly uncharging a LRU hwpoisoned page in delete_from_lru_cache().
We also have to tweak uncharge_list because it cannot rely on zero ref
count for these pages.
[akpm(a)linux-foundation.org: coding-style fixes]
Fixes: 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API")
Link: http://lkml.kernel.org/r/20170502185507.GB19165@dhcp22.suse.cz
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com>
Reviewed-by: Balbir Singh <bsingharora(a)gmail.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
mm/memcontrol.c | 2 +-
mm/memory-failure.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6500,7 +6500,7 @@ static void uncharge_list(struct list_he
next = page->lru.next;
VM_BUG_ON_PAGE(PageLRU(page), page);
- VM_BUG_ON_PAGE(page_count(page), page);
+ VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(page), page);
pc = lookup_page_cgroup(page);
if (!PageCgroupUsed(pc))
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -548,6 +548,13 @@ static int delete_from_lru_cache(struct
*/
ClearPageActive(p);
ClearPageUnevictable(p);
+
+ /*
+ * Poisoned page might never drop its ref count to 0 so we have
+ * to uncharge it manually from its memcg.
+ */
+ mem_cgroup_uncharge(p);
+
/*
* drop the page count elevated by isolate_lru_page()
*/
Patches currently in stable-queue which might be from mhocko(a)suse.com are
queue-3.18/hwpoison-memcg-forcibly-uncharge-lru-pages.patch
queue-3.18/mm-mmap.c-do-not-blow-on-prot_none-map_fixed-holes-in-the-stack.patch
From: Dmitry Eremin <Dmitry.Eremin(a)intel.com>
The logic of the original commit 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")
was assumed conditional free of struct kib_conn if the second argument free_conn
in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true.
But this hunk of code was dropped from original commit. As result the logic
works wrong and current code use struct kib_conn after free.
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
> 3317 kiblnd_destroy_conn(conn, !peer);
> ^^^^ Freed always (but should be conditionally)
> 3318
> 3319 spin_lock_irqsave(lock, flags);
> 3320 if (!peer)
> 3321 continue;
> 3322
> 3323 conn->ibc_peer = peer;
> ^^^^^^^^^^^^^^ Use after free
> 3324 if (peer->ibp_reconnected < KIB_RECONN_HIGH_RACE)
> 3325 list_add_tail(&conn->ibc_list,
> ^^^^^^^^^^^^^^ Use after free
> 3326 &kiblnd_data.kib_reconn_list);
> 3327 else
> 3328 list_add_tail(&conn->ibc_list,
> ^^^^^^^^^^^^^^ Use after free
> 3329 &kiblnd_data.kib_reconn_wait);
After attached patch this code will use struct kib_conn only when it was not freed.
Cc: <stable(a)vger.kernel.org> # v4.6
Fixes: 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd")
Signed-off-by: Dmitry Eremin <Dmitry.Eremin(a)intel.com>
Signed-off-by: Dmitry Eremin <dmitry.eremin(a)intel.com>
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 2ebc484385b3..a15a625ee9b6 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -890,7 +890,8 @@ void kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn)
atomic_dec(&net->ibn_nconns);
}
- kfree(conn);
+ if (free_conn)
+ kfree(conn);
}
int kiblnd_close_peer_conns_locked(struct kib_peer *peer, int why)
--
1.8.3.1
--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
This is a note to let you know that I've just added the patch titled
timers: Plug locking race vs. timer migration
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
timers-plug-locking-race-vs.-timer-migration.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b831275a3553c32091222ac619cfddd73a5553fb Mon Sep 17 00:00:00 2001
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Mon, 24 Oct 2016 11:41:56 +0200
Subject: timers: Plug locking race vs. timer migration
From: Thomas Gleixner <tglx(a)linutronix.de>
commit b831275a3553c32091222ac619cfddd73a5553fb upstream.
Linus noticed that lock_timer_base() lacks a READ_ONCE() for accessing the
timer flags. As a consequence the compiler is allowed to reload the flags
between the initial check for TIMER_MIGRATION and the following timer base
computation and the spin lock of the base.
While this has not been observed (yet), we need to make sure that it never
happens.
Fixes: 0eeda71bc30d ("timer: Replace timer base by a cpu index")
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Signed-off-by: Mike Galbraith <mgalbraith(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/timer.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -764,8 +764,15 @@ static struct tvec_base *lock_timer_base
__acquires(timer->base->lock)
{
for (;;) {
- u32 tf = timer->flags;
struct tvec_base *base;
+ u32 tf;
+
+ /*
+ * We need to use READ_ONCE() here, otherwise the compiler
+ * might re-read @tf between the check for TIMER_MIGRATING
+ * and spin_lock().
+ */
+ tf = READ_ONCE(timer->flags);
if (!(tf & TIMER_MIGRATING)) {
base = per_cpu_ptr(&tvec_bases, tf & TIMER_CPUMASK);
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.4/prevent-timer-value-0-for-mwaitx.patch
queue-4.4/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
queue-4.4/timers-plug-locking-race-vs.-timer-migration.patch
queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch
queue-4.4/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch
queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch
queue-4.4/sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch
This is a note to let you know that I've just added the patch titled
time: Avoid undefined behaviour in ktime_add_safe()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
time-avoid-undefined-behaviour-in-ktime_add_safe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 979515c5645830465739254abc1b1648ada41518 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum(a)oracle.com>
Date: Sat, 13 Aug 2016 01:37:04 +0200
Subject: time: Avoid undefined behaviour in ktime_add_safe()
From: Vegard Nossum <vegard.nossum(a)oracle.com>
commit 979515c5645830465739254abc1b1648ada41518 upstream.
I ran into this:
================================================================================
UBSAN: Undefined behaviour in kernel/time/hrtimer.c:310:16
signed integer overflow:
9223372036854775807 + 50000 cannot be represented in type 'long long int'
CPU: 2 PID: 4798 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #91
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
0000000000000000 ffff88010ce6fb88 ffffffff82344740 0000000041b58ab3
ffffffff84f97a20 ffffffff82344694 ffff88010ce6fbb0 ffff88010ce6fb60
000000000000c350 ffff88010ce6f968 dffffc0000000000 ffffffff857bc320
Call Trace:
[<ffffffff82344740>] dump_stack+0xac/0xfc
[<ffffffff82344694>] ? _atomic_dec_and_lock+0xc4/0xc4
[<ffffffff8242df78>] ubsan_epilogue+0xd/0x8a
[<ffffffff8242e6b4>] handle_overflow+0x202/0x23d
[<ffffffff8242e4b2>] ? val_to_string.constprop.6+0x11e/0x11e
[<ffffffff8236df71>] ? timerqueue_add+0x151/0x410
[<ffffffff81485c48>] ? hrtimer_start_range_ns+0x3b8/0x1380
[<ffffffff81795631>] ? memset+0x31/0x40
[<ffffffff8242e6fd>] __ubsan_handle_add_overflow+0xe/0x10
[<ffffffff81488ac9>] hrtimer_nanosleep+0x5d9/0x790
[<ffffffff814884f0>] ? hrtimer_init_sleeper+0x80/0x80
[<ffffffff813a9ffb>] ? __might_sleep+0x5b/0x260
[<ffffffff8148be10>] common_nsleep+0x20/0x30
[<ffffffff814906c7>] SyS_clock_nanosleep+0x197/0x210
[<ffffffff81490530>] ? SyS_clock_getres+0x150/0x150
[<ffffffff823c7113>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff8162ef60>] ? __context_tracking_exit.part.3+0x30/0x1b0
[<ffffffff81490530>] ? SyS_clock_getres+0x150/0x150
[<ffffffff81007bd3>] do_syscall_64+0x1b3/0x4b0
[<ffffffff845f85aa>] entry_SYSCALL64_slow_path+0x25/0x25
================================================================================
Add a new ktime_add_unsafe() helper which doesn't check for overflow, but
doesn't throw a UBSAN warning when it does overflow either.
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Richard Cochran <richardcochran(a)gmail.com>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/ktime.h | 7 +++++++
kernel/time/hrtimer.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -64,6 +64,13 @@ static inline ktime_t ktime_set(const s6
({ (ktime_t){ .tv64 = (lhs).tv64 + (rhs).tv64 }; })
/*
+ * Same as ktime_add(), but avoids undefined behaviour on overflow; however,
+ * this means that you must check the result for overflow yourself.
+ */
+#define ktime_add_unsafe(lhs, rhs) \
+ ({ (ktime_t){ .tv64 = (u64) (lhs).tv64 + (rhs).tv64 }; })
+
+/*
* Add a ktime_t variable and a scalar nanosecond value.
* res = kt + nsval:
*/
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -312,7 +312,7 @@ EXPORT_SYMBOL_GPL(__ktime_divns);
*/
ktime_t ktime_add_safe(const ktime_t lhs, const ktime_t rhs)
{
- ktime_t res = ktime_add(lhs, rhs);
+ ktime_t res = ktime_add_unsafe(lhs, rhs);
/*
* We use KTIME_SEC_MAX here, the maximum timeout which we can
Patches currently in stable-queue which might be from vegard.nossum(a)oracle.com are
queue-4.4/time-avoid-undefined-behaviour-in-ktime_add_safe.patch
This is a note to let you know that I've just added the patch titled
Prevent timer value 0 for MWAITX
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
prevent-timer-value-0-for-mwaitx.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 88d879d29f9cc0de2d930b584285638cdada6625 Mon Sep 17 00:00:00 2001
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Date: Tue, 25 Apr 2017 16:44:03 -0500
Subject: Prevent timer value 0 for MWAITX
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
commit 88d879d29f9cc0de2d930b584285638cdada6625 upstream.
Newer hardware has uncovered a bug in the software implementation of
using MWAITX for the delay function. A value of 0 for the timer is meant
to indicate that a timeout will not be used to exit MWAITX. On newer
hardware this can result in MWAITX never returning, resulting in NMI
soft lockup messages being printed. On older hardware, some of the other
conditions under which MWAITX can exit masked this issue. The AMD APM
does not currently document this and will be updated.
Please refer to http://marc.info/?l=kvm&m=148950623231140 for
information regarding NMI soft lockup messages on an AMD Ryzen 1800X.
This has been root-caused as a 0 passed to MWAITX causing it to wait
indefinitely.
This change has the added benefit of avoiding the unnecessary setup of
MONITORX/MWAITX when the delay value is zero.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Link: http://lkml.kernel.org/r/1493156643-29366-1-git-send-email-Janakarajan.Nata…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/lib/delay.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -93,6 +93,13 @@ static void delay_mwaitx(unsigned long _
{
u64 start, end, delay, loops = __loops;
+ /*
+ * Timer value of 0 causes MWAITX to wait indefinitely, unless there
+ * is a store on the memory monitored by MONITORX.
+ */
+ if (loops == 0)
+ return;
+
start = rdtsc_ordered();
for (;;) {
Patches currently in stable-queue which might be from Janakarajan.Natarajan(a)amd.com are
queue-4.4/prevent-timer-value-0-for-mwaitx.patch
This is a note to let you know that I've just added the patch titled
PM / sleep: declare __tracedata symbols as char[] rather than char
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f97238373b8662a6d580e204df2e7bcbfa43e27a Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers3(a)gmail.com>
Date: Sun, 24 Jan 2016 20:08:52 -0600
Subject: PM / sleep: declare __tracedata symbols as char[] rather than char
From: Eric Biggers <ebiggers3(a)gmail.com>
commit f97238373b8662a6d580e204df2e7bcbfa43e27a upstream.
Accessing more than one byte from a symbol declared simply 'char' is undefined
behavior, as reported by UBSAN:
UBSAN: Undefined behaviour in drivers/base/power/trace.c:178:18
load of address ffffffff8203fc78 with insufficient space
for an object of type 'char'
Avoid this by declaring the symbols as arrays.
Signed-off-by: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/power/trace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/base/power/trace.c
+++ b/drivers/base/power/trace.c
@@ -166,14 +166,14 @@ void generate_pm_trace(const void *trace
}
EXPORT_SYMBOL(generate_pm_trace);
-extern char __tracedata_start, __tracedata_end;
+extern char __tracedata_start[], __tracedata_end[];
static int show_file_hash(unsigned int value)
{
int match;
char *tracedata;
match = 0;
- for (tracedata = &__tracedata_start ; tracedata < &__tracedata_end ;
+ for (tracedata = __tracedata_start ; tracedata < __tracedata_end ;
tracedata += 2 + sizeof(unsigned long)) {
unsigned short lineno = *(unsigned short *)tracedata;
const char *file = *(const char **)(tracedata + 2);
Patches currently in stable-queue which might be from ebiggers3(a)gmail.com are
queue-4.4/pm-sleep-declare-__tracedata-symbols-as-char-rather-than-char.patch
This is a note to let you know that I've just added the patch titled
PCI: layerscape: Fix MSG TLP drop setting
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-layerscape-fix-msg-tlp-drop-setting.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1195c103f6c98d9ff381cac3a8760d4f8a133627 Mon Sep 17 00:00:00 2001
From: Minghuan Lian <Minghuan.Lian(a)nxp.com>
Date: Mon, 29 Feb 2016 17:24:15 -0600
Subject: PCI: layerscape: Fix MSG TLP drop setting
From: Minghuan Lian <Minghuan.Lian(a)nxp.com>
commit 1195c103f6c98d9ff381cac3a8760d4f8a133627 upstream.
Some kinds of Layerscape PCIe controllers will forward the received message
TLPs to system application address space, which could corrupt system memory
or lead to a system hang. Enable MSG_DROP to fix this issue.
Signed-off-by: Minghuan Lian <Minghuan.Lian(a)nxp.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Matthias Brugger <mbrugger(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-layerscape.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -77,6 +77,16 @@ static void ls_pcie_fix_class(struct ls_
iowrite16(PCI_CLASS_BRIDGE_PCI, pcie->dbi + PCI_CLASS_DEVICE);
}
+/* Drop MSG TLP except for Vendor MSG */
+static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
+{
+ u32 val;
+
+ val = ioread32(pcie->dbi + PCIE_STRFMR1);
+ val &= 0xDFFFFFFF;
+ iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+}
+
static int ls1021_pcie_link_up(struct pcie_port *pp)
{
u32 state;
@@ -97,7 +107,7 @@ static int ls1021_pcie_link_up(struct pc
static void ls1021_pcie_host_init(struct pcie_port *pp)
{
struct ls_pcie *pcie = to_ls_pcie(pp);
- u32 val, index[2];
+ u32 index[2];
pcie->scfg = syscon_regmap_lookup_by_phandle(pp->dev->of_node,
"fsl,pcie-scfg");
@@ -116,13 +126,7 @@ static void ls1021_pcie_host_init(struct
dw_pcie_setup_rc(pp);
- /*
- * LS1021A Workaround for internal TKT228622
- * to fix the INTx hang issue
- */
- val = ioread32(pcie->dbi + PCIE_STRFMR1);
- val &= 0xffff;
- iowrite32(val, pcie->dbi + PCIE_STRFMR1);
+ ls_pcie_drop_msg_tlp(pcie);
}
static int ls_pcie_link_up(struct pcie_port *pp)
@@ -147,6 +151,7 @@ static void ls_pcie_host_init(struct pci
iowrite32(1, pcie->dbi + PCIE_DBI_RO_WR_EN);
ls_pcie_fix_class(pcie);
ls_pcie_clear_multifunction(pcie);
+ ls_pcie_drop_msg_tlp(pcie);
iowrite32(0, pcie->dbi + PCIE_DBI_RO_WR_EN);
}
Patches currently in stable-queue which might be from Minghuan.Lian(a)nxp.com are
queue-4.4/pci-layerscape-fix-msg-tlp-drop-setting.patch
This is a note to let you know that I've just added the patch titled
PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-layerscape-add-fsl-ls2085a-pcie-compatible-id.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From dbae40b76abef2f8a7e7bf1701f77df9e73def48 Mon Sep 17 00:00:00 2001
From: Yang Shi <yang.shi(a)linaro.org>
Date: Wed, 27 Jan 2016 09:32:05 -0800
Subject: PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
From: Yang Shi <yang.shi(a)linaro.org>
commit dbae40b76abef2f8a7e7bf1701f77df9e73def48 upstream.
The Layerscape PCI host driver must recognize ls2085a compatible when using
firmware with ls2085a compatible property, otherwise the PCI bus won't be
detected even though ls2085a compatible is included by the dts.
Signed-off-by: Yang Shi <yang.shi(a)linaro.org>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Matthias Brugger <mbrugger(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/pci/host/pci-layerscape.c
+++ b/drivers/pci/host/pci-layerscape.c
@@ -203,6 +203,7 @@ static const struct of_device_id ls_pcie
{ .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
{ .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
{ .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
+ { .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
{ },
};
MODULE_DEVICE_TABLE(of, ls_pcie_of_match);
Patches currently in stable-queue which might be from yang.shi(a)linaro.org are
queue-4.4/pci-layerscape-add-fsl-ls2085a-pcie-compatible-id.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mmc-sdhci-of-esdhc-add-remove-some-quirks-according-to-vendor-version.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1ef5e49e46b919052474d9b54a15debc79ff0133 Mon Sep 17 00:00:00 2001
From: yangbo lu <yangbo.lu(a)freescale.com>
Date: Wed, 25 Nov 2015 10:05:37 +0800
Subject: mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
From: yangbo lu <yangbo.lu(a)freescale.com>
commit 1ef5e49e46b919052474d9b54a15debc79ff0133 upstream.
A previous patch had removed esdhc_of_platform_init() by mistake.
static void esdhc_of_platform_init(struct sdhci_host *host)
{
u32 vvn;
vvn = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
if (vvn == VENDOR_V_22)
host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
if (vvn > VENDOR_V_22)
host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ;
}
This patch is used to fix it by add/remove some quirks according to
verdor version in probe.
Signed-off-by: Yangbo Lu <yangbo.lu(a)freescale.com>
Fixes: f4932cfd22f1 ("mmc: sdhci-of-esdhc: support both BE and LE host controller")
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Matthias Brugger <mbrugger(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-of-esdhc.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -584,6 +584,8 @@ static int sdhci_esdhc_probe(struct plat
{
struct sdhci_host *host;
struct device_node *np;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_esdhc *esdhc;
int ret;
np = pdev->dev.of_node;
@@ -600,6 +602,14 @@ static int sdhci_esdhc_probe(struct plat
sdhci_get_of_property(pdev);
+ pltfm_host = sdhci_priv(host);
+ esdhc = pltfm_host->priv;
+ if (esdhc->vendor_ver == VENDOR_V_22)
+ host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
+
+ if (esdhc->vendor_ver > VENDOR_V_22)
+ host->quirks &= ~SDHCI_QUIRK_NO_BUSY_IRQ;
+
if (of_device_is_compatible(np, "fsl,p5040-esdhc") ||
of_device_is_compatible(np, "fsl,p5020-esdhc") ||
of_device_is_compatible(np, "fsl,p4080-esdhc") ||
Patches currently in stable-queue which might be from yangbo.lu(a)freescale.com are
queue-4.4/mmc-sdhci-of-esdhc-add-remove-some-quirks-according-to-vendor-version.patch
This is a note to let you know that I've just added the patch titled
fs/select: add vmalloc fallback for select(2)
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fs-select-add-vmalloc-fallback-for-select-2.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2d19309cf86883f634a4f8ec55a54bda87db19bf Mon Sep 17 00:00:00 2001
From: Vlastimil Babka <vbabka(a)suse.cz>
Date: Tue, 11 Oct 2016 13:51:14 -0700
Subject: fs/select: add vmalloc fallback for select(2)
From: Vlastimil Babka <vbabka(a)suse.cz>
commit 2d19309cf86883f634a4f8ec55a54bda87db19bf upstream.
The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
with the number of fds passed. We had a customer report page allocation
failures of order-4 for this allocation. This is a costly order, so it might
easily fail, as the VM expects such allocation to have a lower-order fallback.
Such trivial fallback is vmalloc(), as the memory doesn't have to be physically
contiguous and the allocation is temporary for the duration of the syscall
only. There were some concerns, whether this would have negative impact on the
system by exposing vmalloc() to userspace. Although an excessive use of vmalloc
can cause some system wide performance issues - TLB flushes etc. - a large
order allocation is not for free either and an excessive reclaim/compaction can
have a similar effect. Also note that the size is effectively limited by
RLIMIT_NOFILE which defaults to 1024 on the systems I checked. That means the
bitmaps will fit well within single page and thus the vmalloc() fallback could
be only excercised for processes where root allows a higher limit.
Note that the poll(2) syscall seems to use a linked list of order-0 pages, so
it doesn't need this kind of fallback.
[eric.dumazet(a)gmail.com: fix failure path logic]
[akpm(a)linux-foundation.org: use proper type for size]
Link: http://lkml.kernel.org/r/20160927084536.5923-1-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Eric Dumazet <eric.dumazet(a)gmail.com>
Cc: David Laight <David.Laight(a)ACULAB.COM>
Cc: Hillf Danton <hillf.zj(a)alibaba-inc.com>
Cc: Nicholas Piggin <npiggin(a)gmail.com>
Cc: Jason Baron <jbaron(a)akamai.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/select.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/fs/select.c
+++ b/fs/select.c
@@ -29,6 +29,7 @@
#include <linux/sched/rt.h>
#include <linux/freezer.h>
#include <net/busy_poll.h>
+#include <linux/vmalloc.h>
#include <asm/uaccess.h>
@@ -550,7 +551,7 @@ int core_sys_select(int n, fd_set __user
fd_set_bits fds;
void *bits;
int ret, max_fds;
- unsigned int size;
+ size_t size, alloc_size;
struct fdtable *fdt;
/* Allocate small arguments on the stack to save memory and be faster */
long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
@@ -577,7 +578,14 @@ int core_sys_select(int n, fd_set __user
if (size > sizeof(stack_fds) / 6) {
/* Not enough space in on-stack array; must use kmalloc */
ret = -ENOMEM;
- bits = kmalloc(6 * size, GFP_KERNEL);
+ if (size > (SIZE_MAX / 6))
+ goto out_nofds;
+
+ alloc_size = 6 * size;
+ bits = kmalloc(alloc_size, GFP_KERNEL|__GFP_NOWARN);
+ if (!bits && alloc_size > PAGE_SIZE)
+ bits = vmalloc(alloc_size);
+
if (!bits)
goto out_nofds;
}
@@ -614,7 +622,7 @@ int core_sys_select(int n, fd_set __user
out:
if (bits != stack_fds)
- kfree(bits);
+ kvfree(bits);
out_nofds:
return ret;
}
Patches currently in stable-queue which might be from vbabka(a)suse.cz are
queue-4.4/fs-select-add-vmalloc-fallback-for-select-2.patch
This is a note to let you know that I've just added the patch titled
drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fac51482577d5e05bbb0efa8d602a3c2111098bf Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Fri, 28 Oct 2016 09:45:28 +0100
Subject: drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
From: Sudeep Holla <sudeep.holla(a)arm.com>
commit fac51482577d5e05bbb0efa8d602a3c2111098bf upstream.
With CONFIG_OF enabled on x86, we get the following error on boot:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.
In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.
This patch also sets that boolean for x86.
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 2 ++
drivers/base/cacheinfo.c | 3 +++
include/linux/cacheinfo.h | 1 +
3 files changed, 6 insertions(+)
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -934,6 +934,8 @@ static int __populate_cache_leaves(unsig
ci_leaf_init(this_leaf++, &id4_regs);
__cache_cpumap_setup(cpu, idx, &id4_regs);
}
+ this_cpu_ci->cpu_map_populated = true;
+
return 0;
}
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -106,6 +106,9 @@ static int cache_shared_cpu_map_setup(un
unsigned int index;
int ret;
+ if (this_cpu_ci->cpu_map_populated)
+ return 0;
+
ret = cache_setup_of_node(cpu);
if (ret)
return ret;
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -71,6 +71,7 @@ struct cpu_cacheinfo {
struct cacheinfo *info_list;
unsigned int num_levels;
unsigned int num_leaves;
+ bool cpu_map_populated;
};
/*
Patches currently in stable-queue which might be from sudeep.holla(a)arm.com are
queue-4.4/drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
queue-4.4/drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
This is a note to let you know that I've just added the patch titled
drivers: base: cacheinfo: fix boot error message when acpi is enabled
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 55877ef45fbd7f975d078426866b7d1a2435dcc3 Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Fri, 28 Oct 2016 09:45:29 +0100
Subject: drivers: base: cacheinfo: fix boot error message when acpi is enabled
From: Sudeep Holla <sudeep.holla(a)arm.com>
commit 55877ef45fbd7f975d078426866b7d1a2435dcc3 upstream.
ARM64 enables both CONFIG_OF and CONFIG_ACPI and the firmware can pass
both ACPI tables and the device tree. Based on the kernel parameter, one
of the two will be chosen. If acpi is enabled, then device tree is not
unflattened.
Currently ARM64 platforms report:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
which is incorrect when booting with ACPI. Also latest ACPI v6.1 has no
support for cache properties/hierarchy.
This patch adds check for unflattened device tree and also returns as
"not supported" if ACPI is runtime enabled.
It also removes the reference to DT from the error message as the cache
hierarchy can be detected from the firmware(OF/DT/ACPI)
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/cacheinfo.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -16,6 +16,7 @@
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/cacheinfo.h>
#include <linux/compiler.h>
@@ -104,12 +105,16 @@ static int cache_shared_cpu_map_setup(un
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf, *sib_leaf;
unsigned int index;
- int ret;
+ int ret = 0;
if (this_cpu_ci->cpu_map_populated)
return 0;
- ret = cache_setup_of_node(cpu);
+ if (of_have_populated_dt())
+ ret = cache_setup_of_node(cpu);
+ else if (!acpi_disabled)
+ /* No cache property/hierarchy support yet in ACPI */
+ ret = -ENOTSUPP;
if (ret)
return ret;
@@ -206,8 +211,7 @@ static int detect_cache_attributes(unsig
*/
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
- pr_warn("Unable to detect cache hierarchy from DT for CPU %d\n",
- cpu);
+ pr_warn("Unable to detect cache hierarchy for CPU %d\n", cpu);
goto free_ci;
}
return 0;
Patches currently in stable-queue which might be from sudeep.holla(a)arm.com are
queue-4.4/drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
queue-4.4/drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
This is a note to let you know that I've just added the patch titled
Prevent timer value 0 for MWAITX
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
prevent-timer-value-0-for-mwaitx.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 88d879d29f9cc0de2d930b584285638cdada6625 Mon Sep 17 00:00:00 2001
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Date: Tue, 25 Apr 2017 16:44:03 -0500
Subject: Prevent timer value 0 for MWAITX
From: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
commit 88d879d29f9cc0de2d930b584285638cdada6625 upstream.
Newer hardware has uncovered a bug in the software implementation of
using MWAITX for the delay function. A value of 0 for the timer is meant
to indicate that a timeout will not be used to exit MWAITX. On newer
hardware this can result in MWAITX never returning, resulting in NMI
soft lockup messages being printed. On older hardware, some of the other
conditions under which MWAITX can exit masked this issue. The AMD APM
does not currently document this and will be updated.
Please refer to http://marc.info/?l=kvm&m=148950623231140 for
information regarding NMI soft lockup messages on an AMD Ryzen 1800X.
This has been root-caused as a 0 passed to MWAITX causing it to wait
indefinitely.
This change has the added benefit of avoiding the unnecessary setup of
MONITORX/MWAITX when the delay value is zero.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Link: http://lkml.kernel.org/r/1493156643-29366-1-git-send-email-Janakarajan.Nata…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Davidlohr Bueso <dbueso(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/lib/delay.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/x86/lib/delay.c
+++ b/arch/x86/lib/delay.c
@@ -93,6 +93,13 @@ static void delay_mwaitx(unsigned long _
{
u64 start, end, delay, loops = __loops;
+ /*
+ * Timer value of 0 causes MWAITX to wait indefinitely, unless there
+ * is a store on the memory monitored by MONITORX.
+ */
+ if (loops == 0)
+ return;
+
start = rdtsc_ordered();
for (;;) {
Patches currently in stable-queue which might be from Janakarajan.Natarajan(a)amd.com are
queue-4.9/prevent-timer-value-0-for-mwaitx.patch
This is a note to let you know that I've just added the patch titled
drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From fac51482577d5e05bbb0efa8d602a3c2111098bf Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Fri, 28 Oct 2016 09:45:28 +0100
Subject: drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
From: Sudeep Holla <sudeep.holla(a)arm.com>
commit fac51482577d5e05bbb0efa8d602a3c2111098bf upstream.
With CONFIG_OF enabled on x86, we get the following error on boot:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.
In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.
This patch also sets that boolean for x86.
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/intel_cacheinfo.c | 2 ++
drivers/base/cacheinfo.c | 3 +++
include/linux/cacheinfo.h | 1 +
3 files changed, 6 insertions(+)
--- a/arch/x86/kernel/cpu/intel_cacheinfo.c
+++ b/arch/x86/kernel/cpu/intel_cacheinfo.c
@@ -934,6 +934,8 @@ static int __populate_cache_leaves(unsig
ci_leaf_init(this_leaf++, &id4_regs);
__cache_cpumap_setup(cpu, idx, &id4_regs);
}
+ this_cpu_ci->cpu_map_populated = true;
+
return 0;
}
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -106,6 +106,9 @@ static int cache_shared_cpu_map_setup(un
unsigned int index;
int ret;
+ if (this_cpu_ci->cpu_map_populated)
+ return 0;
+
ret = cache_setup_of_node(cpu);
if (ret)
return ret;
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -71,6 +71,7 @@ struct cpu_cacheinfo {
struct cacheinfo *info_list;
unsigned int num_levels;
unsigned int num_leaves;
+ bool cpu_map_populated;
};
/*
Patches currently in stable-queue which might be from sudeep.holla(a)arm.com are
queue-4.9/drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
queue-4.9/drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
This is a note to let you know that I've just added the patch titled
drivers: base: cacheinfo: fix boot error message when acpi is enabled
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 55877ef45fbd7f975d078426866b7d1a2435dcc3 Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla(a)arm.com>
Date: Fri, 28 Oct 2016 09:45:29 +0100
Subject: drivers: base: cacheinfo: fix boot error message when acpi is enabled
From: Sudeep Holla <sudeep.holla(a)arm.com>
commit 55877ef45fbd7f975d078426866b7d1a2435dcc3 upstream.
ARM64 enables both CONFIG_OF and CONFIG_ACPI and the firmware can pass
both ACPI tables and the device tree. Based on the kernel parameter, one
of the two will be chosen. If acpi is enabled, then device tree is not
unflattened.
Currently ARM64 platforms report:
"
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
"
which is incorrect when booting with ACPI. Also latest ACPI v6.1 has no
support for cache properties/hierarchy.
This patch adds check for unflattened device tree and also returns as
"not supported" if ACPI is runtime enabled.
It also removes the reference to DT from the error message as the cache
hierarchy can be detected from the firmware(OF/DT/ACPI)
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/base/cacheinfo.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -16,6 +16,7 @@
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/bitops.h>
#include <linux/cacheinfo.h>
#include <linux/compiler.h>
@@ -104,12 +105,16 @@ static int cache_shared_cpu_map_setup(un
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf, *sib_leaf;
unsigned int index;
- int ret;
+ int ret = 0;
if (this_cpu_ci->cpu_map_populated)
return 0;
- ret = cache_setup_of_node(cpu);
+ if (of_have_populated_dt())
+ ret = cache_setup_of_node(cpu);
+ else if (!acpi_disabled)
+ /* No cache property/hierarchy support yet in ACPI */
+ ret = -ENOTSUPP;
if (ret)
return ret;
@@ -206,8 +211,7 @@ static int detect_cache_attributes(unsig
*/
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
- pr_warn("Unable to detect cache hierarchy from DT for CPU %d\n",
- cpu);
+ pr_warn("Unable to detect cache hierarchy for CPU %d\n", cpu);
goto free_ci;
}
return 0;
Patches currently in stable-queue which might be from sudeep.holla(a)arm.com are
queue-4.9/drivers-base-cacheinfo-fix-x86-with-config_of-enabled.patch
queue-4.9/drivers-base-cacheinfo-fix-boot-error-message-when-acpi-is-enabled.patch
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-arm-arm64-check-pagesize-when-allocating-a-hugepage-at-stage-2.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c507babf10ead4d5c8cca704539b170752a8ac84 Mon Sep 17 00:00:00 2001
From: Punit Agrawal <punit.agrawal(a)arm.com>
Date: Thu, 4 Jan 2018 18:24:33 +0000
Subject: KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
From: Punit Agrawal <punit.agrawal(a)arm.com>
commit c507babf10ead4d5c8cca704539b170752a8ac84 upstream.
KVM only supports PMD hugepages at stage 2 but doesn't actually check
that the provided hugepage memory pagesize is PMD_SIZE before populating
stage 2 entries.
In cases where the backing hugepage size is smaller than PMD_SIZE (such
as when using contiguous hugepages), KVM can end up creating stage 2
mappings that extend beyond the supplied memory.
Fix this by checking for the pagesize of userspace vma before creating
PMD hugepage at stage 2.
Fixes: 66b3923a1a0f77a ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Punit Agrawal <punit.agrawal(a)arm.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kvm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1284,7 +1284,7 @@ static int user_mem_abort(struct kvm_vcp
return -EFAULT;
}
- if (is_vm_hugetlb_page(vma) && !logging_active) {
+ if (vma_kernel_pagesize(vma) && !logging_active) {
hugetlb = true;
gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
} else {
Patches currently in stable-queue which might be from punit.agrawal(a)arm.com are
queue-4.9/kvm-arm-arm64-check-pagesize-when-allocating-a-hugepage-at-stage-2.patch
This is a note to let you know that I've just added the patch titled
can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d4689846881d160a4d12a514e991a740bcb5d65a Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Tue, 16 Jan 2018 19:30:14 +0100
Subject: can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.
If an invalid CANFD frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+e3b775f40babeff6e68b(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Cc: linux-stable <stable(a)vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -745,13 +745,12 @@ static int canfd_rcv(struct sk_buff *skb
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CANFD_MTU ||
- cfd->len > CANFD_MAX_DLEN,
- "PF_CAN: dropped non conform CAN FD skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CANFD_MTU ||
+ cfd->len > CANFD_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN FD skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-4.9/can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
queue-4.9/can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
This is a note to let you know that I've just added the patch titled
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8cb68751c115d176ec851ca56ecfbb411568c9e8 Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Tue, 16 Jan 2018 19:30:14 +0100
Subject: can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.
If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+4386709c0c1284dca827(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -722,13 +722,12 @@ static int can_rcv(struct sk_buff *skb,
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CAN_MTU ||
- cfd->len > CAN_MAX_DLEN,
- "PF_CAN: dropped non conform CAN skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CAN_MTU ||
+ cfd->len > CAN_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-4.9/can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
queue-4.9/can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
This is a note to let you know that I've just added the patch titled
can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d4689846881d160a4d12a514e991a740bcb5d65a Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Tue, 16 Jan 2018 19:30:14 +0100
Subject: can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.
If an invalid CANFD frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+e3b775f40babeff6e68b(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Cc: linux-stable <stable(a)vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -745,13 +745,12 @@ static int canfd_rcv(struct sk_buff *skb
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CANFD_MTU ||
- cfd->len > CANFD_MAX_DLEN,
- "PF_CAN: dropped non conform CAN FD skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CANFD_MTU ||
+ cfd->len > CANFD_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN FD skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-4.4/can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
queue-4.4/can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
This is a note to let you know that I've just added the patch titled
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8cb68751c115d176ec851ca56ecfbb411568c9e8 Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Tue, 16 Jan 2018 19:30:14 +0100
Subject: can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.
If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+4386709c0c1284dca827(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -722,13 +722,12 @@ static int can_rcv(struct sk_buff *skb,
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CAN_MTU ||
- cfd->len > CAN_MAX_DLEN,
- "PF_CAN: dropped non conform CAN skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CAN_MTU ||
+ cfd->len > CAN_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-4.4/can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
queue-4.4/can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
This is a note to let you know that I've just added the patch titled
can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d4689846881d160a4d12a514e991a740bcb5d65a Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Tue, 16 Jan 2018 19:30:14 +0100
Subject: can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.
If an invalid CANFD frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+e3b775f40babeff6e68b(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Cc: linux-stable <stable(a)vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -742,13 +742,12 @@ static int canfd_rcv(struct sk_buff *skb
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CANFD_MTU ||
- cfd->len > CANFD_MAX_DLEN,
- "PF_CAN: dropped non conform CAN FD skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CANFD_MTU ||
+ cfd->len > CANFD_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN FD skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-3.18/can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
queue-3.18/can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
This is a note to let you know that I've just added the patch titled
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 8cb68751c115d176ec851ca56ecfbb411568c9e8 Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Tue, 16 Jan 2018 19:30:14 +0100
Subject: can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.
If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+4386709c0c1284dca827(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -719,13 +719,12 @@ static int can_rcv(struct sk_buff *skb,
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CAN_MTU ||
- cfd->len > CAN_MAX_DLEN,
- "PF_CAN: dropped non conform CAN skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CAN_MTU ||
+ cfd->len > CAN_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-3.18/can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
queue-3.18/can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From c507babf10ead4d5c8cca704539b170752a8ac84 Mon Sep 17 00:00:00 2001
From: Punit Agrawal <punit.agrawal(a)arm.com>
Date: Thu, 4 Jan 2018 18:24:33 +0000
Subject: [PATCH] KVM: arm/arm64: Check pagesize when allocating a hugepage at
Stage 2
KVM only supports PMD hugepages at stage 2 but doesn't actually check
that the provided hugepage memory pagesize is PMD_SIZE before populating
stage 2 entries.
In cases where the backing hugepage size is smaller than PMD_SIZE (such
as when using contiguous hugepages), KVM can end up creating stage 2
mappings that extend beyond the supplied memory.
Fix this by checking for the pagesize of userspace vma before creating
PMD hugepage at stage 2.
Fixes: 66b3923a1a0f77a ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Punit Agrawal <punit.agrawal(a)arm.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: <stable(a)vger.kernel.org> # v4.5+
Reviewed-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index b4b69c2d1012..9dea96380339 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -1310,7 +1310,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
return -EFAULT;
}
- if (is_vm_hugetlb_page(vma) && !logging_active) {
+ if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
hugetlb = true;
gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
} else {
In Linux 4.12 commit 8e8cda6d737d356054c ("can: initial support for network
namespaces") removed a namespace check which affected this patch:
upstream commit 8cb68751c115d176ec851ca56ecfbb411568c9e8
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+4386709c0c1284dca827(a)syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov(a)google.com>
Acked-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
Cc: linux-stable <stable(a)vger.kernel.org> [pre 4.12]
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan(a)hartkopp.net>
---
net/can/af_can.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/can/af_can.c b/net/can/af_can.c
index 928f58064098..924ad0513af9 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -722,13 +722,12 @@ static int can_rcv(struct sk_buff *skb, struct net_device *dev,
if (unlikely(!net_eq(dev_net(dev), &init_net)))
goto drop;
- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
- skb->len != CAN_MTU ||
- cfd->len > CAN_MAX_DLEN,
- "PF_CAN: dropped non conform CAN skbuf: "
- "dev type %d, len %d, datalen %d\n",
- dev->type, skb->len, cfd->len))
+ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CAN_MTU ||
+ cfd->len > CAN_MAX_DLEN)) {
+ pr_warn_once("PF_CAN: dropped non conform CAN skbuf: dev type %d, len %d, datalen %d\n",
+ dev->type, skb->len, cfd->len);
goto drop;
+ }
can_receive(skb, dev);
return NET_RX_SUCCESS;
--
2.15.1
This is the start of the stable review cycle for the 4.4.107 release.
There are 115 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Dec 20 15:28:15 UTC 2017.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.107-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.107-rc1
Miaoqing Pan <miaoqing(a)codeaurora.org>
ath9k: fix tx99 potential info leak
Alex Vesker <valex(a)mellanox.com>
IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop
Bart Van Assche <bart.vanassche(a)wdc.com>
RDMA/cma: Avoid triggering undefined behavior
Alexander Duyck <alexander.h.duyck(a)intel.com>
macvlan: Only deliver one copy of the frame to the macvlan interface
Jan Kara <jack(a)suse.cz>
udf: Avoid overflow when session starts at large offset
Dan Carpenter <dan.carpenter(a)oracle.com>
scsi: bfa: integer overflow in debugfs
weiping zhang <zhangweiping(a)didichuxing.com>
scsi: sd: change allow_restart to bool in sysfs interface
weiping zhang <zhangweiping(a)didichuxing.com>
scsi: sd: change manage_start_stop to bool in sysfs interface
Jia-Ju Bai <baijiaju1990(a)163.com>
vt6655: Fix a possible sleep-in-atomic bug in vt6655_suspend
Kurt Garloff <garloff(a)suse.de>
scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
NeilBrown <neilb(a)suse.com>
raid5: Set R5_Expanded on parity devices as well as data.
Linus Walleij <linus.walleij(a)linaro.org>
pinctrl: adi2: Fix Kconfig build problem
Bin Liu <b-liu(a)ti.com>
usb: musb: da8xx: fix babble condition handling
nixiaoming <nixiaoming(a)huawei.com>
tty fix oops when rmmod 8250
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/perf/hv-24x7: Fix incorrect comparison in memord
Martin Wilck <mwilck(a)suse.de>
scsi: hpsa: destroy sas transport properties before scsi_host
Martin Wilck <mwilck(a)suse.de>
scsi: hpsa: cleanup sas_phy structures in sysfs when unloading
Alex Williamson <alex.williamson(a)redhat.com>
PCI: Detach driver before procfs & sysfs teardown on device remove
Christoph Hellwig <hch(a)lst.de>
xfs: fix incorrect extent state in xfs_bmap_add_extent_unwritten_real
Brian Foster <bfoster(a)redhat.com>
xfs: fix log block underflow during recovery cycle verification
Jiri Slaby <jslaby(a)suse.cz>
l2tp: cleanup l2tp_tunnel_delete calls
tang.junhui <tang.junhui(a)zte.com.cn>
bcache: fix wrong cache_misses statistics
Liang Chen <liangchen.linux(a)gmail.com>
bcache: explicitly destroy mutex while exiting
Bob Peterson <rpeterso(a)redhat.com>
GFS2: Take inode off order_write list when setting jdata flag
Daniel Lezcano <daniel.lezcano(a)linaro.org>
thermal/drivers/step_wise: Fix temperature regulation misbehavior
Gao Feng <gfree.wind(a)vip.163.com>
ppp: Destroy the mutex when cleanup
Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
clk: tegra: Fix cclk_lp divisor register
Sébastien Szymanski <sebastien.szymanski(a)armadeus.com>
clk: imx6: refine hdmi_isfr's parent to make HDMI work on i.MX6 SoCs w/o VPU
Chen Zhong <chen.zhong(a)mediatek.com>
clk: mediatek: add the option for determining PLL source clock
Jan Kara <jack(a)suse.cz>
mm: Handle 0 flags in _calc_vm_trans() macro
Robert Baronescu <robert.baronescu(a)nxp.com>
crypto: tcrypt - fix buffer lengths in test_aead_speed()
Suzuki K Poulose <suzuki.poulose(a)arm.com>
arm-ccn: perf: Prevent module unload while PMU is in use
Jiang Yi <jiangyilism(a)gmail.com>
target/file: Do not return error for UNMAP if length is zero
tangwenji <tang.wenji(a)zte.com.cn>
target:fix condition return in core_pr_dump_initiator_port()
tangwenji <tang.wenji(a)zte.com.cn>
iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
Bart Van Assche <bart.vanassche(a)wdc.com>
target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
Markus Elfring <elfring(a)users.sourceforge.net>
platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
Christophe Leroy <christophe.leroy(a)c-s.fr>
powerpc/ipic: Fix status get and status clear
William A. Kennington III <wak(a)google.com>
powerpc/opal: Fix EBUSY bug in acquiring tokens
KUWAZAWA Takuya <albatross0(a)gmail.com>
netfilter: ipvs: Fix inappropriate output of procfs
Shriya <shriyak(a)linux.vnet.ibm.com>
powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
Qiang <zhengqiang10(a)huawei.com>
PCI/PME: Handle invalid data when reading Root Status
Peter Ujfalusi <peter.ujfalusi(a)ti.com>
dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
Philipp Zabel <p.zabel(a)pengutronix.de>
rtc: pcf8563: fix output clock rate
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
video: fbdev: au1200fb: Return an error code if a memory allocation fails
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
video: fbdev: au1200fb: Release some resources if a memory allocation fails
Ladislav Michl <ladis(a)linux-mips.org>
video: udlfb: Fix read EDID timeout
Geert Uytterhoeven <geert(a)linux-m68k.org>
fbdev: controlfb: Add missing modes to fix out of bounds access
Robert Stonehouse <rstonehouse(a)solarflare.com>
sfc: don't warn on successful change of MAC
Mike Christie <mchristi(a)redhat.com>
target: fix race during implicit transition work flushes
Mike Christie <mchristi(a)redhat.com>
target: fix ALUA transition timeout handling
Mike Christie <mchristi(a)redhat.com>
target: Use system workqueue for ALUA transitions
Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
btrfs: add missing memset while reading compressed inline extents
Olga Kornievskaia <kolga(a)netapp.com>
NFSv4.1 respect server's max size in CREATE_SESSION
Daniel Drake <drake(a)endlessm.com>
efi/esrt: Cleanup bad memory map log messages
Daniel Borkmann <daniel(a)iogearbox.net>
perf symbols: Fix symbols__fixup_end heuristic for corner cases
Jack Morgenstein <jackm(a)dev.mellanox.co.il>
net/mlx4_core: Avoid delays during VF driver device shutdown
David Howells <dhowells(a)redhat.com>
afs: Fix afs_kill_pages()
David Howells <dhowells(a)redhat.com>
afs: Fix page leak in afs_write_begin()
Marc Dionne <marc.dionne(a)auristor.com>
afs: Populate and use client modification time
David Howells <dhowells(a)redhat.com>
afs: Fix the maths in afs_fs_store_data()
Tina Ruchandani <ruchandani.tina(a)gmail.com>
afs: Prevent callback expiry timer overflow
Tina Ruchandani <ruchandani.tina(a)gmail.com>
afs: Migrate vlocation fields to 64-bit
David Howells <dhowells(a)redhat.com>
afs: Flush outstanding writes when an fd is closed
Marc Dionne <marc.dionne(a)auristor.com>
afs: Adjust mode bits processing
Marc Dionne <marc.dionne(a)auristor.com>
afs: Populate group ID from vnode status
David Howells <dhowells(a)redhat.com>
afs: Fix missing put_page()
Alex Deucher <alexander.deucher(a)amd.com>
drm/radeon: reinstate oland workaround for sclk
yong mao <yong.mao(a)mediatek.com>
mmc: mediatek: Fixed bug where clock frequency could be set wrong
Steven Rostedt (VMware) <rostedt(a)goodmis.org>
sched/deadline: Use deadline instead of period when calculating overflow
Daniel Bristot de Oliveira <bristot(a)redhat.com>
sched/deadline: Throttle a constrained deadline task activated after the deadline
Daniel Bristot de Oliveira <bristot(a)redhat.com>
sched/deadline: Make sure the replenishment timer fires in the next period
Alex Deucher <alexander.deucher(a)amd.com>
drm/radeon/si: add dpm quirk for Oland
Taku Izumi <izumi.taku(a)jp.fujitsu.com>
fjes: Fix wrong netdevice feature flags
Don Brace <don.brace(a)microsemi.com>
scsi: hpsa: limit outstanding rescans
Don Brace <don.brace(a)microsemi.com>
scsi: hpsa: update check for logical volume status
Stafford Horne <shorne(a)gmail.com>
openrisc: fix issue handling 8 byte get_user calls
Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
intel_th: pci: Add Gemini Lake support
Jiri Pirko <jiri(a)mellanox.com>
mlxsw: reg: Fix SPVMLR max record count
Jiri Pirko <jiri(a)mellanox.com>
mlxsw: reg: Fix SPVM max record count
Vlad Yasevich <vyasevich(a)gmail.com>
net: Resend IGMP memberships upon peer notification.
Matthias Kaehlcke <mka(a)chromium.org>
dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
Johan Hovold <johan(a)kernel.org>
net: wimax/i2400m: fix NULL-deref at probe
Tahsin Erdogan <tahsin(a)google.com>
writeback: fix memory leak in wb_queue_work()
Florian Westphal <fw(a)strlen.de>
netfilter: bridge: honor frag_max_size when refragmenting
Tomi Valkeinen <tomi.valkeinen(a)ti.com>
drm/omap: fix dmabuf mmap for dma_alloc'ed buffers
Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Input: i8042 - add TUXEDO BU1406 (N24_25BU) to the nomux list
NeilBrown <neilb(a)suse.com>
NFSD: fix nfsd_reset_versions for NFSv4.
NeilBrown <neilb(a)suse.com>
NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: Power up the internal PHY before probing the MII
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: power down internal phy if open or resume fails
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: reserved phy revisions must be checked first
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: correct MIB access of UniMAC RUNT counters
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values
Alexander Potapenko <glider(a)google.com>
net: initialize msg.msg_flags in recvfrom
Andrea Arcangeli <aarcange(a)redhat.com>
userfaultfd: selftest: vm: allow to build in vm/ directory
Andrea Arcangeli <aarcange(a)redhat.com>
userfaultfd: shmem: __do_fault requires VM_FAULT_NOPAGE
Guoqing Jiang <gqjiang(a)suse.com>
md-cluster: free md_cluster_info if node leave cluster
Javier Martinez Canillas <javier(a)osg.samsung.com>
usb: phy: isp1301: Add OF device ID table
Ilan peer <ilan.peer(a)intel.com>
mac80211: Fix addition of mesh configuration element
Eric Biggers <ebiggers(a)google.com>
KEYS: add missing permission check for request_key() destination
Chandan Rajendra <chandan(a)linux.vnet.ibm.com>
ext4: fix crash when a directory's i_size is too small
Eryu Guan <eguan(a)redhat.com>
ext4: fix fdatasync(2) after fallocate(2) operation
Adam Wallis <awallis(a)codeaurora.org>
dmaengine: dmatest: move callback wait queue to thread context
Steven Rostedt <rostedt(a)goodmis.org>
sched/rt: Do not pull from current CPU if only one CPU to pull
Mathias Nyman <mathias.nyman(a)linux.intel.com>
xhci: Don't add a virt_dev to the devs array before it's fully allocated
Sukumar Ghorai <sukumar.ghorai(a)intel.com>
Bluetooth: btusb: driver to enable the usb-wakeup feature
Yan, Zheng <zyan(a)redhat.com>
ceph: drop negative child dentries before try pruning inode's alias
Shuah Khan <shuahkh(a)osg.samsung.com>
usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer
Alan Stern <stern(a)rowland.harvard.edu>
USB: core: prevent malicious bNumInterfaces overflow
David Kozub <zub(a)linux.fjfi.cvut.cz>
USB: uas and storage: Add US_FL_BROKEN_FUA for another JMicron JMS567 ID
Changbin Du <changbin.du(a)intel.com>
tracing: Allocate mask_str buffer dynamically
NeilBrown <neilb(a)suse.com>
autofs: fix careless error in recent commit
Eric Biggers <ebiggers(a)google.com>
crypto: salsa20 - fix blkcipher_walk API usage
Eric Biggers <ebiggers(a)google.com>
crypto: hmac - require that the underlying hash algorithm is unkeyed
-------------
Diffstat:
Makefile | 4 +-
arch/blackfin/Kconfig | 7 +-
arch/blackfin/Kconfig.debug | 1 +
arch/openrisc/include/asm/uaccess.h | 2 +-
arch/powerpc/perf/hv-24x7.c | 2 +-
arch/powerpc/platforms/powernv/opal-async.c | 6 +-
arch/powerpc/platforms/powernv/setup.c | 2 +-
arch/powerpc/sysdev/ipic.c | 4 +-
arch/x86/crypto/salsa20_glue.c | 7 --
crypto/hmac.c | 6 +-
crypto/salsa20_generic.c | 7 --
crypto/shash.c | 5 +-
crypto/tcrypt.c | 6 +-
drivers/bluetooth/btusb.c | 5 ++
drivers/bus/arm-ccn.c | 1 +
drivers/clk/imx/clk-imx6q.c | 2 +-
drivers/clk/mediatek/clk-mtk.h | 1 +
drivers/clk/mediatek/clk-pll.c | 5 +-
drivers/clk/tegra/clk-tegra30.c | 2 +-
drivers/dma/dmaengine.c | 2 +
drivers/dma/dmatest.c | 55 ++++++++-------
drivers/dma/ti-dma-crossbar.c | 8 +--
drivers/firmware/efi/efi.c | 1 -
drivers/firmware/efi/esrt.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 -
drivers/gpu/drm/radeon/si_dpm.c | 10 +++
drivers/hwtracing/intel_th/pci.c | 5 ++
drivers/infiniband/core/cma.c | 11 +--
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 +-
drivers/input/serio/i8042-x86ia64io.h | 7 ++
drivers/md/bcache/request.c | 6 +-
drivers/md/bcache/super.c | 6 +-
drivers/md/md-cluster.c | 1 +
drivers/md/raid5.c | 5 +-
drivers/mmc/host/mtk-sd.c | 4 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 95 +++++++++++++++++++++-----
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 ++-
drivers/net/ethernet/mellanox/mlx4/cmd.c | 11 +++
drivers/net/ethernet/mellanox/mlx4/main.c | 11 +++
drivers/net/ethernet/mellanox/mlxsw/reg.h | 4 +-
drivers/net/ethernet/sfc/ef10.c | 2 +-
drivers/net/fjes/fjes_main.c | 2 +-
drivers/net/macvlan.c | 2 +-
drivers/net/ppp/ppp_generic.c | 1 +
drivers/net/wimax/i2400m/usb.c | 3 +
drivers/net/wireless/ath/ath9k/tx99.c | 5 ++
drivers/pci/pcie/pme.c | 5 +-
drivers/pci/remove.c | 2 +-
drivers/pinctrl/Kconfig | 3 +-
drivers/platform/x86/sony-laptop.c | 14 ++--
drivers/rtc/rtc-pcf8563.c | 2 +-
drivers/scsi/bfa/bfad_debugfs.c | 5 +-
drivers/scsi/hpsa.c | 57 +++++++++-------
drivers/scsi/hpsa.h | 1 +
drivers/scsi/hpsa_cmd.h | 2 +
drivers/scsi/scsi_devinfo.c | 2 +-
drivers/scsi/sd.c | 12 +++-
drivers/staging/vt6655/device_main.c | 3 +-
drivers/target/iscsi/iscsi_target.c | 3 +-
drivers/target/iscsi/iscsi_target_configfs.c | 3 +-
drivers/target/target_core_alua.c | 33 +++------
drivers/target/target_core_file.c | 4 ++
drivers/target/target_core_pr.c | 4 +-
drivers/thermal/step_wise.c | 11 +--
drivers/usb/core/config.c | 4 +-
drivers/usb/host/xhci-mem.c | 15 ++--
drivers/usb/musb/da8xx.c | 10 ++-
drivers/usb/phy/phy-isp1301.c | 7 ++
drivers/usb/storage/unusual_devs.h | 7 ++
drivers/usb/storage/unusual_uas.h | 7 ++
drivers/usb/usbip/stub_tx.c | 7 ++
drivers/video/fbdev/au1200fb.c | 7 +-
drivers/video/fbdev/controlfb.h | 2 +
drivers/video/fbdev/udlfb.c | 10 +--
fs/afs/callback.c | 7 +-
fs/afs/file.c | 1 +
fs/afs/fsclient.c | 22 +++---
fs/afs/inode.c | 11 +--
fs/afs/internal.h | 12 ++--
fs/afs/security.c | 7 +-
fs/afs/server.c | 6 +-
fs/afs/vlocation.c | 16 +++--
fs/afs/write.c | 32 +++++++--
fs/autofs4/waitq.c | 1 -
fs/btrfs/inode.c | 14 ++++
fs/ceph/mds_client.c | 42 ++++++++++--
fs/ext4/extents.c | 1 +
fs/ext4/namei.c | 4 ++
fs/fs-writeback.c | 35 ++++++----
fs/gfs2/file.c | 4 +-
fs/nfs/nfs4client.c | 4 +-
fs/nfsd/nfssvc.c | 30 ++++----
fs/proc/proc_tty.c | 3 +-
fs/udf/super.c | 2 +-
fs/userfaultfd.c | 2 +-
fs/xfs/libxfs/xfs_bmap.c | 2 +-
fs/xfs/xfs_log_recover.c | 2 +-
include/crypto/internal/hash.h | 8 +++
include/linux/mlx4/device.h | 1 +
include/linux/mman.h | 3 +-
include/target/target_core_base.h | 2 +-
kernel/sched/deadline.c | 62 +++++++++++++++--
kernel/sched/rt.c | 8 ++-
kernel/trace/trace.c | 29 +++-----
net/bridge/br_netfilter_hooks.c | 12 ++--
net/core/dev.c | 1 +
net/l2tp/l2tp_core.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
net/mac80211/mesh.c | 2 -
net/netfilter/ipvs/ip_vs_ctl.c | 4 ++
net/socket.c | 1 +
security/keys/request_key.c | 48 ++++++++++---
tools/perf/util/symbol.c | 2 +-
tools/testing/selftests/vm/Makefile | 4 ++
114 files changed, 727 insertions(+), 320 deletions(-)
This is a note to let you know that I've just added the patch titled
sched/deadline: Use the revised wakeup rule for suspending constrained dl tasks
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3effcb4247e74a51f5d8b775a1ee4abf87cc089a Mon Sep 17 00:00:00 2001
From: Daniel Bristot de Oliveira <bristot(a)redhat.com>
Date: Mon, 29 May 2017 16:24:03 +0200
Subject: sched/deadline: Use the revised wakeup rule for suspending constrained dl tasks
From: Daniel Bristot de Oliveira <bristot(a)redhat.com>
commit 3effcb4247e74a51f5d8b775a1ee4abf87cc089a upstream.
We have been facing some problems with self-suspending constrained
deadline tasks. The main reason is that the original CBS was not
designed for such sort of tasks.
One problem reported by Xunlei Pang takes place when a task
suspends, and then is awakened before the deadline, but so close
to the deadline that its remaining runtime can cause the task
to have an absolute density higher than allowed. In such situation,
the original CBS assumes that the task is facing an early activation,
and so it replenishes the task and set another deadline, one deadline
in the future. This rule works fine for implicit deadline tasks.
Moreover, it allows the system to adapt the period of a task in which
the external event source suffered from a clock drift.
However, this opens the window for bandwidth leakage for constrained
deadline tasks. For instance, a task with the following parameters:
runtime = 5 ms
deadline = 7 ms
[density] = 5 / 7 = 0.71
period = 1000 ms
If the task runs for 1 ms, and then suspends for another 1ms,
it will be awakened with the following parameters:
remaining runtime = 4
laxity = 5
presenting a absolute density of 4 / 5 = 0.80.
In this case, the original CBS would assume the task had an early
wakeup. Then, CBS will reset the runtime, and the absolute deadline will
be postponed by one relative deadline, allowing the task to run.
The problem is that, if the task runs this pattern forever, it will keep
receiving bandwidth, being able to run 1ms every 2ms. Following this
behavior, the task would be able to run 500 ms in 1 sec. Thus running
more than the 5 ms / 1 sec the admission control allowed it to run.
Trying to address the self-suspending case, Luca Abeni, Giuseppe
Lipari, and Juri Lelli [1] revisited the CBS in order to deal with
self-suspending tasks. In the new approach, rather than
replenishing/postponing the absolute deadline, the revised wakeup rule
adjusts the remaining runtime, reducing it to fit into the allowed
density.
A revised version of the idea is:
At a given time t, the maximum absolute density of a task cannot be
higher than its relative density, that is:
runtime / (deadline - t) <= dl_runtime / dl_deadline
Knowing the laxity of a task (deadline - t), it is possible to move
it to the other side of the equality, thus enabling to define max
remaining runtime a task can use within the absolute deadline, without
over-running the allowed density:
runtime = (dl_runtime / dl_deadline) * (deadline - t)
For instance, in our previous example, the task could still run:
runtime = ( 5 / 7 ) * 5
runtime = 3.57 ms
Without causing damage for other deadline tasks. It is note worthy
that the laxity cannot be negative because that would cause a negative
runtime. Thus, this patch depends on the patch:
df8eac8cafce ("sched/deadline: Throttle a constrained deadline task activated after the deadline")
Which throttles a constrained deadline task activated after the
deadline.
Finally, it is also possible to use the revised wakeup rule for
all other tasks, but that would require some more discussions
about pros and cons.
[The main difference from the original commit is that
the BW_SHIFT define was not present yet. As BW_SHIFT was
introduced in a new feature, I just used the value (20),
likewise we used to use before the #define.
Other changes were required because of comments. - bistrot]
Reported-by: Xunlei Pang <xpang(a)redhat.com>
Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com>
[peterz: replaced dl_is_constrained with dl_is_implicit]
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Juri Lelli <juri.lelli(a)arm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Luca Abeni <luca.abeni(a)santannapisa.it>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it>
Link: http://lkml.kernel.org/r/5c800ab3a74a168a84ee5f3f84d12a02e11383be.149580380…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Daniel Bristot de Oliveira <bristot(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/sched.h | 1
kernel/sched/core.c | 2
kernel/sched/deadline.c | 98 ++++++++++++++++++++++++++++++++++++++++++------
3 files changed, 89 insertions(+), 12 deletions(-)
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1313,6 +1313,7 @@ struct sched_dl_entity {
u64 dl_deadline; /* relative deadline of each instance */
u64 dl_period; /* separation of two instances (period) */
u64 dl_bw; /* dl_runtime / dl_deadline */
+ u64 dl_density; /* dl_runtime / dl_deadline */
/*
* Actual scheduling parameters. Initialized with the values above,
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2109,6 +2109,7 @@ void __dl_clear_params(struct task_struc
dl_se->dl_period = 0;
dl_se->flags = 0;
dl_se->dl_bw = 0;
+ dl_se->dl_density = 0;
dl_se->dl_throttled = 0;
dl_se->dl_new = 1;
@@ -3647,6 +3648,7 @@ __setparam_dl(struct task_struct *p, con
dl_se->dl_period = attr->sched_period ?: dl_se->dl_deadline;
dl_se->flags = attr->sched_flags;
dl_se->dl_bw = to_ratio(dl_se->dl_period, dl_se->dl_runtime);
+ dl_se->dl_density = to_ratio(dl_se->dl_deadline, dl_se->dl_runtime);
/*
* Changing the parameters of a task is 'tricky' and we're not doing
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -480,13 +480,84 @@ static bool dl_entity_overflow(struct sc
}
/*
- * When a -deadline entity is queued back on the runqueue, its runtime and
- * deadline might need updating.
+ * Revised wakeup rule [1]: For self-suspending tasks, rather then
+ * re-initializing task's runtime and deadline, the revised wakeup
+ * rule adjusts the task's runtime to avoid the task to overrun its
+ * density.
*
- * The policy here is that we update the deadline of the entity only if:
- * - the current deadline is in the past,
- * - using the remaining runtime with the current deadline would make
- * the entity exceed its bandwidth.
+ * Reasoning: a task may overrun the density if:
+ * runtime / (deadline - t) > dl_runtime / dl_deadline
+ *
+ * Therefore, runtime can be adjusted to:
+ * runtime = (dl_runtime / dl_deadline) * (deadline - t)
+ *
+ * In such way that runtime will be equal to the maximum density
+ * the task can use without breaking any rule.
+ *
+ * [1] Luca Abeni, Giuseppe Lipari, and Juri Lelli. 2015. Constant
+ * bandwidth server revisited. SIGBED Rev. 11, 4 (January 2015), 19-24.
+ */
+static void
+update_dl_revised_wakeup(struct sched_dl_entity *dl_se, struct rq *rq)
+{
+ u64 laxity = dl_se->deadline - rq_clock(rq);
+
+ /*
+ * If the task has deadline < period, and the deadline is in the past,
+ * it should already be throttled before this check.
+ *
+ * See update_dl_entity() comments for further details.
+ */
+ WARN_ON(dl_time_before(dl_se->deadline, rq_clock(rq)));
+
+ dl_se->runtime = (dl_se->dl_density * laxity) >> 20;
+}
+
+/*
+ * Regarding the deadline, a task with implicit deadline has a relative
+ * deadline == relative period. A task with constrained deadline has a
+ * relative deadline <= relative period.
+ *
+ * We support constrained deadline tasks. However, there are some restrictions
+ * applied only for tasks which do not have an implicit deadline. See
+ * update_dl_entity() to know more about such restrictions.
+ *
+ * The dl_is_implicit() returns true if the task has an implicit deadline.
+ */
+static inline bool dl_is_implicit(struct sched_dl_entity *dl_se)
+{
+ return dl_se->dl_deadline == dl_se->dl_period;
+}
+
+/*
+ * When a deadline entity is placed in the runqueue, its runtime and deadline
+ * might need to be updated. This is done by a CBS wake up rule. There are two
+ * different rules: 1) the original CBS; and 2) the Revisited CBS.
+ *
+ * When the task is starting a new period, the Original CBS is used. In this
+ * case, the runtime is replenished and a new absolute deadline is set.
+ *
+ * When a task is queued before the begin of the next period, using the
+ * remaining runtime and deadline could make the entity to overflow, see
+ * dl_entity_overflow() to find more about runtime overflow. When such case
+ * is detected, the runtime and deadline need to be updated.
+ *
+ * If the task has an implicit deadline, i.e., deadline == period, the Original
+ * CBS is applied. the runtime is replenished and a new absolute deadline is
+ * set, as in the previous cases.
+ *
+ * However, the Original CBS does not work properly for tasks with
+ * deadline < period, which are said to have a constrained deadline. By
+ * applying the Original CBS, a constrained deadline task would be able to run
+ * runtime/deadline in a period. With deadline < period, the task would
+ * overrun the runtime/period allowed bandwidth, breaking the admission test.
+ *
+ * In order to prevent this misbehave, the Revisited CBS is used for
+ * constrained deadline tasks when a runtime overflow is detected. In the
+ * Revisited CBS, rather than replenishing & setting a new absolute deadline,
+ * the remaining runtime of the task is reduced to avoid runtime overflow.
+ * Please refer to the comments update_dl_revised_wakeup() function to find
+ * more about the Revised CBS rule.
*/
static void update_dl_entity(struct sched_dl_entity *dl_se,
struct sched_dl_entity *pi_se)
@@ -505,6 +576,14 @@ static void update_dl_entity(struct sche
if (dl_time_before(dl_se->deadline, rq_clock(rq)) ||
dl_entity_overflow(dl_se, pi_se, rq_clock(rq))) {
+
+ if (unlikely(!dl_is_implicit(dl_se) &&
+ !dl_time_before(dl_se->deadline, rq_clock(rq)) &&
+ !dl_se->dl_boosted)){
+ update_dl_revised_wakeup(dl_se, rq);
+ return;
+ }
+
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}
@@ -991,11 +1070,6 @@ static void dequeue_dl_entity(struct sch
__dequeue_dl_entity(dl_se);
}
-static inline bool dl_is_constrained(struct sched_dl_entity *dl_se)
-{
- return dl_se->dl_deadline < dl_se->dl_period;
-}
-
static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags)
{
struct task_struct *pi_task = rt_mutex_get_top_task(p);
@@ -1027,7 +1101,7 @@ static void enqueue_task_dl(struct rq *r
* If that is the case, the task will be throttled and
* the replenishment timer will be set to the next period.
*/
- if (!p->dl.dl_throttled && dl_is_constrained(&p->dl))
+ if (!p->dl.dl_throttled && !dl_is_implicit(&p->dl))
dl_check_constrained_dl(&p->dl);
/*
Patches currently in stable-queue which might be from bristot(a)redhat.com are
queue-4.4/sched-deadline-use-the-revised-wakeup-rule-for-suspending-constrained-dl-tasks.patch
This is a note to let you know that I've just added the patch titled
x86/retpoline: Fill RSB on context switch for affected CPUs
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c995efd5a740d9cbafbf58bde4973e8b50b4d761 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Fri, 12 Jan 2018 17:49:25 +0000
Subject: x86/retpoline: Fill RSB on context switch for affected CPUs
From: David Woodhouse <dwmw(a)amazon.co.uk>
commit c995efd5a740d9cbafbf58bde4973e8b50b4d761 upstream.
On context switch from a shallow call stack to a deeper one, as the CPU
does 'ret' up the deeper side it may encounter RSB entries (predictions for
where the 'ret' goes to) which were populated in userspace.
This is problematic if neither SMEP nor KPTI (the latter of which marks
userspace pages as NX for the kernel) are active, as malicious code in
userspace may then be executed speculatively.
Overwrite the CPU's return prediction stack with calls which are predicted
to return to an infinite loop, to "capture" speculation if this
happens. This is required both for retpoline, and also in conjunction with
IBRS for !SMEP && !KPTI.
On Skylake+ the problem is slightly different, and an *underflow* of the
RSB may cause errant branch predictions to occur. So there it's not so much
overwrite, as *filling* the RSB to attempt to prevent it getting
empty. This is only a partial solution for Skylake+ since there are many
other conditions which may result in the RSB becoming empty. The full
solution on Skylake+ is to use IBRS, which will prevent the problem even
when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
required on context switch.
[ tglx: Added missing vendor check and slighty massaged comments and
changelog ]
[js] backport to 4.4 -- __switch_to_asm does not exist there, we
have to patch the switch_to macros for both x86_32 and x86_64.
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: thomas.lendacky(a)amd.com
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Jiri Kosina <jikos(a)kernel.org>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Kees Cook <keescook(a)google.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linux-foundation.org>
Cc: Paul Turner <pjt(a)google.com>
Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/include/asm/switch_to.h | 38 ++++++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/bugs.c | 36 ++++++++++++++++++++++++++++++++++++
3 files changed, 75 insertions(+)
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -199,6 +199,7 @@
#define X86_FEATURE_HWP_EPP ( 7*32+13) /* Intel HWP_EPP */
#define X86_FEATURE_HWP_PKG_REQ ( 7*32+14) /* Intel HWP_PKG_REQ */
#define X86_FEATURE_INTEL_PT ( 7*32+15) /* Intel Processor Trace */
+#define X86_FEATURE_RSB_CTXSW ( 7*32+19) /* Fill RSB on context switches */
#define X86_FEATURE_RETPOLINE ( 7*32+29) /* Generic Retpoline mitigation for Spectre variant 2 */
#define X86_FEATURE_RETPOLINE_AMD ( 7*32+30) /* AMD Retpoline mitigation for Spectre variant 2 */
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -1,6 +1,8 @@
#ifndef _ASM_X86_SWITCH_TO_H
#define _ASM_X86_SWITCH_TO_H
+#include <asm/nospec-branch.h>
+
struct task_struct; /* one of the stranger aspects of C forward declarations */
__visible struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *next);
@@ -24,6 +26,23 @@ void __switch_to_xtra(struct task_struct
#define __switch_canary_iparam
#endif /* CC_STACKPROTECTOR */
+#ifdef CONFIG_RETPOLINE
+ /*
+ * When switching from a shallower to a deeper call stack
+ * the RSB may either underflow or use entries populated
+ * with userspace addresses. On CPUs where those concerns
+ * exist, overwrite the RSB with entries which capture
+ * speculative execution to prevent attack.
+ */
+#define __retpoline_fill_return_buffer \
+ ALTERNATIVE("jmp 910f", \
+ __stringify(__FILL_RETURN_BUFFER(%%ebx, RSB_CLEAR_LOOPS, %%esp)),\
+ X86_FEATURE_RSB_CTXSW) \
+ "910:\n\t"
+#else
+#define __retpoline_fill_return_buffer
+#endif
+
/*
* Saving eflags is important. It switches not only IOPL between tasks,
* it also protects other tasks from NT leaking through sysenter etc.
@@ -46,6 +65,7 @@ do { \
"movl $1f,%[prev_ip]\n\t" /* save EIP */ \
"pushl %[next_ip]\n\t" /* restore EIP */ \
__switch_canary \
+ __retpoline_fill_return_buffer \
"jmp __switch_to\n" /* regparm call */ \
"1:\t" \
"popl %%ebp\n\t" /* restore EBP */ \
@@ -100,6 +120,23 @@ do { \
#define __switch_canary_iparam
#endif /* CC_STACKPROTECTOR */
+#ifdef CONFIG_RETPOLINE
+ /*
+ * When switching from a shallower to a deeper call stack
+ * the RSB may either underflow or use entries populated
+ * with userspace addresses. On CPUs where those concerns
+ * exist, overwrite the RSB with entries which capture
+ * speculative execution to prevent attack.
+ */
+#define __retpoline_fill_return_buffer \
+ ALTERNATIVE("jmp 910f", \
+ __stringify(__FILL_RETURN_BUFFER(%%r12, RSB_CLEAR_LOOPS, %%rsp)),\
+ X86_FEATURE_RSB_CTXSW) \
+ "910:\n\t"
+#else
+#define __retpoline_fill_return_buffer
+#endif
+
/*
* There is no need to save or restore flags, because flags are always
* clean in kernel mode, with the possible exception of IOPL. Kernel IOPL
@@ -112,6 +149,7 @@ do { \
"call __switch_to\n\t" \
"movq "__percpu_arg([current_task])",%%rsi\n\t" \
__switch_canary \
+ __retpoline_fill_return_buffer \
"movq %P[thread_info](%%rsi),%%r8\n\t" \
"movq %%rax,%%rdi\n\t" \
"testl %[_tif_fork],%P[ti_flags](%%r8)\n\t" \
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -22,6 +22,7 @@
#include <asm/alternative.h>
#include <asm/pgtable.h>
#include <asm/cacheflush.h>
+#include <asm/intel-family.h>
static void __init spectre_v2_select_mitigation(void);
@@ -154,6 +155,23 @@ disable:
return SPECTRE_V2_CMD_NONE;
}
+/* Check for Skylake-like CPUs (for RSB handling) */
+static bool __init is_skylake_era(void)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+ boot_cpu_data.x86 == 6) {
+ switch (boot_cpu_data.x86_model) {
+ case INTEL_FAM6_SKYLAKE_MOBILE:
+ case INTEL_FAM6_SKYLAKE_DESKTOP:
+ case INTEL_FAM6_SKYLAKE_X:
+ case INTEL_FAM6_KABYLAKE_MOBILE:
+ case INTEL_FAM6_KABYLAKE_DESKTOP:
+ return true;
+ }
+ }
+ return false;
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -212,6 +230,24 @@ retpoline_auto:
spectre_v2_enabled = mode;
pr_info("%s\n", spectre_v2_strings[mode]);
+
+ /*
+ * If neither SMEP or KPTI are available, there is a risk of
+ * hitting userspace addresses in the RSB after a context switch
+ * from a shallow call stack to a deeper one. To prevent this fill
+ * the entire RSB, even when using IBRS.
+ *
+ * Skylake era CPUs have a separate issue with *underflow* of the
+ * RSB, when they will predict 'ret' targets from the generic BTB.
+ * The proper mitigation for this is IBRS. If IBRS is not supported
+ * or deactivated in favour of retpolines the RSB fill on context
+ * switch is required.
+ */
+ if ((!boot_cpu_has(X86_FEATURE_KAISER) &&
+ !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Filling RSB on context switch\n");
+ }
}
#undef pr_fmt
Patches currently in stable-queue which might be from dwmw(a)amazon.co.uk are
queue-4.4/x86-retpoline-fill-rsb-on-context-switch-for-affected-cpus.patch
This is a note to let you know that I've just added the patch titled
x86/cpu/intel: Introduce macros for Intel family numbers
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 970442c599b22ccd644ebfe94d1d303bf6f87c05 Mon Sep 17 00:00:00 2001
From: Dave Hansen <dave(a)sr71.net>
Date: Thu, 2 Jun 2016 17:19:27 -0700
Subject: x86/cpu/intel: Introduce macros for Intel family numbers
From: Dave Hansen <dave(a)sr71.net>
commit 970442c599b22ccd644ebfe94d1d303bf6f87c05 upstream.
Problem:
We have a boatload of open-coded family-6 model numbers. Half of
them have these model numbers in hex and the other half in
decimal. This makes grepping for them tons of fun, if you were
to try.
Solution:
Consolidate all the magic numbers. Put all the definitions in
one header.
The names here are closely derived from the comments describing
the models from arch/x86/events/intel/core.c. We could easily
make them shorter by doing things like s/SANDYBRIDGE/SNB/, but
they seemed fine even with the longer versions to me.
Do not take any of these names too literally, like "DESKTOP"
or "MOBILE". These are all colloquial names and not precise
descriptions of everywhere a given model will show up.
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Darren Hart <dvhart(a)infradead.org>
Cc: Dave Hansen <dave(a)sr71.net>
Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
Cc: Doug Thompson <dougthompson(a)xmission.com>
Cc: Eduardo Valentin <edubezval(a)gmail.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Jacob Pan <jacob.jun.pan(a)linux.intel.com>
Cc: Kan Liang <kan.liang(a)intel.com>
Cc: Len Brown <lenb(a)kernel.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj(a)intel.com>
Cc: Souvik Kumar Chakravarty <souvik.k.chakravarty(a)intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com>
Cc: Stephane Eranian <eranian(a)google.com>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: Ulf Hansson <ulf.hansson(a)linaro.org>
Cc: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: Vishwanath Somayaji <vishwanath.somayaji(a)intel.com>
Cc: Zhang Rui <rui.zhang(a)intel.com>
Cc: jacob.jun.pan(a)intel.com
Cc: linux-acpi(a)vger.kernel.org
Cc: linux-edac(a)vger.kernel.org
Cc: linux-mmc(a)vger.kernel.org
Cc: linux-pm(a)vger.kernel.org
Cc: platform-driver-x86(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Jiri Slaby <jslaby(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/intel-family.h | 68 ++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
--- /dev/null
+++ b/arch/x86/include/asm/intel-family.h
@@ -0,0 +1,68 @@
+#ifndef _ASM_X86_INTEL_FAMILY_H
+#define _ASM_X86_INTEL_FAMILY_H
+
+/*
+ * "Big Core" Processors (Branded as Core, Xeon, etc...)
+ *
+ * The "_X" parts are generally the EP and EX Xeons, or the
+ * "Extreme" ones, like Broadwell-E.
+ *
+ * Things ending in "2" are usually because we have no better
+ * name for them. There's no processor called "WESTMERE2".
+ */
+
+#define INTEL_FAM6_CORE_YONAH 0x0E
+#define INTEL_FAM6_CORE2_MEROM 0x0F
+#define INTEL_FAM6_CORE2_MEROM_L 0x16
+#define INTEL_FAM6_CORE2_PENRYN 0x17
+#define INTEL_FAM6_CORE2_DUNNINGTON 0x1D
+
+#define INTEL_FAM6_NEHALEM 0x1E
+#define INTEL_FAM6_NEHALEM_EP 0x1A
+#define INTEL_FAM6_NEHALEM_EX 0x2E
+#define INTEL_FAM6_WESTMERE 0x25
+#define INTEL_FAM6_WESTMERE2 0x1F
+#define INTEL_FAM6_WESTMERE_EP 0x2C
+#define INTEL_FAM6_WESTMERE_EX 0x2F
+
+#define INTEL_FAM6_SANDYBRIDGE 0x2A
+#define INTEL_FAM6_SANDYBRIDGE_X 0x2D
+#define INTEL_FAM6_IVYBRIDGE 0x3A
+#define INTEL_FAM6_IVYBRIDGE_X 0x3E
+
+#define INTEL_FAM6_HASWELL_CORE 0x3C
+#define INTEL_FAM6_HASWELL_X 0x3F
+#define INTEL_FAM6_HASWELL_ULT 0x45
+#define INTEL_FAM6_HASWELL_GT3E 0x46
+
+#define INTEL_FAM6_BROADWELL_CORE 0x3D
+#define INTEL_FAM6_BROADWELL_XEON_D 0x56
+#define INTEL_FAM6_BROADWELL_GT3E 0x47
+#define INTEL_FAM6_BROADWELL_X 0x4F
+
+#define INTEL_FAM6_SKYLAKE_MOBILE 0x4E
+#define INTEL_FAM6_SKYLAKE_DESKTOP 0x5E
+#define INTEL_FAM6_SKYLAKE_X 0x55
+#define INTEL_FAM6_KABYLAKE_MOBILE 0x8E
+#define INTEL_FAM6_KABYLAKE_DESKTOP 0x9E
+
+/* "Small Core" Processors (Atom) */
+
+#define INTEL_FAM6_ATOM_PINEVIEW 0x1C
+#define INTEL_FAM6_ATOM_LINCROFT 0x26
+#define INTEL_FAM6_ATOM_PENWELL 0x27
+#define INTEL_FAM6_ATOM_CLOVERVIEW 0x35
+#define INTEL_FAM6_ATOM_CEDARVIEW 0x36
+#define INTEL_FAM6_ATOM_SILVERMONT1 0x37 /* BayTrail/BYT / Valleyview */
+#define INTEL_FAM6_ATOM_SILVERMONT2 0x4D /* Avaton/Rangely */
+#define INTEL_FAM6_ATOM_AIRMONT 0x4C /* CherryTrail / Braswell */
+#define INTEL_FAM6_ATOM_MERRIFIELD1 0x4A /* Tangier */
+#define INTEL_FAM6_ATOM_MERRIFIELD2 0x5A /* Annidale */
+#define INTEL_FAM6_ATOM_GOLDMONT 0x5C
+#define INTEL_FAM6_ATOM_DENVERTON 0x5F /* Goldmont Microserver */
+
+/* Xeon Phi */
+
+#define INTEL_FAM6_XEON_PHI_KNL 0x57 /* Knights Landing */
+
+#endif /* _ASM_X86_INTEL_FAMILY_H */
Patches currently in stable-queue which might be from dave(a)sr71.net are
queue-4.4/x86-cpu-intel-introduce-macros-for-intel-family-numbers.patch
The backport of commit b94b73733171 ("x86/microcode/intel: Extend BDW
late-loading with a revision check") to 4.4-stable deleted a "return true"
statement. This bug is not present upstream or other stable branches.
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
arch/x86/kernel/cpu/microcode/intel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index b428a8174be1..ee011bd7934d 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -1005,6 +1005,7 @@ static bool is_blacklisted(unsigned int cpu)
c->microcode < 0x0b000021) {
pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode);
pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
+ return true;
}
return false;
--
2.15.0.rc0
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From c995efd5a740d9cbafbf58bde4973e8b50b4d761 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw(a)amazon.co.uk>
Date: Fri, 12 Jan 2018 17:49:25 +0000
Subject: [PATCH] x86/retpoline: Fill RSB on context switch for affected CPUs
On context switch from a shallow call stack to a deeper one, as the CPU
does 'ret' up the deeper side it may encounter RSB entries (predictions for
where the 'ret' goes to) which were populated in userspace.
This is problematic if neither SMEP nor KPTI (the latter of which marks
userspace pages as NX for the kernel) are active, as malicious code in
userspace may then be executed speculatively.
Overwrite the CPU's return prediction stack with calls which are predicted
to return to an infinite loop, to "capture" speculation if this
happens. This is required both for retpoline, and also in conjunction with
IBRS for !SMEP && !KPTI.
On Skylake+ the problem is slightly different, and an *underflow* of the
RSB may cause errant branch predictions to occur. So there it's not so much
overwrite, as *filling* the RSB to attempt to prevent it getting
empty. This is only a partial solution for Skylake+ since there are many
other conditions which may result in the RSB becoming empty. The full
solution on Skylake+ is to use IBRS, which will prevent the problem even
when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
required on context switch.
[ tglx: Added missing vendor check and slighty massaged comments and
changelog ]
Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Acked-by: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: gnomes(a)lxorguk.ukuu.org.uk
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: thomas.lendacky(a)amd.com
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Jiri Kosina <jikos(a)kernel.org>
Cc: Andy Lutomirski <luto(a)amacapital.net>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Kees Cook <keescook(a)google.com>
Cc: Tim Chen <tim.c.chen(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linux-foundation.org>
Cc: Paul Turner <pjt(a)google.com>
Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-dwmw@amazon.co.uk
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index a1f28a54f23a..60c4c342316c 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -244,6 +244,17 @@ ENTRY(__switch_to_asm)
movl %ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
#endif
+#ifdef CONFIG_RETPOLINE
+ /*
+ * When switching from a shallower to a deeper call stack
+ * the RSB may either underflow or use entries populated
+ * with userspace addresses. On CPUs where those concerns
+ * exist, overwrite the RSB with entries which capture
+ * speculative execution to prevent attack.
+ */
+ FILL_RETURN_BUFFER %ebx, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW
+#endif
+
/* restore callee-saved registers */
popl %esi
popl %edi
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 59874bc1aed2..d54a0ede61d1 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -487,6 +487,17 @@ ENTRY(__switch_to_asm)
movq %rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
#endif
+#ifdef CONFIG_RETPOLINE
+ /*
+ * When switching from a shallower to a deeper call stack
+ * the RSB may either underflow or use entries populated
+ * with userspace addresses. On CPUs where those concerns
+ * exist, overwrite the RSB with entries which capture
+ * speculative execution to prevent attack.
+ */
+ FILL_RETURN_BUFFER %r12, RSB_CLEAR_LOOPS, X86_FEATURE_RSB_CTXSW
+#endif
+
/* restore callee-saved registers */
popq %r15
popq %r14
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index f275447862f4..aa09559b2c0b 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -211,6 +211,7 @@
#define X86_FEATURE_AVX512_4FMAPS ( 7*32+17) /* AVX-512 Multiply Accumulation Single precision */
#define X86_FEATURE_MBA ( 7*32+18) /* Memory Bandwidth Allocation */
+#define X86_FEATURE_RSB_CTXSW ( 7*32+19) /* Fill RSB on context switches */
/* Virtualization flags: Linux defined, word 8 */
#define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index e4dc26185aa7..390b3dc3d438 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -23,6 +23,7 @@
#include <asm/alternative.h>
#include <asm/pgtable.h>
#include <asm/set_memory.h>
+#include <asm/intel-family.h>
static void __init spectre_v2_select_mitigation(void);
@@ -155,6 +156,23 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
return SPECTRE_V2_CMD_NONE;
}
+/* Check for Skylake-like CPUs (for RSB handling) */
+static bool __init is_skylake_era(void)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+ boot_cpu_data.x86 == 6) {
+ switch (boot_cpu_data.x86_model) {
+ case INTEL_FAM6_SKYLAKE_MOBILE:
+ case INTEL_FAM6_SKYLAKE_DESKTOP:
+ case INTEL_FAM6_SKYLAKE_X:
+ case INTEL_FAM6_KABYLAKE_MOBILE:
+ case INTEL_FAM6_KABYLAKE_DESKTOP:
+ return true;
+ }
+ }
+ return false;
+}
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -213,6 +231,24 @@ static void __init spectre_v2_select_mitigation(void)
spectre_v2_enabled = mode;
pr_info("%s\n", spectre_v2_strings[mode]);
+
+ /*
+ * If neither SMEP or KPTI are available, there is a risk of
+ * hitting userspace addresses in the RSB after a context switch
+ * from a shallow call stack to a deeper one. To prevent this fill
+ * the entire RSB, even when using IBRS.
+ *
+ * Skylake era CPUs have a separate issue with *underflow* of the
+ * RSB, when they will predict 'ret' targets from the generic BTB.
+ * The proper mitigation for this is IBRS. If IBRS is not supported
+ * or deactivated in favour of retpolines the RSB fill on context
+ * switch is required.
+ */
+ if ((!boot_cpu_has(X86_FEATURE_PTI) &&
+ !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
+ setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+ pr_info("Filling RSB on context switch\n");
+ }
}
#undef pr_fmt
This is a note to let you know that I've just added the patch titled
usbip: prevent vhci_hcd driver from leaking a socket pointer address
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:49 -0700
Subject: usbip: prevent vhci_hcd driver from leaking a socket pointer address
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream.
When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the
/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.
Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from socket
pointer address by looking up /proc/net/{tcp,tcp6}.
As this opens a security hole, the fix replaces socket pointer address with
sockfd.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/usbip_common.h | 1 +
drivers/usb/usbip/vhci_sysfs.c | 25 +++++++++++++++----------
tools/usb/usbip/libsrc/vhci_driver.c | 8 ++++----
3 files changed, 20 insertions(+), 14 deletions(-)
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -271,6 +271,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
+ int sockfd;
struct socket *tcp_socket;
struct task_struct *tcp_rx;
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -49,13 +49,17 @@ static ssize_t status_show_vhci(int pdev
/*
* output example:
- * port sta spd dev socket local_busid
- * 0000 004 000 00000000 c5a7bb80 1-2.3
- * 0001 004 000 00000000 d8cee980 2-3.4
+ * port sta spd dev sockfd local_busid
+ * 0000 004 000 00000000 000003 1-2.3
+ * 0001 004 000 00000000 000004 2-3.4
*
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to
+ * avoid leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was
+ * made visible as a convenient way to find IP address from socket
+ * pointer address by looking up /proc/net/{tcp,tcp6}. As this opens
+ * a security hole, the change is made to use sockfd instead.
*/
for (i = 0; i < VHCI_HC_PORTS; i++) {
struct vhci_device *vdev = &vhci->vdev[i];
@@ -68,13 +72,13 @@ static ssize_t status_show_vhci(int pdev
if (vdev->ud.status == VDEV_ST_USED) {
out += sprintf(out, "%03u %08x ",
vdev->speed, vdev->devid);
- out += sprintf(out, "%16p %s",
- vdev->ud.tcp_socket,
+ out += sprintf(out, "%06u %s",
+ vdev->ud.sockfd,
dev_name(&vdev->udev->dev));
} else {
out += sprintf(out, "000 00000000 ");
- out += sprintf(out, "0000000000000000 0-0");
+ out += sprintf(out, "000000 0-0");
}
out += sprintf(out, "\n");
@@ -125,7 +129,7 @@ static ssize_t status_show(struct device
int pdev_nr;
out += sprintf(out,
- "port sta spd dev socket local_busid\n");
+ "port sta spd dev sockfd local_busid\n");
pdev_nr = status_name_to_id(attr->attr.name);
if (pdev_nr < 0)
@@ -324,6 +328,7 @@ static ssize_t store_attach(struct devic
vdev->devid = devid;
vdev->speed = speed;
+ vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -55,12 +55,12 @@ static int parse_status(const char *valu
while (*c != '\0') {
int port, status, speed, devid;
- unsigned long socket;
+ int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
- ret = sscanf(c, "%d %d %d %x %lx %31s\n",
+ ret = sscanf(c, "%d %d %d %x %u %31s\n",
&port, &status, &speed,
- &devid, &socket, lbusid);
+ &devid, &sockfd, lbusid);
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -69,7 +69,7 @@ static int parse_status(const char *valu
dbg("port %d status %d speed %d devid %x",
port, status, speed, devid);
- dbg("socket %lx lbusid %s", socket, lbusid);
+ dbg("sockfd %u lbusid %s", sockfd, lbusid);
/* if a device is connected, look at it */
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.9/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-4.9/usbip-fix-implicit-fallthrough-warning.patch
queue-4.9/usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
This is a note to let you know that I've just added the patch titled
usbip: Fix potential format overflow in userspace tools
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-potential-format-overflow-in-userspace-tools.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e5dfa3f902b9a642ae8c6997d57d7c41e384a90b Mon Sep 17 00:00:00 2001
From: Jonathan Dieter <jdieter(a)lesbg.com>
Date: Mon, 27 Feb 2017 10:31:03 +0200
Subject: usbip: Fix potential format overflow in userspace tools
From: Jonathan Dieter <jdieter(a)lesbg.com>
commit e5dfa3f902b9a642ae8c6997d57d7c41e384a90b upstream.
The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.
More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.
This patch fixes these problems by replacing sprintf() with snprintf() in
one place and adding checks for the return value of snprintf().
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/libsrc/usbip_common.c | 9 ++++++++-
tools/usb/usbip/libsrc/usbip_host_common.c | 28 +++++++++++++++++++++++-----
2 files changed, 31 insertions(+), 6 deletions(-)
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,16 @@ int read_usb_interface(struct usbip_usb_
struct usbip_usb_interface *uinf)
{
char busid[SYSFS_BUS_ID_SIZE];
+ int size;
struct udev_device *sif;
- sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
+ size = snprintf(busid, sizeof(busid), "%s:%d.%d",
+ udev->busid, udev->bConfigurationValue, i);
+ if (size < 0 || (unsigned int)size >= sizeof(busid)) {
+ err("busid length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(busid));
+ return -1;
+ }
sif = udev_device_new_from_subsystem_sysname(udev_context, "usb", busid);
if (!sif) {
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -40,13 +40,20 @@ struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
char status_attr_path[SYSFS_PATH_MAX];
+ int size;
int fd;
int length;
char status;
int value = 0;
- snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
- udev->path);
+ size = snprintf(status_attr_path, sizeof(status_attr_path),
+ "%s/usbip_status", udev->path);
+ if (size < 0 || (unsigned int)size >= sizeof(status_attr_path)) {
+ err("usbip_status path length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(status_attr_path));
+ return -1;
+ }
+
fd = open(status_attr_path, O_RDONLY);
if (fd < 0) {
@@ -218,6 +225,7 @@ int usbip_export_device(struct usbip_exp
{
char attr_name[] = "usbip_sockfd";
char sockfd_attr_path[SYSFS_PATH_MAX];
+ int size;
char sockfd_buff[30];
int ret;
@@ -237,10 +245,20 @@ int usbip_export_device(struct usbip_exp
}
/* only the first interface is true */
- snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
- edev->udev.path, attr_name);
+ size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
+ edev->udev.path, attr_name);
+ if (size < 0 || (unsigned int)size >= sizeof(sockfd_attr_path)) {
+ err("exported device path length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(sockfd_attr_path));
+ return -1;
+ }
- snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+ size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+ if (size < 0 || (unsigned int)size >= sizeof(sockfd_buff)) {
+ err("socket length %i >= %lu or < 0", size,
+ (long unsigned)sizeof(sockfd_buff));
+ return -1;
+ }
ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
strlen(sockfd_buff));
Patches currently in stable-queue which might be from jdieter(a)lesbg.com are
queue-4.9/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-4.9/usbip-fix-implicit-fallthrough-warning.patch
This is a note to let you know that I've just added the patch titled
orangefs: use list_for_each_entry_safe in purge_waiting_ops
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
orangefs-use-list_for_each_entry_safe-in-purge_waiting_ops.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0afc0decf247f65b7aba666a76a0a68adf4bc435 Mon Sep 17 00:00:00 2001
From: Martin Brandenburg <martin(a)omnibond.com>
Date: Mon, 22 Jan 2018 15:44:51 -0500
Subject: orangefs: use list_for_each_entry_safe in purge_waiting_ops
From: Martin Brandenburg <martin(a)omnibond.com>
commit 0afc0decf247f65b7aba666a76a0a68adf4bc435 upstream.
set_op_state_purged can delete the op.
Signed-off-by: Martin Brandenburg <martin(a)omnibond.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/orangefs/waitqueue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/orangefs/waitqueue.c
+++ b/fs/orangefs/waitqueue.c
@@ -28,10 +28,10 @@ static void orangefs_clean_up_interrupte
*/
void purge_waiting_ops(void)
{
- struct orangefs_kernel_op_s *op;
+ struct orangefs_kernel_op_s *op, *tmp;
spin_lock(&orangefs_request_list_lock);
- list_for_each_entry(op, &orangefs_request_list, list) {
+ list_for_each_entry_safe(op, tmp, &orangefs_request_list, list) {
gossip_debug(GOSSIP_WAIT_DEBUG,
"pvfs2-client-core: purging op tag %llu %s\n",
llu(op->tag),
Patches currently in stable-queue which might be from martin(a)omnibond.com are
queue-4.9/orangefs-initialize-op-on-loop-restart-in-orangefs_devreq_read.patch
queue-4.9/orangefs-use-list_for_each_entry_safe-in-purge_waiting_ops.patch
This is a note to let you know that I've just added the patch titled
usbip: Fix implicit fallthrough warning
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-implicit-fallthrough-warning.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 Mon Sep 17 00:00:00 2001
From: Jonathan Dieter <jdieter(a)lesbg.com>
Date: Mon, 27 Feb 2017 10:31:04 +0200
Subject: usbip: Fix implicit fallthrough warning
From: Jonathan Dieter <jdieter(a)lesbg.com>
commit cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 upstream.
GCC 7 now warns when switch statements fall through implicitly, and with
-Werror enabled in configure.ac, that makes these tools unbuildable.
We fix this by notifying the compiler that this particular case statement
is meant to fall through.
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/src/usbip.c | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -176,6 +176,8 @@ int main(int argc, char *argv[])
break;
case '?':
printf("usbip: invalid option\n");
+ /* Terminate after printing error */
+ /* FALLTHRU */
default:
usbip_usage();
goto out;
Patches currently in stable-queue which might be from jdieter(a)lesbg.com are
queue-4.9/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-4.9/usbip-fix-implicit-fallthrough-warning.patch
This is a note to let you know that I've just added the patch titled
orangefs: initialize op on loop restart in orangefs_devreq_read
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
orangefs-initialize-op-on-loop-restart-in-orangefs_devreq_read.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a0ec1ded22e6a6bc41981fae22406835b006a66e Mon Sep 17 00:00:00 2001
From: Martin Brandenburg <martin(a)omnibond.com>
Date: Mon, 22 Jan 2018 15:44:52 -0500
Subject: orangefs: initialize op on loop restart in orangefs_devreq_read
From: Martin Brandenburg <martin(a)omnibond.com>
commit a0ec1ded22e6a6bc41981fae22406835b006a66e upstream.
In orangefs_devreq_read, there is a loop which picks an op off the list
of pending ops. If the loop fails to find an op, there is nothing to
read, and it returns EAGAIN. If the op has been given up on, the loop
is restarted via a goto. The bug is that the variable which the found
op is written to is not reinitialized, so if there are no more eligible
ops on the list, the code runs again on the already handled op.
This is triggered by interrupting a process while the op is being copied
to the client-core. It's a fairly small window, but it's there.
Signed-off-by: Martin Brandenburg <martin(a)omnibond.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/orangefs/devorangefs-req.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/orangefs/devorangefs-req.c
+++ b/fs/orangefs/devorangefs-req.c
@@ -161,7 +161,7 @@ static ssize_t orangefs_devreq_read(stru
struct orangefs_kernel_op_s *op, *temp;
__s32 proto_ver = ORANGEFS_KERNEL_PROTO_VERSION;
static __s32 magic = ORANGEFS_DEVREQ_MAGIC;
- struct orangefs_kernel_op_s *cur_op = NULL;
+ struct orangefs_kernel_op_s *cur_op;
unsigned long ret;
/* We do not support blocking IO. */
@@ -181,6 +181,7 @@ static ssize_t orangefs_devreq_read(stru
}
restart:
+ cur_op = NULL;
/* Get next op (if any) from top of list. */
spin_lock(&orangefs_request_list_lock);
list_for_each_entry_safe(op, temp, &orangefs_request_list, list) {
Patches currently in stable-queue which might be from martin(a)omnibond.com are
queue-4.9/orangefs-initialize-op-on-loop-restart-in-orangefs_devreq_read.patch
queue-4.9/orangefs-use-list_for_each_entry_safe-in-purge_waiting_ops.patch
This is a note to let you know that I've just added the patch titled
usbip: prevent vhci_hcd driver from leaking a socket pointer address
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 Mon Sep 17 00:00:00 2001
From: Shuah Khan <shuahkh(a)osg.samsung.com>
Date: Thu, 7 Dec 2017 14:16:49 -0700
Subject: usbip: prevent vhci_hcd driver from leaking a socket pointer address
From: Shuah Khan <shuahkh(a)osg.samsung.com>
commit 2f2d0088eb93db5c649d2a5e34a3800a8a935fc5 upstream.
When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the
/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.
Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from socket
pointer address by looking up /proc/net/{tcp,tcp6}.
As this opens a security hole, the fix replaces socket pointer address with
sockfd.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/usbip/usbip_common.h | 1 +
drivers/usb/usbip/vhci_sysfs.c | 25 +++++++++++++++----------
tools/usb/usbip/libsrc/vhci_driver.c | 8 ++++----
3 files changed, 20 insertions(+), 14 deletions(-)
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -261,6 +261,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
+ int sockfd;
struct socket *tcp_socket;
struct task_struct *tcp_rx;
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -39,16 +39,20 @@ static ssize_t status_show(struct device
/*
* output example:
- * prt sta spd dev socket local_busid
- * 000 004 000 000 c5a7bb80 1-2.3
- * 001 004 000 000 d8cee980 2-3.4
+ * port sta spd dev sockfd local_busid
+ * 0000 004 000 00000000 000003 1-2.3
+ * 0001 004 000 00000000 000004 2-3.4
*
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to
+ * avoid leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was
+ * made visible as a convenient way to find IP address from socket
+ * pointer address by looking up /proc/net/{tcp,tcp6}. As this opens
+ * a security hole, the change is made to use sockfd instead.
*/
out += sprintf(out,
- "prt sta spd bus dev socket local_busid\n");
+ "prt sta spd bus dev sockfd local_busid\n");
for (i = 0; i < VHCI_NPORTS; i++) {
struct vhci_device *vdev = port_to_vdev(i);
@@ -60,11 +64,11 @@ static ssize_t status_show(struct device
out += sprintf(out, "%03u %08x ",
vdev->speed, vdev->devid);
out += sprintf(out, "%16p ", vdev->ud.tcp_socket);
+ out += sprintf(out, "%06u", vdev->ud.sockfd);
out += sprintf(out, "%s", dev_name(&vdev->udev->dev));
- } else {
- out += sprintf(out, "000 000 000 0000000000000000 0-0");
- }
+ } else
+ out += sprintf(out, "000 000 000 000000 0-0");
out += sprintf(out, "\n");
spin_unlock(&vdev->ud.lock);
@@ -223,6 +227,7 @@ static ssize_t store_attach(struct devic
vdev->devid = devid;
vdev->speed = speed;
+ vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -55,12 +55,12 @@ static int parse_status(const char *valu
while (*c != '\0') {
int port, status, speed, devid;
- unsigned long socket;
+ int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
- ret = sscanf(c, "%d %d %d %x %lx %31s\n",
+ ret = sscanf(c, "%d %d %d %x %u %31s\n",
&port, &status, &speed,
- &devid, &socket, lbusid);
+ &devid, &sockfd, lbusid);
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -69,7 +69,7 @@ static int parse_status(const char *valu
dbg("port %d status %d speed %d devid %x",
port, status, speed, devid);
- dbg("socket %lx lbusid %s", socket, lbusid);
+ dbg("sockfd %u lbusid %s", sockfd, lbusid);
/* if a device is connected, look at it */
Patches currently in stable-queue which might be from shuahkh(a)osg.samsung.com are
queue-4.4/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-4.4/usbip-fix-implicit-fallthrough-warning.patch
queue-4.4/usbip-prevent-vhci_hcd-driver-from-leaking-a-socket-pointer-address.patch
This is a note to let you know that I've just added the patch titled
usbip: Fix potential format overflow in userspace tools
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-potential-format-overflow-in-userspace-tools.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e5dfa3f902b9a642ae8c6997d57d7c41e384a90b Mon Sep 17 00:00:00 2001
From: Jonathan Dieter <jdieter(a)lesbg.com>
Date: Mon, 27 Feb 2017 10:31:03 +0200
Subject: usbip: Fix potential format overflow in userspace tools
From: Jonathan Dieter <jdieter(a)lesbg.com>
commit e5dfa3f902b9a642ae8c6997d57d7c41e384a90b upstream.
The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.
More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.
This patch fixes these problems by replacing sprintf() with snprintf() in
one place and adding checks for the return value of snprintf().
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Acked-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/libsrc/usbip_common.c | 9 ++++++++-
tools/usb/usbip/libsrc/usbip_host_driver.c | 27 ++++++++++++++++++++++-----
2 files changed, 30 insertions(+), 6 deletions(-)
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,16 @@ int read_usb_interface(struct usbip_usb_
struct usbip_usb_interface *uinf)
{
char busid[SYSFS_BUS_ID_SIZE];
+ int size;
struct udev_device *sif;
- sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
+ size = snprintf(busid, sizeof(busid), "%s:%d.%d",
+ udev->busid, udev->bConfigurationValue, i);
+ if (size < 0 || (unsigned int)size >= sizeof(busid)) {
+ err("busid length %i >= %lu or < 0", size,
+ (unsigned long)sizeof(busid));
+ return -1;
+ }
sif = udev_device_new_from_subsystem_sysname(udev_context, "usb", busid);
if (!sif) {
--- a/tools/usb/usbip/libsrc/usbip_host_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_host_driver.c
@@ -39,13 +39,19 @@ struct udev *udev_context;
static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
{
char status_attr_path[SYSFS_PATH_MAX];
+ int size;
int fd;
int length;
char status;
int value = 0;
- snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
- udev->path);
+ size = snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
+ udev->path);
+ if (size < 0 || (unsigned int)size >= sizeof(status_attr_path)) {
+ err("usbip_status path length %i >= %lu or < 0", size,
+ (unsigned long)sizeof(status_attr_path));
+ return -1;
+ }
fd = open(status_attr_path, O_RDONLY);
if (fd < 0) {
@@ -225,6 +231,7 @@ int usbip_host_export_device(struct usbi
{
char attr_name[] = "usbip_sockfd";
char sockfd_attr_path[SYSFS_PATH_MAX];
+ int size;
char sockfd_buff[30];
int ret;
@@ -244,10 +251,20 @@ int usbip_host_export_device(struct usbi
}
/* only the first interface is true */
- snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
- edev->udev.path, attr_name);
+ size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
+ edev->udev.path, attr_name);
+ if (size < 0 || (unsigned int)size >= sizeof(sockfd_attr_path)) {
+ err("exported device path length %i >= %lu or < 0", size,
+ (unsigned long)sizeof(sockfd_attr_path));
+ return -1;
+ }
- snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+ size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+ if (size < 0 || (unsigned int)size >= sizeof(sockfd_buff)) {
+ err("socket length %i >= %lu or < 0", size,
+ (unsigned long)sizeof(sockfd_buff));
+ return -1;
+ }
ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
strlen(sockfd_buff));
Patches currently in stable-queue which might be from jdieter(a)lesbg.com are
queue-4.4/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-4.4/usbip-fix-implicit-fallthrough-warning.patch
This is a note to let you know that I've just added the patch titled
usbip: Fix implicit fallthrough warning
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-implicit-fallthrough-warning.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 Mon Sep 17 00:00:00 2001
From: Jonathan Dieter <jdieter(a)lesbg.com>
Date: Mon, 27 Feb 2017 10:31:04 +0200
Subject: usbip: Fix implicit fallthrough warning
From: Jonathan Dieter <jdieter(a)lesbg.com>
commit cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 upstream.
GCC 7 now warns when switch statements fall through implicitly, and with
-Werror enabled in configure.ac, that makes these tools unbuildable.
We fix this by notifying the compiler that this particular case statement
is meant to fall through.
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/src/usbip.c | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -176,6 +176,8 @@ int main(int argc, char *argv[])
break;
case '?':
printf("usbip: invalid option\n");
+ /* Terminate after printing error */
+ /* FALLTHRU */
default:
usbip_usage();
goto out;
Patches currently in stable-queue which might be from jdieter(a)lesbg.com are
queue-4.4/usbip-fix-potential-format-overflow-in-userspace-tools.patch
queue-4.4/usbip-fix-implicit-fallthrough-warning.patch
This is a note to let you know that I've just added the patch titled
orangefs: initialize op on loop restart in orangefs_devreq_read
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
orangefs-initialize-op-on-loop-restart-in-orangefs_devreq_read.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a0ec1ded22e6a6bc41981fae22406835b006a66e Mon Sep 17 00:00:00 2001
From: Martin Brandenburg <martin(a)omnibond.com>
Date: Mon, 22 Jan 2018 15:44:52 -0500
Subject: orangefs: initialize op on loop restart in orangefs_devreq_read
From: Martin Brandenburg <martin(a)omnibond.com>
commit a0ec1ded22e6a6bc41981fae22406835b006a66e upstream.
In orangefs_devreq_read, there is a loop which picks an op off the list
of pending ops. If the loop fails to find an op, there is nothing to
read, and it returns EAGAIN. If the op has been given up on, the loop
is restarted via a goto. The bug is that the variable which the found
op is written to is not reinitialized, so if there are no more eligible
ops on the list, the code runs again on the already handled op.
This is triggered by interrupting a process while the op is being copied
to the client-core. It's a fairly small window, but it's there.
Signed-off-by: Martin Brandenburg <martin(a)omnibond.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/orangefs/devorangefs-req.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/orangefs/devorangefs-req.c
+++ b/fs/orangefs/devorangefs-req.c
@@ -162,7 +162,7 @@ static ssize_t orangefs_devreq_read(stru
struct orangefs_kernel_op_s *op, *temp;
__s32 proto_ver = ORANGEFS_KERNEL_PROTO_VERSION;
static __s32 magic = ORANGEFS_DEVREQ_MAGIC;
- struct orangefs_kernel_op_s *cur_op = NULL;
+ struct orangefs_kernel_op_s *cur_op;
unsigned long ret;
/* We do not support blocking IO. */
@@ -186,6 +186,7 @@ static ssize_t orangefs_devreq_read(stru
return -EAGAIN;
restart:
+ cur_op = NULL;
/* Get next op (if any) from top of list. */
spin_lock(&orangefs_request_list_lock);
list_for_each_entry_safe(op, temp, &orangefs_request_list, list) {
Patches currently in stable-queue which might be from martin(a)omnibond.com are
queue-4.14/orangefs-initialize-op-on-loop-restart-in-orangefs_devreq_read.patch
queue-4.14/orangefs-use-list_for_each_entry_safe-in-purge_waiting_ops.patch
This is a note to let you know that I've just added the patch titled
orangefs: use list_for_each_entry_safe in purge_waiting_ops
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
orangefs-use-list_for_each_entry_safe-in-purge_waiting_ops.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0afc0decf247f65b7aba666a76a0a68adf4bc435 Mon Sep 17 00:00:00 2001
From: Martin Brandenburg <martin(a)omnibond.com>
Date: Mon, 22 Jan 2018 15:44:51 -0500
Subject: orangefs: use list_for_each_entry_safe in purge_waiting_ops
From: Martin Brandenburg <martin(a)omnibond.com>
commit 0afc0decf247f65b7aba666a76a0a68adf4bc435 upstream.
set_op_state_purged can delete the op.
Signed-off-by: Martin Brandenburg <martin(a)omnibond.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/orangefs/waitqueue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/orangefs/waitqueue.c
+++ b/fs/orangefs/waitqueue.c
@@ -29,10 +29,10 @@ static void orangefs_clean_up_interrupte
*/
void purge_waiting_ops(void)
{
- struct orangefs_kernel_op_s *op;
+ struct orangefs_kernel_op_s *op, *tmp;
spin_lock(&orangefs_request_list_lock);
- list_for_each_entry(op, &orangefs_request_list, list) {
+ list_for_each_entry_safe(op, tmp, &orangefs_request_list, list) {
gossip_debug(GOSSIP_WAIT_DEBUG,
"pvfs2-client-core: purging op tag %llu %s\n",
llu(op->tag),
Patches currently in stable-queue which might be from martin(a)omnibond.com are
queue-4.14/orangefs-initialize-op-on-loop-restart-in-orangefs_devreq_read.patch
queue-4.14/orangefs-use-list_for_each_entry_safe-in-purge_waiting_ops.patch
From: Jonathan Dieter <jdieter(a)lesbg.com>
Upstream commit cfd6ed4537a9 ("usbip: Fix implicit fallthrough warning")
GCC 7 now warns when switch statements fall through implicitly, and with
-Werror enabled in configure.ac, that makes these tools unbuildable.
We fix this by notifying the compiler that this particular case statement
is meant to fall through.
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
---
tools/usb/usbip/src/usbip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
index d7599d943529..73d8eee8130b 100644
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -176,6 +176,8 @@ int main(int argc, char *argv[])
break;
case '?':
printf("usbip: invalid option\n");
+ /* Terminate after printing error */
+ /* FALLTHRU */
default:
usbip_usage();
goto out;
--
2.14.1
This is a note to let you know that I've just added the patch titled
usbip: Fix implicit fallthrough warning
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usbip-fix-implicit-fallthrough-warning.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 Mon Sep 17 00:00:00 2001
From: Jonathan Dieter <jdieter(a)lesbg.com>
Date: Mon, 27 Feb 2017 10:31:04 +0200
Subject: usbip: Fix implicit fallthrough warning
From: Jonathan Dieter <jdieter(a)lesbg.com>
commit cfd6ed4537a9e938fa76facecd4b9cd65b6d1563 upstream.
GCC 7 now warns when switch statements fall through implicitly, and with
-Werror enabled in configure.ac, that makes these tools unbuildable.
We fix this by notifying the compiler that this particular case statement
is meant to fall through.
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/usb/usbip/src/usbip.c | 2 ++
1 file changed, 2 insertions(+)
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -176,6 +176,8 @@ int main(int argc, char *argv[])
break;
case '?':
printf("usbip: invalid option\n");
+ /* Terminate after printing error */
+ /* FALLTHRU */
default:
usbip_usage();
goto out;
Patches currently in stable-queue which might be from jdieter(a)lesbg.com are
queue-3.18/usbip-fix-implicit-fallthrough-warning.patch
commit 2f2d0088eb93 ("usbip: prevent vhci_hcd driver from leaking a
socket pointer address")
When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the
/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.
Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from
socket pointer address by looking up /proc/net/{tcp,tcp6}.
As this opens a security hole, the fix replaces socket pointer address
with sockfd.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
---
drivers/usb/usbip/usbip_common.h | 1 +
drivers/usb/usbip/vhci_sysfs.c | 25 +++++++++++++++----------
tools/usb/usbip/libsrc/vhci_driver.c | 8 ++++----
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index 9f490375ac92..f0b955f8504e 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -271,6 +271,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
+ int sockfd;
struct socket *tcp_socket;
struct task_struct *tcp_rx;
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index b96e5b189269..c287ccc78fde 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -49,13 +49,17 @@ static ssize_t status_show_vhci(int pdev_nr, char *out)
/*
* output example:
- * port sta spd dev socket local_busid
- * 0000 004 000 00000000 c5a7bb80 1-2.3
- * 0001 004 000 00000000 d8cee980 2-3.4
+ * port sta spd dev sockfd local_busid
+ * 0000 004 000 00000000 000003 1-2.3
+ * 0001 004 000 00000000 000004 2-3.4
*
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to
+ * avoid leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was
+ * made visible as a convenient way to find IP address from socket
+ * pointer address by looking up /proc/net/{tcp,tcp6}. As this opens
+ * a security hole, the change is made to use sockfd instead.
*/
for (i = 0; i < VHCI_HC_PORTS; i++) {
struct vhci_device *vdev = &vhci->vdev[i];
@@ -68,13 +72,13 @@ static ssize_t status_show_vhci(int pdev_nr, char *out)
if (vdev->ud.status == VDEV_ST_USED) {
out += sprintf(out, "%03u %08x ",
vdev->speed, vdev->devid);
- out += sprintf(out, "%16p %s",
- vdev->ud.tcp_socket,
+ out += sprintf(out, "%06u %s",
+ vdev->ud.sockfd,
dev_name(&vdev->udev->dev));
} else {
out += sprintf(out, "000 00000000 ");
- out += sprintf(out, "0000000000000000 0-0");
+ out += sprintf(out, "000000 0-0");
}
out += sprintf(out, "\n");
@@ -125,7 +129,7 @@ static ssize_t status_show(struct device *dev,
int pdev_nr;
out += sprintf(out,
- "port sta spd dev socket local_busid\n");
+ "port sta spd dev sockfd local_busid\n");
pdev_nr = status_name_to_id(attr->attr.name);
if (pdev_nr < 0)
@@ -324,6 +328,7 @@ static ssize_t store_attach(struct device *dev, struct device_attribute *attr,
vdev->devid = devid;
vdev->speed = speed;
+ vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c b/tools/usb/usbip/libsrc/vhci_driver.c
index ad9204773533..1274f326242c 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -55,12 +55,12 @@ static int parse_status(const char *value)
while (*c != '\0') {
int port, status, speed, devid;
- unsigned long socket;
+ int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
- ret = sscanf(c, "%d %d %d %x %lx %31s\n",
+ ret = sscanf(c, "%d %d %d %x %u %31s\n",
&port, &status, &speed,
- &devid, &socket, lbusid);
+ &devid, &sockfd, lbusid);
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -69,7 +69,7 @@ static int parse_status(const char *value)
dbg("port %d status %d speed %d devid %x",
port, status, speed, devid);
- dbg("socket %lx lbusid %s", socket, lbusid);
+ dbg("sockfd %u lbusid %s", sockfd, lbusid);
/* if a device is connected, look at it */
--
2.14.1
This is a note to let you know that I've just added the patch titled
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1c52d859cb2d417e7216d3e56bb7fea88444cec9 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto(a)kernel.org>
Date: Fri, 9 Dec 2016 10:24:05 -0800
Subject: x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
From: Andy Lutomirski <luto(a)kernel.org>
commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Matthew Whitehead <tedheadster(a)gmail.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Henrique de Moraes Holschuh <hmh(a)hmh.eng.br>
Cc: Andrew Cooper <andrew.cooper3(a)citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: xen-devel <Xen-devel(a)lists.xen.org>
Link: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.148130776…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: "Zhang, Ning A" <ning.a.zhang(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -596,7 +596,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
This is a note to let you know that I've just added the patch titled
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1c52d859cb2d417e7216d3e56bb7fea88444cec9 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto(a)kernel.org>
Date: Fri, 9 Dec 2016 10:24:05 -0800
Subject: x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
From: Andy Lutomirski <luto(a)kernel.org>
commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Matthew Whitehead <tedheadster(a)gmail.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Henrique de Moraes Holschuh <hmh(a)hmh.eng.br>
Cc: Andrew Cooper <andrew.cooper3(a)citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: xen-devel <Xen-devel(a)lists.xen.org>
Link: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.148130776…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: "Zhang, Ning A" <ning.a.zhang(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -574,7 +574,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.4/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
This is a note to let you know that I've just added the patch titled
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 1c52d859cb2d417e7216d3e56bb7fea88444cec9 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto(a)kernel.org>
Date: Fri, 9 Dec 2016 10:24:05 -0800
Subject: x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
From: Andy Lutomirski <luto(a)kernel.org>
commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 upstream.
We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong. For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.
Reported-by: One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Matthew Whitehead <tedheadster(a)gmail.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Henrique de Moraes Holschuh <hmh(a)hmh.eng.br>
Cc: Andrew Cooper <andrew.cooper3(a)citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: xen-devel <Xen-devel(a)lists.xen.org>
Link: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.148130776…
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/processor.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -669,7 +669,7 @@ static inline void sync_core(void)
{
int tmp;
-#ifdef CONFIG_M486
+#ifdef CONFIG_X86_32
/*
* Do a CPUID if available, otherwise do a jump. The jump
* can conveniently enough be the jump around CPUID.
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-3.18/x86-asm-32-make-sync_core-handle-missing-cpuid-on-all-32-bit-kernels.patch
During _ffs_func_bind(), the received descriptors are evaluated
to prepare for binding with the gadget in order to allocate
endpoints and optionally set up OS descriptors. However, the
high- and super-speed descriptors are only parsed based on
whether the gadget_is_dualspeed() and gadget_is_superspeed()
calls are true, respectively.
This is a problem in case a userspace program always provides
all of the {full,high,super,OS} descriptors when configuring a
function. Then, for example if a gadget device is not capable
of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
is skipped, resulting in an incorrect offset calculation for
the vla_ptr when moving on to the OS descriptors that follow.
This causes ffs_do_os_descs() to fail as it is now looking at
the SS descriptors' offset within the raw_descs buffer instead.
_ffs_func_bind() should evaluate the descriptors unconditionally,
so remove the checks for gadget speed.
Fixes: f0175ab51993 ("usb: gadget: f_fs: OS descriptors support")
Cc: stable(a)vger.kernel.org
Co-Developed-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Mayank Rana <mrana(a)codeaurora.org>
Signed-off-by: Jack Pham <jackp(a)codeaurora.org>
---
drivers/usb/gadget/function/f_fs.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index b6cf5ab..5f2dafb5 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2976,10 +2976,8 @@ static int _ffs_func_bind(struct usb_configuration *c,
struct ffs_data *ffs = func->ffs;
const int full = !!func->ffs->fs_descs_count;
- const int high = gadget_is_dualspeed(func->gadget) &&
- func->ffs->hs_descs_count;
- const int super = gadget_is_superspeed(func->gadget) &&
- func->ffs->ss_descs_count;
+ const int high = !!func->ffs->hs_descs_count;
+ const int super = !!func->ffs->ss_descs_count;
int fs_len, hs_len, ss_len, ret, i;
struct ffs_ep *eps_ptr;
--
2.9.1.200.gb1ec08f
From: Liran Alon <liran.alon(a)oracle.com>
[ Upstream commit 1f4dcb3b213235e642088709a1c54964d23365e9 ]
On this case, handle_emulation_failure() fills kvm_run with
internal-error information which it expects to be delivered
to user-mode for further processing.
However, the code reports a wrong return-value which makes KVM to never
return to user-mode on this scenario.
Fixes: 6d77dbfc88e3 ("KVM: inject #UD if instruction emulation fails and exit to
userspace")
Signed-off-by: Liran Alon <liran.alon(a)oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko(a)oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Reviewed-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
arch/x86/kvm/x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0dcbe370374f..80a83113a1ce 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5109,7 +5109,7 @@ static int handle_emulation_failure(struct kvm_vcpu *vcpu)
vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
vcpu->run->internal.ndata = 0;
- r = EMULATE_FAIL;
+ r = EMULATE_USER_EXIT;
}
kvm_queue_exception(vcpu, UD_VECTOR);
--
2.11.0
From: Sean Wang <sean.wang(a)mediatek.com>
commit 6066998cbd2b1012a8d5bc9a2957cfd0ad53150e upstream.
commit edeec420de24 ("cpufreq: dt-platdev: Automatically create cpufreq
device with OPP v2") not added MediaTek SoCs to the blacklist that would
lead to cause an occasional hang or unexpected behaviors on related boards
as kernelci reported and complained on [1] specifically for 4.14 and 4.15
tree.
For those reasons, add MediaTek SoCs into cpufreq-dt blacklist and wish
the patch be applied to 4.14 and 4.15 tree to allow kernelci able to
complete following automated kernel testing.
[1] https://kernelci.org/boot/mt7623n-bananapi-bpi-r2/
Fixes: edeec420de24 (cpufreq: dt-cpufreq: platdev Automatically create device with OPP v2)
Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng(a)mediatek.com>
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Cc: Kevin Hilman <khilman(a)baylibre.com>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index a753c50..9e0aa76 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -111,6 +111,14 @@ static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "marvell,armadaxp", },
+ { .compatible = "mediatek,mt2701", },
+ { .compatible = "mediatek,mt2712", },
+ { .compatible = "mediatek,mt7622", },
+ { .compatible = "mediatek,mt7623", },
+ { .compatible = "mediatek,mt817x", },
+ { .compatible = "mediatek,mt8173", },
+ { .compatible = "mediatek,mt8176", },
+
{ .compatible = "nvidia,tegra124", },
{ .compatible = "st,stih407", },
--
2.7.4
From: Jonathan Dieter <jdieter(a)lesbg.com>
Upstream commit cfd6ed4537a9 ("usbip: Fix implicit fallthrough warning")
GCC 7 now warns when switch statements fall through implicitly, and with
-Werror enabled in configure.ac, that makes these tools unbuildable.
We fix this by notifying the compiler that this particular case statement
is meant to fall through.
Reviewed-by: Peter Senna Tschudin <peter.senna(a)gmail.com>
Signed-off-by: Jonathan Dieter <jdieter(a)lesbg.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
---
tools/usb/usbip/src/usbip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
index d7599d943529..73d8eee8130b 100644
--- a/tools/usb/usbip/src/usbip.c
+++ b/tools/usb/usbip/src/usbip.c
@@ -176,6 +176,8 @@ int main(int argc, char *argv[])
break;
case '?':
printf("usbip: invalid option\n");
+ /* Terminate after printing error */
+ /* FALLTHRU */
default:
usbip_usage();
goto out;
--
2.14.1
commit 2f2d0088eb93 ("usbip: prevent vhci_hcd driver from leaking a
socket pointer address")
When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the
/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.
Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from
socket pointer address by looking up /proc/net/{tcp,tcp6}.
As this opens a security hole, the fix replaces socket pointer address
with sockfd.
Reported-by: Secunia Research <vuln(a)secunia.com>
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
---
drivers/usb/usbip/usbip_common.h | 1 +
drivers/usb/usbip/vhci_sysfs.c | 25 +++++++++++++++----------
tools/usb/usbip/libsrc/vhci_driver.c | 8 ++++----
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index 86b08475c254..f875ccaa55f9 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -261,6 +261,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
+ int sockfd;
struct socket *tcp_socket;
struct task_struct *tcp_rx;
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index 211f43f67ea2..84c21c4ccf46 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -39,16 +39,20 @@ static ssize_t status_show(struct device *dev, struct device_attribute *attr,
/*
* output example:
- * prt sta spd dev socket local_busid
- * 000 004 000 000 c5a7bb80 1-2.3
- * 001 004 000 000 d8cee980 2-3.4
+ * port sta spd dev sockfd local_busid
+ * 0000 004 000 00000000 000003 1-2.3
+ * 0001 004 000 00000000 000004 2-3.4
*
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to
+ * avoid leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was
+ * made visible as a convenient way to find IP address from socket
+ * pointer address by looking up /proc/net/{tcp,tcp6}. As this opens
+ * a security hole, the change is made to use sockfd instead.
*/
out += sprintf(out,
- "prt sta spd bus dev socket local_busid\n");
+ "prt sta spd bus dev sockfd local_busid\n");
for (i = 0; i < VHCI_NPORTS; i++) {
struct vhci_device *vdev = port_to_vdev(i);
@@ -60,11 +64,11 @@ static ssize_t status_show(struct device *dev, struct device_attribute *attr,
out += sprintf(out, "%03u %08x ",
vdev->speed, vdev->devid);
out += sprintf(out, "%16p ", vdev->ud.tcp_socket);
+ out += sprintf(out, "%06u", vdev->ud.sockfd);
out += sprintf(out, "%s", dev_name(&vdev->udev->dev));
- } else {
- out += sprintf(out, "000 000 000 0000000000000000 0-0");
- }
+ } else
+ out += sprintf(out, "000 000 000 000000 0-0");
out += sprintf(out, "\n");
spin_unlock(&vdev->ud.lock);
@@ -223,6 +227,7 @@ static ssize_t store_attach(struct device *dev, struct device_attribute *attr,
vdev->devid = devid;
vdev->speed = speed;
+ vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c b/tools/usb/usbip/libsrc/vhci_driver.c
index ad9204773533..1274f326242c 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -55,12 +55,12 @@ static int parse_status(const char *value)
while (*c != '\0') {
int port, status, speed, devid;
- unsigned long socket;
+ int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
- ret = sscanf(c, "%d %d %d %x %lx %31s\n",
+ ret = sscanf(c, "%d %d %d %x %u %31s\n",
&port, &status, &speed,
- &devid, &socket, lbusid);
+ &devid, &sockfd, lbusid);
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -69,7 +69,7 @@ static int parse_status(const char *value)
dbg("port %d status %d speed %d devid %x",
port, status, speed, devid);
- dbg("socket %lx lbusid %s", socket, lbusid);
+ dbg("sockfd %u lbusid %s", sockfd, lbusid);
/* if a device is connected, look at it */
--
2.14.1
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
When issuing an IPI RT push, where an IPI is sent to each CPU that has more
than one RT task scheduled on it, it references the root domain's rto_mask,
that contains all the CPUs within the root domain that has more than one RT
task in the runable state. The problem is, after the IPIs are initiated, the
rq->lock is released. This means that the root domain that is associated to
the run queue could be freed while the IPIs are going around.
Add a sched_get_rd() and a sched_put_rd() that will increment and decrement
the root domain's ref count respectively. This way when initiating the IPIs,
the scheduler will up the root domain's ref count before releasing the
rq->lock, ensuring that the root domain does not go away until the IPI round
is complete.
Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtN…
Cc: stable(a)vger.kernel.org
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Reported-by: Pavan Kondeti <pkondeti(a)codeaurora.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/sched/rt.c | 9 +++++++--
kernel/sched/sched.h | 2 ++
kernel/sched/topology.c | 13 +++++++++++++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 274b55e4a560..3401f588c916 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1990,8 +1990,11 @@ static void tell_cpu_to_push(struct rq *rq)
rto_start_unlock(&rq->rd->rto_loop_start);
- if (cpu >= 0)
+ if (cpu >= 0) {
+ /* Make sure the rd does not get freed while pushing */
+ sched_get_rd(rq->rd);
irq_work_queue_on(&rq->rd->rto_push_work, cpu);
+ }
}
/* Called from hardirq context */
@@ -2021,8 +2024,10 @@ void rto_push_irq_work_func(struct irq_work *work)
raw_spin_unlock(&rd->rto_lock);
- if (cpu < 0)
+ if (cpu < 0) {
+ sched_put_rd(rd);
return;
+ }
/* Try the next RT overloaded CPU */
irq_work_queue_on(&rd->rto_push_work, cpu);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 2e95505e23c6..fb5fc458547f 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -691,6 +691,8 @@ extern struct mutex sched_domains_mutex;
extern void init_defrootdomain(void);
extern int sched_init_domains(const struct cpumask *cpu_map);
extern void rq_attach_root(struct rq *rq, struct root_domain *rd);
+extern void sched_get_rd(struct root_domain *rd);
+extern void sched_put_rd(struct root_domain *rd);
#ifdef HAVE_RT_PUSH_IPI
extern void rto_push_irq_work_func(struct irq_work *work);
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 034cbed7f88b..519b024f4e94 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -259,6 +259,19 @@ void rq_attach_root(struct rq *rq, struct root_domain *rd)
call_rcu_sched(&old_rd->rcu, free_rootdomain);
}
+void sched_get_rd(struct root_domain *rd)
+{
+ atomic_inc(&rd->refcount);
+}
+
+void sched_put_rd(struct root_domain *rd)
+{
+ if (!atomic_dec_and_test(&rd->refcount))
+ return;
+
+ call_rcu_sched(&rd->rcu, free_rootdomain);
+}
+
static int init_rootdomain(struct root_domain *rd)
{
if (!zalloc_cpumask_var(&rd->span, GFP_KERNEL))
--
2.15.1
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
When the rto_push_irq_work_func() is called, it looks at the RT overloaded
bitmask in the root domain via the runqueue (rq->rd). The problem is that
during CPU up and down, nothing here stops rq->rd from changing between
taking the rq->rd->rto_lock and releasing it. That means the lock that is
released is not the same lock that was taken.
Instead of using this_rq()->rd to get the root domain, as the irq work is
part of the root domain, we can simply get the root domain from the irq work
that is passed to the routine:
container_of(work, struct root_domain, rto_push_work)
This keeps the root domain consistent.
Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtN…
Cc: stable(a)vger.kernel.org
Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic")
Reported-by: Pavan Kondeti <pkondeti(a)codeaurora.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
kernel/sched/rt.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 665ace2fc558..274b55e4a560 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1907,9 +1907,8 @@ static void push_rt_tasks(struct rq *rq)
* the rt_loop_next will cause the iterator to perform another scan.
*
*/
-static int rto_next_cpu(struct rq *rq)
+static int rto_next_cpu(struct root_domain *rd)
{
- struct root_domain *rd = rq->rd;
int next;
int cpu;
@@ -1985,7 +1984,7 @@ static void tell_cpu_to_push(struct rq *rq)
* Otherwise it is finishing up and an ipi needs to be sent.
*/
if (rq->rd->rto_cpu < 0)
- cpu = rto_next_cpu(rq);
+ cpu = rto_next_cpu(rq->rd);
raw_spin_unlock(&rq->rd->rto_lock);
@@ -1998,6 +1997,8 @@ static void tell_cpu_to_push(struct rq *rq)
/* Called from hardirq context */
void rto_push_irq_work_func(struct irq_work *work)
{
+ struct root_domain *rd =
+ container_of(work, struct root_domain, rto_push_work);
struct rq *rq;
int cpu;
@@ -2013,18 +2014,18 @@ void rto_push_irq_work_func(struct irq_work *work)
raw_spin_unlock(&rq->lock);
}
- raw_spin_lock(&rq->rd->rto_lock);
+ raw_spin_lock(&rd->rto_lock);
/* Pass the IPI to the next rt overloaded queue */
- cpu = rto_next_cpu(rq);
+ cpu = rto_next_cpu(rd);
- raw_spin_unlock(&rq->rd->rto_lock);
+ raw_spin_unlock(&rd->rto_lock);
if (cpu < 0)
return;
/* Try the next RT overloaded CPU */
- irq_work_queue_on(&rq->rd->rto_push_work, cpu);
+ irq_work_queue_on(&rd->rto_push_work, cpu);
}
#endif /* HAVE_RT_PUSH_IPI */
--
2.15.1
From: Josef Bacik <jbacik(a)fb.com>
In fixing the readdir+pagefault deadlock I accidentally introduced a
stale entry regression in readdir. If we get close to full for the
temporary buffer, and then skip a few delayed deletions, and then try to
add another entry that won't fit, we will emit the entries we found and
retry. Unfortunately we delete entries from our del_list as we find
them, assuming we won't need them. However our pos will be with
whatever our last entry was, which could be before the delayed deletions
we skipped, so the next search will add the deleted entries back into
our readdir buffer. So instead don't delete entries we find in our
del_list so we can make sure we always find our delayed deletions. This
is a slight perf hit for readdir with lots of pending deletions, but
hopefully this isn't a common occurrence. If it is we can revist this
and optimize it.
cc: stable(a)vger.kernel.org
Fixes: 23b5ec74943f ("btrfs: fix readdir deadlock with pagefault")
Signed-off-by: Josef Bacik <jbacik(a)fb.com>
---
fs/btrfs/delayed-inode.c | 26 ++++++++------------------
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 1c0bab4080a0..c9f7b13a7847 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1632,28 +1632,18 @@ void btrfs_readdir_put_delayed_items(struct inode *inode,
int btrfs_should_delete_dir_index(struct list_head *del_list,
u64 index)
{
- struct btrfs_delayed_item *curr, *next;
- int ret;
-
- if (list_empty(del_list))
- return 0;
+ struct btrfs_delayed_item *curr;
+ int ret = 0;
- list_for_each_entry_safe(curr, next, del_list, readdir_list) {
+ list_for_each_entry(curr, del_list, readdir_list) {
if (curr->key.offset > index)
break;
-
- list_del(&curr->readdir_list);
- ret = (curr->key.offset == index);
-
- if (refcount_dec_and_test(&curr->refs))
- kfree(curr);
-
- if (ret)
- return 1;
- else
- continue;
+ if (curr->key.offset == index) {
+ ret = 1;
+ break;
+ }
}
- return 0;
+ return ret;
}
/*
--
2.7.5
The Toshiba Click Mini uses an i2c attached keyboard/touchpad combo
(single i2c_hid device for both) which has a vid:pid of 04F3:0401,
which is also used by a bunch of Elan touchpads which are handled by the
drivers/input/mouse/elan_i2c driver, but that driver deals with pure
touchpads and does not work for a combo device such as the one on the
Toshiba Click Mini.
The combo on the Mini has an ACPI id of ELAN0800, which is not claimed
by the elan_i2c driver, so check for that and if it is found do not ignore
the device. This fixes the keyboard/touchpad combo on the Mini not working
(although with the touchpad in mouse emulation mode).
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/hid/hid-quirks.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 1cf1e9a0d699..ed4b30bbdde3 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -729,7 +729,6 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EARTHMATE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) },
{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0400) },
- { HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, 0x0401) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
@@ -997,6 +996,17 @@ bool hid_ignore(struct hid_device *hdev)
strncmp(hdev->name, "www.masterkit.ru MA901", 22) == 0)
return true;
break;
+ case USB_VENDOR_ID_ELAN:
+ /*
+ * Many Elan devices have a product id of 0x0401 and are handled
+ * by the elan_i2c input driver. But the ACPI HID ELAN0800 dev
+ * is not (and cannot be) handled by that driver ->
+ * Ignore all 0x0401 devs except for the ELAN0800 dev.
+ */
+ if (hdev->product == 0x0401 &&
+ strncmp(hdev->name, "ELAN0800", 8) != 0)
+ return true;
+ break;
}
if (hdev->type == HID_TYPE_USBMOUSE &&
--
2.14.3
Touch toggle softkeys send a '1' while pressed and a '0' while released,
requring the kernel to keep track of wether touch should be enabled or
disabled. The code does not handle the state transitions properly,
however. If the key is pressed repeatedly, the following four states
of states are cycled through (assuming touch starts out enabled):
Press: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
Release: shared->is_touch_on => 0, SW_MUTE_DEVICE => 1
Press: shared->is_touch_on => 1, SW_MUTE_DEVICE => 0
Release: shared->is_touch_on => 1, SW_MUTE_DEVICE => 1
The hardware always properly enables/disables touch when the key is
pressed but applications that listen for SW_MUTE_DEVICE events to provide
feedback about the state will only ever show touch as being enabled while
the key is held, and only every-other time. This sequence occurs because
the fallthrough WACOM_HID_WD_TOUCHONOFF case is always handled, and it
uses the value of the *local* is_touch_on variable as the value to
report to userspace. The local value is equal to the shared value when
the button is pressed, but equal to zero when the button is released.
Reporting the shared value to userspace fixes this problem, but the
fallthrough case needs to update the shared value in an incompatible
way (which is why the local variable was introduced in the first place).
To work around this, we just handle both cases in a single block of code
and update the shared variable as appropriate.
Fixes: d793ff8187 ("HID: wacom: generic: support touch on/off softkey")
Cc: <stable(a)vger.kernel.org> # v4.12+
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
Reviewed-by: Aaron Skomra <aaron.skomra(a)wacom.com>
Tested-by: Aaron Skomra <aaron.skomra(a)wacom.com>
---
drivers/hid/wacom_wac.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 16af6886e828..7dbff253c05c 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -1924,7 +1924,6 @@ static void wacom_wac_pad_event(struct hid_device *hdev, struct hid_field *field
struct wacom_features *features = &wacom_wac->features;
unsigned equivalent_usage = wacom_equivalent_usage(usage->hid);
int i;
- bool is_touch_on = value;
bool do_report = false;
/*
@@ -1969,16 +1968,17 @@ static void wacom_wac_pad_event(struct hid_device *hdev, struct hid_field *field
break;
case WACOM_HID_WD_MUTE_DEVICE:
- if (wacom_wac->shared->touch_input && value) {
- wacom_wac->shared->is_touch_on = !wacom_wac->shared->is_touch_on;
- is_touch_on = wacom_wac->shared->is_touch_on;
- }
-
- /* fall through*/
case WACOM_HID_WD_TOUCHONOFF:
if (wacom_wac->shared->touch_input) {
+ bool *is_touch_on = &wacom_wac->shared->is_touch_on;
+
+ if (equivalent_usage == WACOM_HID_WD_MUTE_DEVICE && value)
+ *is_touch_on = !(*is_touch_on);
+ else if (equivalent_usage == WACOM_HID_WD_TOUCHONOFF)
+ *is_touch_on = value;
+
input_report_switch(wacom_wac->shared->touch_input,
- SW_MUTE_DEVICE, !is_touch_on);
+ SW_MUTE_DEVICE, !(*is_touch_on));
input_sync(wacom_wac->shared->touch_input);
}
break;
--
2.15.1
Background: ExpressKey Remotes communicate their events via usb dongle.
Each dongle can hold up to 5 pairings at one time and one EKR (identified
by its serial number) can unfortunately be paired with its dongle
more than once. The pairing takes place in a round-robin fashion.
Input devices are only created once per EKR, when a new serial number
is seen in the list of pairings. However, if a device is created for
a "higher" paring index and subsequently a second pairing occurs at a
lower pairing index, unpairing the remote with that serial number from
any pairing index will currently cause a driver crash. This occurs
infrequently, as two remotes are necessary to trigger this bug and most
users have only one remote.
As an illustration, to trigger the bug you need to have two remotes,
and pair them in this order:
1. slot 0 -> remote 1 (input device created for remote 1)
2. slot 1 -> remote 1 (duplicate pairing - no device created)
3. slot 2 -> remote 1 (duplicate pairing - no device created)
4. slot 3 -> remote 1 (duplicate pairing - no device created)
5. slot 4 -> remote 2 (input device created for remote 2)
6. slot 0 -> remote 2 (1 destroyed and recreated at slot 1)
7. slot 1 -> remote 2 (1 destroyed and recreated at slot 2)
8. slot 2 -> remote 2 (1 destroyed and recreated at slot 3)
9. slot 3 -> remote 2 (1 destroyed and not recreated)
10. slot 4 -> remote 2 (2 was already in this slot so no changes)
11. slot 0 -> remote 1 (The current code sees remote 2 was paired over in
one of the dongle slots it occupied and attempts
to remove all information about remote 2 [1]. It
calls wacom_remote_destroy_one for remote 2, but
the destroy function assumes the lowest index is
where the remote's input device was created. The
code "cleans up" the other remote 2 pairings
including the one which the input device was based
on, assuming they were were just duplicate
pairings. However, the cleanup doesn't call the
devres release function for the input device that
was created in slot 4).
This issue is fixed by this commit.
[1] Remote 2 should subsequently be re-created on the next packet from the
EKR at the lowest numbered slot that it occupies (here slot 1).
Fixes: f9036bd43602 ("HID: wacom: EKR: use devres groups to manage resources")
Cc: stable <stable(a)vger.kernel.org> #4.9
Signed-off-by: Aaron Armstrong Skomra <aaron.skomra(a)wacom.com>
---
drivers/hid/wacom_sys.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index ee71ad9b6cc1..76531796bd3c 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -2347,23 +2347,23 @@ static void wacom_remote_destroy_one(struct wacom *wacom, unsigned int index)
int i;
unsigned long flags;
- spin_lock_irqsave(&remote->remote_lock, flags);
- remote->remotes[index].registered = false;
- spin_unlock_irqrestore(&remote->remote_lock, flags);
+ for (i = 0; i < WACOM_MAX_REMOTES; i++) {
+ if (remote->remotes[i].serial == serial) {
- if (remote->remotes[index].battery.battery)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index].battery.bat_desc);
+ spin_lock_irqsave(&remote->remote_lock, flags);
+ remote->remotes[i].registered = false;
+ spin_unlock_irqrestore(&remote->remote_lock, flags);
- if (remote->remotes[index].group.name)
- devres_release_group(&wacom->hdev->dev,
- &remote->remotes[index]);
+ if (remote->remotes[i].battery.battery)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i].battery.bat_desc);
+
+ if (remote->remotes[i].group.name)
+ devres_release_group(&wacom->hdev->dev,
+ &remote->remotes[i]);
- for (i = 0; i < WACOM_MAX_REMOTES; i++) {
- if (remote->remotes[i].serial == serial) {
remote->remotes[i].serial = 0;
remote->remotes[i].group.name = NULL;
- remote->remotes[i].registered = false;
remote->remotes[i].battery.battery = NULL;
wacom->led.groups[i].select = WACOM_STATUS_UNKNOWN;
}
--
2.7.4
From: Marcin Nowakowski <marcin.nowakowski(a)mips.com>
Change 73fbc1eba7ff added a fix to ensure that the memory range between
PHYS_OFFSET and low memory address specified by mem= cmdline argument is
not later processed by free_all_bootmem.
This change was incorrect for systems where the commandline specifies
more than 1 mem argument, as it will cause all memory between
PHYS_OFFSET and each of the memory offsets to be marked as reserved,
which results in parts of the RAM marked as reserved (Creator CI20's
u-boot has a default commandline argument 'mem=256M@0x0
mem=768M@0x30000000').
Change the behaviour to ensure that only the range between PHYS_OFFSET
and the lowest start address of the memories is marked as protected.
This change also ensures that the range is marked protected even if it's
only defined through the devicetree and not only via commandline
arguments.
Reported-by: Mathieu Malaterre <mathieu.malaterre(a)gmail.com>
Signed-off-by: Marcin Nowakowski <marcin.nowakowski(a)mips.com>
Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
Cc: <stable(a)vger.kernel.org> # v4.11
---
v2: Use updated email adress, add tag for stable.
arch/mips/kernel/setup.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 702c678de116..f19d61224c71 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -375,6 +375,7 @@ static void __init bootmem_init(void)
unsigned long reserved_end;
unsigned long mapstart = ~0UL;
unsigned long bootmap_size;
+ phys_addr_t ramstart = ~0UL;
bool bootmap_valid = false;
int i;
@@ -395,6 +396,21 @@ static void __init bootmem_init(void)
max_low_pfn = 0;
/*
+ * Reserve any memory between the start of RAM and PHYS_OFFSET
+ */
+ for (i = 0; i < boot_mem_map.nr_map; i++) {
+ if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
+ continue;
+
+ ramstart = min(ramstart, boot_mem_map.map[i].addr);
+ }
+
+ if (ramstart > PHYS_OFFSET)
+ add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
+ BOOT_MEM_RESERVED);
+
+
+ /*
* Find the highest page frame number we have available.
*/
for (i = 0; i < boot_mem_map.nr_map; i++) {
@@ -664,9 +680,6 @@ static int __init early_parse_mem(char *p)
add_memory_region(start, size, BOOT_MEM_RAM);
- if (start && start > PHYS_OFFSET)
- add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
- BOOT_MEM_RESERVED);
return 0;
}
early_param("mem", early_parse_mem);
--
2.11.0
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: dt-bindings/media/cec-gpio.txt: mention the CEC/HPD max voltages
Author: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Sat Dec 16 05:44:13 2017 -0500
Mention the maximum voltages of the CEC and HPD lines. Since in the example
these lines are connected to a Raspberry Pi and the Rpi GPIO lines are 3.3V
it is a good idea to warn against directly connecting the HPD to the Raspberry
Pi's GPIO line.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Reviewed-by: Rob Herring <robh(a)kernel.org>
Cc: <stable(a)vger.kernel.org> # for v4.15
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Documentation/devicetree/bindings/media/cec-gpio.txt | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
---
diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt b/Documentation/devicetree/bindings/media/cec-gpio.txt
index 46a0bac8b3b9..12fcd55ed153 100644
--- a/Documentation/devicetree/bindings/media/cec-gpio.txt
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -4,6 +4,10 @@ The HDMI CEC GPIO module supports CEC implementations where the CEC line
is hooked up to a pull-up GPIO line and - optionally - the HPD line is
hooked up to another GPIO line.
+Please note: the maximum voltage for the CEC line is 3.63V, for the HPD
+line it is 5.3V. So you may need some sort of level conversion circuitry
+when connecting them to a GPIO line.
+
Required properties:
- compatible: value must be "cec-gpio".
- cec-gpios: gpio that the CEC line is connected to. The line should be
@@ -21,7 +25,7 @@ the following property is optional:
Example for the Raspberry Pi 3 where the CEC line is connected to
pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
-connected to pin 11 aka BCM17:
+connected to pin 11 aka BCM17 (some level shifter is needed for this!):
#include <dt-bindings/gpio/gpio.h>
Tree/Branch: v4.1.49
Git describe: v4.1.49
Commit: 30ad2851a6 Linux 4.1.49
Build Time: 67 min 8 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 31
Section Mismatches: 1
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
21 warnings 3 mismatches : arm64-allmodconfig
2 warnings 0 mismatches : arm-multi_v7_defconfig
23 warnings 0 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm-multi_v5_defconfig
4 warnings 0 mismatches : x86_64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 31
8 ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
5 ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
2 ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
2 ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
2 ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
2 ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
2 ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
2 ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
1 ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion]
1 ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
1 ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1 ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
1 ../drivers/iommu/intel-iommu.c:3800:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
1 ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
1 ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1 ../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
1 ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
1 ../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
1 ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1 ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
Section Mismatch Summary: 1
3 WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 21 warnings, 3 section mismatches
Warnings:
../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined
../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion]
Section Mismatches:
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0x168): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit()
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 23 warnings, 0 section mismatches
Warnings:
../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=]
../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined
../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable]
../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast
../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=]
../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable]
../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp]
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool]
../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow]
../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
../drivers/iommu/intel-iommu.c:3800:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig
arm64-allnoconfig
arm-allnoconfig
arm64-defconfig
On Mon, Jan 22, 2018 at 3:34 PM, Maxime Ripard
<maxime.ripard(a)free-electrons.com> wrote:
> Hi,
>
> On Sat, Jan 20, 2018 at 11:37:28AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Jan 19, 2018 at 9:32 PM, Maxime Ripard
>> <maxime.ripard(a)free-electrons.com> wrote:
>> > The DRM driver most notably, but also out of tree drivers (for now) like
>> > the VPU or GPU drivers, are quite big consumers of large, contiguous memory
>> > buffers. However, the sunxi_defconfig doesn't enable CMA in order to
>> > mitigate that, which makes them almost unusable.
>> >
>> > Enable it to make sure it somewhat works.
>>
>> IIRC the default size for CMA pretty much limits it to small tablet
>> screen resolutions. Is this something we want to leave up to the
>> user?
>
> That's one of the pain points of CMA in our case. The amount of memory
> you need depends on the resolution itself, but also the number of
> multiple buffers you want to use, and even the number of planes you
> want to use.
>
> And then, you have to trade that off with the amount of RAM you have
> on your board in order to still have something that's usable.
>
> tl;dr: I don't really see how to define a value good enough for
> everyone.
Yeah, that's what I thought. On the other hand, I don't think any
of the kernelci boards have display enabled? So either way we won't
see any automated tests fail.
ChenYu
The patch titled
Subject: kasan: don't emit builtin calls when sanitization is off
has been added to the -mm tree. Its filename is
kasan-dont-emit-builtin-calls-when-sanitization-is-off.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/kasan-dont-emit-builtin-calls-when…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/kasan-dont-emit-builtin-calls-when…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrey Konovalov <andreyknvl(a)google.com>
Subject: kasan: don't emit builtin calls when sanitization is off
With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.
The issue is that clang emits memset() calls even when there is no
memset() in the source code. They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.
The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.
Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.151638459…
Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com>
Acked-by: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Michal Marek <michal.lkml(a)markovi.net>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
Makefile | 3 ++-
scripts/Makefile.kasan | 3 +++
scripts/Makefile.lib | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff -puN Makefile~kasan-dont-emit-builtin-calls-when-sanitization-is-off Makefile
--- a/Makefile~kasan-dont-emit-builtin-calls-when-sanitization-is-off
+++ a/Makefile
@@ -432,7 +432,8 @@ export MAKE AWK GENKSYMS INSTALLKERNEL P
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
+export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
diff -puN scripts/Makefile.kasan~kasan-dont-emit-builtin-calls-when-sanitization-is-off scripts/Makefile.kasan
--- a/scripts/Makefile.kasan~kasan-dont-emit-builtin-calls-when-sanitization-is-off
+++ a/scripts/Makefile.kasan
@@ -31,4 +31,7 @@ else
endif
CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+
endif
diff -puN scripts/Makefile.lib~kasan-dont-emit-builtin-calls-when-sanitization-is-off scripts/Makefile.lib
--- a/scripts/Makefile.lib~kasan-dont-emit-builtin-calls-when-sanitization-is-off
+++ a/scripts/Makefile.lib
@@ -121,7 +121,7 @@ endif
ifeq ($(CONFIG_KASAN),y)
_c_flags += $(if $(patsubst n%,, \
$(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
- $(CFLAGS_KASAN))
+ $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
endif
ifeq ($(CONFIG_UBSAN),y)
_
Patches currently in -mm which might be from andreyknvl(a)google.com are
kasan-dont-emit-builtin-calls-when-sanitization-is-off.patch
kasan-fix-prototype-author-email-address.patch
kasan-clean-up-kasan_shadow_scale_shift-usage.patch
The patch titled
Subject: mm/hmm: fix uninitialized use of 'entry' in hmm_vma_walk_pmd()
has been added to the -mm tree. Its filename is
mm-hmm-fix-uninitialized-use-of-entry-in-hmm_vma_walk_pmd.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-fix-uninitialized-use-of-en…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-fix-uninitialized-use-of-en…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ralph Campbell <rcampbell(a)nvidia.com>
Subject: mm/hmm: fix uninitialized use of 'entry' in hmm_vma_walk_pmd()
The variable 'entry' is used before being initialized in
hmm_vma_walk_pmd().
Link: http://lkml.kernel.org/r/20180122185759.26286-1-jglisse@redhat.com
Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com>
Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/hmm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN mm/hmm.c~mm-hmm-fix-uninitialized-use-of-entry-in-hmm_vma_walk_pmd mm/hmm.c
--- a/mm/hmm.c~mm-hmm-fix-uninitialized-use-of-entry-in-hmm_vma_walk_pmd
+++ a/mm/hmm.c
@@ -418,7 +418,7 @@ again:
}
if (!pte_present(pte)) {
- swp_entry_t entry;
+ swp_entry_t entry = pte_to_swp_entry(pte);
if (!non_swap_entry(entry)) {
if (hmm_vma_walk->fault)
@@ -426,8 +426,6 @@ again:
continue;
}
- entry = pte_to_swp_entry(pte);
-
/*
* This is a special swap entry, ignore migration, use
* device and report anything else as error.
_
Patches currently in -mm which might be from rcampbell(a)nvidia.com are
mm-hmm-fix-uninitialized-use-of-entry-in-hmm_vma_walk_pmd.patch
The patch titled
Subject: scripts/gdb/linux/tasks.py: fix get_thread_info
has been removed from the -mm tree. Its filename was
scripts-gdb-fix-get_thread_info.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Xi Kangjie <imxikangjie(a)gmail.com>
Subject: scripts/gdb/linux/tasks.py: fix get_thread_info
Since kernel 4.9, the thread_info has been moved into task_struct, no
longer locates at the bottom of kernel stack.
See c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") and 15f4eae70d36 ("x86: Move thread_info into task_struct").
Before fix:
(gdb) set $current = $lx_current()
(gdb) p $lx_thread_info($current)
$1 = {flags = 1470918301}
(gdb) p $current.thread_info
$2 = {flags = 2147483648}
After fix:
(gdb) p $lx_thread_info($current)
$1 = {flags = 2147483648}
(gdb) p $current.thread_info
$2 = {flags = 2147483648}
Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com
Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
Signed-off-by: Xi Kangjie <imxikangjie(a)gmail.com>
Acked-by: Jan Kiszka <jan.kiszka(a)siemens.com>
Acked-by: Kieran Bingham <kbingham(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
scripts/gdb/linux/tasks.py | 2 ++
1 file changed, 2 insertions(+)
diff -puN scripts/gdb/linux/tasks.py~scripts-gdb-fix-get_thread_info scripts/gdb/linux/tasks.py
--- a/scripts/gdb/linux/tasks.py~scripts-gdb-fix-get_thread_info
+++ a/scripts/gdb/linux/tasks.py
@@ -96,6 +96,8 @@ def get_thread_info(task):
thread_info_addr = task.address + ia64_task_size
thread_info = thread_info_addr.cast(thread_info_ptr_type)
else:
+ if task.type.fields()[0].type == thread_info_type.get_type():
+ return task['thread_info']
thread_info = task['stack'].cast(thread_info_ptr_type)
return thread_info.dereference()
_
Patches currently in -mm which might be from imxikangjie(a)gmail.com are
In orangefs_devreq_read, there is a loop which picks an op off the list
of pending ops. If the loop fails to find an op, there is nothing to
read, and it returns EAGAIN. If the op has been given up on, the loop
is restarted via a goto. The bug is that the variable which the found
op is written to is not reinitialized, so if there are no more eligible
ops on the list, the code runs again on the already handled op.
This is triggered by interrupting a process while the op is being copied
to the client-core. It's a fairly small window, but it's there.
Signed-off-by: Martin Brandenburg <martin(a)omnibond.com>
Cc: stable(a)vger.kernel.org
---
fs/orangefs/devorangefs-req.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/orangefs/devorangefs-req.c b/fs/orangefs/devorangefs-req.c
index ded456f17de6..c584ad8d023c 100644
--- a/fs/orangefs/devorangefs-req.c
+++ b/fs/orangefs/devorangefs-req.c
@@ -162,7 +162,7 @@ static ssize_t orangefs_devreq_read(struct file *file,
struct orangefs_kernel_op_s *op, *temp;
__s32 proto_ver = ORANGEFS_KERNEL_PROTO_VERSION;
static __s32 magic = ORANGEFS_DEVREQ_MAGIC;
- struct orangefs_kernel_op_s *cur_op = NULL;
+ struct orangefs_kernel_op_s *cur_op;
unsigned long ret;
/* We do not support blocking IO. */
@@ -186,6 +186,7 @@ static ssize_t orangefs_devreq_read(struct file *file,
return -EAGAIN;
restart:
+ cur_op = NULL;
/* Get next op (if any) from top of list. */
spin_lock(&orangefs_request_list_lock);
list_for_each_entry_safe(op, temp, &orangefs_request_list, list) {
--
2.15.1
This is a note to let you know that I've just added the patch titled
test_firmware: fix missing unlock on error in
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From a5e1923356505e46476c2fb518559b7a4d9d25b1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Thu, 11 Jan 2018 11:12:55 +0000
Subject: test_firmware: fix missing unlock on error in
config_num_requests_store()
Add the missing unlock before return from function
config_num_requests_store() in the error handling case.
Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/test_firmware.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 1e907dd3b4fe..078a61480573 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -371,6 +371,7 @@ static ssize_t config_num_requests_store(struct device *dev,
if (test_fw_config->reqs) {
pr_err("Must call release_all_firmware prior to changing config\n");
rc = -EINVAL;
+ mutex_unlock(&test_fw_mutex);
goto out;
}
mutex_unlock(&test_fw_mutex);
--
2.16.0
This is a note to let you know that I've just added the patch titled
usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 11fb37998759c48e4e4c200c974593cbeab25d3e Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Fri, 12 Jan 2018 17:50:02 +1100
Subject: usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc()
The current code tries to test for bits that are masked out by
usb_endpoint_maxp(). Instead, use the proper accessor to access
the new high bandwidth bits.
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 1b3efb14aec7..ac0541529499 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -912,7 +912,7 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
return 0;
/* "high bandwidth" works only at high speed */
- if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
+ if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp_mult(desc) > 1)
return 0;
switch (type) {
--
2.16.0
This is a note to let you know that I've just added the patch titled
USB: serial: simple: add Motorola Tetra driver
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 46fe895e22ab3845515ec06b01eaf1282b342e29 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Thu, 18 Jan 2018 14:46:41 +1100
Subject: USB: serial: simple: add Motorola Tetra driver
Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI
devices.
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0cad ProdID=9011 Rev=24.16
S: Manufacturer=Motorola Solutions Inc.
S: Product=Motorola Solutions TETRA PEI interface
C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
Note that these devices do not support the CDC SET_CONTROL_LINE_STATE
request (for any interface).
Reported-by: Max Schulze <max.schulze(a)posteo.de>
Tested-by: Max Schulze <max.schulze(a)posteo.de>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/Kconfig | 1 +
drivers/usb/serial/usb-serial-simple.c | 7 +++++++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index a8d5f2e4878d..c66b93664d54 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -63,6 +63,7 @@ config USB_SERIAL_SIMPLE
- Google USB serial devices
- HP4x calculators
- a number of Motorola phones
+ - Motorola Tetra devices
- Novatel Wireless GPS receivers
- Siemens USB/MPI adapter.
- ViVOtech ViVOpay USB device.
diff --git a/drivers/usb/serial/usb-serial-simple.c b/drivers/usb/serial/usb-serial-simple.c
index 74172fe158df..4ef79e29cb26 100644
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -77,6 +77,11 @@ DEVICE(vivopay, VIVOPAY_IDS);
{ USB_DEVICE(0x22b8, 0x2c64) } /* Motorola V950 phone */
DEVICE(moto_modem, MOTO_IDS);
+/* Motorola Tetra driver */
+#define MOTOROLA_TETRA_IDS() \
+ { USB_DEVICE(0x0cad, 0x9011) } /* Motorola Solutions TETRA PEI */
+DEVICE(motorola_tetra, MOTOROLA_TETRA_IDS);
+
/* Novatel Wireless GPS driver */
#define NOVATEL_IDS() \
{ USB_DEVICE(0x09d7, 0x0100) } /* NovAtel FlexPack GPS */
@@ -107,6 +112,7 @@ static struct usb_serial_driver * const serial_drivers[] = {
&google_device,
&vivopay_device,
&moto_modem_device,
+ &motorola_tetra_device,
&novatel_gps_device,
&hp4x_device,
&suunto_device,
@@ -122,6 +128,7 @@ static const struct usb_device_id id_table[] = {
GOOGLE_IDS(),
VIVOPAY_IDS(),
MOTO_IDS(),
+ MOTOROLA_TETRA_IDS(),
NOVATEL_IDS(),
HP4X_IDS(),
SUUNTO_IDS(),
--
2.16.0
This is a note to let you know that I've just added the patch titled
usb: option: Add support for FS040U modem
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 69341bd15018da0a662847e210f9b2380c71e623 Mon Sep 17 00:00:00 2001
From: OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp>
Date: Tue, 16 Jan 2018 09:51:17 +0000
Subject: usb: option: Add support for FS040U modem
FS040U modem is manufactured by omega, and sold by Fujisoft. This patch
adds ID of the modem to use option1 driver. Interface 3 is used as
qmi_wwan, so the interface is ignored.
Signed-off-by: Yoshiaki Okamoto <yokamoto(a)allied-telesis.co.jp>
Signed-off-by: Hiroyuki Yamamoto <hyamamo(a)allied-telesis.co.jp>
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index b6320e3be429..5db8ed517e0e 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -380,6 +380,9 @@ static void option_instat_callback(struct urb *urb);
#define FOUR_G_SYSTEMS_PRODUCT_W14 0x9603
#define FOUR_G_SYSTEMS_PRODUCT_W100 0x9b01
+/* Fujisoft products */
+#define FUJISOFT_PRODUCT_FS040U 0x9b02
+
/* iBall 3.5G connect wireless modem */
#define IBALL_3_5G_CONNECT 0x9605
@@ -1894,6 +1897,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W100),
.driver_info = (kernel_ulong_t)&four_g_w100_blacklist
},
+ {USB_DEVICE(LONGCHEER_VENDOR_ID, FUJISOFT_PRODUCT_FS040U),
+ .driver_info = (kernel_ulong_t)&net_intf3_blacklist},
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, SPEEDUP_PRODUCT_SU9800, 0xff) },
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9801, 0xff),
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
--
2.16.0
This is a note to let you know that I've just added the patch titled
test_firmware: fix missing unlock on error in
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the driver-core-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From a5e1923356505e46476c2fb518559b7a4d9d25b1 Mon Sep 17 00:00:00 2001
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Thu, 11 Jan 2018 11:12:55 +0000
Subject: test_firmware: fix missing unlock on error in
config_num_requests_store()
Add the missing unlock before return from function
config_num_requests_store() in the error handling case.
Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
lib/test_firmware.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 1e907dd3b4fe..078a61480573 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -371,6 +371,7 @@ static ssize_t config_num_requests_store(struct device *dev,
if (test_fw_config->reqs) {
pr_err("Must call release_all_firmware prior to changing config\n");
rc = -EINVAL;
+ mutex_unlock(&test_fw_mutex);
goto out;
}
mutex_unlock(&test_fw_mutex);
--
2.16.0
This is a note to let you know that I've just added the patch titled
serial: 8250_dw: Revert "Improve clock rate setting"
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From c14b65feac9ebed649d6fe79c6b6d64d21d0287d Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Fri, 19 Jan 2018 18:02:05 +0200
Subject: serial: 8250_dw: Revert "Improve clock rate setting"
The commit
de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
obviously tries to cure symptoms, and not a root cause.
The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.
Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.
Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].
Taking above, revert the commit de9e33bdfa22 for now.
[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782
Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
Cc: stable <stable(a)vger.kernel.org> # 4.15
Cc: Ed Blake <ed.blake(a)sondrel.com>
Cc: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Cc: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_dw.c | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index bda75d317d24..cd1b94a0f451 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -252,31 +252,25 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios,
struct ktermios *old)
{
unsigned int baud = tty_termios_baud_rate(termios);
- unsigned int target_rate, min_rate, max_rate;
struct dw8250_data *d = p->private_data;
long rate;
- int i, ret;
+ int ret;
if (IS_ERR(d->clk) || !old)
goto out;
- /* Find a clk rate within +/-1.6% of an integer multiple of baudx16 */
- target_rate = baud * 16;
- min_rate = target_rate - (target_rate >> 6);
- max_rate = target_rate + (target_rate >> 6);
-
- for (i = 1; i <= UART_DIV_MAX; i++) {
- rate = clk_round_rate(d->clk, i * target_rate);
- if (rate >= i * min_rate && rate <= i * max_rate)
- break;
- }
- if (i <= UART_DIV_MAX) {
- clk_disable_unprepare(d->clk);
+ clk_disable_unprepare(d->clk);
+ rate = clk_round_rate(d->clk, baud * 16);
+ if (rate < 0)
+ ret = rate;
+ else if (rate == 0)
+ ret = -ENOENT;
+ else
ret = clk_set_rate(d->clk, rate);
- clk_prepare_enable(d->clk);
- if (!ret)
- p->uartclk = rate;
- }
+ clk_prepare_enable(d->clk);
+
+ if (!ret)
+ p->uartclk = rate;
out:
p->status &= ~UPSTAT_AUTOCTS;
--
2.16.0
This is a note to let you know that I've just added the patch titled
usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 11fb37998759c48e4e4c200c974593cbeab25d3e Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Date: Fri, 12 Jan 2018 17:50:02 +1100
Subject: usb/gadget: Fix "high bandwidth" check in usb_gadget_ep_match_desc()
The current code tries to test for bits that are masked out by
usb_endpoint_maxp(). Instead, use the proper accessor to access
the new high bandwidth bits.
Signed-off-by: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/udc/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 1b3efb14aec7..ac0541529499 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -912,7 +912,7 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
return 0;
/* "high bandwidth" works only at high speed */
- if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp(desc) & (3<<11))
+ if (!gadget_is_dualspeed(gadget) && usb_endpoint_maxp_mult(desc) > 1)
return 0;
switch (type) {
--
2.16.0
This is a note to let you know that I've just added the patch titled
usb: option: Add support for FS040U modem
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the usb-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From 69341bd15018da0a662847e210f9b2380c71e623 Mon Sep 17 00:00:00 2001
From: OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp>
Date: Tue, 16 Jan 2018 09:51:17 +0000
Subject: usb: option: Add support for FS040U modem
FS040U modem is manufactured by omega, and sold by Fujisoft. This patch
adds ID of the modem to use option1 driver. Interface 3 is used as
qmi_wwan, so the interface is ignored.
Signed-off-by: Yoshiaki Okamoto <yokamoto(a)allied-telesis.co.jp>
Signed-off-by: Hiroyuki Yamamoto <hyamamo(a)allied-telesis.co.jp>
Cc: stable <stable(a)vger.kernel.org>
Acked-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/option.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index b6320e3be429..5db8ed517e0e 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -380,6 +380,9 @@ static void option_instat_callback(struct urb *urb);
#define FOUR_G_SYSTEMS_PRODUCT_W14 0x9603
#define FOUR_G_SYSTEMS_PRODUCT_W100 0x9b01
+/* Fujisoft products */
+#define FUJISOFT_PRODUCT_FS040U 0x9b02
+
/* iBall 3.5G connect wireless modem */
#define IBALL_3_5G_CONNECT 0x9605
@@ -1894,6 +1897,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W100),
.driver_info = (kernel_ulong_t)&four_g_w100_blacklist
},
+ {USB_DEVICE(LONGCHEER_VENDOR_ID, FUJISOFT_PRODUCT_FS040U),
+ .driver_info = (kernel_ulong_t)&net_intf3_blacklist},
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, SPEEDUP_PRODUCT_SU9800, 0xff) },
{ USB_DEVICE_INTERFACE_CLASS(LONGCHEER_VENDOR_ID, 0x9801, 0xff),
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
--
2.16.0
This is a note to let you know that I've just added the patch titled
MIPS: AR7: ensure the port type's FCR value is used
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:21 +0100
Subject: MIPS: AR7: ensure the port type's FCR value is used
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream.
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
trigger I/F of FIFO buffers"), the port's default FCR value isn't used
in serial8250_do_set_termios anymore, but copied over once in
serial8250_config_port and then modified as needed.
Unfortunately, serial8250_config_port will never be called if the port
is shared between kernel and userspace, and the port's flag doesn't have
UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
This causes garbled output from userspace:
[ 5.220000] random: procd urandom read with 49 bits of entropy available
ers
[kee
Fix this by forcing it to be configured on boot, resulting in the
expected output:
[ 5.250000] random: procd urandom read with 50 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17544/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Cc: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -576,7 +576,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
- uart_port.flags = UPF_FIXED_TYPE;
+ uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-4.9/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: ensure the port type's FCR value is used
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:21 +0100
Subject: MIPS: AR7: ensure the port type's FCR value is used
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream.
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
trigger I/F of FIFO buffers"), the port's default FCR value isn't used
in serial8250_do_set_termios anymore, but copied over once in
serial8250_config_port and then modified as needed.
Unfortunately, serial8250_config_port will never be called if the port
is shared between kernel and userspace, and the port's flag doesn't have
UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
This causes garbled output from userspace:
[ 5.220000] random: procd urandom read with 49 bits of entropy available
ers
[kee
Fix this by forcing it to be configured on boot, resulting in the
expected output:
[ 5.250000] random: procd urandom read with 50 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17544/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Cc: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -576,7 +576,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
- uart_port.flags = UPF_FIXED_TYPE;
+ uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-4.4/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
This is a note to let you know that I've just added the patch titled
MIPS: AR7: ensure the port type's FCR value is used
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:21 +0100
Subject: MIPS: AR7: ensure the port type's FCR value is used
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream.
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
trigger I/F of FIFO buffers"), the port's default FCR value isn't used
in serial8250_do_set_termios anymore, but copied over once in
serial8250_config_port and then modified as needed.
Unfortunately, serial8250_config_port will never be called if the port
is shared between kernel and userspace, and the port's flag doesn't have
UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
This causes garbled output from userspace:
[ 5.220000] random: procd urandom read with 49 bits of entropy available
ers
[kee
Fix this by forcing it to be configured on boot, resulting in the
expected output:
[ 5.250000] random: procd urandom read with 50 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17544/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Cc: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -575,7 +575,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
- uart_port.flags = UPF_FIXED_TYPE;
+ uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-4.14/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
On Mon, Jan 22, 2018 at 01:07:19PM +0000, James Hogan wrote:
> Hi stable maintainers,
>
> On Sun, Oct 29, 2017 at 04:27:21PM +0100, Jonas Gorski wrote:
> > Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
> > trigger I/F of FIFO buffers"), the port's default FCR value isn't used
> > in serial8250_do_set_termios anymore, but copied over once in
> > serial8250_config_port and then modified as needed.
> >
> > Unfortunately, serial8250_config_port will never be called if the port
> > is shared between kernel and userspace, and the port's flag doesn't have
> > UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
> >
> > This causes garbled output from userspace:
> >
> > [ 5.220000] random: procd urandom read with 49 bits of entropy available
> > ers
> > [kee
> >
> > Fix this by forcing it to be configured on boot, resulting in the
> > expected output:
> >
> > [ 5.250000] random: procd urandom read with 50 bits of entropy available
> > Press the [f] key and hit [enter] to enter failsafe mode
> > Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> >
> > Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
> > Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
>
> Please can this patch be applied to stable branches 3.17+. It is now
> merged into mainline as commit 0a5191efe06b ("MIPS: AR7: ensure the port
> type's FCR value is used").
>
> Commit b084116f8587 ("MIPS: AR7: Ensure that serial ports are properly
> set up") is a prerequisite for it to apply cleanly, but is already
> tagged for stable.
Now snuck into this round of stable -rc review :)
thanks,
greg k-h
This is a note to let you know that I've just added the patch titled
MIPS: AR7: ensure the port type's FCR value is used
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 0a5191efe06b5103909206e4fbcff81d30283f8e Mon Sep 17 00:00:00 2001
From: Jonas Gorski <jonas.gorski(a)gmail.com>
Date: Sun, 29 Oct 2017 16:27:21 +0100
Subject: MIPS: AR7: ensure the port type's FCR value is used
From: Jonas Gorski <jonas.gorski(a)gmail.com>
commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream.
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
trigger I/F of FIFO buffers"), the port's default FCR value isn't used
in serial8250_do_set_termios anymore, but copied over once in
serial8250_config_port and then modified as needed.
Unfortunately, serial8250_config_port will never be called if the port
is shared between kernel and userspace, and the port's flag doesn't have
UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
This causes garbled output from userspace:
[ 5.220000] random: procd urandom read with 49 bits of entropy available
ers
[kee
Fix this by forcing it to be configured on boot, resulting in the
expected output:
[ 5.250000] random: procd urandom read with 50 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com>
Cc: Florian Fainelli <f.fainelli(a)gmail.com>
Cc: Nicolas Schichan <nschichan(a)freebox.fr>
Cc: linux-mips(a)linux-mips.org
Cc: linux-serial(a)vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17544/
Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org>
Cc: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/ar7/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -581,7 +581,7 @@ static int __init ar7_register_uarts(voi
uart_port.type = PORT_AR7;
uart_port.uartclk = clk_get_rate(bus_clk) / 2;
uart_port.iotype = UPIO_MEM32;
- uart_port.flags = UPF_FIXED_TYPE;
+ uart_port.flags = UPF_FIXED_TYPE | UPF_BOOT_AUTOCONF;
uart_port.regshift = 2;
uart_port.line = 0;
Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are
queue-3.18/mips-ar7-ensure-the-port-type-s-fcr-value-is-used.patch
This is a note to let you know that I've just added the patch titled
serial: 8250_dw: Revert "Improve clock rate setting"
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the tty-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From c14b65feac9ebed649d6fe79c6b6d64d21d0287d Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Fri, 19 Jan 2018 18:02:05 +0200
Subject: serial: 8250_dw: Revert "Improve clock rate setting"
The commit
de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
obviously tries to cure symptoms, and not a root cause.
The root cause is the non-flexible rate calculation inside the
corresponding clock driver. What we need is to provide maximum UART
divisor value to the clock driver to allow it do the job transparently
to the caller.
Since from the initial commit message I have got no clue which clock
driver actually needs to be amended, I leave this exercise to the people
who know better the case.
Moreover, it seems [1] the fix introduced a regression. And possible
even one more [2].
Taking above, revert the commit de9e33bdfa22 for now.
[1]: https://www.spinics.net/lists/linux-serial/msg28872.html
[2]: https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782
Fixes: de9e33bdfa22 ("serial: 8250_dw: Improve clock rate setting")
Cc: stable <stable(a)vger.kernel.org> # 4.15
Cc: Ed Blake <ed.blake(a)sondrel.com>
Cc: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Cc: Lukas Wunner <lukas(a)wunner.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_dw.c | 30 ++++++++++++------------------
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index bda75d317d24..cd1b94a0f451 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -252,31 +252,25 @@ static void dw8250_set_termios(struct uart_port *p, struct ktermios *termios,
struct ktermios *old)
{
unsigned int baud = tty_termios_baud_rate(termios);
- unsigned int target_rate, min_rate, max_rate;
struct dw8250_data *d = p->private_data;
long rate;
- int i, ret;
+ int ret;
if (IS_ERR(d->clk) || !old)
goto out;
- /* Find a clk rate within +/-1.6% of an integer multiple of baudx16 */
- target_rate = baud * 16;
- min_rate = target_rate - (target_rate >> 6);
- max_rate = target_rate + (target_rate >> 6);
-
- for (i = 1; i <= UART_DIV_MAX; i++) {
- rate = clk_round_rate(d->clk, i * target_rate);
- if (rate >= i * min_rate && rate <= i * max_rate)
- break;
- }
- if (i <= UART_DIV_MAX) {
- clk_disable_unprepare(d->clk);
+ clk_disable_unprepare(d->clk);
+ rate = clk_round_rate(d->clk, baud * 16);
+ if (rate < 0)
+ ret = rate;
+ else if (rate == 0)
+ ret = -ENOENT;
+ else
ret = clk_set_rate(d->clk, rate);
- clk_prepare_enable(d->clk);
- if (!ret)
- p->uartclk = rate;
- }
+ clk_prepare_enable(d->clk);
+
+ if (!ret)
+ p->uartclk = rate;
out:
p->status &= ~UPSTAT_AUTOCTS;
--
2.16.0
The bounce buffer is gone from the MMC core, and now we found out
that there are some (crippled) i.MX boards out there that have broken
ADMA (cannot do scatter-gather), and also broken PIO so they must
use SDMA. Closer examination shows a less significant slowdown
also on SDMA-only capable Laptop hosts.
SDMA sets down the number of segments to one, so that each segment
gets turned into a singular request that ping-pongs to the block
layer before the next request/segment is issued.
Apparently it happens a lot that the block layer send requests
that include a lot of physically discontigous segments. My guess
is that this phenomenon is coming from the file system.
These devices that cannot handle scatterlists in hardware can see
major benefits from a DMA-contigous bounce buffer.
This patch accumulates those fragmented scatterlists in a physically
contigous bounce buffer so that we can issue bigger DMA data chunks
to/from the card.
When tested with thise PCI-integrated host (1217:8221) that
only supports SDMA:
0b:00.0 SD Host controller: O2 Micro, Inc. OZ600FJ0/OZ900FJ0/OZ600FJS
SD/MMC Card Reader Controller (rev 05)
This patch gave ~1Mbyte/s improved throughput on large reads and
writes when testing using iozone than without the patch.
dmesg:
sdhci-pci 0000:0b:00.0: SDHCI controller found [1217:8221] (rev 5)
mmc0 bounce up to 128 segments into one, max segment size 65536 bytes
mmc0: SDHCI controller on PCI [0000:0b:00.0] using DMA
On the i.MX SDHCI controllers on the crippled i.MX 25 and i.MX 35
the patch restores the performance to what it was before we removed
the bounce buffers, and then some: performance is better than ever
because we now allocate a bounce buffer the size of the maximum
single request the SDMA engine can handle. On the PCI laptop this
is 256K, whereas with the old bounce buffer code it was 64K max.
Cc: Benjamin Beckmeyer <beckmeyer.b(a)rittal.de>
Cc: Pierre Ossman <pierre(a)ossman.eu>
Cc: Benoît Thébaudeau <benoit(a)wsystem.com>
Cc: Fabio Estevam <fabio.estevam(a)nxp.com>
Cc: stable(a)vger.kernel.org
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
ChangeLog v5->v6:
- Again switch back to explicit sync of buffers. I want to get this
solution to work because it gives more control and it's more
elegant.
- Update host->max_req_size as noted by Adrian, hopefully this
fixes the i.MX. I was just lucky on my Intel laptop I guess:
the block stack never requested anything bigger than 64KB and
that was why it worked even if max_req_size was bigger than
what would fit in the bounce buffer.
- Copy the number of bytes in the mmc_data instead of the number
of bytes in the bounce buffer. For RX this is blksize * blocks
and for TX this is bytes_xfered.
- Break out a sdhci_sdma_address() for getting the DMA address
for either the raw sglist or the bounce buffer depending on
configuration.
- Add some explicit bounds check for the data so that we do not
attempt to copy more than the bounce buffer size even if the
block layer is erroneously configured.
- Move allocation of bounce buffer out to its own function.
- Use pr_[info|err] throughout so all debug prints from the
driver come out in the same manner and style.
- Use unsigned int for the bounce buffer size.
- Re-tested with iozone: we still get the same nice performance
improvements.
- Request a text on i.MX (hi Benjamin)
ChangeLog v4->v5:
- Go back to dma_alloc_coherent() as this apparently works better.
- Keep the other changes, cap for 64KB, fall back to single segments.
- Requesting a test of this on i.MX. (Sorry Benjamin.)
ChangeLog v3->v4:
- Cap the bounce buffer to 64KB instead of the biggest segment
as we experience diminishing returns with buffers > 64KB.
- Instead of using dma_alloc_coherent(), use good old devm_kmalloc()
and issue dma_sync_single_for*() to explicitly switch
ownership between CPU and the device. This way we exercise the
cache better and may consume less CPU.
- Bail out with single segments if we cannot allocate a bounce
buffer.
- Tested on the PCI SDHCI on my laptop: requesting a new test
on i.MX from Benjamin. (Please!)
ChangeLog v2->v3:
- Rewrite the commit message a bit
- Add Benjamin's Tested-by
- Add Fixes and stable tags
ChangeLog v1->v2:
- Skip the remapping and fiddling with the buffer, instead use
dma_alloc_coherent() and use a simple, coherent bounce buffer.
- Couple kernel messages to ->parent of the mmc_host as it relates
to the hardware characteristics.
---
drivers/mmc/host/sdhci.c | 162 ++++++++++++++++++++++++++++++++++++++++++++---
drivers/mmc/host/sdhci.h | 3 +
2 files changed, 157 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e9290a3439d5..26b93d72f56d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -21,6 +21,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/scatterlist.h>
+#include <linux/sizes.h>
#include <linux/swiotlb.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
@@ -502,8 +503,35 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host,
if (data->host_cookie == COOKIE_PRE_MAPPED)
return data->sg_count;
- sg_count = dma_map_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
- mmc_get_dma_dir(data));
+ /* Bounce write requests to the bounce buffer */
+ if (host->bounce_buffer) {
+ unsigned int length = data->blksz * data->blocks;
+
+ if (length > host->bounce_buffer_size) {
+ pr_err("%s: asked for transfer of %u bytes exceeds bounce buffer %u bytes\n",
+ mmc_hostname(host->mmc), length,
+ host->bounce_buffer_size);
+ return -EIO;
+ }
+ if (mmc_get_dma_dir(data) == DMA_TO_DEVICE) {
+ /* Copy the data to the bounce buffer */
+ sg_copy_to_buffer(data->sg, data->sg_len,
+ host->bounce_buffer,
+ length);
+ }
+ /* Switch ownership to the DMA */
+ dma_sync_single_for_device(host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ DMA_TO_DEVICE);
+ /* Just a dummy value */
+ sg_count = 1;
+ } else {
+ /* Just access the data directly from memory */
+ sg_count = dma_map_sg(mmc_dev(host->mmc),
+ data->sg, data->sg_len,
+ mmc_get_dma_dir(data));
+ }
if (sg_count == 0)
return -ENOSPC;
@@ -858,8 +886,13 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
SDHCI_ADMA_ADDRESS_HI);
} else {
WARN_ON(sg_cnt != 1);
- sdhci_writel(host, sg_dma_address(data->sg),
- SDHCI_DMA_ADDRESS);
+ /* Bounce buffer goes to work */
+ if (host->bounce_buffer)
+ sdhci_writel(host, host->bounce_addr,
+ SDHCI_DMA_ADDRESS);
+ else
+ sdhci_writel(host, sg_dma_address(data->sg),
+ SDHCI_DMA_ADDRESS);
}
}
@@ -2248,7 +2281,12 @@ static void sdhci_pre_req(struct mmc_host *mmc, struct mmc_request *mrq)
mrq->data->host_cookie = COOKIE_UNMAPPED;
- if (host->flags & SDHCI_REQ_USE_DMA)
+ /*
+ * No pre-mapping in the pre hook if we're using the bounce buffer,
+ * for that we would need two bounce buffers since one buffer is
+ * in flight when this is getting called.
+ */
+ if (host->flags & SDHCI_REQ_USE_DMA && !host->bounce_buffer)
sdhci_pre_dma_transfer(host, mrq->data, COOKIE_PRE_MAPPED);
}
@@ -2352,8 +2390,38 @@ static bool sdhci_request_done(struct sdhci_host *host)
struct mmc_data *data = mrq->data;
if (data && data->host_cookie == COOKIE_MAPPED) {
- dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
- mmc_get_dma_dir(data));
+ if (host->bounce_buffer) {
+ /*
+ * On reads, copy the bounced data into the
+ * sglist
+ */
+ if (mmc_get_dma_dir(data) == DMA_FROM_DEVICE) {
+ unsigned int length = data->bytes_xfered;
+
+ if (length > host->bounce_buffer_size) {
+ pr_err("%s: bounce buffer is %u bytes but DMA claims to have transferred %u bytes\n",
+ mmc_hostname(host->mmc),
+ host->bounce_buffer_size,
+ data->bytes_xfered);
+ /* Cap it down and continue */
+ length = host->bounce_buffer_size;
+ }
+ dma_sync_single_for_cpu(
+ host->mmc->parent,
+ host->bounce_addr,
+ host->bounce_buffer_size,
+ DMA_FROM_DEVICE);
+ sg_copy_from_buffer(data->sg,
+ data->sg_len,
+ host->bounce_buffer,
+ length);
+ }
+ } else {
+ /* Unmap the raw data */
+ dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+ data->sg_len,
+ mmc_get_dma_dir(data));
+ }
data->host_cookie = COOKIE_UNMAPPED;
}
}
@@ -2543,6 +2611,14 @@ static void sdhci_adma_show_error(struct sdhci_host *host)
}
}
+static u32 sdhci_sdma_address(struct sdhci_host *host)
+{
+ if (host->bounce_buffer)
+ return host->bounce_addr;
+ else
+ return sg_dma_address(host->data->sg);
+}
+
static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
{
u32 command;
@@ -2636,7 +2712,8 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 intmask)
*/
if (intmask & SDHCI_INT_DMA_END) {
u32 dmastart, dmanow;
- dmastart = sg_dma_address(host->data->sg);
+
+ dmastart = sdhci_sdma_address(host);
dmanow = dmastart + host->data->bytes_xfered;
/*
* Force update to the next DMA block boundary.
@@ -3217,6 +3294,68 @@ void __sdhci_read_caps(struct sdhci_host *host, u16 *ver, u32 *caps, u32 *caps1)
}
EXPORT_SYMBOL_GPL(__sdhci_read_caps);
+static int sdhci_allocate_bounce_buffer(struct sdhci_host *host)
+{
+ struct mmc_host *mmc = host->mmc;
+ unsigned int max_blocks;
+ unsigned int bounce_size;
+ int ret;
+
+ /*
+ * Cap the bounce buffer at 64KB. Using a bigger bounce buffer
+ * has diminishing returns, this is probably because SD/MMC
+ * cards are usually optimized to handle this size of requests.
+ */
+ bounce_size = SZ_64K;
+ /*
+ * Adjust downwards to maximum request size if this is less
+ * than our segment size, else hammer down the maximum
+ * request size to the maximum buffer size.
+ */
+ if (mmc->max_req_size < bounce_size)
+ bounce_size = mmc->max_req_size;
+ max_blocks = bounce_size / 512;
+
+ /*
+ * When we just support one segment, we can get significant
+ * speedups by the help of a bounce buffer to group scattered
+ * reads/writes together.
+ */
+ host->bounce_buffer = devm_kmalloc(mmc->parent,
+ bounce_size,
+ GFP_KERNEL);
+ if (!host->bounce_buffer) {
+ pr_err("%s: failed to allocate %u bytes for bounce buffer, falling back to single segments\n",
+ mmc_hostname(mmc),
+ bounce_size);
+ /*
+ * Exiting with zero here makes sure we proceed with
+ * mmc->max_segs == 1.
+ */
+ return 0;
+ }
+
+ host->bounce_addr = dma_map_single(mmc->parent,
+ host->bounce_buffer,
+ bounce_size,
+ DMA_BIDIRECTIONAL);
+ ret = dma_mapping_error(mmc->parent, host->bounce_addr);
+ if (ret)
+ /* Again fall back to max_segs == 1 */
+ return 0;
+ host->bounce_buffer_size = bounce_size;
+
+ /* Lie about this since we're bouncing */
+ mmc->max_segs = max_blocks;
+ mmc->max_seg_size = bounce_size;
+ mmc->max_req_size = bounce_size;
+
+ pr_info("%s bounce up to %u segments into one, max segment size %u bytes\n",
+ mmc_hostname(mmc), max_blocks, bounce_size);
+
+ return 0;
+}
+
int sdhci_setup_host(struct sdhci_host *host)
{
struct mmc_host *mmc;
@@ -3713,6 +3852,13 @@ int sdhci_setup_host(struct sdhci_host *host)
*/
mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535;
+ if (mmc->max_segs == 1) {
+ /* This may alter mmc->*_blk_* parameters */
+ ret = sdhci_allocate_bounce_buffer(host);
+ if (ret)
+ return ret;
+ }
+
return 0;
unreg:
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 54bc444c317f..1d7d61e25dbf 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -440,6 +440,9 @@ struct sdhci_host {
int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
+ char *bounce_buffer; /* For packing SDMA reads/writes */
+ dma_addr_t bounce_addr;
+ unsigned int bounce_buffer_size;
const struct sdhci_ops *ops; /* Low level hw interface */
--
2.14.3
This is a note to let you know that I've just added the patch titled
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 16 Jan 2018 10:23:47 +0000
Subject: arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kvm/handle_exit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -34,7 +34,7 @@ static int handle_hvc(struct kvm_vcpu *v
ret = kvm_psci_call(vcpu);
if (ret < 0) {
- kvm_inject_undefined(vcpu);
+ *vcpu_reg(vcpu, 0) = ~0UL;
return 1;
}
@@ -43,7 +43,7 @@ static int handle_hvc(struct kvm_vcpu *v
static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- kvm_inject_undefined(vcpu);
+ *vcpu_reg(vcpu, 0) = ~0UL;
return 1;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-3.18/arm64-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch