[PATCH 3.12 030/142] dccp: Unlock sock before calling sk_free()

[Jiri Slaby]

From: Arnaldo Carvalho de Melo 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit d5afb6f9b6bb2c57bd0c05e76e12489dc0d037d9 ]

The code where sk_clone() came from created a new socket and locked it,
but then, on the error path didn't unlock it.

This problem stayed there for a long while, till b0691c8ee7c2 ("net:
Unlock sock before calling sk_free()") fixed it, but unfortunately the
callers of sk_clone() (now sk_clone_locked()) were not audited and the
one in dccp_create_openreq_child() remained.

Now in the age of the syskaller fuzzer, this was finally uncovered, as
reported by Dmitry:

  8< 

I've got the following report while running syzkaller fuzzer on
86292b33d4b7 ("Merge branch 'akpm' (patches from Andrew)")

  [ BUG: held lock freed! ]
  4.10.0+ #234 Not tainted
  -
  syz-executor6/6898 is freeing memory
  88006286cac0-88006286d3b7, with a lock still held there!
   (slock-AF_INET6){+.-...}, at: [] spin_lock
  include/linux/spinlock.h:299 [inline]
   (slock-AF_INET6){+.-...}, at: []
  sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504
  5 locks held by syz-executor6/6898:
   #0:  (sk_lock-AF_INET6){+.+.+.}, at: [] lock_sock
  include/net/sock.h:1460 [inline]
   #0:  (sk_lock-AF_INET6){+.+.+.}, at: []
  inet_stream_connect+0x44/0xa0 net/ipv4/af_inet.c:681
   #1:  (rcu_read_lock){..}, at: []
  inet6_csk_xmit+0x12a/0x5d0 net/ipv6/inet6_connection_sock.c:126
   #2:  (rcu_read_lock){..}, at: [] __skb_unlink
  include/linux/skbuff.h:1767 [inline]
   #2:  (rcu_read_lock){..}, at: [] __skb_dequeue
  include/linux/skbuff.h:1783 [inline]
   #2:  (rcu_read_lock){..}, at: []
  process_backlog+0x264/0x730 net/core/dev.c:4835
   #3:  (rcu_read_lock){..}, at: []
  ip6_input_finish+0x0/0x1700 net/ipv6/ip6_input.c:59
   #4:  (slock-AF_INET6){+.-...}, at: [] spin_lock
  include/linux/spinlock.h:299 [inline]
   #4:  (slock-AF_INET6){+.-...}, at: []
  sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504

Fix it just like was done by b0691c8ee7c2 ("net: Unlock sock before calling
sk_free()").

Reported-by: Dmitry Vyukov 
Cc: Cong Wang 
Cc: Eric Dumazet 
Cc: Gerrit Renker 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170301153510.ge15...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 
---
 net/dccp/minisocks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/dccp/minisocks.c b/net/dccp/minisocks.c
index 662071b249cc..e47b15dd9b39 100644
--- a/net/dccp/minisocks.c
+++ b/net/dccp/minisocks.c
@@ -140,6 +140,7 @@ struct sock *dccp_create_openreq_child(struct sock *sk,
/* It is still raw copy of parent, so invalidate
 * destructor and make plain sk_free() */
newsk->sk_destruct = NULL;
+   bh_unlock_sock(newsk);
sk_free(newsk);
return NULL;
}
-- 
2.12.2

[PATCH 3.12 038/142] futex: Add missing error handling to FUTEX_REQUEUE_PI

[Jiri Slaby]

From: Peter Zijlstra 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 9bbb25afeb182502ca4f2c4f3f88af0681b34cae upstream.

Thomas spotted that fixup_pi_state_owner() can return errors and we
fail to unlock the rt_mutex in that case.

Reported-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Darren Hart 
Cc: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: xlp...@redhat.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170304093558.867401...@infradead.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Jiri Slaby 
---
 kernel/futex.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/futex.c b/kernel/futex.c
index 9667d9233289..566e2e0e56cf 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2496,6 +2496,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
if (q.pi_state && (q.pi_state->owner != current)) {
spin_lock(q.lock_ptr);
ret = fixup_pi_state_owner(uaddr2, &q, current);
+   if (ret && rt_mutex_owner(&q.pi_state->pi_mutex) == 
current)
+   rt_mutex_unlock(&q.pi_state->pi_mutex);
/*
 * Drop the reference to the pi state which
 * the requeue_pi() code acquired for us.
-- 
2.12.2

[PATCH 3.12 032/142] uapi: fix linux/packet_diag.h userspace compilation error

[Jiri Slaby]

From: "Dmitry V. Levin" 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 745cb7f8a5de0805cade3de3991b7a95317c7c73 ]

Replace MAX_ADDR_LEN with its numeric value to fix the following
linux/packet_diag.h userspace compilation error:

/usr/include/linux/packet_diag.h:67:17: error: 'MAX_ADDR_LEN' undeclared here 
(not in a function)
  __u8 pdmc_addr[MAX_ADDR_LEN];

This is not the first case in the UAPI where the numeric value
of MAX_ADDR_LEN is used instead of symbolic one, uapi/linux/if_link.h
already does the same:

$ grep MAX_ADDR_LEN include/uapi/linux/if_link.h
__u8 mac[32]; /* MAX_ADDR_LEN */

There are no UAPI headers besides these two that use MAX_ADDR_LEN.

Signed-off-by: Dmitry V. Levin 
Acked-by: Pavel Emelyanov 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 
---
 include/uapi/linux/packet_diag.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/packet_diag.h b/include/uapi/linux/packet_diag.h
index b2cc0cd9c4d9..1a9de73e845d 100644
--- a/include/uapi/linux/packet_diag.h
+++ b/include/uapi/linux/packet_diag.h
@@ -63,7 +63,7 @@ struct packet_diag_mclist {
__u32   pdmc_count;
__u16   pdmc_type;
__u16   pdmc_alen;
-   __u8pdmc_addr[MAX_ADDR_LEN];
+   __u8pdmc_addr[32]; /* MAX_ADDR_LEN */
 };
 
 struct packet_diag_ring {
-- 
2.12.2

[PATCH 3.12 033/142] ipv6: avoid write to a possibly cloned skb

[Jiri Slaby]

From: Florian Westphal 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 79e49503efe53a8c51d8b695bedc8a346c5e4a87 ]

ip6_fragment, in case skb has a fraglist, checks if the
skb is cloned.  If it is, it will move to the 'slow path' and allocates
new skbs for each fragment.

However, right before entering the slowpath loop, it updates the
nexthdr value of the last ipv6 extension header to NEXTHDR_FRAGMENT,
to account for the fragment header that will be inserted in the new
ipv6-fragment skbs.

In case original skb is cloned this munges nexthdr value of another
skb.  Avoid this by doing the nexthdr update for each of the new fragment
skbs separately.

This was observed with tcpdump on a bridge device where netfilter ipv6
reassembly is active:  tcpdump shows malformed fragment headers as
the l4 header (icmpv6, tcp, etc). is decoded as a fragment header.

Cc: Hannes Frederic Sowa 
Reported-by: Andreas Karis 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 
---
 net/ipv6/ip6_output.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index f5f86850a305..c5db1d52d542 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -716,7 +716,6 @@ slow_path:
 *  Fragment the datagram.
 */
 
-   *prevhdr = NEXTHDR_FRAGMENT;
hroom = LL_RESERVED_SPACE(rt->dst.dev);
troom = rt->dst.dev->needed_tailroom;
 
@@ -724,6 +723,8 @@ slow_path:
 *  Keep copying data until we run out.
 */
while(left > 0) {
+   u8 *fragnexthdr_offset;
+
len = left;
/* IF: it doesn't fit, use 'mtu' - the data space left */
if (len > mtu)
@@ -770,6 +771,10 @@ slow_path:
 */
skb_copy_from_linear_data(skb, skb_network_header(frag), hlen);
 
+   fragnexthdr_offset = skb_network_header(frag);
+   fragnexthdr_offset += prevhdr - skb_network_header(skb);
+   *fragnexthdr_offset = NEXTHDR_FRAGMENT;
+
/*
 *  Build fragment header.
 */
-- 
2.12.2

[PATCH 3.12 026/142] ipv4: mask tos for input route

[Jiri Slaby]

From: Julian Anastasov 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 6e28099d38c0e50d62c1afc054e37e573adf3d21 ]

Restore the lost masking of TOS in input route code to
allow ip rules to match it properly.

Problem [1] noticed by Shmulik Ladkani 

[1] http://marc.info/?t=137331755300040&r=1&w=2

Fixes: 89aef8921bfb ("ipv4: Delete routing cache.")
Signed-off-by: Julian Anastasov 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 
---
 net/ipv4/route.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index fd2811086257..1b180691086c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1881,6 +1881,7 @@ int ip_route_input_noref(struct sk_buff *skb, __be32 
daddr, __be32 saddr,
 {
int res;
 
+   tos &= IPTOS_RT_MASK;
rcu_read_lock();
 
/* Multicast recognition logic is moved from route cache to here.
-- 
2.12.2

Re: [PATCH -v6 13/13] futex: futex_lock_pi() vs PREEMPT_RT_FULL

[Darren Hart]

On Mon, Apr 10, 2017 at 11:08:18AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 07, 2017 at 07:26:10PM -0700, Darren Hart wrote:
> > Peter, I presume there will be a v7 with the u32 change and hopefully a 
> > couple
> > text updates?
> 
> Well, tglx already committed these here patches, so no -v7. What I can
> do however is do a follow up patch that fixes some of the in-code things
> you mentioned.
> 
> Something like the below is what I had lying about from your earlier
> emails; I've not looked to see if there's anything else from your later
> emails.
> 
> ---
> Subject: futex: Small misc fixes..
> From: Peter Zijlstra 
> Date: Fri Apr 7 09:04:07 CEST 2017
> 
> Feedback from Darren's review.
> 
> Reported-by: Darren Hart (VMWare) 
> Signed-off-by: Peter Zijlstra (Intel) 


OK, this addresses 2 of the big ones as I recall. I'll go through my feedback
and if I think anything else needs updating, I'll prepare a few patches.

Reviewed-by: Darren Hart (VMware) 

Thanks Peter!

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH 3.12 037/142] futex: Fix potential use-after-free in FUTEX_REQUEUE_PI

[Jiri Slaby]

From: Peter Zijlstra 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit c236c8e95a3d395b0494e7108f0d41cf36ec107c upstream.

While working on the futex code, I stumbled over this potential
use-after-free scenario. Dmitry triggered it later with syzkaller.

pi_mutex is a pointer into pi_state, which we drop the reference on in
unqueue_me_pi(). So any access to that pointer after that is bad.

Since other sites already do rt_mutex_unlock() with hb->lock held, see
for example futex_lock_pi(), simply move the unlock before
unqueue_me_pi().

Reported-by: Dmitry Vyukov 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Darren Hart 
Cc: juri.le...@arm.com
Cc: bige...@linutronix.de
Cc: xlp...@redhat.com
Cc: rost...@goodmis.org
Cc: mathieu.desnoy...@efficios.com
Cc: jdesfos...@efficios.com
Cc: dvh...@infradead.org
Cc: bris...@redhat.com
Link: http://lkml.kernel.org/r/20170304093558.801744...@infradead.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Jiri Slaby 
---
 kernel/futex.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 9c6394afd10f..9667d9233289 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2415,7 +2415,6 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
 {
struct hrtimer_sleeper timeout, *to = NULL;
struct rt_mutex_waiter rt_waiter;
-   struct rt_mutex *pi_mutex = NULL;
struct futex_hash_bucket *hb;
union futex_key key2 = FUTEX_KEY_INIT;
struct futex_q q = futex_q_init;
@@ -2505,6 +2504,8 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
spin_unlock(q.lock_ptr);
}
} else {
+   struct rt_mutex *pi_mutex;
+
/*
 * We have been woken up by futex_unlock_pi(), a timeout, or a
 * signal.  futex_unlock_pi() will not destroy the lock_ptr nor
@@ -2528,18 +2529,19 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
if (res)
ret = (res < 0) ? res : 0;
 
+   /*
+* If fixup_pi_state_owner() faulted and was unable to handle
+* the fault, unlock the rt_mutex and return the fault to
+* userspace.
+*/
+   if (ret && rt_mutex_owner(pi_mutex) == current)
+   rt_mutex_unlock(pi_mutex);
+
/* Unqueue and drop the lock. */
unqueue_me_pi(&q);
}
 
-   /*
-* If fixup_pi_state_owner() faulted and was unable to handle the
-* fault, unlock the rt_mutex and return the fault to userspace.
-*/
-   if (ret == -EFAULT) {
-   if (pi_mutex && rt_mutex_owner(pi_mutex) == current)
-   rt_mutex_unlock(pi_mutex);
-   } else if (ret == -EINTR) {
+   if (ret == -EINTR) {
/*
 * We've already been requeued, but cannot restart by calling
 * futex_lock_pi() directly. We could restart this syscall, but
-- 
2.12.2

[PATCH 3.12 045/142] crypto: cryptd - Assign statesize properly

[Jiri Slaby]

From: "Wang, Rui Y" 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 1a07834024dfca5c4bed5de8f8714306e0a11836 upstream.

cryptd_create_hash() fails by returning -EINVAL.  It is because after
8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers must have a non-zero statesize.

This patch fixes the problem by properly assigning the statesize.

Signed-off-by: Rui Wang 
Signed-off-by: Herbert Xu 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 crypto/cryptd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index d85fab975514..acbe1b978431 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -606,6 +606,7 @@ static int cryptd_create_hash(struct crypto_template *tmpl, 
struct rtattr **tb,
inst->alg.halg.base.cra_flags = CRYPTO_ALG_ASYNC;
 
inst->alg.halg.digestsize = salg->digestsize;
+   inst->alg.halg.statesize = salg->statesize;
inst->alg.halg.base.cra_ctxsize = sizeof(struct cryptd_hash_ctx);
 
inst->alg.halg.base.cra_init = cryptd_hash_init_tfm;
-- 
2.12.2

[PATCH 3.12 041/142] xfs: fix up xfs_swap_extent_forks inline extent handling

[Jiri Slaby]

From: Eric Sandeen 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 4dfce57db6354603641132fac3c887614e3ebe81 upstream.

There have been several reports over the years of NULL pointer
dereferences in xfs_trans_log_inode during xfs_fsr processes,
when the process is doing an fput and tearing down extents
on the temporary inode, something like:

BUG: unable to handle kernel NULL pointer dereference at 0018
PID: 29439  TASK: 880550584fa0  CPU: 6   COMMAND: "xfs_fsr"
[exception RIP: xfs_trans_log_inode+0x10]
 #9 [8800a57bbbe0] xfs_bunmapi at a037398e [xfs]

As it turns out, this is because the i_itemp pointer, along
with the d_ops pointer, has been overwritten with zeros
when we tear down the extents during truncate.  When the in-core
inode fork on the temporary inode used by xfs_fsr was originally
set up during the extent swap, we mistakenly looked at di_nextents
to determine whether all extents fit inline, but this misses extents
generated by speculative preallocation; we should be using if_bytes
instead.

This mistake corrupts the in-memory inode, and code in
xfs_iext_remove_inline eventually gets bad inputs, causing
it to memmove and memset incorrect ranges; this became apparent
because the two values in ifp->if_u2.if_inline_ext[1] contained
what should have been in d_ops and i_itemp; they were memmoved due
to incorrect array indexing and then the original locations
were zeroed with memset, again due to an array overrun.

Fix this by properly using i_df.if_bytes to determine the number
of extents, not di_nextents.

Thanks to dchinner for looking at this with me and spotting the
root cause.

[nborisov: Backported to 3.12]

Signed-off-by: Eric Sandeen 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
Signed-off-by: Nikolay Borisov 
Signed-off-by: Jiri Slaby 
---
 fs/xfs/xfs_bmap_util.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 42cb2f3ea51f..51df0cf5ea62 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1776,6 +1776,7 @@ xfs_swap_extents(
xfs_trans_t *tp;
xfs_bstat_t *sbp = &sxp->sx_stat;
xfs_ifork_t *tempifp, *ifp, *tifp;
+   xfs_extnum_tnextents;
int src_log_flags, target_log_flags;
int error = 0;
int aforkblks = 0;
@@ -1984,7 +1985,8 @@ xfs_swap_extents(
 * pointer.  Otherwise it's already NULL or
 * pointing to the extent.
 */
-   if (ip->i_d.di_nextents <= XFS_INLINE_EXTS) {
+   nextents = ip->i_df.if_bytes / (uint)sizeof(xfs_bmbt_rec_t);
+   if (nextents <= XFS_INLINE_EXTS) {
ifp->if_u1.if_extents =
ifp->if_u2.if_inline_ext;
}
@@ -2003,7 +2005,8 @@ xfs_swap_extents(
 * pointer.  Otherwise it's already NULL or
 * pointing to the extent.
 */
-   if (tip->i_d.di_nextents <= XFS_INLINE_EXTS) {
+   nextents = tip->i_df.if_bytes / (uint)sizeof(xfs_bmbt_rec_t);
+   if (nextents <= XFS_INLINE_EXTS) {
tifp->if_u1.if_extents =
tifp->if_u2.if_inline_ext;
}
-- 
2.12.2

[PATCH 3.12 053/142] cpufreq: Fix and clean up show_cpuinfo_cur_freq()

[Jiri Slaby]

From: "Rafael J. Wysocki" 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 9b4f603e7a9f4282aec451063ffbbb8bb410dcd9 upstream.

There is a missing newline in show_cpuinfo_cur_freq(), so add it,
but while at it clean that function up somewhat too.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Signed-off-by: Jiri Slaby 
---
 drivers/cpufreq/cpufreq.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index a7b2a5f53b2b..ac6ed021f2de 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -462,9 +462,11 @@ static ssize_t show_cpuinfo_cur_freq(struct cpufreq_policy 
*policy,
char *buf)
 {
unsigned int cur_freq = __cpufreq_get(policy->cpu);
-   if (!cur_freq)
-   return sprintf(buf, "");
-   return sprintf(buf, "%u\n", cur_freq);
+
+   if (cur_freq)
+   return sprintf(buf, "%u\n", cur_freq);
+
+   return sprintf(buf, "\n");
 }
 
 /**
-- 
2.12.2

[PATCH 3.12 043/142] netlink: remove mmapped netlink support

[Jiri Slaby]

From: Florian Westphal 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit d1b4c689d4130bcfd3532680b64db562300716b6 upstream.

mmapped netlink has a number of unresolved issues:

- TX zerocopy support had to be disabled more than a year ago via
  commit 4682a0358639b29cf ("netlink: Always copy on mmap TX.")
  because the content of the mmapped area can change after netlink
  attribute validation but before message processing.

- RX support was implemented mainly to speed up nfqueue dumping packet
  payload to userspace.  However, since commit ae08ce0021087a5d812d2
  ("netfilter: nfnetlink_queue: zero copy support") we avoid one copy
  with the socket-based interface too (via the skb_zerocopy helper).

The other problem is that skbs attached to mmaped netlink socket
behave different from normal skbs:

- they don't have a shinfo area, so all functions that use skb_shinfo()
(e.g. skb_clone) cannot be used.

- reserving headroom prevents userspace from seeing the content as
it expects message to start at skb->head.
See for instance
commit aa3a022094fa ("netlink: not trim skb for mmaped socket when dump").

- skbs handed e.g. to netlink_ack must have non-NULL skb->sk, else we
crash because it needs the sk to check if a tx ring is attached.

Also not obvious, leads to non-intuitive bug fixes such as 7c7bdf359
("netfilter: nfnetlink: use original skbuff when acking batches").

mmaped netlink also didn't play nicely with the skb_zerocopy helper
used by nfqueue and openvswitch.  Daniel Borkmann fixed this via
commit 6bb0fef489f6 ("netlink, mmap: fix edge-case leakages in nf queue
zero-copy")' but at the cost of also needing to provide remaining
length to the allocation function.

nfqueue also has problems when used with mmaped rx netlink:
- mmaped netlink doesn't allow use of nfqueue batch verdict messages.
  Problem is that in the mmap case, the allocation time also determines
  the ordering in which the frame will be seen by userspace (A
  allocating before B means that A is located in earlier ring slot,
  but this also means that B might get a lower sequence number then A
  since seqno is decided later.  To fix this we would need to extend the
  spinlocked region to also cover the allocation and message setup which
  isn't desirable.
- nfqueue can now be configured to queue large (GSO) skbs to userspace.
  Queing GSO packets is faster than having to force a software segmentation
  in the kernel, so this is a desirable option.  However, with a mmap based
  ring one has to use 64kb per ring slot element, else mmap has to fall back
  to the socket path (NL_MMAP_STATUS_COPY) for all large packets.

To use the mmap interface, userspace not only has to probe for mmap netlink
support, it also has to implement a recv/socket receive path in order to
handle messages that exceed the size of an rx ring element.

Cc: Daniel Borkmann 
Cc: Ken-ichirou MATSUZAWA 
Cc: Pablo Neira Ayuso 
Cc: Patrick McHardy 
Cc: Thomas Graf 
Signed-off-by: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 
---
 include/uapi/linux/netlink.h  |   4 +
 include/uapi/linux/netlink_diag.h |   2 +
 net/netlink/Kconfig   |   9 -
 net/netlink/af_netlink.c  | 726 +-
 net/netlink/af_netlink.h  |  15 -
 net/netlink/diag.c|  39 --
 6 files changed, 14 insertions(+), 781 deletions(-)

diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
index 1a85940f8ab7..8a8135c4e99a 100644
--- a/include/uapi/linux/netlink.h
+++ b/include/uapi/linux/netlink.h
@@ -106,8 +106,10 @@ struct nlmsgerr {
 #define NETLINK_PKTINFO3
 #define NETLINK_BROADCAST_ERROR4
 #define NETLINK_NO_ENOBUFS 5
+#ifndef __KERNEL__
 #define NETLINK_RX_RING6
 #define NETLINK_TX_RING7
+#endif
 
 struct nl_pktinfo {
__u32   group;
@@ -130,6 +132,7 @@ struct nl_mmap_hdr {
__u32   nm_gid;
 };
 
+#ifndef __KERNEL__
 enum nl_mmap_status {
NL_MMAP_STATUS_UNUSED,
NL_MMAP_STATUS_RESERVED,
@@ -141,6 +144,7 @@ enum nl_mmap_status {
 #define NL_MMAP_MSG_ALIGNMENT  NLMSG_ALIGNTO
 #define NL_MMAP_MSG_ALIGN(sz)  __ALIGN_KERNEL(sz, 
NL_MMAP_MSG_ALIGNMENT)
 #define NL_MMAP_HDRLEN NL_MMAP_MSG_ALIGN(sizeof(struct 
nl_mmap_hdr))
+#endif
 
 #define NET_MAJOR 36   /* Major 36 is reserved for networking  
*/
 
diff --git a/include/uapi/linux/netlink_diag.h 
b/include/uapi/linux/netlink_diag.h
index 4e31db4eea41..01d7ff3b92dc 100644
--- a/include/uapi/linux/netlink_diag.h
+++ b/include/uapi/linux/netlink_diag.h
@@ -47,6 +47,8 @@ enum {
 
 #define NDIAG_SHOW_MEMINFO 0x0001 /* show memory info of a socket */
 #define NDIAG_SHOW_GROUPS  0x0002 /* show groups of a netlink socket */
+#ifndef __KERNEL__
 #define NDIAG_SHOW_RING_CFG0x0004 /* show ring co

Re: [RFC 6/8] nvmet: Be careful about using iomem accesses when dealing with p2pmem

[Logan Gunthorpe]

On 10/04/17 02:29 AM, Sagi Grimberg wrote:
> What you are saying is surprising to me. The switch needs to preserve
> ordering across different switch ports ??

> You are suggesting that there is a *switch-wide* state that tracks
> MemRds never pass MemWrs across all the switch ports? That is a very
> non-trivial statement...

Yes, it is a requirement of the PCIe spec for transactions to be
strongly ordered throughout the fabric so switches must have an internal
state across all ports. Without that, it would be impossible to have PCI
cards work together even if they are using system memory to do so. Also,
I believe, it was done this way to maintain maximum compatibility with
the legacy PCI bus. There is also a relaxed ordering bit that allows
specific transactions to ignore ordering which can help performance.

Obviously this becomes impossible if you have some kind of complex
multi-path fabric.

Logan

[PATCH 3.12 054/142] target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export

[Jiri Slaby]

From: Nicholas Bellinger 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit a04e54f2c35823ca32d56afcd5cea5b783e2f51a upstream.

The following fixes a divide by zero OOPs with TYPE_TAPE
due to pscsi_tape_read_blocksize() failing causing a zero
sd->sector_size being propigated up via dev_attrib.hw_block_size.

It also fixes another long-standing bug where TYPE_TAPE and
TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(),
which does not call scsi_device_get() to take the device
reference.  Instead, rename pscsi_create_type_rom() to
pscsi_create_type_nondisk() and use it for all cases.

Finally, also drop a dump_stack() in pscsi_get_blocks() for
non TYPE_DISK, which in modern target-core can get invoked
via target_sense_desc_format() during CHECK_CONDITION.

[js] cast max_sectors to unsigned to avoid warnings

Reported-by: Malcolm Haak 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Jiri Slaby 
---
 drivers/target/target_core_pscsi.c | 47 ++
 1 file changed, 12 insertions(+), 35 deletions(-)

diff --git a/drivers/target/target_core_pscsi.c 
b/drivers/target/target_core_pscsi.c
index 9b90cfacf75c..a67877503234 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -157,7 +157,7 @@ static void pscsi_tape_read_blocksize(struct se_device *dev,
 
buf = kzalloc(12, GFP_KERNEL);
if (!buf)
-   return;
+   goto out_free;
 
memset(cdb, 0, MAX_COMMAND_SIZE);
cdb[0] = MODE_SENSE;
@@ -172,9 +172,10 @@ static void pscsi_tape_read_blocksize(struct se_device 
*dev,
 * If MODE_SENSE still returns zero, set the default value to 1024.
 */
sdev->sector_size = (buf[9] << 16) | (buf[10] << 8) | (buf[11]);
+out_free:
if (!sdev->sector_size)
sdev->sector_size = 1024;
-out_free:
+
kfree(buf);
 }
 
@@ -317,9 +318,10 @@ static int pscsi_add_device_to_list(struct se_device *dev,
sd->lun, sd->queue_depth);
}
 
-   dev->dev_attrib.hw_block_size = sd->sector_size;
+   dev->dev_attrib.hw_block_size =
+   min_not_zero((int)sd->sector_size, 512);
dev->dev_attrib.hw_max_sectors =
-   min_t(int, sd->host->max_sectors, queue_max_hw_sectors(q));
+   min_not_zero((unsigned)sd->host->max_sectors, 
queue_max_hw_sectors(q));
dev->dev_attrib.hw_queue_depth = sd->queue_depth;
 
/*
@@ -342,8 +344,10 @@ static int pscsi_add_device_to_list(struct se_device *dev,
/*
 * For TYPE_TAPE, attempt to determine blocksize with MODE_SENSE.
 */
-   if (sd->type == TYPE_TAPE)
+   if (sd->type == TYPE_TAPE) {
pscsi_tape_read_blocksize(dev, sd);
+   dev->dev_attrib.hw_block_size = sd->sector_size;
+   }
return 0;
 }
 
@@ -409,7 +413,7 @@ static int pscsi_create_type_disk(struct se_device *dev, 
struct scsi_device *sd)
 /*
  * Called with struct Scsi_Host->host_lock called.
  */
-static int pscsi_create_type_rom(struct se_device *dev, struct scsi_device *sd)
+static int pscsi_create_type_nondisk(struct se_device *dev, struct scsi_device 
*sd)
__releases(sh->host_lock)
 {
struct pscsi_hba_virt *phv = dev->se_hba->hba_ptr;
@@ -436,28 +440,6 @@ static int pscsi_create_type_rom(struct se_device *dev, 
struct scsi_device *sd)
return 0;
 }
 
-/*
- * Called with struct Scsi_Host->host_lock called.
- */
-static int pscsi_create_type_other(struct se_device *dev,
-   struct scsi_device *sd)
-   __releases(sh->host_lock)
-{
-   struct pscsi_hba_virt *phv = dev->se_hba->hba_ptr;
-   struct Scsi_Host *sh = sd->host;
-   int ret;
-
-   spin_unlock_irq(sh->host_lock);
-   ret = pscsi_add_device_to_list(dev, sd);
-   if (ret)
-   return ret;
-
-   pr_debug("CORE_PSCSI[%d] - Added Type: %s for %d:%d:%d:%d\n",
-   phv->phv_host_id, scsi_device_type(sd->type), sh->host_no,
-   sd->channel, sd->id, sd->lun);
-   return 0;
-}
-
 static int pscsi_configure_device(struct se_device *dev)
 {
struct se_hba *hba = dev->se_hba;
@@ -545,11 +527,8 @@ static int pscsi_configure_device(struct se_device *dev)
case TYPE_DISK:
ret = pscsi_create_type_disk(dev, sd);
break;
-   case TYPE_ROM:
-   ret = pscsi_create_type_rom(dev, sd);
-   break;
default:
-   ret = pscsi_create_type_other(dev, sd);
+   ret = pscsi_create_type_nondisk(dev, sd);
break;
}
 
@@ -606,8 +585,7 @@ static void pscsi_free_device(struct se_device *dev)
else if (pdv->pdv_lld_host)
scsi_host_put(pdv->pdv_lld_host);
 
-   if ((sd->type == TYPE_DI

Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

[Thomas Gleixner]

On Mon, 10 Apr 2017, alexander.le...@verizon.com wrote:
> On Wed, Mar 22, 2017 at 11:35:58AM +0100, Peter Zijlstra wrote:
> > By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive
> > at a point where all wait_list modifications are done under both
> > hb->lock and wait_lock.
> [...]
> 
> Hey Peter,
> 
> I'm seeing the following, which seems to be related to this patch:
> 
> [   21.762875] ODEBUG: free active (active state 0) object type: hrtimer 
> hint: hrtimer_wakeup (kernel/time/hrtimer.c:1423)

> [   21.788050] debug_object_free (lib/debugobjects.c:603)
> [   21.791105] destroy_hrtimer_on_stack (kernel/time/hrtimer.c:427)
> [   21.791746] futex_lock_pi (kernel/futex.c:2740)
> [   21.800721] do_futex (kernel/futex.c:3399)
> [   21.818395] SyS_futex (kernel/futex.c:3447 kernel/futex.c:3415)
> [   21.822260] do_syscall_64 (arch/x86/entry/common.c:284)
> [   21.827328] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)

Yep, that rework dropped the hrtimer cancel. Fix below.

Thanks,

tglx

8<

diff --git a/kernel/futex.c b/kernel/futex.c
index c3eebcdac206..7ac167683c9f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2736,8 +2736,10 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int 
flags,
 out_put_key:
put_futex_key(&q.key);
 out:
-   if (to)
+   if (to) {
+   hrtimer_cancel(&to->timer);
destroy_hrtimer_on_stack(&to->timer);
+   }
return ret != -EINTR ? ret : -ERESTARTNOINTR;
 
 uaddr_faulted:

[PATCH 3.12 044/142] crypto: ghash-clmulni - Fix load failure

[Jiri Slaby]

From: "Wang, Rui Y" 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 3a020a723c65eb8ffa7c237faca26521a024e582 upstream.

ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
"modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"

After 8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers are required to implement import()/export(), and must have a non-
zero statesize.

This patch has been tested with the algif_hash interface. The calculated
digest values, after several rounds of import()s and export()s, match those
calculated by tcrypt.

Signed-off-by: Rui Wang 
Signed-off-by: Herbert Xu 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 arch/x86/crypto/ghash-clmulni-intel_glue.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/x86/crypto/ghash-clmulni-intel_glue.c 
b/arch/x86/crypto/ghash-clmulni-intel_glue.c
index 4bcf841e4701..3deb8e533359 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_glue.c
+++ b/arch/x86/crypto/ghash-clmulni-intel_glue.c
@@ -218,6 +218,29 @@ static int ghash_async_final(struct ahash_request *req)
}
 }
 
+static int ghash_async_import(struct ahash_request *req, const void *in)
+{
+   struct ahash_request *cryptd_req = ahash_request_ctx(req);
+   struct shash_desc *desc = cryptd_shash_desc(cryptd_req);
+   struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
+
+   ghash_async_init(req);
+   memcpy(dctx, in, sizeof(*dctx));
+   return 0;
+
+}
+
+static int ghash_async_export(struct ahash_request *req, void *out)
+{
+   struct ahash_request *cryptd_req = ahash_request_ctx(req);
+   struct shash_desc *desc = cryptd_shash_desc(cryptd_req);
+   struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
+
+   memcpy(out, dctx, sizeof(*dctx));
+   return 0;
+
+}
+
 static int ghash_async_digest(struct ahash_request *req)
 {
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
@@ -285,8 +308,11 @@ static struct ahash_alg ghash_async_alg = {
.final  = ghash_async_final,
.setkey = ghash_async_setkey,
.digest = ghash_async_digest,
+   .export = ghash_async_export,
+   .import = ghash_async_import,
.halg = {
.digestsize = GHASH_DIGEST_SIZE,
+   .statesize = sizeof(struct ghash_desc_ctx),
.base = {
.cra_name   = "ghash",
.cra_driver_name= "ghash-clmulni",
-- 
2.12.2

[PATCH 3.12 055/142] scsi: lpfc: Add shutdown method for kexec

[Jiri Slaby]

From: Anton Blanchard 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 85e8a23936ab3442de0c42da97d53b29f004ece1 upstream.

We see lpfc devices regularly fail during kexec. Fix this by adding a
shutdown method which mirrors the remove method.

Signed-off-by: Anton Blanchard 
Reviewed-by: Mauricio Faria de Oliveira 
Tested-by: Mauricio Faria de Oliveira 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Jiri Slaby 
---
 drivers/scsi/lpfc/lpfc_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 3b73eea72946..7656f8b46649 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -10907,6 +10907,7 @@ static struct pci_driver lpfc_driver = {
.id_table   = lpfc_id_table,
.probe  = lpfc_pci_probe_one,
.remove = lpfc_pci_remove_one,
+   .shutdown   = lpfc_pci_remove_one,
.suspend= lpfc_pci_suspend_one,
.resume = lpfc_pci_resume_one,
.err_handler= &lpfc_err_handler,
-- 
2.12.2

[PATCH 3.12 048/142] Drivers: hv: avoid vfree() on crash

[Jiri Slaby]

From: Vitaly Kuznetsov 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit a9f61ca793becabdefab03b77568d6c6f8c1bc79 upstream.

When we crash from NMI context (e.g. after NMI injection from host when
'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit

kernel BUG at mm/vmalloc.c:1530!

as vfree() is denied. While the issue could be solved with in_nmi() check
instead I opted for skipping vfree on all sorts of crashes to reduce the
amount of work which can cause consequent crashes. We don't really need to
free anything on crash.

[js] no tsc and kexec in 3.12 yet

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 drivers/hv/hv.c   | 5 +++--
 drivers/hv/hyperv_vmbus.h | 2 +-
 drivers/hv/vmbus_drv.c| 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 9c0d458ec232..24d3ceec9d0a 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -193,7 +193,7 @@ cleanup:
  *
  * This routine is called normally during driver unloading or exiting.
  */
-void hv_cleanup(void)
+void hv_cleanup(bool crash)
 {
union hv_x64_msr_hypercall_contents hypercall_msr;
 
@@ -203,7 +203,8 @@ void hv_cleanup(void)
if (hv_context.hypercall_page) {
hypercall_msr.as_uint64 = 0;
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
-   vfree(hv_context.hypercall_page);
+   if (!crash)
+   vfree(hv_context.hypercall_page);
hv_context.hypercall_page = NULL;
}
 }
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index d84918fe19ab..862004c15c41 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -519,7 +519,7 @@ extern struct hv_context hv_context;
 
 extern int hv_init(void);
 
-extern void hv_cleanup(void);
+extern void hv_cleanup(bool crash);
 
 extern int hv_post_message(union hv_connection_id connection_id,
 enum hv_message_type message_type,
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index d13f3dda6769..37f697fcf477 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -622,7 +622,7 @@ err_unregister:
bus_unregister(&hv_bus);
 
 err_cleanup:
-   hv_cleanup();
+   hv_cleanup(false);
 
return ret;
 }
@@ -845,7 +845,7 @@ static void __exit vmbus_exit(void)
free_irq(irq, hv_acpi_dev);
vmbus_free_channels();
bus_unregister(&hv_bus);
-   hv_cleanup();
+   hv_cleanup(false);
acpi_bus_unregister_driver(&vmbus_acpi_driver);
hv_cpu_hotplug_quirk(false);
 }
-- 
2.12.2

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

[Michal Hocko]

On Mon 10-04-17 16:27:49, Igor Mammedov wrote:
[...]
> #issue3:
> removable flag flipped to non-removable state
> 
> // before series at commit ef0b577b6:
> memory32:offline removable: 0  zones: Normal Movable
> memory33:offline removable: 0  zones: Normal Movable
> memory34:offline removable: 0  zones: Normal Movable
> memory35:offline removable: 0  zones: Normal Movable

did you mean _after_ the series because the bellow looks like
the original behavior (at least valid_zones).
 
> // after series at commit 6a010434
> memory32:offline removable: 1  zones: Normal
> memory33:offline removable: 1  zones: Normal
> memory34:offline removable: 1  zones: Normal
> memory35:offline removable: 1  zones: Normal Movable
> 
> also looking at #issue1 removable flag state doesn't
> seem to be consistent between state changes but maybe that's
> been broken before

Well, the file has a very questionable semantic. It doesn't provide
a stable information. Anyway put that aside.
is_pageblock_removable_nolock relies on having zone association
which we do not have yet if the memblock is offline. So we need
the following. I will queue this as a preparatory patch.
---
>From 4f3ebc02f4d552d3fe114787ca8a38cc68702208 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Mon, 10 Apr 2017 17:59:03 +0200
Subject: [PATCH] mm, memory_hotplug: consider offline memblocks removable

is_pageblock_removable_nolock relies on having zone association to
examine all the page blocks to check whether they are movable or free.
This is just wasting of cycles when the memblock is offline. Later patch
in the series will also change the time when the page is associated with
a zone so we let's bail out early if the memblock is offline.

Reported-by: Igor Mammedov 
Signed-off-by: Michal Hocko 
---
 drivers/base/memory.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 9677b6b711b0..0c29ec5598ea 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -128,6 +128,9 @@ static ssize_t show_mem_removable(struct device *dev,
int ret = 1;
struct memory_block *mem = to_memory_block(dev);
 
+   if (mem->stat != MEM_ONLINE)
+   goto out;
+
for (i = 0; i < sections_per_block; i++) {
if (!present_section_nr(mem->start_section_nr + i))
continue;
@@ -135,6 +138,7 @@ static ssize_t show_mem_removable(struct device *dev,
ret &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
}
 
+out:
return sprintf(buf, "%d\n", ret);
 }
 
-- 
2.11.0


-- 
Michal Hocko
SUSE Labs

[PATCH 3.12 056/142] isdn/gigaset: fix NULL-deref at probe

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 68c32f9c2a36d410aa242e661506e5b2c2764179 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers - direct USB 
connection")
Cc: Hansjoerg Lipp 
Signed-off-by: Johan Hovold 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 
---
 drivers/isdn/gigaset/bas-gigaset.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/isdn/gigaset/bas-gigaset.c 
b/drivers/isdn/gigaset/bas-gigaset.c
index c44950d3eb7b..6d4d9c1c2cf0 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -2317,6 +2317,9 @@ static int gigaset_probe(struct usb_interface *interface,
return -ENODEV;
}
 
+   if (hostif->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
dev_info(&udev->dev,
 "%s: Device matched (Vendor: 0x%x, Product: 0x%x)\n",
 __func__, le16_to_cpu(udev->descriptor.idVendor),
-- 
2.12.2

Re: [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions

[Boris Brezillon]

On Mon, 10 Apr 2017 17:10:11 +0200
Thierry Reding  wrote:

> On Mon, Apr 10, 2017 at 04:35:58PM +0200, Boris Brezillon wrote:
> > On Mon, 10 Apr 2017 17:20:20 +0300
> > Claudiu Beznea  wrote:
> >   
> > > Implement suspend and resume power management specific
> > > function to allow PWM controller to correctly suspend
> > > and resume.
> > > 
> > > Signed-off-by: Claudiu Beznea 
> > > ---
> > >  drivers/pwm/pwm-atmel.c | 81 
> > > +
> > >  1 file changed, 81 insertions(+)
> > > 
> > > diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> > > index 530d7dc..75177c6 100644
> > > --- a/drivers/pwm/pwm-atmel.c
> > > +++ b/drivers/pwm/pwm-atmel.c
> > > @@ -58,6 +58,8 @@
> > >  #define PWM_MAX_PRD  0x
> > >  #define PRD_MAX_PRES 10
> > >  
> > > +#define PWM_MAX_CH_NUM   (4)
> > > +
> > >  struct atmel_pwm_registers {
> > >   u8 period;
> > >   u8 period_upd;
> > > @@ -65,11 +67,18 @@ struct atmel_pwm_registers {
> > >   u8 duty_upd;
> > >  };
> > >  
> > > +struct atmel_pwm_pm_ctx {
> > > + u32 cmr;
> > > + u32 cdty;
> > > + u32 cprd;
> > > +};
> > > +
> > >  struct atmel_pwm_chip {
> > >   struct pwm_chip chip;
> > >   struct clk *clk;
> > >   void __iomem *base;
> > >   const struct atmel_pwm_registers *regs;
> > > + struct atmel_pwm_pm_ctx ctx[PWM_MAX_CH_NUM];  
> > 
> > Hm, I'm pretty sure you can rely on the current PWM state and call
> > atmel_pwm_apply() at resume time instead of doing that. See what I did
> > here [1].
> > 
> > Thierry, maybe it's time to start thinking about a generic solution to
> > save/restore PWM states.  
> 
> Generally speaking I think applying the states are the right way to go.
> Ideally the PWM core could simply resume all of the PWM channels that a
> device exports and the ->apply() callback would be enough to restore
> that. I'm not sure if that's going to work with current implementations,
> though. Your pwm-atmel-hlcdc patch certainly indicates that we're not
> quite there yet.
> 
> On the other hand, I'm beginning to think that maybe PWMs are too low-
> level for this kind of suspend/resume. For example if you use the PWM to
> control a backlight brightness, restoring it via the driver core's
> resume hook is potentially going to turn it back on at the wrong time. I
> have a feeling that we might be better off just pushing this up to the
> PWM users. A slight special case might be sysfs, for which no external
> user driver exists. But we already have separate data structures to keep
> track of sysfs-related context, so suspend/resume support could be added
> there.

Yep, you're probably right, we should let the PWM user take care of
re-applying the PWM state, because it's the only one having enough
knowledge about what the PWM is really driving to take a wise decision.

This goes against my patch adding suspend/resume hooks to the
pwm-atmel-hlcdc driver, but we can easily drop the call to
atmel_hlcdc_pwm_apply() in ->resume() once we have patched the
pwm-backlight driver to take care of that.

[PATCH 3.12 047/142] Drivers: hv: balloon: don't crash when memory is added in non-sorted order

[Jiri Slaby]

From: Vitaly Kuznetsov 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 77c0c9735bc0ba5898e637a3a20d6bcb50e3f67d upstream.

When we iterate through all HA regions in handle_pg_range() we have an
assumption that all these regions are sorted in the list and the
'start_pfn >= has->end_pfn' check is enough to find the proper region.
Unfortunately it's not the case with WS2016 where host can hot-add regions
in a different order. We end up modifying the wrong HA region and crashing
later on pages online. Modify the check to make sure we found the region
we were searching for while iterating. Fix the same check in pfn_covered()
as well.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 drivers/hv/hv_balloon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 393fd8a98735..17109ce27fe8 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -673,7 +673,7 @@ static bool pfn_covered(unsigned long start_pfn, unsigned 
long pfn_cnt)
 * If the pfn range we are dealing with is not in the current
 * "hot add block", move on.
 */
-   if ((start_pfn >= has->end_pfn))
+   if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
continue;
/*
 * If the current hot add-request extends beyond
@@ -728,7 +728,7 @@ static unsigned long handle_pg_range(unsigned long pg_start,
 * If the pfn range we are dealing with is not in the current
 * "hot add block", move on.
 */
-   if ((start_pfn >= has->end_pfn))
+   if (start_pfn < has->start_pfn || start_pfn >= has->end_pfn)
continue;
 
old_covered_state = has->covered_end_pfn;
-- 
2.12.2

Re: [kernel-hardening] Re: [RFC v2][PATCH 04/11] x86: Implement __arch_rare_write_begin/unmap()

[Andy Lutomirski]

On Mon, Apr 10, 2017 at 3:42 AM, PaX Team  wrote:
> On 9 Apr 2017 at 17:10, Andy Lutomirski wrote:
>
>> On Sun, Apr 9, 2017 at 5:47 AM, PaX Team  wrote:
>> > on x86 the cost of the pax_open/close_kernel primitives comes from the cr0
>> > writes and nothing else, use_mm suffers not only from the cr3 writes but
>> > also locking/atomic ops and cr4 writes on its path and the inevitable TLB
>> > entry costs. and if cpu vendors cared enough, they could make toggling 
>> > cr0.wp
>> > a fast path in the microcode and reduce its overhead by an order of 
>> > magnitude.
>> >
>>
>> If the CR4 writes happen in for this use case, that's a bug.
>
> that depends on how you plan to handle perf/rdpmc users and how many
> alternative mm structs you plan to manage (one global, one per cpu,
> one per mm struct, etc).
>

I was thinking one global unless more are needed for some reason.

>> > you'll be duplicating TLB entries in the alternative PCID for both code
>> > and data, where they will accumulate (=take room away from the normal PCID
>> > and expose unwanted memory for access) unless you also flush them when
>> > switching back (which then will cost even more cycles). also i'm not sure
>> > that processors implement all the 12 PCID bits so depending on how many 
>> > PCIDs
>> > you plan to use, you could be causing even more unnecessary TLB 
>> > replacements.
>> >
>>
>> Unless the CPU is rather dumber than I expect, the only duplicated
>> entries should be for the writable aliases of pages that are written.
>> The rest of the pages are global and should be shared for all PCIDs.
>
> well, 4.10.2.4 has language like this (4.10.3.2 implies similar):
>
>A logical processor may use a global TLB entry to translate a linear
>address, even if the TLB entry is associated with a PCID different
>from the current PCID.

I read this as: the CPU still semantically tags global TLB entries
with a PCID, but the CPU will use (probably) use those TLB entries
even if the PCIDs don't match.  IIRC none of the TLB instructions have
any effect that makes the PCID associated with a global entry visible,
so the CPU could presumably omit the PCID tags entirely for global
entries.  E.g. I don't think there's any way to say "flush global
entries with a given PCID".

--Andy

[PATCH 3.12 057/142] xen: do not re-use pirq number cached in pci device msi msg data

[Jiri Slaby]

From: Dan Streetman 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit c74fd80f2f41d05f350bb478151021f88551afe8 ]

Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")

That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq.  At the time, that was the correct behavior.  However, a
later change to Qemu caused it to call into the Xen hypervisor to unmap
all pirqs for a pci device, when the pci device disables its MSI/MSIX
vectors; specifically the Qemu commit:
c976437c7dba9c7444fb41df45468968aaa326ad
("qemu-xen: free all the pirqs for msi/msix when driver unload")

Once Qemu added this pirq unmapping, it was no longer correct for the
kernel to re-use the pirq number cached in the pci device msi message
data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
pirqs when the pci device disables its MSI/MSIX vectors.

This bug is causing failures to initialize multiple NVMe controllers
under Xen, because the NVMe driver sets up a single MSIX vector for
each controller (concurrently), and then after using that to talk to
the controller for some configuration data, it disables the single MSIX
vector and re-configures all the MSIX vectors it needs.  So the MSIX
setup code tries to re-use the cached pirq from the first vector
for each controller, but the hypervisor has already given away that
pirq to another controller, and its initialization fails.

This is discussed in more detail at:
https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html

Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
Signed-off-by: Dan Streetman 
Reviewed-by: Stefano Stabellini 
Acked-by: Konrad Rzeszutek Wilk 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Sasha Levin 
Signed-off-by: Jiri Slaby 
---
 arch/x86/pci/xen.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 48e8461057ba..6e4580b87600 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -227,23 +227,14 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, 
int nvec, int type)
return 1;
 
list_for_each_entry(msidesc, &dev->msi_list, list) {
-   __read_msi_msg(msidesc, &msg);
-   pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
-   ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
-   if (msg.data != XEN_PIRQ_MSI_DATA ||
-   xen_irq_from_pirq(pirq) < 0) {
-   pirq = xen_allocate_pirq_msi(dev, msidesc);
-   if (pirq < 0) {
-   irq = -ENODEV;
-   goto error;
-   }
-   xen_msi_compose_msg(dev, pirq, &msg);
-   __write_msi_msg(msidesc, &msg);
-   dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
-   } else {
-   dev_dbg(&dev->dev,
-   "xen: msi already bound to pirq=%d\n", pirq);
+   pirq = xen_allocate_pirq_msi(dev, msidesc);
+   if (pirq < 0) {
+   irq = -ENODEV;
+   goto error;
}
+   xen_msi_compose_msg(dev, pirq, &msg);
+   __write_msi_msg(msidesc, &msg);
+   dev_dbg(&dev->dev, "xen: msi bound to pirq=%d\n", pirq);
irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
   (type == PCI_CAP_ID_MSIX) ?
   "msi-x" : "msi",
-- 
2.12.2

[PATCH 3.12 040/142] cancel the setfilesize transation when io error happen

[Jiri Slaby]

From: Zhaohongjiang 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

Commit 5cb13dcd0fac071b45c4bebe1801a08ff0d89cad upstream.

When I ran xfstest/073 case, the remount process was blocked to wait
transactions to be zero. I found there was a io error happened, and
the setfilesize transaction was not released properly. We should add
the changes to cancel the io error in this case.

Reproduction steps:
1. dd if=/dev/zero of=xfs1.img bs=1M count=2048
2. mkfs.xfs xfs1.img
3. losetup -f ./xfs1.img /dev/loop0
4. mount -t xfs /dev/loop0 /home/test_dir/
5. mkdir /home/test_dir/test
6. mkfs.xfs -dfile,name=image,size=2g
7. mount -t xfs -o loop image /home/test_dir/test
8. cp a file bigger than 2g to /home/test_dir/test
9. mount -t xfs -o remount,ro /home/test_dir/test

[ dchinner: moved io error detection to xfs_setfilesize_ioend() after
  transaction context restoration. ]

[ nborisov: Adjusted context for 3.12 ]

Signed-off-by: Zhao Hongjiang 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Nikolay Borisov 
Signed-off-by: Jiri Slaby 
---
 fs/xfs/xfs_aops.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index ab28ad576b16..6394e3f51553 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -150,6 +150,12 @@ xfs_setfilesize(
rwsem_acquire_read(&VFS_I(ip)->i_sb->s_writers.lock_map[SB_FREEZE_FS-1],
   0, 1, _THIS_IP_);
 
+   /* we abort the update if there was an IO error */
+   if (ioend->io_error) {
+   xfs_trans_cancel(tp, 0);
+   return ioend->io_error;
+   }
+
xfs_ilock(ip, XFS_ILOCK_EXCL);
isize = xfs_new_eof(ip, ioend->io_offset + ioend->io_size);
if (!isize) {
@@ -205,14 +211,17 @@ xfs_end_io(
ioend->io_error = -EIO;
goto done;
}
-   if (ioend->io_error)
-   goto done;
 
/*
 * For unwritten extents we need to issue transactions to convert a
 * range to normal written extens after the data I/O has finished.
+* Detecting and handling completion IO errors is done individually
+* for each case as different cleanup operations need to be performed
+* on error.
 */
if (ioend->io_type == XFS_IO_UNWRITTEN) {
+   if (ioend->io_error)
+   goto done;
error = xfs_iomap_write_unwritten(ip, ioend->io_offset,
  ioend->io_size);
} else if (ioend->io_isdirect && xfs_ioend_is_append(ioend)) {
-- 
2.12.2

[PATCH 3.12 050/142] s390/pci: fix use after free in dma_init

[Jiri Slaby]

From: Sebastian Ott 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit dba599091c191d209b1499511a524ad9657c0e5a upstream.

After a failure during registration of the dma_table (because of the
function being in error state) we free its memory but don't reset the
associated pointer to zero.

When we then receive a notification from firmware (about the function
being in error state) we'll try to walk and free the dma_table again.

Fix this by resetting the dma_table pointer. In addition to that make
sure that we free the iommu_bitmap when appropriate.

Signed-off-by: Sebastian Ott 
Reviewed-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 arch/s390/pci/pci_dma.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 7e5573acb063..9b76189d3375 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -416,7 +416,7 @@ int zpci_dma_init_device(struct zpci_dev *zdev)
zdev->dma_table = dma_alloc_cpu_table();
if (!zdev->dma_table) {
rc = -ENOMEM;
-   goto out_clean;
+   goto out;
}
 
zdev->iommu_size = (unsigned long) high_memory - PAGE_OFFSET;
@@ -424,7 +424,7 @@ int zpci_dma_init_device(struct zpci_dev *zdev)
zdev->iommu_bitmap = vzalloc(zdev->iommu_pages / 8);
if (!zdev->iommu_bitmap) {
rc = -ENOMEM;
-   goto out_reg;
+   goto free_dma_table;
}
 
rc = zpci_register_ioat(zdev,
@@ -433,12 +433,16 @@ int zpci_dma_init_device(struct zpci_dev *zdev)
zdev->start_dma + zdev->iommu_size - 1,
(u64) zdev->dma_table);
if (rc)
-   goto out_reg;
-   return 0;
+   goto free_bitmap;
 
-out_reg:
+   return 0;
+free_bitmap:
+   vfree(zdev->iommu_bitmap);
+   zdev->iommu_bitmap = NULL;
+free_dma_table:
dma_free_cpu_table(zdev->dma_table);
-out_clean:
+   zdev->dma_table = NULL;
+out:
return rc;
 }
 
-- 
2.12.2

[PATCH 3.12 062/142] qmi_wwan: add Dell DW5811e

[Jiri Slaby]

From: Bjørn Mork 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 6bd845d1cf98b45c634baacb8381436dad3c2dd0 ]

This is a Dell branded Sierra Wireless EM7455. It is operating in
MBIM mode by default, but can be configured to provide two QMI/RMNET
functions.

Signed-off-by: Bjørn Mork 
Signed-off-by: David S. Miller 
---
 drivers/net/usb/qmi_wwan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 40eabbb4bcd7..811b9cdb1824 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -829,6 +829,8 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},/* Dell Wireless 5808e Gobi(TM) 
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81b1, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)},/* Dell Wireless 5809e Gobi(TM) 
4G LTE Mobile Broadband Card (rev3) */
+   {QMI_FIXED_INTF(0x413c, 0x81b6, 8)},/* Dell Wireless 5811e */
+   {QMI_FIXED_INTF(0x413c, 0x81b6, 10)},   /* Dell Wireless 5811e */
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
-- 
2.12.2

[PATCH 3.12 051/142] kernek/fork.c: allocate idle task for a CPU always on its local node

[Jiri Slaby]

From: Andi Kleen 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 725fc629ff2545b061407305ae51016c9f928fce upstream.

Linux preallocates the task structs of the idle tasks for all possible
CPUs.  This currently means they all end up on node 0.  This also
implies that the cache line of MWAIT, which is around the flags field in
the task struct, are all located in node 0.

We see a noticeable performance improvement on Knights Landing CPUs when
the cache lines used for MWAIT are located in the local nodes of the
CPUs using them.  I would expect this to give a (likely slight)
improvement on other systems too.

The patch implements placing the idle task in the node of its CPUs, by
passing the right target node to copy_process()

[js] to tls in copy_process in 3.12 yet

[a...@linux-foundation.org: use NUMA_NO_NODE, not a bare -1]
Link: 
http://lkml.kernel.org/r/1463492694-15833-1-git-send-email-a...@firstfloor.org
Signed-off-by: Andi Kleen 
Cc: Thomas Gleixner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 kernel/fork.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 360c1d46e842..00e6407cc85a 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -292,14 +292,15 @@ int __attribute__((weak)) arch_dup_task_struct(struct 
task_struct *dst,
return 0;
 }
 
-static struct task_struct *dup_task_struct(struct task_struct *orig)
+static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
 {
struct task_struct *tsk;
struct thread_info *ti;
unsigned long *stackend;
-   int node = tsk_fork_get_node(orig);
int err;
 
+   if (node == NUMA_NO_NODE)
+   node = tsk_fork_get_node(orig);
tsk = alloc_task_struct_node(node);
if (!tsk)
return NULL;
@@ -1142,7 +1143,8 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
unsigned long stack_size,
int __user *child_tidptr,
struct pid *pid,
-   int trace)
+   int trace,
+   int node)
 {
int retval;
struct task_struct *p;
@@ -1195,7 +1197,7 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
goto fork_out;
 
retval = -ENOMEM;
-   p = dup_task_struct(current);
+   p = dup_task_struct(current, node);
if (!p)
goto fork_out;
 
@@ -1565,7 +1567,8 @@ static inline void init_idle_pids(struct pid_link *links)
 struct task_struct *fork_idle(int cpu)
 {
struct task_struct *task;
-   task = copy_process(CLONE_VM, 0, 0, NULL, &init_struct_pid, 0);
+   task = copy_process(CLONE_VM, 0, 0, NULL, &init_struct_pid, 0,
+   cpu_to_node(cpu));
if (!IS_ERR(task)) {
init_idle_pids(task->pids);
init_idle(task, cpu);
@@ -1609,7 +1612,7 @@ long do_fork(unsigned long clone_flags,
}
 
p = copy_process(clone_flags, stack_start, stack_size,
-child_tidptr, NULL, trace);
+child_tidptr, NULL, trace, NUMA_NO_NODE);
/*
 * Do this prior waking up the new thread - the thread pointer
 * might get invalid after that point, if the thread exits quickly.
-- 
2.12.2

[PATCH 3.12 061/142] net: unix: properly re-increment inflight counter of GC discarded candidates

[Jiri Slaby]

From: Andrey Ulanov 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 7df9c24625b9981779afb8fcdbe2bb4765e61147 ]

Dmitry has reported that a BUG_ON() condition in unix_notinflight()
may be triggered by a simple code that forwards unix socket in an
SCM_RIGHTS message.
That is caused by incorrect unix socket GC implementation in unix_gc().

The GC first collects list of candidates, then (a) decrements their
"children's" inflight counter, (b) checks which inflight counters are
now 0, and then (c) increments all inflight counters back.
(a) and (c) are done by calling scan_children() with inc_inflight or
dec_inflight as the second argument.

Commit 6209344f5a37 ("net: unix: fix inflight counting bug in garbage
collector") changed scan_children() such that it no longer considers
sockets that do not have UNIX_GC_CANDIDATE flag. It also added a block
of code that that unsets this flag _before_ invoking
scan_children(, dec_iflight, ). This may lead to incorrect inflight
counters for some sockets.

This change fixes this bug by changing order of operations:
UNIX_GC_CANDIDATE is now unset only after all inflight counters are
restored to the original state.

  kernel BUG at net/unix/garbage.c:149!
  RIP: 0010:[]  []
  unix_notinflight+0x3b4/0x490 net/unix/garbage.c:149
  Call Trace:
   [] unix_detach_fds.isra.19+0xff/0x170 
net/unix/af_unix.c:1487
   [] unix_destruct_scm+0xf9/0x210 net/unix/af_unix.c:1496
   [] skb_release_head_state+0x101/0x200 net/core/skbuff.c:655
   [] skb_release_all+0x1a/0x60 net/core/skbuff.c:668
   [] __kfree_skb+0x1a/0x30 net/core/skbuff.c:684
   [] kfree_skb+0x184/0x570 net/core/skbuff.c:705
   [] unix_release_sock+0x5b5/0xbd0 net/unix/af_unix.c:559
   [] unix_release+0x49/0x90 net/unix/af_unix.c:836
   [] sock_release+0x92/0x1f0 net/socket.c:570
   [] sock_close+0x1b/0x20 net/socket.c:1017
   [] __fput+0x34e/0x910 fs/file_table.c:208
   [] fput+0x1a/0x20 fs/file_table.c:244
   [] task_work_run+0x1a0/0x280 kernel/task_work.c:116
   [< inline >] exit_task_work include/linux/task_work.h:21
   [] do_exit+0x183a/0x2640 kernel/exit.c:828
   [] do_group_exit+0x14e/0x420 kernel/exit.c:931
   [] get_signal+0x663/0x1880 kernel/signal.c:2307
   [] do_signal+0xc5/0x2190 arch/x86/kernel/signal.c:807
   [] exit_to_usermode_loop+0x1ea/0x2d0
  arch/x86/entry/common.c:156
   [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190
   [] syscall_return_slowpath+0x4d3/0x570
  arch/x86/entry/common.c:259
   [] entry_SYSCALL_64_fastpath+0xc4/0xc6

Link: https://lkml.org/lkml/2017/3/6/252
Signed-off-by: Andrey Ulanov 
Reported-by: Dmitry Vyukov 
Fixes: 6209344 ("net: unix: fix inflight counting bug in garbage collector")
Signed-off-by: David S. Miller 
---
 net/unix/garbage.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index a72182d6750f..58ba0e5f147b 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -152,6 +152,7 @@ void unix_notinflight(struct user_struct *user, struct file 
*fp)
if (s) {
struct unix_sock *u = unix_sk(s);
 
+   BUG_ON(!atomic_long_read(&u->inflight));
BUG_ON(list_empty(&u->link));
if (atomic_long_dec_and_test(&u->inflight))
list_del_init(&u->link);
@@ -358,6 +359,14 @@ void unix_gc(void)
}
list_del(&cursor);
 
+   /* Now gc_candidates contains only garbage.  Restore original
+* inflight counters for these as well, and remove the skbuffs
+* which are creating the cycle(s).
+*/
+   skb_queue_head_init(&hitlist);
+   list_for_each_entry(u, &gc_candidates, link)
+   scan_children(&u->sk, inc_inflight, &hitlist);
+
/*
 * not_cycle_list contains those sockets which do not make up a
 * cycle.  Restore these to the inflight list.
@@ -368,15 +377,6 @@ void unix_gc(void)
list_move_tail(&u->link, &gc_inflight_list);
}
 
-   /*
-* Now gc_candidates contains only garbage.  Restore original
-* inflight counters for these as well, and remove the skbuffs
-* which are creating the cycle(s).
-*/
-   skb_queue_head_init(&hitlist);
-   list_for_each_entry(u, &gc_candidates, link)
-   scan_children(&u->sk, inc_inflight, &hitlist);
-
spin_unlock(&unix_gc_lock);
 
/* Here we are. Hitlist is filled. Die. */
-- 
2.12.2

Re: [PATCH RFC 1/6] KVM: fix guest_mode optimization in kvm_make_all_cpus_request()

[Andrew Jones]

On Thu, Apr 06, 2017 at 10:02:15PM +0100, James Hogan wrote:
> On Thu, Apr 06, 2017 at 10:20:51PM +0200, Radim Krčmář wrote:
> > We have kvm_arch_vcpu_should_kick() to decide whether the target cpu
> > needs to be kicked.  The previous condition was wrong, because
> > architectures that don't use vcpu->mode would not get interrupts and
> > also suboptimal, because it sent IPI in cases where none was necessary.
> > 
> > The situation is even more convoluted.  MIPS and POWERPC return 1 from
> > kvm_arch_vcpu_should_kick(), but implement vcpu->mode for some reason,
> > so now they might kick uselessly.  This is not a huge problem.
> 
> Whoops. I hadn't spotted kvm_arch_vcpu_should_kick() when I added
> vcpu->mode stuff in 4.11... I'm guessing I need to implement that
> similar to ARM / x86... though MIPS doesn't use kvm_vcpu_kick() yet.
> 
> > 
> > s390, on the other hand, never changed vcpu->mode, so it would always be
> > OUTSIDE_GUEST_MODE before and therefore didn't send IPIs.
> > I don't see a reason why s390 had kvm_make_all_cpus_request() that did
> > nothing but set the bit in vcpu->request, so the new behavior seems
> > better.
> > 
> > Signed-off-by: Radim Krčmář 
> > ---
> >  arch/s390/kvm/kvm-s390.c | 4 +---
> >  virt/kvm/kvm_main.c  | 2 +-
> >  2 files changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> > index fd6cd05bb6a7..45b6d9ca5d24 100644
> > --- a/arch/s390/kvm/kvm-s390.c
> > +++ b/arch/s390/kvm/kvm-s390.c
> > @@ -2130,9 +2130,7 @@ static void kvm_gmap_notifier(struct gmap *gmap, 
> > unsigned long start,
> >  
> >  int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> >  {
> > -   /* kvm common code refers to this, but never calls it */
> > -   BUG();
> > -   return 0;
> > +   return 1;
> >  }
> >  
> >  static int kvm_arch_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index f489167839c4..2389e9c41cd2 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -187,7 +187,7 @@ bool kvm_make_all_cpus_request(struct kvm *kvm, 
> > unsigned int req)
> > smp_mb__after_atomic();
> >  
> > if (cpus != NULL && cpu != -1 && cpu != me &&
> > - kvm_vcpu_exiting_guest_mode(vcpu) != OUTSIDE_GUEST_MODE)
> > +   kvm_arch_vcpu_should_kick(vcpu))

Hi James,

I'm actually thinking we should do away with kvm_arch_vcpu_should_kick(),
putting the x86 implementation of it directly in the common code.  The
reason is that, while there are currently two implementations for the
function, the x86 one and 'return true', I don't think 'return true'
is correct.  'return true' doesn't consider whether or not the target VCPU
has interrupts disabled, and I don't see how sending the IPI when the
vcpu is not in guest mode, or has disabled interrupts prior to entering
guest mode, makes sense.  To consider whether the target vcpu has
interrupts disabled we need to require it to tell us.  Requiring the
setting of IN_GUEST_MODE after calling local_irq_disable() is how x86
does it, and seems like it should work for all architectures. So, can you
help me better understand the concerns you have below?

> 
> This presumably changes the behaviour on x86, from != OUTSIDE_GUEST_MODE
> to == IN_GUEST_MODE. so:
> - you'll no longer get IPIs if its in READING_SHADOW_PAGE_TABLES (which
>   MIPS also now uses when accessing mappings outside of guest mode and
>   depends upon to wait until the old mappings are no longer in use).

But as long as the kicks were due to vcpu requests, then, since the VCPU
should check requests again before reentering guest mode, it'll still
handle them.  I see the comment under the setting of
READING_SHADOW_PAGE_TABLES in arch/mips/kvm/trap_emul.c refers to TLB
flush requests, so that one should be OK.  Are there other kicks that
are request-less to be concerned with?

> - you'll no longer get IPIs if its in EXITING_GUEST_MODE (i.e. if you
>   get two of these in quick succession only the first will wait for the
>   IPI, which might work as long as they're already serialised but it
>   still feels wrong).

Can you elaborate on this one?  My understanding is that there should
be no harm in coalescing these IPIs.

> 
> But it doesn't seem right to change the kvm_arch_vcpu_should_kick()
> implementations to check kvm_vcpu_exiting_guest_mode(vcpu) !=
> OUTSIDE_GUEST_MODE to match condition either, since kvm_vcpu_kick()
> doesn't seem to need synchronisation, only to know that it won't be
> delayed in reaching hypervisor code.

I can't think of a scenario that requires sending an IPI to a vcpu
outside guest mode, particularly because if it's the only runnable
task on the cpu then nothing will happen anyway.

Thanks,
drew

[PATCH 3.12 063/142] net/mlx5: Increase number of max QPs in default profile

[Jiri Slaby]

From: Maor Gottlieb 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 5f40b4ed975c26016cf41953b7510fe90718e21c ]

With ConnectX-4 sharing SRQs from the same space as QPs, we hit a
limit preventing some applications to allocate needed QPs amount.
Double the size to 256K.

[js] this is in another file in 3.12

Fixes: e126ba97dba9e ('mlx5: Add driver for Mellanox Connect-IB adapters')
Signed-off-by: Maor Gottlieb 
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller 
---
 drivers/infiniband/hw/mlx5/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mlx5/main.c 
b/drivers/infiniband/hw/mlx5/main.c
index 1300a377aca8..94f1408b391c 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -73,7 +73,7 @@ static struct mlx5_profile profile[] = {
[2] = {
.mask   = MLX5_PROF_MASK_QP_SIZE |
  MLX5_PROF_MASK_MR_CACHE,
-   .log_max_qp = 17,
+   .log_max_qp = 18,
.mr_cache[0]= {
.size   = 500,
.limit  = 250
-- 
2.12.2

[PATCH 3.12 064/142] ipv4: provide stronger user input validation in nl_fib_input()

[Jiri Slaby]

From: Eric Dumazet 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit c64c0b3cac4c5b8cb093727d2c19743ea3965c0b ]

Alexander reported a KMSAN splat caused by reads of uninitialized
field (tb_id_in) from user provided struct fib_result_nl

It turns out nl_fib_input() sanity tests on user input is a bit
wrong :

User can pretend nlh->nlmsg_len is big enough, but provide
at sendmsg() time a too small buffer.

Reported-by: Alexander Potapenko 
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
---
 net/ipv4/fib_frontend.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 3d3966bf3df6..4a30de61bec1 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -965,7 +965,8 @@ static void nl_fib_input(struct sk_buff *skb)
 
net = sock_net(skb->sk);
nlh = nlmsg_hdr(skb);
-   if (skb->len < NLMSG_HDRLEN || skb->len < nlh->nlmsg_len ||
+   if (skb->len < nlmsg_total_size(sizeof(*frn)) ||
+   skb->len < nlh->nlmsg_len ||
nlmsg_len(nlh) < sizeof(*frn))
return;
 
-- 
2.12.2

[PATCH 3.12 039/142] give up on gcc ilog2() constant optimizations

[Jiri Slaby]

From: Linus Torvalds 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 474c90156c8dcc2fa815e6716cc9394d7930cb9c upstream.

gcc-7 has an "optimization" pass that completely screws up, and
generates the code expansion for the (impossible) case of calling
ilog2() with a zero constant, even when the code gcc compiles does not
actually have a zero constant.

And we try to generate a compile-time error for anybody doing ilog2() on
a constant where that doesn't make sense (be it zero or negative).  So
now gcc7 will fail the build due to our sanity checking, because it
created that constant-zero case that didn't actually exist in the source
code.

There's a whole long discussion on the kernel mailing about how to work
around this gcc bug.  The gcc people themselevs have discussed their
"feature" in

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

but it's all water under the bridge, because while it looked at one
point like it would be solved by the time gcc7 was released, that was
not to be.

So now we have to deal with this compiler braindamage.

And the only simple approach seems to be to just delete the code that
tries to warn about bad uses of ilog2().

So now "ilog2()" will just return 0 not just for the value 1, but for
any non-positive value too.

It's not like I can recall anybody having ever actually tried to use
this function on any invalid value, but maybe the sanity check just
meant that such code never made it out in public.

[js] no tools/include/linux/log2.h copy of that yet

Reported-by: Laura Abbott 
Cc: John Stultz ,
Cc: Thomas Gleixner 
Cc: Ard Biesheuvel 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 include/linux/log2.h | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/include/linux/log2.h b/include/linux/log2.h
index fd7ff3d91e6a..f38fae23bdac 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -16,12 +16,6 @@
 #include 
 
 /*
- * deal with unrepresentable constant logarithms
- */
-extern __attribute__((const, noreturn))
-int ilog2_NaN(void);
-
-/*
  * non-constant log of base 2 calculators
  * - the arch may override these in asm/bitops.h if they can be implemented
  *   more efficiently than using fls() and fls64()
@@ -85,7 +79,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
 #define ilog2(n)   \
 (  \
__builtin_constant_p(n) ? ( \
-   (n) < 1 ? ilog2_NaN() : \
+   (n) < 2 ? 0 :   \
(n) & (1ULL << 63) ? 63 :   \
(n) & (1ULL << 62) ? 62 :   \
(n) & (1ULL << 61) ? 61 :   \
@@ -148,10 +142,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
(n) & (1ULL <<  4) ?  4 :   \
(n) & (1ULL <<  3) ?  3 :   \
(n) & (1ULL <<  2) ?  2 :   \
-   (n) & (1ULL <<  1) ?  1 :   \
-   (n) & (1ULL <<  0) ?  0 :   \
-   ilog2_NaN() \
-  ) :  \
+   1 ) :   \
(sizeof(n) <= 4) ?  \
__ilog2_u32(n) :\
__ilog2_u64(n)  \
-- 
2.12.2

[PATCH 3.12 066/142] libceph: don't set weight to IN when OSD is destroyed

[Jiri Slaby]

From: Ilya Dryomov 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit b581a5854eee4b7851dedb0f8c2ceb54fb902c06 upstream.

Since ceph.git commit 4e28f9e63644 ("osd/OSDMap: clear osd_info,
osd_xinfo on osd deletion"), weight is set to IN when OSD is deleted.
This changes the result of applying an incremental for clients, not
just OSDs.  Because CRUSH computations are obviously affected,
pre-4e28f9e63644 servers disagree with post-4e28f9e63644 clients on
object placement, resulting in misdirected requests.

Mirrors ceph.git commit a6009d1039a55e2c77f431662b3d6cc5a8e8e63f.

Fixes: 930c53286977 ("libceph: apply new_state before new_up_client on 
incrementals")
Link: http://tracker.ceph.com/issues/19122
Signed-off-by: Ilya Dryomov 
Reviewed-by: Sage Weil 
Signed-off-by: Jiri Slaby 
---
 net/ceph/osdmap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index c1de8d404c47..26e2235356c5 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -870,7 +870,6 @@ static int decode_new_up_state_weight(void **p, void *end,
if ((map->osd_state[osd] & CEPH_OSD_EXISTS) &&
(xorstate & CEPH_OSD_EXISTS)) {
pr_info("osd%d does not exist\n", osd);
-   map->osd_weight[osd] = CEPH_OSD_IN;
memset(map->osd_addr + osd, 0, sizeof(*map->osd_addr));
map->osd_state[osd] = 0;
} else {
-- 
2.12.2

[PATCH 3.12 065/142] tcp: initialize icsk_ack.lrcvtime at session start time

[Jiri Slaby]

From: Eric Dumazet 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 15bb7745e94a665caf42bfaabf0ce062845b533b ]

icsk_ack.lrcvtime has a 0 value at socket creation time.

tcpi_last_data_recv can have bogus value if no payload is ever received.

This patch initializes icsk_ack.lrcvtime for active sessions
in tcp_finish_connect(), and for passive sessions in
tcp_create_openreq_child()

Signed-off-by: Eric Dumazet 
Acked-by: Neal Cardwell 
Signed-off-by: David S. Miller 
---
 net/ipv4/tcp_input.c | 2 +-
 net/ipv4/tcp_minisocks.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9eef76176704..7789595a1009 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5292,6 +5292,7 @@ void tcp_finish_connect(struct sock *sk, struct sk_buff 
*skb)
struct inet_connection_sock *icsk = inet_csk(sk);
 
tcp_set_state(sk, TCP_ESTABLISHED);
+   icsk->icsk_ack.lrcvtime = tcp_time_stamp;
 
if (skb != NULL) {
icsk->icsk_af_ops->sk_rx_dst_set(sk, skb);
@@ -5492,7 +5493,6 @@ static int tcp_rcv_synsent_state_process(struct sock *sk, 
struct sk_buff *skb,
 * to stand against the temptation 8) --ANK
 */
inet_csk_schedule_ack(sk);
-   icsk->icsk_ack.lrcvtime = tcp_time_stamp;
tcp_enter_quickack_mode(sk);
inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
  TCP_DELACK_MAX, TCP_RTO_MAX);
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 58a3e69aef64..34fe583eeef3 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -403,6 +403,7 @@ struct sock *tcp_create_openreq_child(struct sock *sk, 
struct request_sock *req,
newtp->srtt = 0;
newtp->mdev = TCP_TIMEOUT_INIT;
newicsk->icsk_rto = TCP_TIMEOUT_INIT;
+   newicsk->icsk_ack.lrcvtime = tcp_time_stamp;
 
newtp->packets_out = 0;
newtp->retrans_out = 0;
-- 
2.12.2

[PATCH 3.12 068/142] USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module

[Jiri Slaby]

From: David Ward 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 44840dec6127e4d7c5074f75d2dd96bc4ab85fe3 upstream.

This is an HP-branded Sierra Wireless EM7355:
https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2

Signed-off-by: David Ward 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index d328bb1d7d55..7fea50498c00 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -137,6 +137,7 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x0AF0, 0x8120)},   /* Option GTM681W */
 
/* non-Gobi Sierra Wireless devices */
+   {DEVICE_SWI(0x03f0, 0x4e1d)},   /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G 
Module */
{DEVICE_SWI(0x0f3d, 0x68a2)},   /* Sierra Wireless MC7700 */
{DEVICE_SWI(0x114f, 0x68a2)},   /* Sierra Wireless MC7750 */
{DEVICE_SWI(0x1199, 0x68a2)},   /* Sierra Wireless MC7710 */
-- 
2.12.2

Re: [PATCH v3 0/4] Improved seccomp logging

[Andy Lutomirski]

On Fri, Apr 7, 2017 at 3:16 PM, Tyler Hicks  wrote:
> On 02/22/2017 12:46 PM, Kees Cook wrote:
>> On Thu, Feb 16, 2017 at 3:29 PM, Kees Cook  wrote:
>>> On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski  
>>> wrote:
 On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks  wrote:
> This patch set is the third revision of the following two previously
> submitted patch sets:
>
> v1: 
> http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhi...@canonical.com
> v1: 
> http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhi...@canonical.com
>
> v2: 
> http://lkml.kernel.org/r/1486100262-32391-1-git-send-email-tyhi...@canonical.com
>
> The patch set aims to address some known deficiencies in seccomp's current
> logging capabilities:
>
>   1. Inability to log all filter actions.
>   2. Inability to selectively enable filtering; e.g. devs want noisy 
> logging,
>  users want relative quiet.
>   3. Consistent behavior with audit enabled and disabled.
>   4. Inability to easily develop a filter due to the lack of a
>  permissive/complain mode.

 I think I dislike this, but I think my dislikes may be fixable with
 minor changes.

 What I dislike is that this mixes app-specific built-in configuration
 (seccomp) with global privileged stuff (audit).  The result is a
 potentially difficult to use situation in which you need to modify an
 app to make it loggable (using RET_LOG) and then fiddle with
 privileged config (auditctl, etc) to actually see the logs.
>>>
>>> You make a good point about RET_LOG vs log_max_action. I think making
>>> RET_LOG the default value would work for 99% of the cases.
>>
>> Actually, I take this back: making "log" the default means that
>> everything else gets logged too, include "expected" return values like
>> errno, trap, etc. I think that would be extremely noisy as a default
>> (for upstream or Ubuntu).
>>
>> Perhaps RET_LOG should unconditionally log? Or maybe the logged
>> actions should be a bit field instead of a single value? Then the
>> default could be "RET_KILL and RET_LOG", but an admin could switch it
>> to just RET_KILL, or even nothing at all? Hmmm...
>
> Hi Kees - my apologies for going quiet on this topic after we spoke
> about it more in IRC. I needed to tend to other work but now I'm able to
> return to this seccomp logging patch set.
>
> To summarize what we discussed in IRC, the Chrome browser makes
> extensive use of RET_ERRNO, RET_TRACE, etc., to sandbox code that may
> not ever be adjusted to keep from bump into the sandbox walls.
> Therefore, it is unreasonable to enable logging of something like
> RET_ERRNO on a system-wide level where Chrome browser is in use.
>
> In contrast, snapd wants to set up "noisier" sandboxes for applications
> to make it clear to the developers and the users that the sandboxed
> application is bumping into the sandbox walls. Developers will know why
> their code may not be working as intended and users will know that the
> application is doing things that the platform doesn't agree with. These
> sandboxes will end up using RET_ERRNO in the majority of cases.
>
> This means that with the current design of this patch set, Chrome
> browser will either be unintentionally spamming the logs or snapd's
> sandboxes will be helplessly silent when both Chrome and snapd is
> installed at the same time, depending on the admin's preferences.
>
> To bring it back up a level, two applications may have a very different
> outlook on how acceptable a given seccomp action is and they may
> disagree on whether or not the user/administrator should be informed.
>
> I've been giving thought to the idea of providing a way for the
> application setting up the filter to opt into logging of certain
> actions. Here's a high level breakdown:

At the risk of overcomplicating things, I think this issue may be a
decent argument for doing something more like what I suggested
earlier: let seccomp users emit loggable things and let their parents
(optionally) catch and handle those things.  Then we get real scoping
rather than fiddling with bitmasks and hoping we get what we want to
see without generating massive log spam.

--Andy

[PATCH 3.12 046/142] ACPI / video: skip evaluating _DOD when it does not exist

[Jiri Slaby]

From: Alex Hung 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit e34fbbac669de0b7fb7803929d0477f35f6e2833 upstream.

Some system supports hybrid graphics and its discrete VGA
does not have any connectors and therefore has no _DOD method.

Signed-off-by: Alex Hung 
Reviewed-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 drivers/acpi/video.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index ff5ec8ecc257..cf7efcda09e1 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1174,6 +1174,9 @@ static int acpi_video_device_enumerate(struct 
acpi_video_bus *video)
union acpi_object *dod = NULL;
union acpi_object *obj;
 
+   if (!video->cap._DOD)
+   return AE_NOT_EXIST;
+
status = acpi_evaluate_object(video->device->handle, "_DOD", NULL, 
&buffer);
if (!ACPI_SUCCESS(status)) {
ACPI_EXCEPTION((AE_INFO, status, "Evaluating _DOD"));
-- 
2.12.2

[PATCH 3.12 067/142] USB: qcserial: Add support for Dell Wireless 5809e 4G Modem

[Jiri Slaby]

From: Pieter Hollants 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 6da3700c98cdc8360f55c5510915efae1d66deea upstream.

Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G
LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE
card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook
series.

"lsusb -v" output for this device:

Bus 002 Device 003: ID 413c:81b1 Dell Computer Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x413c Dell Computer Corp.
  idProduct  0x81b1
  bcdDevice0.06
  iManufacturer   1 Sierra Wireless, Incorporated
  iProduct2 Dell Wireless 5809e Gobi™ 4G LTE Mobile Broadband 
Card
  iSerial 3
  bNumConfigurations  2
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  204
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000c  1x 12 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000c  1x 12 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
   

Re: [PATCH v2 2/5] iio: dac: add support for stm32 DAC

[Fabrice Gasnier]

On 04/09/2017 10:39 AM, Jonathan Cameron wrote:
> On 06/04/17 17:11, Fabrice Gasnier wrote:
>> Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage
>> output digital-to-analog converter. It has two output channels, each
>> with its own converter.
>> It supports 8 bits or 12bits left/right aligned data format. Only
>> 12bits right-aligned is used here. It has built-in noise or
>> triangle waveform generator, and supports external triggers for
>> conversions.
>> Each channel can be used independently, with separate trigger, then
>> separate IIO devices are used to handle this. Core driver is intended
>> to share common resources such as clock, reset, reference voltage and
>> registers.
>>
>> Signed-off-by: Fabrice Gasnier 
> A few little bits and pieces from the change to powerdown modes...
> 
> I have also been thinking about whether we can take this prior to sorting
> out the DDS side, but worry a little that we may end up wanting to change
> the way we define the channels - so that might need sorting to some degree
> before we can get the basics in place.

Hi Jonathan,

Just sent updated v3 with powerdown changes as per your comments.

> 
> Jonathan
>> ---
>> Changes in v2:
>> - Define 'Hi-Z'/'enable' powerdown modes instead of using 'enable'
>>   attribute normally not used for DACs.
>> - use 'reg' instead of 'st,dac-channel' property
>> - Use macro to differentiate channels
>> - Fix typos, remove leading '&' for functions
>> - Add comments on single channel per device
>> - Use devm_iio_device_register variant, removes need for .remove
>> ---
>>  drivers/iio/dac/Kconfig  |  15 ++
>>  drivers/iio/dac/Makefile |   2 +
>>  drivers/iio/dac/stm32-dac-core.c | 180 
>>  drivers/iio/dac/stm32-dac-core.h |  51 ++
>>  drivers/iio/dac/stm32-dac.c  | 350 
>> +++
>>  5 files changed, 598 insertions(+)
>>  create mode 100644 drivers/iio/dac/stm32-dac-core.c
>>  create mode 100644 drivers/iio/dac/stm32-dac-core.h
>>  create mode 100644 drivers/iio/dac/stm32-dac.c
>>
>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>> index d3084028..7198648 100644
>> --- a/drivers/iio/dac/Kconfig
>> +++ b/drivers/iio/dac/Kconfig
>> @@ -274,6 +274,21 @@ config MCP4922
>>To compile this driver as a module, choose M here: the module
>>will be called mcp4922.
>>  
>> +config STM32_DAC
>> +tristate "STMicroelectronics STM32 DAC"
>> +depends on (ARCH_STM32 && OF) || COMPILE_TEST
>> +depends on REGULATOR
>> +select STM32_DAC_CORE
>> +help
>> +  Say yes here to build support for STMicroelectronics STM32 Digital
>> +  to Analog Converter (DAC).
>> +
>> +  This driver can also be built as a module.  If so, the module
>> +  will be called stm32-dac.
>> +
>> +config STM32_DAC_CORE
>> +tristate
>> +
>>  config VF610_DAC
>>  tristate "Vybrid vf610 DAC driver"
>>  depends on OF
>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>> index f01bf4a..afe8ae7 100644
>> --- a/drivers/iio/dac/Makefile
>> +++ b/drivers/iio/dac/Makefile
>> @@ -29,4 +29,6 @@ obj-$(CONFIG_MAX517) += max517.o
>>  obj-$(CONFIG_MAX5821) += max5821.o
>>  obj-$(CONFIG_MCP4725) += mcp4725.o
>>  obj-$(CONFIG_MCP4922) += mcp4922.o
>> +obj-$(CONFIG_STM32_DAC_CORE) += stm32-dac-core.o
>> +obj-$(CONFIG_STM32_DAC) += stm32-dac.o
>>  obj-$(CONFIG_VF610_DAC) += vf610_dac.o
>> diff --git a/drivers/iio/dac/stm32-dac-core.c 
>> b/drivers/iio/dac/stm32-dac-core.c
>> new file mode 100644
>> index 000..75e4878
>> --- /dev/null
>> +++ b/drivers/iio/dac/stm32-dac-core.c
>> @@ -0,0 +1,180 @@
>> +/*
>> + * This file is part of STM32 DAC driver
>> + *
>> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
>> + * Author: Fabrice Gasnier .
>> + *
>> + * License type: GPLv2
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of 
>> MERCHANTABILITY
>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>> + * See the GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program. If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "stm32-dac-core.h"
>> +
>> +/**
>> + * struct stm32_dac_priv - stm32 DAC core private data
>> + * @pclk:   peripheral clock common for all DACs
>> + * @rst:peripheral reset control
>> + * @vref:   regulator reference
>> + * @common: Common data for all DAC instances
>> + */
>> +struct stm32_dac_priv {
>> +struct clk *pclk;
>> +struct reset_cont

[PATCH 3.12 058/142] igb: Workaround for igb i210 firmware issue

[Jiri Slaby]

From: Chris J Arges 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 4e684f59d760a2c7c716bb60190783546e2d08a1 ]

Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT causing
the probe of an igb i210 NIC to fail. This patch adds an addition zeroing
of this register during igb_get_phy_id to workaround this issue.

Thanks for Jochen Henneberg for the idea and original patch.

Signed-off-by: Chris J Arges 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Jiri Slaby 
---
 drivers/net/ethernet/intel/igb/e1000_phy.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c 
b/drivers/net/ethernet/intel/igb/e1000_phy.c
index ad2b74d95138..bd91752760d0 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -87,6 +87,10 @@ s32 igb_get_phy_id(struct e1000_hw *hw)
s32 ret_val = 0;
u16 phy_id;
 
+   /* ensure PHY page selection to fix misconfigured i210 */
+   if (hw->mac.type == e1000_i210)
+   phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0);
+
ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
if (ret_val)
goto out;
-- 
2.12.2

Re: KASLR causes intermittent boot failures on some systems

[Jeff Moyer]

Baoquan He  writes:

> On 04/07/17 at 10:41am, Jeff Moyer wrote:
>> Hi,
>> 
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to boot with a couple of different crash
>> signatures.  The first signature is a NMI watchdog lockup of all but 1
>> cpu, which causes much difficulty in extracting useful information from
>> the console.  The second variant is an invalid paging request, listed
>> below.
>> 
>> On some systems, I haven't hit this problem at all.  Other systems
>> experience a failed boot maybe 20-30% of the time.  To reproduce it,
>> configure some emulated pmem on your system.  You can find directions
>> for that here: https://nvdimm.wiki.kernel.org/
>
> I got below problem when configure ndctl, didn't find a package named
> libkmod:

Sorry, you can skip the ndctl step altogether.  This is emulated pmem,
so the setting won't stick anyway.

-Jeff

[PATCH 3.12 073/142] Input: i8042 - add noloop quirk for Dell Embedded Box PC 3000

[Jiri Slaby]

From: Kai-Heng Feng 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 45838660e34d90db8d4f7cbc8fd66e8aff79f4fe upstream.

The aux port does not get detected without noloop quirk, so external PS/2
mouse cannot work as result.

The PS/2 mouse can work with this quirk.

BugLink: https://bugs.launchpad.net/bugs/1591053
Signed-off-by: Kai-Heng Feng 
Reviewed-by: Marcos Paulo de Souza 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/serio/i8042-x86ia64io.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/input/serio/i8042-x86ia64io.h 
b/drivers/input/serio/i8042-x86ia64io.h
index 3f3c517f2039..9a2d2159bf0c 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -120,6 +120,13 @@ static const struct dmi_system_id __initconst 
i8042_dmi_noloop_table[] = {
},
},
{
+   /* Dell Embedded Box PC 3000 */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Embedded Box PC 3000"),
+   },
+   },
+   {
/* OQO Model 01 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "OQO"),
-- 
2.12.2

Re: [PATCH v3] lightnvm: physical block device (pblk) target

[Bart Van Assche]

On Sun, 2017-04-09 at 11:15 +0200, Javier González wrote:
> On 8 Apr 2017, at 22.56, Bart Van Assche  wrote:
> > On 04/07/17 11:50, Javier González wrote:
> struct ppa_addr, which is the physical address format is not affected,
> but pblk's internal L2P address representation (pblk_addr) is. You can
> see that the type either represents struct ppa_addr or ppa_addr_32. How
> would you define a type that can either be u64 or u32 with different bit
> offsets at run-time? Note that address conversions to this type is in
> the fast path and this format allows us to only use bit shifts.

Selecting the appropriate representation at run-time would require to pass
pblk_addr by reference instead of by value to any function that expects a
pblk_addr. It would also require to have two versions of every data structure
that depends on pblk_addr and to use casts to convert to the appropritate
version. However, this approach is probably only worth to be implemented if
it doesn't introduce too much additional complexity.

> > > +#ifdef CONFIG_NVM_DEBUG
> > > + atomic_add(nr_entries, &pblk->inflight_writes);
> > > + atomic_add(nr_entries, &pblk->req_writes);
> > > +#endif
> > 
> > Has it been considered to use the "static key" feature such that
> > consistency checks can be enabled at run-time instead of having to
> > rebuild the kernel to enable CONFIG_NVM_DEBUG?
> 
> I haven't considered it. I'll look into it. I would like to have this
> counters and the corresponding sysfs entry only available on debug mode
> since it allows us to have a good picture of the FTL state.

If there are sysfs entries that depend on CONFIG_NVM_DEBUG then the static
key mechanism is probably not a good alternative for CONFIG_NVM_DEBUG.

> > Has it been considered to add support for keeping a subset of the L2P
> > translation table in memory instead of keeping it in memory in its entirety?
> 
> Yes. L2P caching is on our roadmap and will be included in the future.

That's great. This will also help with reducing the time between discovery of
a lightnvm device and the time at which I/O can start since the L2P table must
be available before I/O can start.

Bart.

Re: [patch 2/3] x86/vdso: Plug race between mapping and ELF header setup

[Andy Lutomirski]

On Mon, Apr 10, 2017 at 8:14 AM, Thomas Gleixner  wrote:
> The vsyscall32 sysctl can racy against a concurrent fork when it switches
> from disabled to enabled:
>
> arch_setup_additional_pages()
> if (vdso32_enabled)
>--> No mapping
> sysctl.vsysscall32()
>   --> vdso32_enabled = true
> create_elf_tables()
>   ARCH_DLINFO_IA32
> if (vdso32_enabled) {
>--> Add VDSO entry with NULL pointer
>
> Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
> the newly forked process or not.

Acked-by: Andy Lutomirski 

[PATCH 3.12 074/142] Input: iforce - validate number of endpoints before using them

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 59cf8bed44a79ec42303151dd014fdb6434254bb upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory that lie beyond the end of the endpoint
array should a malicious device lack the expected endpoints.

Signed-off-by: Johan Hovold 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/joystick/iforce/iforce-usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/joystick/iforce/iforce-usb.c 
b/drivers/input/joystick/iforce/iforce-usb.c
index d96aa27dfcdc..db64adfbe1af 100644
--- a/drivers/input/joystick/iforce/iforce-usb.c
+++ b/drivers/input/joystick/iforce/iforce-usb.c
@@ -141,6 +141,9 @@ static int iforce_usb_probe(struct usb_interface *intf,
 
interface = intf->cur_altsetting;
 
+   if (interface->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
epirq = &interface->endpoint[0].desc;
epout = &interface->endpoint[1].desc;
 
-- 
2.12.2

[PATCH 3.12 075/142] Input: ims-pcu - validate number of endpoints before using them

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 1916d319271664241b7aa0cd2b05e32bdb310ce9 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack control-interface endpoints.

Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
Signed-off-by: Johan Hovold 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/misc/ims-pcu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index 77164dc1bedd..8fb814ccfd7a 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1437,6 +1437,10 @@ static int ims_pcu_parse_cdc_data(struct usb_interface 
*intf, struct ims_pcu *pc
return -EINVAL;
 
alt = pcu->ctrl_intf->cur_altsetting;
+
+   if (alt->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
pcu->ep_ctrl = &alt->endpoint[0].desc;
pcu->max_ctrl_size = usb_endpoint_maxp(pcu->ep_ctrl);
 
-- 
2.12.2

Re: [patch 3/3] x86/vdso: Sanitize vdso*_enabled handling

[Andy Lutomirski]

On Mon, Apr 10, 2017 at 8:14 AM, Thomas Gleixner  wrote:
> +static int vdso32_sysctl;
> +
> +static int vdso_update_handler(struct ctl_table *table, int write,
> +  void __user *buffer, size_t *lenp,
> +  loff_t *ppos)
> +{
> +   int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);

Using a global for the temporary is gross and mildly racy.  I would
just open-code the conversion.  Or, even better, add proc_dobool().

I'm not convinced that the current patch is a cleanup.

--Andy

[PATCH 3.12 059/142] igb: add i211 to i210 PHY workaround

[Jiri Slaby]

From: Todd Fujinaka 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 5bc8c230e2a993b49244f9457499f17283da9ec7 ]

i210 and i211 share the same PHY but have different PCI IDs. Don't
forget i211 for any i210 workarounds.

Signed-off-by: Todd Fujinaka 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin 
Signed-off-by: Jiri Slaby 
---
 drivers/net/ethernet/intel/igb/e1000_phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c 
b/drivers/net/ethernet/intel/igb/e1000_phy.c
index bd91752760d0..44274022a73b 100644
--- a/drivers/net/ethernet/intel/igb/e1000_phy.c
+++ b/drivers/net/ethernet/intel/igb/e1000_phy.c
@@ -88,7 +88,7 @@ s32 igb_get_phy_id(struct e1000_hw *hw)
u16 phy_id;
 
/* ensure PHY page selection to fix misconfigured i210 */
-   if (hw->mac.type == e1000_i210)
+   if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211))
phy->ops.write_reg(hw, I347AT4_PAGE_SELECT, 0);
 
ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
-- 
2.12.2

[PATCH 3.12 069/142] USB: qcserial: add Sierra Wireless MC74xx/EM74xx

[Jiri Slaby]

From: Bjørn Mork 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit f504ab1888026d15b5be8f9c262bf4ae9cacd177 upstream.

New device IDs shamelessly lifted from the vendor driver.

Signed-off-by: Bjørn Mork 
Acked-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/serial/qcserial.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 7fea50498c00..9792bfa17f74 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -153,6 +153,8 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
+   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.12.2

[PATCH 3.12 077/142] Input: yealink - validate number of endpoints before using them

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 5cc4a1a9f5c179795c8a1f2b0f4361829d6a070e upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: aca951a22a1d ("[PATCH] input-driver-yealink-P1K-usb-phone")
Signed-off-by: Johan Hovold 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/misc/yealink.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index 285a5bd6cbc9..3b6fdb389a2d 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -876,6 +876,10 @@ static int usb_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
int ret, pipe, i;
 
interface = intf->cur_altsetting;
+
+   if (interface->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
endpoint = &interface->endpoint[0].desc;
if (!usb_endpoint_is_int_in(endpoint))
return -ENODEV;
-- 
2.12.2

[PATCH 3.12 076/142] Input: hanwang - validate number of endpoints before using them

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit ba340d7b83703768ce566f53f857543359aa1b98 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: bba5394ad3bd ("Input: add support for Hanwang tablets")
Signed-off-by: Johan Hovold 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/tablet/hanwang.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/tablet/hanwang.c b/drivers/input/tablet/hanwang.c
index 5cc04124995c..263c85e72e14 100644
--- a/drivers/input/tablet/hanwang.c
+++ b/drivers/input/tablet/hanwang.c
@@ -341,6 +341,9 @@ static int hanwang_probe(struct usb_interface *intf, const 
struct usb_device_id
int error;
int i;
 
+   if (intf->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
hanwang = kzalloc(sizeof(struct hanwang), GFP_KERNEL);
input_dev = input_allocate_device();
if (!hanwang || !input_dev) {
-- 
2.12.2

[PATCH 3.12 080/142] ALSA: seq: Fix racy cell insertions during snd_seq_pool_done()

[Jiri Slaby]

From: Takashi Iwai 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit c520ff3d03f0b5db7146d9beed6373ad5d2a5e0e upstream.

When snd_seq_pool_done() is called, it marks the closing flag to
refuse the further cell insertions.  But snd_seq_pool_done() itself
doesn't clear the cells but just waits until all cells are cleared by
the caller side.  That is, it's racy, and this leads to the endless
stall as syzkaller spotted.

This patch addresses the racy by splitting the setup of pool->closing
flag out of snd_seq_pool_done(), and calling it properly before
snd_seq_pool_done().

BugLink: 
http://lkml.kernel.org/r/cact4y+aqqy8bza1ffieifnxr2faffqqabcbhj801+u5epv0...@mail.gmail.com
Reported-and-tested-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Jiri Slaby 
---
 sound/core/seq/seq_clientmgr.c |  1 +
 sound/core/seq/seq_fifo.c  |  3 +++
 sound/core/seq/seq_memory.c| 17 +
 sound/core/seq/seq_memory.h|  1 +
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
index 08865dcbf5f1..d449dde1bf50 100644
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1909,6 +1909,7 @@ static int snd_seq_ioctl_set_client_pool(struct 
snd_seq_client *client,
 info.output_pool != client->pool->size)) {
if (snd_seq_write_pool_allocated(client)) {
/* remove all existing cells */
+   snd_seq_pool_mark_closing(client->pool);
snd_seq_queue_client_leave_cells(client->number);
snd_seq_pool_done(client->pool);
}
diff --git a/sound/core/seq/seq_fifo.c b/sound/core/seq/seq_fifo.c
index 118481839d46..fc2c55b18f49 100644
--- a/sound/core/seq/seq_fifo.c
+++ b/sound/core/seq/seq_fifo.c
@@ -72,6 +72,9 @@ void snd_seq_fifo_delete(struct snd_seq_fifo **fifo)
return;
*fifo = NULL;
 
+   if (f->pool)
+   snd_seq_pool_mark_closing(f->pool);
+
snd_seq_fifo_clear(f);
 
/* wake up clients if any */
diff --git a/sound/core/seq/seq_memory.c b/sound/core/seq/seq_memory.c
index 7204c0f1700b..4603bcae5e40 100644
--- a/sound/core/seq/seq_memory.c
+++ b/sound/core/seq/seq_memory.c
@@ -414,6 +414,18 @@ int snd_seq_pool_init(struct snd_seq_pool *pool)
return 0;
 }
 
+/* refuse the further insertion to the pool */
+void snd_seq_pool_mark_closing(struct snd_seq_pool *pool)
+{
+   unsigned long flags;
+
+   if (snd_BUG_ON(!pool))
+   return;
+   spin_lock_irqsave(&pool->lock, flags);
+   pool->closing = 1;
+   spin_unlock_irqrestore(&pool->lock, flags);
+}
+
 /* remove events */
 int snd_seq_pool_done(struct snd_seq_pool *pool)
 {
@@ -424,10 +436,6 @@ int snd_seq_pool_done(struct snd_seq_pool *pool)
return -EINVAL;
 
/* wait for closing all threads */
-   spin_lock_irqsave(&pool->lock, flags);
-   pool->closing = 1;
-   spin_unlock_irqrestore(&pool->lock, flags);
-
if (waitqueue_active(&pool->output_sleep))
wake_up(&pool->output_sleep);
 
@@ -486,6 +494,7 @@ int snd_seq_pool_delete(struct snd_seq_pool **ppool)
*ppool = NULL;
if (pool == NULL)
return 0;
+   snd_seq_pool_mark_closing(pool);
snd_seq_pool_done(pool);
kfree(pool);
return 0;
diff --git a/sound/core/seq/seq_memory.h b/sound/core/seq/seq_memory.h
index 4a2ec779b8a7..32f959c17786 100644
--- a/sound/core/seq/seq_memory.h
+++ b/sound/core/seq/seq_memory.h
@@ -84,6 +84,7 @@ static inline int snd_seq_total_cells(struct snd_seq_pool 
*pool)
 int snd_seq_pool_init(struct snd_seq_pool *pool);
 
 /* done pool - free events */
+void snd_seq_pool_mark_closing(struct snd_seq_pool *pool);
 int snd_seq_pool_done(struct snd_seq_pool *pool);
 
 /* create pool */
-- 
2.12.2

Re: [PATCH] staging: rtl8723bs: remove null test before kfree

[Larry Finger]

On 04/10/2017 08:43 AM, Aishwarya Pant wrote:

kfree(..) on a NULL pointer is a no-op; the null test here is redundant.
Detected by coccicheck.

Signed-off-by: Aishwarya Pant 


Acked-by: Larry Finger 

Thanks,

Larry


---
 drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c |  6 ++
 drivers/staging/rtl8723bs/hal/sdio_ops.c  |  6 ++
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c |  8 ++-
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c| 26 ++-
 drivers/staging/rtl8723bs/os_dep/xmit_linux.c |  6 ++
 5 files changed, 15 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c 
b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
index d40ad03..910f7fa 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
@@ -995,8 +995,7 @@ if (1) {
rtw_hal_set_hwreg(padapter, HW_VAR_EFUSE_USAGE, (u8 
*)&efuse_usage);
}

-   if (efuseTbl)
-   kfree(efuseTbl);
+   kfree(efuseTbl);
 }

 static void hal_ReadEFuse_BT(
@@ -1128,8 +1127,7 @@ static void hal_ReadEFuse_BT(
}

 exit:
-   if (efuseTbl)
-   kfree(efuseTbl);
+   kfree(efuseTbl);
 }

 static void Hal_ReadEFuse(
diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c 
b/drivers/staging/rtl8723bs/hal/sdio_ops.c
index cf09a0a..6285b72 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_ops.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c
@@ -602,8 +602,7 @@ static s32 _sdio_local_read(
if (!err)
memcpy(pbuf, ptmpbuf, cnt);

-   if (ptmpbuf)
-   kfree(ptmpbuf);
+   kfree(ptmpbuf);

return err;
 }
@@ -646,8 +645,7 @@ s32 sdio_local_read(
if (!err)
memcpy(pbuf, ptmpbuf, cnt);

-   if (ptmpbuf)
-   kfree(ptmpbuf);
+   kfree(ptmpbuf);

return err;
 }
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index d2c6604..52aa65b 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1170,10 +1170,7 @@ static int cfg80211_rtw_add_key(struct wiphy *wiphy, 
struct net_device *ndev,
}

 addkey_end:
-   if (param)
-   {
-   kfree((u8 *)param);
-   }
+   kfree((u8 *)param);

return ret;

@@ -1968,8 +1965,7 @@ static int rtw_cfg80211_set_wpa_ie(struct adapter 
*padapter, u8 *pie, size_t iel
pairwise_cipher, padapter->securitypriv.ndisencryptstatus, 
padapter->securitypriv.ndisauthtype));

 exit:
-   if (buf)
-   kfree(buf);
+   kfree(buf);
if (ret)
_clr_fwstate_(&padapter->mlmepriv, WIFI_UNDER_WPS);
return ret;
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c 
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index fe3c42a..e11045f 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -766,9 +766,7 @@ static int wpa_set_encryption(struct net_device *dev, 
struct ieee_param *param,

 exit:

-   if (pwep) {
-   kfree((u8 *)pwep);
-   }
+   kfree((u8 *)pwep);
return ret;
 }

@@ -926,7 +924,7 @@ static int rtw_set_wpa_ie(struct adapter *padapter, char 
*pie, unsigned short ie

 exit:

-   if (buf) kfree(buf);
+   kfree(buf);

return ret;
 }
@@ -2502,10 +2500,7 @@ static int rtw_wx_set_enc_ext(struct net_device *dev,
ret =  wpa_set_encryption(dev, param, param_len);

 exit:
-   if (param)
-   {
-   kfree((u8 *)param);
-   }
+   kfree((u8 *)param);

return ret;
 }
@@ -4135,11 +4130,7 @@ static int rtw_set_encryption(struct net_device *dev, 
struct ieee_param *param,
}

 exit:
-
-   if (pwep)
-   {
-   kfree((u8 *)pwep);
-   }
+   kfree((u8 *)pwep);

return ret;

@@ -5785,12 +5776,9 @@ static int rtw_ioctl_wext_private(struct net_device 
*dev, union iwreq_data *wrq_
}

 exit:
-   if (input)
-   kfree(input);
-   if (buffer)
-   kfree(buffer);
-   if (output)
-   kfree(output);
+   kfree(input);
+   kfree(buffer);
+   kfree(output);

return err;
 }
diff --git a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c 
b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
index 66dfec1..7696816 100644
--- a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
@@ -76,10 +76,8 @@ int rtw_os_xmit_resource_alloc(struct adapter *padapter, 
struct xmit_buf *pxmitb

 void rtw_os_xmit_resource_free(struct adapter *padapter, struct xmit_buf 
*pxmitbuf, u32 free_sz, u8 flag)
 {
-   if (free_sz > 0) {
-   if (pxmitbuf->pallocated_buf)
-   kfree(pxmitbuf->pallocated_buf);
-   }
+   if (free_sz > 0)
+  

[PATCH 3.12 049/142] KVM: PPC: Book3S PR: Fix illegal opcode emulation

[Jiri Slaby]

From: Thomas Huth 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 708e75a3ee750dce1072134e630d66c4e6eaf63c upstream.

If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
returned EMULATE_FAIL, so the guest gets an program interrupt for the
illegal opcode.
However, the kvmppc_emulate_instruction() also tried to inject a
program exception for this already, so the program interrupt gets
injected twice and the return address in srr0 gets destroyed.
All other callers of kvmppc_emulate_instruction() are also injecting
a program interrupt, and since the callers have the right knowledge
about the srr1 flags that should be used, it is the function
kvmppc_emulate_instruction() that should _not_ inject program
interrupts, so remove the kvmppc_core_queue_program() here.

This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
where the logs are filled with these messages when the test tries
to execute an illegal instruction:

 Couldn't emulate instruction 0x (op 0 xop 0)
 kvmppc_handle_exit_pr: emulation at 700 failed ()

Signed-off-by: Thomas Huth 
Reviewed-by: Alexander Graf 
Tested-by: Laurent Vivier 
Signed-off-by: Paul Mackerras 
Cc: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 arch/powerpc/kvm/emulate.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index 751cd45f65a0..128651aa8437 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -471,7 +471,6 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct 
kvm_vcpu *vcpu)
advance = 0;
printk(KERN_ERR "Couldn't emulate instruction 0x%08x "
   "(op %d xop %d)\n", inst, get_op(inst), 
get_xop(inst));
-   kvmppc_core_queue_program(vcpu, 0);
}
}
 
-- 
2.12.2

[PATCH 3.12 078/142] Input: cm109 - validate number of endpoints before using them

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit ac2ee9ba953afe88f7a673e1c0c839227b1d7891 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: c04148f915e5 ("Input: add driver for USB VoIP phones with CM109...")
Signed-off-by: Johan Hovold 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/misc/cm109.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index 9365535ba7f1..50a7faa504f7 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -675,6 +675,10 @@ static int cm109_usb_probe(struct usb_interface *intf,
int error = -ENOMEM;
 
interface = intf->cur_altsetting;
+
+   if (interface->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
endpoint = &interface->endpoint[0].desc;
 
if (!usb_endpoint_is_int_in(endpoint))
-- 
2.12.2

[PATCH 3.12 060/142] net: properly release sk_frag.page

[Jiri Slaby]

From: Eric Dumazet 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

[ Upstream commit 22a0e18eac7a9e986fec76c60fa4a2926d1291e2 ]

I mistakenly added the code to release sk->sk_frag in
sk_common_release() instead of sk_destruct()

TCP sockets using sk->sk_allocation == GFP_ATOMIC do no call
sk_common_release() at close time, thus leaking one (order-3) page.

iSCSI is using such sockets.

Fixes: 5640f7685831 ("net: use a per task frag allocator")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
---
 net/core/sock.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index d765d6411a5b..046a72affe69 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1425,6 +1425,11 @@ static void __sk_free(struct sock *sk)
pr_debug("%s: optmem leakage (%d bytes) detected\n",
 __func__, atomic_read(&sk->sk_omem_alloc));
 
+   if (sk->sk_frag.page) {
+   put_page(sk->sk_frag.page);
+   sk->sk_frag.page = NULL;
+   }
+
if (sk->sk_peer_cred)
put_cred(sk->sk_peer_cred);
put_pid(sk->sk_peer_pid);
@@ -2660,11 +2665,6 @@ void sk_common_release(struct sock *sk)
 
sk_refcnt_debug_release(sk);
 
-   if (sk->sk_frag.page) {
-   put_page(sk->sk_frag.page);
-   sk->sk_frag.page = NULL;
-   }
-
sock_put(sk);
 }
 EXPORT_SYMBOL(sk_common_release);
-- 
2.12.2

[PATCH 3.12 070/142] USB: qcserial: Add support for Quectel EC20 Mini PCIe module

[Jiri Slaby]

From: Petr Štetiar 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 9d5b5ed796d7afd7e8d2ac4b4fb77c6a49463f4b upstream.

It seems like this device has same vendor and product IDs as G2K
devices, but it has different number of interfaces(4 vs 5) and also
different interface layout which makes it currently unusable:

usbcore: registered new interface driver qcserial
usbserial: USB Serial support registered for Qualcomm USB modem
usb 2-1.2: unknown number of interfaces: 5

lsusb output:

Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x05c6 Qualcomm, Inc.
  idProduct  0x9215 Acer Gobi 2000 Wireless Modem
  bcdDevice2.32
  iManufacturer   1 Quectel
  iProduct2 Quectel LTE Module
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  209
bNumInterfaces  5
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  500mA

Signed-off-by: Petr Štetiar 
[johan: rename define and add comment ]
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/serial/qcserial.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 9792bfa17f74..2c9a44523991 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -22,6 +22,8 @@
 #define DRIVER_AUTHOR "Qualcomm Inc"
 #define DRIVER_DESC "Qualcomm USB Serial driver"
 
+#define QUECTEL_EC20_PID   0x9215
+
 /* standard device layouts supported by this driver */
 enum qcserial_layouts {
QCSERIAL_G2K = 0,   /* Gobi 2000 */
@@ -166,6 +168,38 @@ static const struct usb_device_id id_table[] = {
 };
 MODULE_DEVICE_TABLE(usb, id_table);
 
+static int handle_quectel_ec20(struct device *dev, int ifnum)
+{
+   int altsetting = 0;
+
+   /*
+* Quectel EC20 Mini PCIe LTE module layout:
+* 0: DM/DIAG (use libqcdm from ModemManager for communication)
+* 1: NMEA
+* 2: AT-capable modem port
+* 3: Modem interface
+* 4: NDIS
+*/
+   switch (ifnum) {
+   case 0:
+   dev_dbg(dev, "Quectel EC20 DM/DIAG interface found\n");
+   break;
+   case 1:
+   dev_dbg(dev, "Quectel EC20 NMEA GPS interface found\n");
+   break;
+   case 2:
+   case 3:
+   dev_dbg(dev, "Quectel EC20 Modem port found\n");
+   break;
+   case 4:
+   /* Don't claim the QMI/net interface */
+   altsetting = -1;
+   break;
+   }
+
+   return altsetting;
+}
+
 static int qcprobe(struct usb_serial *serial, const struct usb_device_id *id)
 {
struct usb_host_interface *intf = serial->interface->cur_altsetting;
@@ -241,6 +275,12 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
altsetting = -1;
break;
case QCSERIAL_G2K:
+   /* handle non-standard layouts */
+   if (nintf == 5 && id->idProduct == QUECTEL_EC20_PID) {
+   altsetting = handle_quectel_ec20(dev, ifnum);
+   goto done;
+   }
+
/*
 * Gobi 2K+ USB layout:
 * 0: QMI/net
-- 
2.12.2

[PATCH 3.12 082/142] USB: serial: qcserial: add Dell DW5811e

[Jiri Slaby]

From: Bjørn Mork 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 436ecf5519d892397af133a79ccd38a17c25fa51 upstream.

This is a Dell branded Sierra Wireless EM7455.

Signed-off-by: Bjørn Mork 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/serial/qcserial.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 25f97da78989..c811c2dc1ae3 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -166,6 +166,8 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81a9)},   /* Dell Wireless 5808e Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81b1)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card (rev3) */
+   {DEVICE_SWI(0x413c, 0x81b5)},   /* Dell Wireless 5811e QDL */
+   {DEVICE_SWI(0x413c, 0x81b6)},   /* Dell Wireless 5811e QDL */
 
{ } /* Terminating entry */
 };
-- 
2.12.2

Re: [PATCH RFC v2 1/3] LSM: Allow per LSM module per "struct task_struct" blob.

[Casey Schaufler]

On 4/9/2017 3:42 AM, Djalal Harouni wrote:
> From: Tetsuo Handa 
>
> Since several modules are planning to use per "struct task_struct" blob,
> we need a layer for isolating it. Therefore, this patch introduces per LSM
> module per "struct task_struct" blob.
>
> It would be possible to remember location in security_hook_heads.task_alloc
> list and undo up to the corresponding security_hook_heads.task_free list
> when task_alloc hook failed. But this patch calls all task_free hooks
> without checking whether the corresponding task_alloc hook was called
> since most modules should be able to handle this correctly.
>
> How to calculate amount of needed bytes and allocate memory for initial
> task is a chicken-or-egg syndrome. We need to know how many bytes needs
> to be allocated for initial task's security blobs before security_init()
> is called. But security_reserve_task_blob_index() which calculates amount
> of needed bytes is called from security_init(). We will need to split
> module registration into three steps. The first step is call
> security_reserve_task_blob_index() on all modules which should be
> activated. The second step is allocate memory for the initial task's
> security blob. The third step is actually activate all modules which
> should be activated.
>
> Signed-off-by: Djalal Harouni 
> Signed-off-by: Tetsuo Handa 

While I appreciate your enthusiasm, I would really like
to see a mechanism for managing all of the blobs as being
potentially shared rather than just the task blob. With
infrastructure blob management being the general case we
could stack any set of existing modules that does not
include both SELinux and Smack. (AppArmor is threatening
to join that set, but we're still waiting on that) I
think it's a bad idea to go ahead with one implementation
for task blobs without taking care of the others.

> ---
>  include/linux/lsm_hooks.h | 36 +++-
>  security/security.c   | 37 -
>  2 files changed, 71 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 080f34e..ca19cdb 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include  /* "struct task_struct" */
>  
>  /**
>   * Security hooks for program execution operations.
> @@ -536,7 +537,10 @@
>   * @task_alloc:
>   *   @task task being allocated.
>   *   @clone_flags contains the flags indicating what should be shared.
> - *   Handle allocation of task-related resources.
> + *   Handle allocation of task-related resources. Note that task_free is
> + *   called even if task_alloc failed. This means that all task_free users
> + *   have to be prepared for task_free being called without corresponding
> + *   task_alloc call.
>   *   Returns a zero on success, negative values on failure.
>   * @task_free:
>   *   @task task about to be freed.
> @@ -1947,4 +1951,34 @@ void __init loadpin_add_hooks(void);
>  static inline void loadpin_add_hooks(void) { };
>  #endif
>  
> +/*
> + * Per "struct task_struct" security blob is managed using index numbers.
> + *
> + * Any user who wants to use per "struct task_struct" security blob reserves 
> an
> + * index number using security_reserve_task_blob_index() before calling
> + * security_add_hooks().
> + *
> + * security_reserve_task_blob_index() returns an index number which has to be
> + * passed to task_security() by that user when fetching security blob of 
> given
> + * "struct task_struct" for that user.
> + *
> + * Security blob for newly allocated "struct task_struct" is allocated and
> + * initialized with 0 inside security_task_alloc(), before calling each 
> user's
> + * task_alloc hook. Be careful with task_free hook, for security_task_free()
> + * can be called when calling each user's task_alloc hook failed.
> + *
> + * Note that security_reserve_task_blob_index() uses "u16". It is not a good
> + * idea to directly reserve large amount. Sum of reserved amount by all users
> + * should be less than PAGE_SIZE bytes, for per "struct task_struct" security
> + * blob is allocated for each "struct task_struct" using kcalloc().
> + */
> +extern u16 __init security_reserve_task_blob_index(const u16 size);
> +static inline void *task_security(const struct task_struct *task,
> +   const u16 index)
> +{
> + unsigned long *p = task->security;
> +
> + return p + index;
> +}
> +
>  #endif /* ! __LINUX_LSM_HOOKS_H */
> diff --git a/security/security.c b/security/security.c
> index 549bddc..4dc6bca 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -32,6 +32,7 @@
>  /* Maximum number of letters for an LSM name string */
>  #define SECURITY_NAME_MAX10
>  
> +static u16 lsm_max_per_task_blob_index __ro_after_init;
>  struct security_hook_heads security_hook_heads __lsm_ro_after_init;
>  char *lsm_names;
>  /* Boot-time LSM user choice */

Re: [PATCH -v6 11/13] futex: Rework futex_lock_pi() to use rt_mutex_*_proxy_lock()

[alexander . levin]

On Wed, Mar 22, 2017 at 11:35:58AM +0100, Peter Zijlstra wrote:
> By changing futex_lock_pi() to use rt_mutex_*_proxy_lock() we arrive
> at a point where all wait_list modifications are done under both
> hb->lock and wait_lock.
[...]

Hey Peter,

I'm seeing the following, which seems to be related to this patch:

[   21.762875] ODEBUG: free active (active state 0) object type: hrtimer hint: 
hrtimer_wakeup (kernel/time/hrtimer.c:1423)
[   21.771034] [ cut here ]
[   21.771657] WARNING: CPU: 6 PID: 1974 at lib/debugobjects.c:289 
debug_print_object (lib/debugobjects.c:286)
[   21.772872] Modules linked in:
[   21.773323] CPU: 6 PID: 1974 Comm: trinity-c92 Not tainted 
4.11.0-rc5-next-20170407-dirty #21
[   21.774534] task: 880389063e40 task.stack: 880389158000
[   21.775383] RIP: 0010:debug_print_object (??:?)
[   21.776081] RSP: 0018:88038915f108 EFLAGS: 00010086
[   21.776815] RAX: 0057 RBX: 0003 RCX: 
[   21.91] RDX: 0057 RSI: 11007122bdc0 RDI: ed007122be17
[   21.778773] RBP: 88038915f130 R08: 203a47554245444f R09: 7463612065657266
[   21.779756] R10:  R11: 147e R12: 834598e0
[   21.780741] R13: 8127c150 R14:  R15: 8410e588
[   21.782945] FS:  7fd5e261f700() GS:88039cb8() 
knlGS:
[   21.783942] CS:  0010 DS:  ES:  CR0: 80050033
[   21.784638] CR2: 7fd5e21f2520 CR3: 00038d4c9000 CR4: 000406a0
[   21.785718] DR0: 7fd5e00df000 DR1:  DR2: 
[   21.786675] DR3:  DR6: 0ff0 DR7: 0600
[   21.787684] Call Trace:
[   21.788050] debug_object_free (lib/debugobjects.c:603)
[   21.791105] destroy_hrtimer_on_stack (kernel/time/hrtimer.c:427)
[   21.791746] futex_lock_pi (kernel/futex.c:2740)
[   21.800721] do_futex (kernel/futex.c:3399)
[   21.818395] SyS_futex (kernel/futex.c:3447 kernel/futex.c:3415)
[   21.822260] do_syscall_64 (arch/x86/entry/common.c:284)
[   21.827328] entry_SYSCALL64_slow_path (arch/x86/entry/entry_64.S:249)
  [ 
  21.827960] RIP: 0033:0x7fd5e1f2e8e9^M 
[   
21.828455] RSP: 002b:7ffcfe586f48 EFLAGS: 0246 ORIG_RAX: 
00ca^M  
 [   21.829931] RAX: ffda RBX: 00ca RCX: 
7fd5e1f2e8e9^M  
  [   21.830875] RDX: 4000 RSI: 0086 RDI: 
7fd5e00df000^M  
  [   21.831783] RBP: 7fd5e0a12000 R08: 7fd5e2426000 R09: 
008008000100a000^M  
  [   21.832775] R10: 7fd5e00e1000 R11: 0246 R12: 
0002^M  
  [   21.833705] R13: 7fd5e0a12048 R14: 7fd5e261f698 R15: 
7fd5e0a12000^M  
  [   21.834644] Code: 0d 48 89 75 d8 e8 30 01 8b ff 48 8b 75 d8 48 
8b 14 dd 40 8f 51 83 4d 89 e9 4d 89 e0 44 89 f1 48 c7 c7 e0 85 51 83 e8 e3 29 
75 ff <0f> ff 83 05 4a 1e 16 02 01 48 83 c4 08 5b 41 5c 41 5d 41 5e 5d 
All code
  

   0:   0d 48 89 75 d8  or $0xd8758948,%eax 

 5:   e8 30 01 8b ff  callq  0xff8b013a
   a:   48 8b 75 d8 mov-0x28(%rbp),%rsi 

 e:   48 8b 14 dd 40 8f 51mov-0x7cae70c0(,%rbx,8),%rdx  
  
15:   83
  
16:   4d 89 e9mov%r13,%r9   
  
19:   4d 89 e0mov%r12,%r8   
  
1c:   44 89 f1mov%r14d,%ecx
  1f:   48 c7 c7 e0 85 51 83mov$0x835185e0,%rdi
  26:   e8 e3 29 75 ff  callq  0xff752a0e
  2b:*  0f ff   (bad)   

[PATCH v3 1/2] dt-bindings: iio: stm32-dac: Add support for STM32 DAC

[Fabrice Gasnier]

Document STMicroelectronics STM32 DAC (digital-to-analog converter).

Signed-off-by: Fabrice Gasnier 
---
Changes in v2:
- use 'reg' instead of 'st,dac-channel' property
- remove alignment from description
---
 .../devicetree/bindings/iio/dac/st,stm32-dac.txt   | 61 ++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt

diff --git a/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt 
b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt
new file mode 100644
index 000..bcee71f
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt
@@ -0,0 +1,61 @@
+STMicroelectronics STM32 DAC
+
+The STM32 DAC is a 12-bit voltage output digital-to-analog converter. The DAC
+may be configured in 8 or 12-bit mode. It has two output channels, each with
+its own converter.
+It has built-in noise and triangle waveform generator and supports external
+triggers for conversions. The DAC's output buffer allows a high drive output
+current.
+
+Contents of a stm32 dac root node:
+---
+Required properties:
+- compatible: Must be "st,stm32h7-dac-core".
+- reg: Offset and length of the device's register set.
+- clocks: Must contain an entry for pclk (which feeds the peripheral bus
+  interface)
+- clock-names: Must be "pclk".
+- vref-supply: Phandle to the vref+ input analog reference supply.
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties:
+- resets: Must contain the phandle to the reset controller.
+- A pinctrl state named "default" for each DAC channel may be defined to set
+  DAC_OUTx pin in mode of operation for analog output on external pin.
+
+Contents of a stm32 dac child node:
+---
+DAC core node should contain at least one subnode, representing a
+DAC instance/channel available on the machine.
+
+Required properties:
+- compatible: Must be "st,stm32-dac".
+- reg: Must be either 1 or 2, to define (single) channel in use
+- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
+  Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Example:
+   dac: dac@40007400 {
+   compatible = "st,stm32h7-dac-core";
+   reg = <0x40007400 0x400>;
+   clocks = <&clk>;
+   clock-names = "pclk";
+   vref-supply = <®_vref>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&dac_out1 &dac_out2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dac1: dac@1 {
+   compatible = "st,stm32-dac";
+   #io-channels-cells = <1>;
+   reg = <1>;
+   };
+
+   dac2: dac@2 {
+   compatible = "st,stm32-dac";
+   #io-channels-cells = <1>;
+   reg = <2>;
+   };
+   };
-- 
1.9.1

[PATCH 3.12 052/142] perf/core: Fix event inheritance on fork()

[Jiri Slaby]

From: Peter Zijlstra 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit e7cc4865f0f31698ef2f7aac01a50e78968985b7 upstream.

While hunting for clues to a use-after-free, Oleg spotted that
perf_event_init_context() can loose an error value with the result
that fork() can succeed even though we did not fully inherit the perf
event context.

Spotted-by: Oleg Nesterov 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Arnaldo Carvalho de Melo 
Cc: Dmitry Vyukov 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Mathieu Desnoyers 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Cc: o...@redhat.com
Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned 
and non-pinned lists")
Link: http://lkml.kernel.org/r/20170316125823.190342...@infradead.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby 
---
 kernel/events/core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index a4a1516f3efc..0a360d3868c5 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7754,7 +7754,7 @@ int perf_event_init_context(struct task_struct *child, 
int ctxn)
ret = inherit_task_group(event, parent, parent_ctx,
 child, ctxn, &inherited_all);
if (ret)
-   break;
+   goto out_unlock;
}
 
/*
@@ -7770,7 +7770,7 @@ int perf_event_init_context(struct task_struct *child, 
int ctxn)
ret = inherit_task_group(event, parent, parent_ctx,
 child, ctxn, &inherited_all);
if (ret)
-   break;
+   goto out_unlock;
}
 
raw_spin_lock_irqsave(&parent_ctx->lock, flags);
@@ -7798,6 +7798,7 @@ int perf_event_init_context(struct task_struct *child, 
int ctxn)
}
 
raw_spin_unlock_irqrestore(&parent_ctx->lock, flags);
+out_unlock:
mutex_unlock(&parent_ctx->mutex);
 
perf_unpin_context(parent_ctx);
-- 
2.12.2

Re: [PATCH] x86/irq: Do not check available vectors if current CPU has no irq to migrate

[Chen Yu]

Hi Prarit,
On Mon, Apr 10, 2017 at 07:26:31AM -0400, Prarit Bhargava wrote:
> 
> 
> On 04/09/2017 09:53 AM, Chen Yu wrote:
> > This is an optimization to bypass the free vector checking if the current
> > CPU has no irq to migrate. This can especially speed up the CPU offline
> > process when there are many CPUs in the system.
> 
> Chen, OOC how much time does this save?
> 
Previously I was doing some debugging on irq related issue
when check_irq_vectors_for_cpu_disable() printed a warning
on that platform, thus I incidentally look at this code and
did not measure it : )

I've just done a comparison of the function duration of
check_irq_vectors_for_cpu_disable() with/without the patch
(32 online CPUs)
before patch:
[001] d..1   264.017803: check_irq_vectors_for_cpu_disable <-native_cpu_disable
[001] d..1   264.017886: clear_local_APIC <-native_cpu_disable
after patch:
[001] d..1   862.011847: check_irq_vectors_for_cpu_disable <-native_cpu_disable
[001] d..1   862.011850: clear_local_APIC <-native_cpu_disable
About  (83 - 17) = 66 microsecond.

thanks,
Yu
> P.
> 
> > 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: Prarit Bhargava 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Len Brown 
> > Cc: x...@kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Chen Yu 
> > ---
> >  arch/x86/kernel/irq.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> > index 4d8183b..b9bdc1e 100644
> > --- a/arch/x86/kernel/irq.c
> > +++ b/arch/x86/kernel/irq.c
> > @@ -394,6 +394,9 @@ int check_irq_vectors_for_cpu_disable(void)
> > !cpumask_subset(&affinity_new, &online_new))
> > this_count++;
> > }
> > +   /* No need to check any further. */
> > +   if (!this_count)
> > +   return 0;
> >  
> > count = 0;
> > for_each_online_cpu(cpu) {
> > 

[PATCH v3 2/2] iio: dac: add support for stm32 DAC

[Fabrice Gasnier]

Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage
output digital-to-analog converter. It has two output channels, each
with its own converter.
It supports 8 bits or 12bits left/right aligned data format. Only
12bits right-aligned is used here. It has built-in noise or
triangle waveform generator, and supports external triggers for
conversions.
Each channel can be used independently, with separate trigger, then
separate IIO devices are used to handle this. Core driver is intended
to share common resources such as clock, reset, reference voltage and
registers.

Signed-off-by: Fabrice Gasnier 
---
Changes in v3:
- Fix powerdown, no need for 'enable', use 'three_state' as standard name
  for 'left floating' as per ABI documentation, instead of 'Hi-Z'.

Changes in v2:
- Define 'Hi-Z'/'enable' powerdown modes instead of using 'enable'
  attribute normally not used for DACs.
- use 'reg' instead of 'st,dac-channel' property
- Use macro to differentiate channels
- Fix typos, remove leading '&' for functions
- Add comments on single channel per device
- Use devm_iio_device_register variant, removes need for .remove
---
 drivers/iio/dac/Kconfig  |  15 ++
 drivers/iio/dac/Makefile |   2 +
 drivers/iio/dac/stm32-dac-core.c | 180 +
 drivers/iio/dac/stm32-dac-core.h |  51 ++
 drivers/iio/dac/stm32-dac.c  | 334 +++
 5 files changed, 582 insertions(+)
 create mode 100644 drivers/iio/dac/stm32-dac-core.c
 create mode 100644 drivers/iio/dac/stm32-dac-core.h
 create mode 100644 drivers/iio/dac/stm32-dac.c

diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index d3084028..7198648 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -274,6 +274,21 @@ config MCP4922
  To compile this driver as a module, choose M here: the module
  will be called mcp4922.
 
+config STM32_DAC
+   tristate "STMicroelectronics STM32 DAC"
+   depends on (ARCH_STM32 && OF) || COMPILE_TEST
+   depends on REGULATOR
+   select STM32_DAC_CORE
+   help
+ Say yes here to build support for STMicroelectronics STM32 Digital
+ to Analog Converter (DAC).
+
+ This driver can also be built as a module.  If so, the module
+ will be called stm32-dac.
+
+config STM32_DAC_CORE
+   tristate
+
 config VF610_DAC
tristate "Vybrid vf610 DAC driver"
depends on OF
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index f01bf4a..afe8ae7 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -29,4 +29,6 @@ obj-$(CONFIG_MAX517) += max517.o
 obj-$(CONFIG_MAX5821) += max5821.o
 obj-$(CONFIG_MCP4725) += mcp4725.o
 obj-$(CONFIG_MCP4922) += mcp4922.o
+obj-$(CONFIG_STM32_DAC_CORE) += stm32-dac-core.o
+obj-$(CONFIG_STM32_DAC) += stm32-dac.o
 obj-$(CONFIG_VF610_DAC) += vf610_dac.o
diff --git a/drivers/iio/dac/stm32-dac-core.c b/drivers/iio/dac/stm32-dac-core.c
new file mode 100644
index 000..75e4878
--- /dev/null
+++ b/drivers/iio/dac/stm32-dac-core.c
@@ -0,0 +1,180 @@
+/*
+ * This file is part of STM32 DAC driver
+ *
+ * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
+ * Author: Fabrice Gasnier .
+ *
+ * License type: GPLv2
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.
+ * See the GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "stm32-dac-core.h"
+
+/**
+ * struct stm32_dac_priv - stm32 DAC core private data
+ * @pclk:  peripheral clock common for all DACs
+ * @rst:   peripheral reset control
+ * @vref:  regulator reference
+ * @common:Common data for all DAC instances
+ */
+struct stm32_dac_priv {
+   struct clk *pclk;
+   struct reset_control *rst;
+   struct regulator *vref;
+   struct stm32_dac_common common;
+};
+
+static struct stm32_dac_priv *to_stm32_dac_priv(struct stm32_dac_common *com)
+{
+   return container_of(com, struct stm32_dac_priv, common);
+}
+
+static const struct regmap_config stm32_dac_regmap_cfg = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = sizeof(u32),
+   .max_register = 0x3fc,
+};
+
+static int stm32_dac_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct stm32_dac_priv *priv;
+   struct regmap *regmap;
+   struct resource *res;
+   void __iomem *mmio;
+   int ret;
+
+   if 

[PATCH 3.12 085/142] USB: uss720: fix NULL-deref at probe

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit f259ca3eed6e4b79ac3d5c5c9fb259fb46e86217 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Note that the endpoint access that causes the NULL-deref is currently
only used for debugging purposes during probe so the oops only happens
when dynamic debugging is enabled. This means the driver could be
rewritten to continue to accept device with only two endpoints, should
such devices exist.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/misc/uss720.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index 40ef40affe83..3cb05eb5f1df 100644
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -715,6 +715,11 @@ static int uss720_probe(struct usb_interface *intf,
 
interface = intf->cur_altsetting;
 
+   if (interface->desc.bNumEndpoints < 3) {
+   usb_put_dev(usbdev);
+   return -ENODEV;
+   }
+
/*
 * Allocate parport interface 
 */
-- 
2.12.2

[PATCH 3.12 084/142] usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

[Jiri Slaby]

From: Samuel Thibault 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault 
Acked-by: Alan Stern 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/core/config.c  | 10 ++
 drivers/usb/core/quirks.c  |  8 
 include/linux/usb/quirks.h |  6 ++
 3 files changed, 24 insertions(+)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 15b39065f1dc..ee8e42064d25 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -248,6 +248,16 @@ static int usb_parse_endpoint(struct device *ddev, int 
cfgno, int inum,
 
/*
 * Adjust bInterval for quirked devices.
+*/
+   /*
+* This quirk fixes bIntervals reported in ms.
+*/
+   if (to_usb_device(ddev)->quirks &
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL) {
+   n = clamp(fls(d->bInterval) + 3, i, j);
+   i = j = n;
+   }
+   /*
 * This quirk fixes bIntervals reported in
 * linear microframes.
 */
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 094fe92ac21f..f792e6bea6b4 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -164,6 +164,14 @@ static const struct usb_device_id usb_quirk_list[] = {
/* M-Systems Flash Disk Pioneers */
{ USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME },
 
+   /* Baum Vario Ultra */
+   { USB_DEVICE(0x0904, 0x6101), .driver_info =
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
+   { USB_DEVICE(0x0904, 0x6102), .driver_info =
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
+   { USB_DEVICE(0x0904, 0x6103), .driver_info =
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
+
/* Keytouch QWERTY Panel keyboard */
{ USB_DEVICE(0x0926, 0x), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 7eb814c60b5d..24872fc86962 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -50,4 +50,10 @@
 /* device can't handle Link Power Management */
 #define USB_QUIRK_NO_LPM   BIT(10)
 
+/*
+ * Device reports its bInterval as linear frames instead of the
+ * USB 2.0 calculation.
+ */
+#define USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL  BIT(11)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
2.12.2

[PATCH v3 0/2] Add STM32H7 DAC driver

[Fabrice Gasnier]

This patchset adds support for the STM32H7 DAC controller

It's a 12-bit, voltage output digital-to-analog converter. It has two
output channels, each with its own converter, trigger sources and
waveform generator.

Each channel can be used independently, so common resources are managed
in stm32-dac-core driver (e.g. clock, reset, regulator, registers).
One IIO device is instantiated per DAC output channel, in stm32-dac
driver, so each channel can have its own trigger.

Examples, using this driver to generate DC voltage output on channel1:
# set max DC voltage / enable / min DC voltage / disable on out1
cd /sys/bus/iio/devices/iio\:device0
echo 4095 > out_voltage1_raw
echo 0 > out_voltage1_powerdown
echo 0 > out_voltage1_raw
echo 1 > out_voltage1_powerdown
cat out_voltage_powerdown_mode_available
three_state

---
Changes in v3:
- Fix powerdown mode, use 'three_state' as documented in sysfs-bus-iio
- For now, drop support for triggers & waveform generator that requires more 
work.
  This needs to be discussed more deeply.

Changes in v2:
- Update dt binding, use 'reg' property to select channel
- Use 'powerdown' attribute instead of 'enable'
- Added set_trigger callback
- Use 'offset' attribute in waveform generation mode to add DC offset
- rework ABI for waveform generation mode
- Various typos, comments

Fabrice Gasnier (2):
  dt-bindings: iio: stm32-dac: Add support for STM32 DAC
  iio: dac: add support for stm32 DAC

 .../devicetree/bindings/iio/dac/st,stm32-dac.txt   |  61 
 drivers/iio/dac/Kconfig|  15 +
 drivers/iio/dac/Makefile   |   2 +
 drivers/iio/dac/stm32-dac-core.c   | 180 +++
 drivers/iio/dac/stm32-dac-core.h   |  51 
 drivers/iio/dac/stm32-dac.c| 334 +
 6 files changed, 643 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/dac/st,stm32-dac.txt
 create mode 100644 drivers/iio/dac/stm32-dac-core.c
 create mode 100644 drivers/iio/dac/stm32-dac-core.h
 create mode 100644 drivers/iio/dac/stm32-dac.c

-- 
1.9.1

[PATCH 3.12 071/142] USB: qcserial: add Dell Wireless 5809e Gobi 4G HSPA+ (rev3)

[Jiri Slaby]

From: Patrik Halfar 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 013dd239d6220a4e0dfdf0d45a82c34f1fd73deb upstream.

New revision of Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card
has new idProduct.

Bus 002 Device 006: ID 413c:81b3 Dell Computer Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x413c Dell Computer Corp.
  idProduct  0x81b3
  bcdDevice0.06
  iManufacturer   1 Sierra Wireless, Incorporated
  iProduct2 Dell Wireless 5809e Gobi™ 4G HSPA+ Mobile Broadband 
Card
  iSerial 3
  bNumConfigurations  2

Signed-off-by: Patrik Halfar 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 2c9a44523991..68ec0b1bdc18 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -163,6 +163,7 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81a8)},   /* Dell Wireless 5808 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a9)},   /* Dell Wireless 5808e Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81b1)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card */
+   {DEVICE_SWI(0x413c, 0x81b3)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card (rev3) */
 
{ } /* Terminating entry */
 };
-- 
2.12.2

Re: [patch 1/3] mm: protect set_page_dirty() from ongoing truncation

[Jan Kara]

On Mon 10-04-17 15:07:58, alexander.le...@verizon.com wrote:
> On Mon, Apr 10, 2017 at 02:06:38PM +0200, Jan Kara wrote:
> > On Mon 10-04-17 02:22:33, alexander.le...@verizon.com wrote:
> > > On Fri, Dec 05, 2014 at 09:52:44AM -0500, Johannes Weiner wrote:
> > > > Tejun, while reviewing the code, spotted the following race condition
> > > > between the dirtying and truncation of a page:
> > > > 
> > > > __set_page_dirty_nobuffers()   __delete_from_page_cache()
> > > >   if (TestSetPageDirty(page))
> > > >  page->mapping = NULL
> > > >  if (PageDirty())
> > > >dec_zone_page_state(page, 
> > > > NR_FILE_DIRTY);
> > > >
> > > > dec_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
> > > > if (page->mapping)
> > > >   account_page_dirtied(page)
> > > > __inc_zone_page_state(page, NR_FILE_DIRTY);
> > > > __inc_bdi_stat(mapping->backing_dev_info, BDI_RECLAIMABLE);
> > > > 
> > > > which results in an imbalance of NR_FILE_DIRTY and BDI_RECLAIMABLE.
> > > > 
> > > > Dirtiers usually lock out truncation, either by holding the page lock
> > > > directly, or in case of zap_pte_range(), by pinning the mapcount with
> > > > the page table lock held.  The notable exception to this rule, though,
> > > > is do_wp_page(), for which this race exists.  However, do_wp_page()
> > > > already waits for a locked page to unlock before setting the dirty
> > > > bit, in order to prevent a race where clear_page_dirty() misses the
> > > > page bit in the presence of dirty ptes.  Upgrade that wait to a fully
> > > > locked set_page_dirty() to also cover the situation explained above.
> > > > 
> > > > Afterwards, the code in set_page_dirty() dealing with a truncation
> > > > race is no longer needed.  Remove it.
> > > > 
> > > > Reported-by: Tejun Heo 
> > > > Signed-off-by: Johannes Weiner 
> > > > Cc: 
> > > > Acked-by: Kirill A. Shutemov 
> > > 
> > > Hi Johannes,
> > > 
> > > I'm seeing the following while fuzzing with trinity on linux-next (I've 
> > > changed
> > > the WARN to a VM_BUG_ON_PAGE for some extra page info).
> > 
> > But this looks more like a bug in 9p which allows v9fs_write_end() to dirty
> > a !Uptodate page?
> 
> I thought that 77469c3f5 ("9p: saner ->write_end() on failing copy into
> non-uptodate page") prevented from that happening, but that's actually the
> change that's causing it (I ended up misreading it last night).
> 
> Will fix it as follows:

Yep, this looks good to me, although I'd find it more future-proof if we
had that SetPageUptodate() additionally guarded a by len == PAGE_SIZE
check.

Honza

> 
> diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c 
> index adaf6f6..be84c0c 100644 
> --- a/fs/9p/vfs_addr.c 
> +++ b/fs/9p/vfs_addr.c 
> @@ -310,9 +310,13 @@ static int v9fs_write_end(struct file *filp, struct 
> address_space *mapping, 
>   
> p9_debug(P9_DEBUG_VFS, "filp %p, mapping %p\n", filp, mapping); 
>   
> -   if (unlikely(copied < len && !PageUptodate(page))) { 
> -   copied = 0; 
> -   goto out; 
> +   if (!PageUptodate(page)) { 
> +   if (unlikely(copied < len)) { 
> +   copied = 0;
> +   goto out; 
> +   } else { 
> +   SetPageUptodate(page); 
> +   } 
> } 
> /* 
>  * No need to use i_size_read() here, the i_size
>  
> -- 
> 
> Thanks,
> Sasha
-- 
Jan Kara 
SUSE Labs, CR

[PATCH 3.12 072/142] USB: qcserial: add Sierra Wireless EM74xx device ID

[Jiri Slaby]

From: Bjørn Mork 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 04fdbc825ffc02fb098964b92de802fff44e73fd upstream.

The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.

Signed-off-by: Bjørn Mork 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/serial/qcserial.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 68ec0b1bdc18..25f97da78989 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -155,8 +155,10 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
-   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
-   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
+   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx */
+   {DEVICE_SWI(0x1199, 0x9078)},   /* Sierra Wireless EM74xx */
+   {DEVICE_SWI(0x1199, 0x9079)},   /* Sierra Wireless EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.12.2

[PATCH 3.12 086/142] USB: idmouse: fix NULL-deref at probe

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit b0addd3fa6bcd119be9428996d5d4522479ab240 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/misc/idmouse.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/misc/idmouse.c b/drivers/usb/misc/idmouse.c
index ce978384fda1..3b885c61b73e 100644
--- a/drivers/usb/misc/idmouse.c
+++ b/drivers/usb/misc/idmouse.c
@@ -347,6 +347,9 @@ static int idmouse_probe(struct usb_interface *interface,
if (iface_desc->desc.bInterfaceClass != 0x0A)
return -ENODEV;
 
+   if (iface_desc->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL)
-- 
2.12.2

Re: KASLR causes intermittent boot failures on some systems

[Jeff Moyer]

Kees Cook  writes:

> On Fri, Apr 7, 2017 at 7:41 AM, Jeff Moyer  wrote:
>> Hi,
>>
>> commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory
>> regions") causes some of my systems with persistent memory (whether real
>> or emulated) to fail to boot with a couple of different crash
>> signatures.  The first signature is a NMI watchdog lockup of all but 1
>> cpu, which causes much difficulty in extracting useful information from
>> the console.  The second variant is an invalid paging request, listed
>> below.
>
> Just to rule out some of the stuff in the boot path, does booting with
> "nokaslr" solve this? (i.e. I want to figure out if this is from some
> of the rearrangements done that are exposed under that commit, or if
> it is genuinely the randomization that is killing the systems...)

Adding "nokaslr" to the boot line does indeed make the problem go away.

Cheers,
Jeff

[PATCH 3.12 087/142] USB: wusbcore: fix NULL-deref at probe

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 03ace948a4eb89d1cf51c06afdfc41ebca5fdb27 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

This specifically fixes the NULL-pointer dereference when probing HWA HC
devices.

Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core")
Cc: Inaky Perez-Gonzalez 
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/wusbcore/wa-hc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/wusbcore/wa-hc.c b/drivers/usb/wusbcore/wa-hc.c
index a09b65ebd9bb..2bb0fd3f3423 100644
--- a/drivers/usb/wusbcore/wa-hc.c
+++ b/drivers/usb/wusbcore/wa-hc.c
@@ -38,6 +38,9 @@ int wa_create(struct wahc *wa, struct usb_interface *iface)
int result;
struct device *dev = &iface->dev;
 
+   if (iface->cur_altsetting->desc.bNumEndpoints < 3)
+   return -ENODEV;
+
result = wa_rpipes_create(wa);
if (result < 0)
goto error_rpipes_create;
-- 
2.12.2

[PATCH 3.12 088/142] usb: hub: Fix crash after failure to read BOS descriptor

[Jiri Slaby]

From: Guenter Roeck 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 7b2db29fbb4e766fcd02207eb2e2087170bd6ebc upstream.

If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
Nevertheless, it is dereferenced unconditionally in
hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
This results in a crash.

usb 5-1: unable to get BOS descriptor
...
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = ffc00165f000
[0008] *pgd=0174f003, *pud=0174f003,
*pmd=01750003, *pte=00e801751713
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: GB 4.4.52 #480
Hardware name: Google Kevin (DT)
Workqueue: events driver_set_config_work
task: ffc0c369 ti: ffc0ae9a8000 task.ti: ffc0ae9a8000
PC is at hub_port_init+0xc3c/0xd10
LR is at hub_port_init+0xc3c/0xd10
...
Call trace:
[] hub_port_init+0xc3c/0xd10
[] usb_reset_and_verify_device+0x15c/0x82c
[] usb_reset_device+0xe4/0x298
[] rtl8152_probe+0x84/0x9b0 [r8152]
[] usb_probe_interface+0x244/0x2f8
[] driver_probe_device+0x180/0x3b4
[] __device_attach_driver+0xb4/0xe0
[] bus_for_each_drv+0xb4/0xe4
[] __device_attach+0xd0/0x158
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x50/0xe4
[] device_add+0x414/0x738
[] usb_set_configuration+0x89c/0x914
[] driver_set_config_work+0xc0/0xf0
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

Since we don't know anything about LPM capabilities without BOS descriptor,
don't attempt to enable LPM if it is not available.

Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...")
Cc: Mathias Nyman 
Signed-off-by: Guenter Roeck 
Acked-by: Mathias Nyman 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/core/hub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 770cea7de0ec..53aa23dee140 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4004,7 +4004,7 @@ static void hub_set_initial_usb2_lpm_policy(struct 
usb_device *udev)
 {
int connect_type;
 
-   if (!udev->usb2_hw_lpm_capable)
+   if (!udev->usb2_hw_lpm_capable || !udev->bos)
return;
 
connect_type = usb_get_hub_port_connect_type(udev->parent,
-- 
2.12.2

[PATCH 3.12 093/142] mmc: sdhci: Do not disable interrupts while waiting for clock

[Jiri Slaby]

From: Adrian Hunter 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit e2ebfb2142acefecc2496e71360f50d25726040b upstream.

Disabling interrupts for even a millisecond can cause problems for some
devices. That can happen when sdhci changes clock frequency because it
waits for the clock to become stable under a spin lock.

The spin lock is not necessary here. Anything that is racing with changes
to the I/O state is already broken. The mmc core already provides
synchronization via "claiming" the host.

Although the spin lock probably should be removed from the code paths that
lead to this point, such a patch would touch too much code to be suitable
for stable trees. Consequently, for this patch, just drop the spin lock
while waiting.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson 
Tested-by: Ludovic Desroches 
Signed-off-by: Jiri Slaby 
---
 drivers/mmc/host/sdhci.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4e697ea67ae2..c3070ab2a05c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1232,7 +1232,9 @@ clock_set:
return;
}
timeout--;
-   mdelay(1);
+   spin_unlock_irq(&host->lock);
+   usleep_range(900, 1100);
+   spin_lock_irq(&host->lock);
}
 
clk |= SDHCI_CLOCK_CARD_EN;
-- 
2.12.2

[PATCH 3.12 083/142] ACM gadget: fix endianness in notifications

[Jiri Slaby]

From: Oliver Neukum 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit cdd7928df0d2efaa3270d711963773a08a4cc8ab upstream.

The gadget code exports the bitfield for serial status changes
over the wire in its internal endianness. The fix is to convert
to little endian before sending it over the wire.

Signed-off-by: Oliver Neukum 
Tested-by: 家瑋 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/gadget/f_acm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/f_acm.c b/drivers/usb/gadget/f_acm.c
index 3384486c2884..ff30171b6926 100644
--- a/drivers/usb/gadget/f_acm.c
+++ b/drivers/usb/gadget/f_acm.c
@@ -535,13 +535,15 @@ static int acm_notify_serial_state(struct f_acm *acm)
 {
struct usb_composite_dev *cdev = acm->port.func.config->cdev;
int status;
+   __le16  serial_state;
 
spin_lock(&acm->lock);
if (acm->notify_req) {
DBG(cdev, "acm ttyGS%d serial state %04x\n",
acm->port_num, acm->serial_state);
+   serial_state = cpu_to_le16(acm->serial_state);
status = acm_cdc_notify(acm, USB_CDC_NOTIFY_SERIAL_STATE,
-   0, &acm->serial_state, 
sizeof(acm->serial_state));
+   0, &serial_state, sizeof(acm->serial_state));
} else {
acm->pending = true;
status = 0;
-- 
2.12.2

[PATCH 3.12 079/142] Input: kbtab - validate number of endpoints before using them

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit cb1b494663e037253337623bf1ef2df727883cb7 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Signed-off-by: Johan Hovold 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Slaby 
---
 drivers/input/tablet/kbtab.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/tablet/kbtab.c b/drivers/input/tablet/kbtab.c
index 3fba74b9b602..f0d532684afd 100644
--- a/drivers/input/tablet/kbtab.c
+++ b/drivers/input/tablet/kbtab.c
@@ -123,6 +123,9 @@ static int kbtab_probe(struct usb_interface *intf, const 
struct usb_device_id *i
struct input_dev *input_dev;
int error = -ENOMEM;
 
+   if (intf->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
kbtab = kzalloc(sizeof(struct kbtab), GFP_KERNEL);
input_dev = input_allocate_device();
if (!kbtab || !input_dev)
-- 
2.12.2

[PATCH 3.12 096/142] xfs: clear _XBF_PAGES from buffers when readahead page

[Jiri Slaby]

From: "Darrick J. Wong" 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b upstream.

If we try to allocate memory pages to back an xfs_buf that we're trying
to read, it's possible that we'll be so short on memory that the page
allocation fails.  For a blocking read we'll just wait, but for
readahead we simply dump all the pages we've collected so far.

Unfortunately, after dumping the pages we neglect to clear the
_XBF_PAGES state, which means that the subsequent call to xfs_buf_free
thinks that b_pages still points to pages we own.  It then double-frees
the b_pages pages.

This results in screaming about negative page refcounts from the memory
manager, which xfs oughtn't be triggering.  To reproduce this case,
mount a filesystem where the size of the inodes far outweighs the
availalble memory (a ~500M inode filesystem on a VM with 300MB memory
did the trick here) and run bulkstat in parallel with other memory
eating processes to put a huge load on the system.  The "check summary"
phase of xfs_scrub also works for this purpose.

Signed-off-by: Darrick J. Wong 
Reviewed-by: Eric Sandeen 
Cc: Ivan Kozik 
Signed-off-by: Jiri Slaby 
---
 fs/xfs/xfs_buf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index c4a4ad0cd33e..e99655a1b372 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -376,6 +376,7 @@ retry:
 out_free_pages:
for (i = 0; i < bp->b_page_count; i++)
__free_page(bp->b_pages[i]);
+   bp->b_flags &= ~_XBF_PAGES;
return error;
 }
 
-- 
2.12.2

[PATCH 3.12 094/142] nl80211: fix dumpit error path RTNL deadlocks

[Jiri Slaby]

From: Johannes Berg 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit ea90e0dc8cecba6359b481e24d9c37160f6f524f upstream.

Sowmini pointed out Dmitry's RTNL deadlock report to me, and it turns out
to be perfectly accurate - there are various error paths that miss unlock
of the RTNL.

To fix those, change the locking a bit to not be conditional in all those
nl80211_prepare_*_dump() functions, but make those require the RTNL to
start with, and fix the buggy error paths. This also let me use sparse
(by appropriately overriding the rtnl_lock/rtnl_unlock functions) to
validate the changes.

[js] no mpp and vendor dumps in 3.12 yet

Reported-by: Sowmini Varadhan 
Reported-by: Dmitry Vyukov 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby 
---
 net/wireless/nl80211.c | 52 --
 1 file changed, 21 insertions(+), 31 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cda142009426..bb03e47bf887 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -438,21 +438,17 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
 {
int err;
 
-   rtnl_lock();
-
if (!cb->args[0]) {
err = nlmsg_parse(cb->nlh, GENL_HDRLEN + nl80211_fam.hdrsize,
  nl80211_fam.attrbuf, nl80211_fam.maxattr,
  nl80211_policy);
if (err)
-   goto out_unlock;
+   return err;
 
*wdev = __cfg80211_wdev_from_attrs(sock_net(skb->sk),
   nl80211_fam.attrbuf);
-   if (IS_ERR(*wdev)) {
-   err = PTR_ERR(*wdev);
-   goto out_unlock;
-   }
+   if (IS_ERR(*wdev))
+   return PTR_ERR(*wdev);
*rdev = wiphy_to_dev((*wdev)->wiphy);
/* 0 is the first index - add 1 to parse only once */
cb->args[0] = (*rdev)->wiphy_idx + 1;
@@ -462,10 +458,8 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0] - 1);
struct wireless_dev *tmp;
 
-   if (!wiphy) {
-   err = -ENODEV;
-   goto out_unlock;
-   }
+   if (!wiphy)
+   return -ENODEV;
*rdev = wiphy_to_dev(wiphy);
*wdev = NULL;
 
@@ -476,21 +470,11 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
}
}
 
-   if (!*wdev) {
-   err = -ENODEV;
-   goto out_unlock;
-   }
+   if (!*wdev)
+   return -ENODEV;
}
 
return 0;
- out_unlock:
-   rtnl_unlock();
-   return err;
-}
-
-static void nl80211_finish_wdev_dump(struct cfg80211_registered_device *rdev)
-{
-   rtnl_unlock();
 }
 
 /* IE validation */
@@ -3607,9 +3591,10 @@ static int nl80211_dump_station(struct sk_buff *skb,
int sta_idx = cb->args[2];
int err;
 
+   rtnl_lock();
err = nl80211_prepare_wdev_dump(skb, cb, &dev, &wdev);
if (err)
-   return err;
+   goto out_err;
 
if (!wdev->netdev) {
err = -EINVAL;
@@ -3645,7 +3630,7 @@ static int nl80211_dump_station(struct sk_buff *skb,
cb->args[2] = sta_idx;
err = skb->len;
  out_err:
-   nl80211_finish_wdev_dump(dev);
+   rtnl_unlock();
 
return err;
 }
@@ -4273,9 +4258,10 @@ static int nl80211_dump_mpath(struct sk_buff *skb,
int path_idx = cb->args[2];
int err;
 
+   rtnl_lock();
err = nl80211_prepare_wdev_dump(skb, cb, &dev, &wdev);
if (err)
-   return err;
+   goto out_err;
 
if (!dev->ops->dump_mpath) {
err = -EOPNOTSUPP;
@@ -4309,7 +4295,7 @@ static int nl80211_dump_mpath(struct sk_buff *skb,
cb->args[2] = path_idx;
err = skb->len;
  out_err:
-   nl80211_finish_wdev_dump(dev);
+   rtnl_unlock();
return err;
 }
 
@@ -5853,9 +5839,12 @@ static int nl80211_dump_scan(struct sk_buff *skb, struct 
netlink_callback *cb)
int start = cb->args[2], idx = 0;
int err;
 
+   rtnl_lock();
err = nl80211_prepare_wdev_dump(skb, cb, &rdev, &wdev);
-   if (err)
+   if (err) {
+   rtnl_unlock();
return err;
+   }
 
wdev_lock(wdev);
spin_lock_bh(&rdev->bss_lock);
@@ -5878,7 +5867,7 @@ static int nl80211_dump_scan(struct sk_buff *skb, struct 
netlink_callback *cb)
wdev_unlock(wdev);
 
cb->args[2] = idx;
-   nl80211_finish_wdev_dump(rdev);
+   rtnl_unlock();
 
return skb->len;
 }
@@ -5951,9 +5940,10 @@ static int nl80

[PATCH 3.12 097/142] block: allow WRITE_SAME commands with the SG_IO ioctl

[Jiri Slaby]

From: Sumit Semwal 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

From: Mauricio Faria de Oliveira 

[ Upstream commit 25cdb64510644f3e854d502d69c73f21c6df88a9 ]

The WRITE_SAME commands are not present in the blk_default_cmd_filter
write_ok list, and thus are failed with -EPERM when the SG_IO ioctl()
is executed without CAP_SYS_RAWIO capability (e.g., unprivileged users).
[ sg_io() -> blk_fill_sghdr_rq() > blk_verify_command() -> -EPERM ]

The problem can be reproduced with the sg_write_same command

  # sg_write_same --num 1 --xferlen 512 /dev/sda
  #

  # capsh --drop=cap_sys_rawio -- -c \
'sg_write_same --num 1 --xferlen 512 /dev/sda'
Write same: pass through os error: Operation not permitted
  #

For comparison, the WRITE_VERIFY command does not observe this problem,
since it is in that list:

  # capsh --drop=cap_sys_rawio -- -c \
'sg_write_verify --num 1 --ilen 512 --lba 0 /dev/sda'
  #

So, this patch adds the WRITE_SAME commands to the list, in order
for the SG_IO ioctl to finish successfully:

  # capsh --drop=cap_sys_rawio -- -c \
'sg_write_same --num 1 --xferlen 512 /dev/sda'
  #

That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices
(qemu "-device scsi-block" [1], libvirt "" [2]),
which employs the SG_IO ioctl() and runs as an unprivileged user (libvirt-qemu).

In that scenario, when a filesystem (e.g., ext4) performs its zero-out calls,
which are translated to write-same calls in the guest kernel, and then into
SG_IO ioctls to the host kernel, SCSI I/O errors may be observed in the guest:

  [...] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
  [...] sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
  [...] sd 0:0:0:0: [sda] tag#0 Add. Sense: I/O process terminated
  [...] sd 0:0:0:0: [sda] tag#0 CDB: Write Same(10) 41 00 01 04 e0 78 00 00 08 
00
  [...] blk_update_request: I/O error, dev sda, sector 17096824

Links:
[1] 
http://git.qemu.org/?p=qemu.git;a=commit;h=336a6915bc7089fb20fea4ba99972ad9a97c5f52
[2] https://libvirt.org/formatdomain.html#elementsDisks (see 'disk' -> 'device')

Signed-off-by: Mauricio Faria de Oliveira 
Signed-off-by: Brahadambal Srinivasan 
Reported-by: Manjunatha H R 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 block/scsi_ioctl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 1b4988b4bc11..9bfbb51aa75e 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -175,6 +175,9 @@ static void blk_set_cmd_filter_defaults(struct 
blk_cmd_filter *filter)
__set_bit(WRITE_16, filter->write_ok);
__set_bit(WRITE_LONG, filter->write_ok);
__set_bit(WRITE_LONG_2, filter->write_ok);
+   __set_bit(WRITE_SAME, filter->write_ok);
+   __set_bit(WRITE_SAME_16, filter->write_ok);
+   __set_bit(WRITE_SAME_32, filter->write_ok);
__set_bit(ERASE, filter->write_ok);
__set_bit(GPCMD_MODE_SELECT_10, filter->write_ok);
__set_bit(MODE_SELECT, filter->write_ok);
-- 
2.12.2

[PATCH 3.12 098/142] uvcvideo: uvc_scan_fallback() for webcams with broken chain

[Jiri Slaby]

From: Sumit Semwal 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

From: Henrik Ingo 

[ Upstream commit e950267ab802c8558f1100eafd4087fd039ad634 ]

Some devices have invalid baSourceID references, causing uvc_scan_chain()
to fail, but if we just take the entities we can find and put them
together in the most sensible chain we can think of, turns out they do
work anyway. Note: This heuristic assumes there is a single chain.

At the time of writing, devices known to have such a broken chain are
  - Acer Integrated Camera (5986:055a)
  - Realtek rtl157a7 (0bda:57a7)

Signed-off-by: Henrik Ingo 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sumit Semwal 
Signed-off-by: Jiri Slaby 
---
 drivers/media/usb/uvc/uvc_driver.c | 118 +++--
 1 file changed, 112 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 45314412b4a3..f47d1885b0d4 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1533,6 +1533,114 @@ static const char *uvc_print_chain(struct 
uvc_video_chain *chain)
return buffer;
 }
 
+static struct uvc_video_chain *uvc_alloc_chain(struct uvc_device *dev)
+{
+   struct uvc_video_chain *chain;
+
+   chain = kzalloc(sizeof(*chain), GFP_KERNEL);
+   if (chain == NULL)
+   return NULL;
+
+   INIT_LIST_HEAD(&chain->entities);
+   mutex_init(&chain->ctrl_mutex);
+   chain->dev = dev;
+   v4l2_prio_init(&chain->prio);
+
+   return chain;
+}
+
+/*
+ * Fallback heuristic for devices that don't connect units and terminals in a
+ * valid chain.
+ *
+ * Some devices have invalid baSourceID references, causing uvc_scan_chain()
+ * to fail, but if we just take the entities we can find and put them together
+ * in the most sensible chain we can think of, turns out they do work anyway.
+ * Note: This heuristic assumes there is a single chain.
+ *
+ * At the time of writing, devices known to have such a broken chain are
+ *  - Acer Integrated Camera (5986:055a)
+ *  - Realtek rtl157a7 (0bda:57a7)
+ */
+static int uvc_scan_fallback(struct uvc_device *dev)
+{
+   struct uvc_video_chain *chain;
+   struct uvc_entity *iterm = NULL;
+   struct uvc_entity *oterm = NULL;
+   struct uvc_entity *entity;
+   struct uvc_entity *prev;
+
+   /*
+* Start by locating the input and output terminals. We only support
+* devices with exactly one of each for now.
+*/
+   list_for_each_entry(entity, &dev->entities, list) {
+   if (UVC_ENTITY_IS_ITERM(entity)) {
+   if (iterm)
+   return -EINVAL;
+   iterm = entity;
+   }
+
+   if (UVC_ENTITY_IS_OTERM(entity)) {
+   if (oterm)
+   return -EINVAL;
+   oterm = entity;
+   }
+   }
+
+   if (iterm == NULL || oterm == NULL)
+   return -EINVAL;
+
+   /* Allocate the chain and fill it. */
+   chain = uvc_alloc_chain(dev);
+   if (chain == NULL)
+   return -ENOMEM;
+
+   if (uvc_scan_chain_entity(chain, oterm) < 0)
+   goto error;
+
+   prev = oterm;
+
+   /*
+* Add all Processing and Extension Units with two pads. The order
+* doesn't matter much, use reverse list traversal to connect units in
+* UVC descriptor order as we build the chain from output to input. This
+* leads to units appearing in the order meant by the manufacturer for
+* the cameras known to require this heuristic.
+*/
+   list_for_each_entry_reverse(entity, &dev->entities, list) {
+   if (entity->type != UVC_VC_PROCESSING_UNIT &&
+   entity->type != UVC_VC_EXTENSION_UNIT)
+   continue;
+
+   if (entity->num_pads != 2)
+   continue;
+
+   if (uvc_scan_chain_entity(chain, entity) < 0)
+   goto error;
+
+   prev->baSourceID[0] = entity->id;
+   prev = entity;
+   }
+
+   if (uvc_scan_chain_entity(chain, iterm) < 0)
+   goto error;
+
+   prev->baSourceID[0] = iterm->id;
+
+   list_add_tail(&chain->list, &dev->chains);
+
+   uvc_trace(UVC_TRACE_PROBE,
+ "Found a video chain by fallback heuristic (%s).\n",
+ uvc_print_chain(chain));
+
+   return 0;
+
+error:
+   kfree(chain);
+   return -EINVAL;
+}
+
 /*
  * Scan the device for video chains and register video devices.
  *
@@ -1555,15 +1663,10 @@ static int uvc_scan_device(struct uvc_device *dev)
if (term->chain.next || term->chain.prev)
continue;
 
-

[PATCH 3.12 090/142] uwb: hwa-rc: fix NULL-deref at probe

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit daf229b15907fbfdb6ee183aac8ca428cb57e361 upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Note that the dereference happens in the start callback which is called
during probe.

Fixes: de520b8bd552 ("uwb: add HWA radio controller driver")
Cc: Inaky Perez-Gonzalez 
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/uwb/hwa-rc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/uwb/hwa-rc.c b/drivers/uwb/hwa-rc.c
index 0257f35cfb9d..e75bbe5a10cd 100644
--- a/drivers/uwb/hwa-rc.c
+++ b/drivers/uwb/hwa-rc.c
@@ -825,6 +825,9 @@ static int hwarc_probe(struct usb_interface *iface,
struct hwarc *hwarc;
struct device *dev = &iface->dev;
 
+   if (iface->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
result = -ENOMEM;
uwb_rc = uwb_rc_alloc();
if (uwb_rc == NULL) {
-- 
2.12.2

[PATCH 3.12 099/142] fbcon: Fix vc attr at deinit

[Jiri Slaby]

From: Takashi Iwai 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.

fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs in
the existing console buffer with one bit shift up (for 9 bits), while
it remaps with one bit shift down (for 8 bits) when the value is
cleared.  It works fine as long as the font gets updated after fbcon
was initialized.

However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb).  At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver.  During the
switching, we leave the modified attrs as is.  Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.

An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback.  Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Jiri Slaby 
---
 drivers/video/console/fbcon.c | 67 ++-
 1 file changed, 40 insertions(+), 27 deletions(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 9297a9b967fc..3939493bd3b3 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -1168,6 +1168,8 @@ static void fbcon_free_font(struct display *p, bool 
freefont)
p->userfont = 0;
 }
 
+static void set_vc_hi_font(struct vc_data *vc, bool set);
+
 static void fbcon_deinit(struct vc_data *vc)
 {
struct display *p = &fb_display[vc->vc_num];
@@ -1203,6 +1205,9 @@ finished:
if (free_font)
vc->vc_font.data = NULL;
 
+   if (vc->vc_hi_font_mask)
+   set_vc_hi_font(vc, false);
+
if (!con_is_bound(&fb_con))
fbcon_exit();
 
@@ -2438,32 +2443,10 @@ static int fbcon_get_font(struct vc_data *vc, struct 
console_font *font)
return 0;
 }
 
-static int fbcon_do_set_font(struct vc_data *vc, int w, int h,
-const u8 * data, int userfont)
+/* set/clear vc_hi_font_mask and update vc attrs accordingly */
+static void set_vc_hi_font(struct vc_data *vc, bool set)
 {
-   struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
-   struct fbcon_ops *ops = info->fbcon_par;
-   struct display *p = &fb_display[vc->vc_num];
-   int resize;
-   int cnt;
-   char *old_data = NULL;
-
-   if (CON_IS_VISIBLE(vc) && softback_lines)
-   fbcon_set_origin(vc);
-
-   resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
-   if (p->userfont)
-   old_data = vc->vc_font.data;
-   if (userfont)
-   cnt = FNTCHARCNT(data);
-   else
-   cnt = 256;
-   vc->vc_font.data = (void *)(p->fontdata = data);
-   if ((p->userfont = userfont))
-   REFCOUNT(data)++;
-   vc->vc_font.width = w;
-   vc->vc_font.height = h;
-   if (vc->vc_hi_font_mask && cnt == 256) {
+   if (!set) {
vc->vc_hi_font_mask = 0;
if (vc->vc_can_do_color) {
vc->vc_complement_mask >>= 1;
@@ -2486,7 +2469,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, 
int h,
((c & 0xfe00) >> 1) | (c & 0xff);
vc->vc_attr >>= 1;
}
-   } else if (!vc->vc_hi_font_mask && cnt == 512) {
+   } else {
vc->vc_hi_font_mask = 0x100;
if (vc->vc_can_do_color) {
vc->vc_complement_mask <<= 1;
@@ -2518,8 +2501,38 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, 
int h,
} else
vc->vc_video_erase_char = c & ~0x100;
}
-
}
+}
+
+static int fbcon_do_set_font(struct vc_data *vc, int w, int h,
+const u8 * data, int userfont)
+{
+   struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+   struct fbcon_ops *ops = info->fbcon_par;
+   struct display *p = &fb_display[vc->vc_num];
+   int resize;
+   int cnt;
+   char *old_data = NULL;
+
+   if (CON_IS_VISIBLE(vc) && softback_lines)
+   fbcon_set_origin(vc);
+
+   resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
+   if (p

[PATCH 3.12 103/142] virtio_balloon: init 1st buffer in stats vq

[Jiri Slaby]

From: Ladi Prosek 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit fc8653228c8588a120f6b5dad6983b7b61ff669e upstream.

When init_vqs runs, virtio_balloon.stats is either uninitialized or
contains stale values. The host updates its state with garbage data
because it has no way of knowing that this is just a marker buffer
used for signaling.

This patch updates the stats before pushing the initial buffer.

Alternative fixes:
* Push an empty buffer in init_vqs. Not easily done with the current
  virtio implementation and violates the spec "Driver MUST supply the
  same subset of statistics in all buffers submitted to the statsq".
* Push a buffer with invalid tags in init_vqs. Violates the same
  spec clause, plus "invalid tag" is not really defined.

Note: the spec says:
When using the legacy interface, the device SHOULD ignore all values in
the first buffer in the statsq supplied by the driver after device
initialization. Note: Historically, drivers supplied an uninitialized
buffer in the first buffer.

Unfortunately QEMU does not seem to implement the recommendation
even for the legacy interface.

Signed-off-by: Ladi Prosek 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Jiri Slaby 
---
 drivers/virtio/virtio_balloon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index d6fa59e447c5..0dc571a3cf65 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -350,6 +350,8 @@ static int init_vqs(struct virtio_balloon *vb)
 * Prime this virtqueue with one buffer so the hypervisor can
 * use it to signal us later.
 */
+   update_balloon_stats(vb);
+
sg_init_one(&sg, vb->stats, sizeof vb->stats);
if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL)
< 0)
-- 
2.12.2

Re: [PATCH] tick/nohz: Fix wrong user and system time accouting against vtime sampling

[Thomas Gleixner]

On Wed, 5 Apr 2017, Wanpeng Li wrote:
> + /*
> +  * Offset the tick to avert jiffies_lock contention, and all ticks
> +  * alignment in order that the vtime sampling does not end up "in
> +  * phase" with the jiffies incrementing.
> +  */
> + if (sched_skew_tick || tick_nohz_full_enabled()) {
>   u64 offset = ktime_to_ns(tick_period) >> 1;
>   do_div(offset, num_possible_cpus());
>   offset *= smp_processor_id();

That's not a fix, that's just papering over the problem.

   offset = 1ms / 2 = 500us = 50ns;
   offset /= 144 = 3472ns

So CPU0 and CPU1 ticks are ~3 microseconds apart. That merily reduces the
probability of the issue, but does not prevent it.

Thanks,

tglx

[PATCH 3.12 107/142] metag/ptrace: Provide default TXSTATUS for short NT_PRSTATUS

[Jiri Slaby]

From: Dave Martin 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 5fe81fe98123ce41265c65e95d34418d30d005d1 upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill TXSTATUS, a well-defined default value is used, based on the
task's current value.

Suggested-by: James Hogan 
Signed-off-by: Dave Martin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 arch/metag/kernel/ptrace.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/metag/kernel/ptrace.c b/arch/metag/kernel/ptrace.c
index ae659ba61948..2e4dfc15abd3 100644
--- a/arch/metag/kernel/ptrace.c
+++ b/arch/metag/kernel/ptrace.c
@@ -24,6 +24,16 @@
  * user_regset definitions.
  */
 
+static unsigned long user_txstatus(const struct pt_regs *regs)
+{
+   unsigned long data = (unsigned long)regs->ctx.Flags;
+
+   if (regs->ctx.SaveMask & TBICTX_CBUF_BIT)
+   data |= USER_GP_REGS_STATUS_CATCH_BIT;
+
+   return data;
+}
+
 int metag_gp_regs_copyout(const struct pt_regs *regs,
  unsigned int pos, unsigned int count,
  void *kbuf, void __user *ubuf)
@@ -62,9 +72,7 @@ int metag_gp_regs_copyout(const struct pt_regs *regs,
if (ret)
goto out;
/* TXSTATUS */
-   data = (unsigned long)regs->ctx.Flags;
-   if (regs->ctx.SaveMask & TBICTX_CBUF_BIT)
-   data |= USER_GP_REGS_STATUS_CATCH_BIT;
+   data = user_txstatus(regs);
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
  &data, 4*25, 4*26);
if (ret)
@@ -119,6 +127,7 @@ int metag_gp_regs_copyin(struct pt_regs *regs,
if (ret)
goto out;
/* TXSTATUS */
+   data = user_txstatus(regs);
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
 &data, 4*25, 4*26);
if (ret)
-- 
2.12.2

[PATCH 3.12 109/142] sched/rt: Add a missing rescheduling point

[Jiri Slaby]

From: Sebastian Andrzej Siewior 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 619bd4a71874a8fd78eb6ccf9f272c5e98bcc7b7 upstream.

Since the change in commit:

  fd7a4bed1835 ("sched, rt: Convert switched_{from, to}_rt() / 
prio_changed_rt() to balance callbacks")

... we don't reschedule a task under certain circumstances:

Lets say task-A, SCHED_OTHER, is running on CPU0 (and it may run only on
CPU0) and holds a PI lock. This task is removed from the CPU because it
used up its time slice and another SCHED_OTHER task is running. Task-B on
CPU1 runs at RT priority and asks for the lock owned by task-A. This
results in a priority boost for task-A. Task-B goes to sleep until the
lock has been made available. Task-A is already runnable (but not active),
so it receives no wake up.

The reality now is that task-A gets on the CPU once the scheduler decides
to remove the current task despite the fact that a high priority task is
enqueued and waiting. This may take a long time.

The desired behaviour is that CPU0 immediately reschedules after the
priority boost which made task-A the task with the lowest priority.

[js] no deadline in 3.12 yet

Suggested-by: Peter Zijlstra 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Thomas Gleixner 
Fixes: fd7a4bed1835 ("sched, rt: Convert switched_{from, to}_rt() 
prio_changed_rt() to balance callbacks")
Link: http://lkml.kernel.org/r/20170124144006.29821-1-bige...@linutronix.de
Signed-off-by: Ingo Molnar 
Signed-off-by: Jiri Slaby 
---
 kernel/sched/rt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 10edf9d2a8b7..ce4ec3ae9abc 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1871,10 +1871,9 @@ static void switched_to_rt(struct rq *rq, struct 
task_struct *p)
 #ifdef CONFIG_SMP
if (rq->rt.overloaded)
queue_push_tasks(rq);
-#else
+#endif /* CONFIG_SMP */
if (p->prio < rq->curr->prio)
resched_task(rq->curr);
-#endif /* CONFIG_SMP */
}
 }
 
-- 
2.12.2

[PATCH 3.12 105/142] sparc/ptrace: Preserve previous registers for short regset write

[Jiri Slaby]

From: Dave Martin 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit d3805c546b275c8cc7d40f759d029ae92c7175f2 upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.

Signed-off-by: Dave Martin 
Acked-by: David S. Miller 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 arch/sparc/kernel/ptrace_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
index 773c1f2983ce..89297b7c6261 100644
--- a/arch/sparc/kernel/ptrace_64.c
+++ b/arch/sparc/kernel/ptrace_64.c
@@ -310,7 +310,7 @@ static int genregs64_set(struct task_struct *target,
}
 
if (!ret) {
-   unsigned long y;
+   unsigned long y = regs->y;
 
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
 &y,
-- 
2.12.2

[PATCH 3.12 110/142] libceph: force GFP_NOIO for socket allocations

[Jiri Slaby]

From: Ilya Dryomov 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 633ee407b9d15a75ac9740ba9d3338815e1fcb95 upstream.

sock_alloc_inode() allocates socket+inode and socket_wq with
GFP_KERNEL, which is not allowed on the writeback path:

Workqueue: ceph-msgr con_work [libceph]
8810871cb018 0046  881085d4
00012b00 881025cad428 8810871cbfd8 00012b00
880102fc1000 881085d4 8810871cb038 8810871cb148
Call Trace:
[] schedule+0x29/0x70
[] schedule_timeout+0x1bd/0x200
[] ? ttwu_do_wakeup+0x2c/0x120
[] ? ttwu_do_activate.constprop.135+0x66/0x70
[] wait_for_completion+0xbf/0x180
[] ? try_to_wake_up+0x390/0x390
[] flush_work+0x165/0x250
[] ? worker_detach_from_pool+0xd0/0xd0
[] xlog_cil_force_lsn+0x81/0x200 [xfs]
[] ? __slab_free+0xee/0x234
[] _xfs_log_force_lsn+0x4d/0x2c0 [xfs]
[] ? lookup_page_cgroup_used+0xe/0x30
[] ? xfs_reclaim_inode+0xa3/0x330 [xfs]
[] xfs_log_force_lsn+0x3f/0xf0 [xfs]
[] ? xfs_reclaim_inode+0xa3/0x330 [xfs]
[] xfs_iunpin_wait+0xc6/0x1a0 [xfs]
[] ? wake_atomic_t_function+0x40/0x40
[] xfs_reclaim_inode+0xa3/0x330 [xfs]
[] xfs_reclaim_inodes_ag+0x257/0x3d0 [xfs]
[] xfs_reclaim_inodes_nr+0x33/0x40 [xfs]
[] xfs_fs_free_cached_objects+0x15/0x20 [xfs]
[] super_cache_scan+0x178/0x180
[] shrink_slab_node+0x14e/0x340
[] ? mem_cgroup_iter+0x16b/0x450
[] shrink_slab+0x100/0x140
[] do_try_to_free_pages+0x335/0x490
[] try_to_free_pages+0xb9/0x1f0
[] ? __alloc_pages_direct_compact+0x69/0x1be
[] __alloc_pages_nodemask+0x69a/0xb40
[] alloc_pages_current+0x9e/0x110
[] new_slab+0x2c5/0x390
[] __slab_alloc+0x33b/0x459
[] ? sock_alloc_inode+0x2d/0xd0
[] ? inet_sendmsg+0x71/0xc0
[] ? sock_alloc_inode+0x2d/0xd0
[] kmem_cache_alloc+0x1a2/0x1b0
[] sock_alloc_inode+0x2d/0xd0
[] alloc_inode+0x26/0xa0
[] new_inode_pseudo+0x1a/0x70
[] sock_alloc+0x1e/0x80
[] __sock_create+0x95/0x220
[] sock_create_kern+0x24/0x30
[] con_work+0xef9/0x2050 [libceph]
[] ? rbd_img_request_submit+0x4c/0x60 [rbd]
[] process_one_work+0x159/0x4f0
[] worker_thread+0x11b/0x530
[] ? create_worker+0x1d0/0x1d0
[] kthread+0xc9/0xe0
[] ? flush_kthread_worker+0x90/0x90
[] ret_from_fork+0x58/0x90
[] ? flush_kthread_worker+0x90/0x90

Use memalloc_noio_{save,restore}() to temporarily force GFP_NOIO here.

Link: http://tracker.ceph.com/issues/19309
Reported-by: Sergey Jerusalimov 
Signed-off-by: Ilya Dryomov 
Reviewed-by: Jeff Layton 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ceph/messenger.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c
index ecdf164c80fe..a61159bd5b02 100644
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -475,11 +476,16 @@ static int ceph_tcp_connect(struct ceph_connection *con)
 {
struct sockaddr_storage *paddr = &con->peer_addr.in_addr;
struct socket *sock;
+   unsigned int noio_flag;
int ret;
 
BUG_ON(con->sock);
+
+   /* sock_create_kern() allocates with GFP_KERNEL */
+   noio_flag = memalloc_noio_save();
ret = sock_create_kern(con->peer_addr.in_addr.ss_family, SOCK_STREAM,
   IPPROTO_TCP, &sock);
+   memalloc_noio_restore(noio_flag);
if (ret)
return ret;
sock->sk->sk_allocation = GFP_NOFS;
-- 
2.12.2

[PATCH 3.12 101/142] xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window

[Jiri Slaby]

From: Andy Whitcroft 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 677e806da4d916052585301785d847c3b3e6186a upstream.

When a new xfrm state is created during an XFRM_MSG_NEWSA call we
validate the user supplied replay_esn to ensure that the size is valid
and to ensure that the replay_window size is within the allocated
buffer.  However later it is possible to update this replay_esn via a
XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
buffer matches the existing state and if so inject the contents.  We do
not at this point check that the replay_window is within the allocated
memory.  This leads to out-of-bounds reads and writes triggered by
netlink packets.  This leads to memory corruption and the potential for
priviledge escalation.

We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
is not trying to change the size of the replay state buffer which
includes the replay_esn.  It however does not check the replay_window
remains within that buffer.  Add validation of the contained
replay_window.

CVE-2017-7184
Signed-off-by: Andy Whitcroft 
Acked-by: Steffen Klassert 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 net/xfrm/xfrm_user.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 32a2dd39b785..9a6bd448468d 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -393,6 +393,9 @@ static inline int xfrm_replay_verify_len(struct 
xfrm_replay_state_esn *replay_es
if (nla_len(rp) < ulen || xfrm_replay_state_esn_len(replay_esn) != ulen)
return -EINVAL;
 
+   if (up->replay_window > up->bmp_len * sizeof(__u32) * 8)
+   return -EINVAL;
+
return 0;
 }
 
-- 
2.12.2

[PATCH 3.12 100/142] crypto: algif_hash - avoid zero-sized array

[Jiri Slaby]

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 6207119444595d287b1e9e83a2066c17209698f3 upstream.

With this reproducer:
  struct sockaddr_alg alg = {
  .salg_family = 0x26,
  .salg_type = "hash",
  .salg_feat = 0xf,
  .salg_mask = 0x5,
  .salg_name = "digest_null",
  };
  int sock, sock2;

  sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
  bind(sock, (struct sockaddr *)&alg, sizeof(alg));
  sock2 = accept(sock, NULL, NULL);
  setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2);
  accept(sock2, NULL, NULL);

 8<  8<  8<  8< 

one can immediatelly see an UBSAN warning:
UBSAN: Undefined behaviour in crypto/algif_hash.c:187:7
variable length array bound value 0 <= 0
CPU: 0 PID: 15949 Comm: syz-executor Tainted: GE  
4.4.30-0-default #1
...
Call Trace:
...
 [] ? __ubsan_handle_vla_bound_not_positive+0x13d/0x188
 [] ? __ubsan_handle_out_of_bounds+0x1bc/0x1bc
 [] ? hash_accept+0x5bd/0x7d0 [algif_hash]
 [] ? hash_accept_nokey+0x3f/0x51 [algif_hash]
 [] ? hash_accept_parent_nokey+0x4a0/0x4a0 [algif_hash]
 [] ? SyS_accept+0x2b/0x40

It is a correct warning, as hash state is propagated to accept as zero,
but creating a zero-length variable array is not allowed in C.

Fix this as proposed by Herbert -- do "?: 1" on that site. No sizeof or
similar happens in the code there, so we just allocate one byte even
though we do not use the array.

Signed-off-by: Jiri Slaby 
Cc: Herbert Xu 
Cc: "David S. Miller"  (maintainer:CRYPTO API)
Reported-by: Sasha Levin 
Signed-off-by: Herbert Xu 
Cc: Arnd Bergmann 
Signed-off-by: Jiri Slaby 
---
 crypto/algif_hash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index b351127426db..2c4df1304922 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -195,7 +195,7 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
struct alg_sock *ask = alg_sk(sk);
struct hash_ctx *ctx = ask->private;
struct ahash_request *req = &ctx->req;
-   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
+   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req)) ? : 1];
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
-- 
2.12.2

[PATCH 3.12 095/142] USB: usbtmc: add missing endpoint sanity check

[Jiri Slaby]

From: Johan Hovold 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 687e0687f71ec00e0132a21fef802dee88c2f1ad upstream.

USBTMC devices are required to have a bulk-in and a bulk-out endpoint,
but the driver failed to verify this, something which could lead to the
endpoint addresses being taken from uninitialised memory.

Make sure to zero all private data as part of allocation, and add the
missing endpoint sanity check.

Note that this also addresses a more recently introduced issue, where
the interrupt-in-presence flag would also be uninitialised whenever the
optional interrupt-in endpoint is not present. This in turn could lead
to an interrupt urb being allocated, initialised and submitted based on
uninitialised values.

Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 
READ_STATUS_BYTE operation.")
Fixes: 5b775f672cc9 ("USB: add USB test and measurement class driver")
Signed-off-by: Johan Hovold 
[ johan: backport to v4.4 ]
Signed-off-by: Johan Hovold 
Signed-off-by: Jiri Slaby 
---
 drivers/usb/class/usbtmc.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 72ed4ac2cfad..13583a2edba7 100644
--- a/drivers/usb/class/usbtmc.c
+++ b/drivers/usb/class/usbtmc.c
@@ -1102,7 +1102,7 @@ static int usbtmc_probe(struct usb_interface *intf,
 
dev_dbg(&intf->dev, "%s called\n", __func__);
 
-   data = kmalloc(sizeof(*data), GFP_KERNEL);
+   data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(&intf->dev, "Unable to allocate kernel memory\n");
return -ENOMEM;
@@ -1162,6 +1162,12 @@ static int usbtmc_probe(struct usb_interface *intf,
}
}
 
+   if (!data->bulk_out || !data->bulk_in) {
+   dev_err(&intf->dev, "bulk endpoints not found\n");
+   retcode = -ENODEV;
+   goto err_put;
+   }
+
retcode = get_capabilities(data);
if (retcode)
dev_err(&intf->dev, "can't read capabilities\n");
@@ -1185,6 +1191,7 @@ static int usbtmc_probe(struct usb_interface *intf,
 error_register:
sysfs_remove_group(&intf->dev.kobj, &capability_attr_grp);
sysfs_remove_group(&intf->dev.kobj, &data_attr_grp);
+err_put:
kref_put(&data->kref, usbtmc_delete);
return retcode;
 }
-- 
2.12.2

[PATCH 3.12 102/142] xfrm_user: validate XFRM_MSG_NEWAE incoming ESN size harder

[Jiri Slaby]

From: Andy Whitcroft 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit f843ee6dd019bcece3e74e76ad9df0155655d0df upstream.

Kees Cook has pointed out that xfrm_replay_state_esn_len() is subject to
wrapping issues.  To ensure we are correctly ensuring that the two ESN
structures are the same size compare both the overall size as reported
by xfrm_replay_state_esn_len() and the internal length are the same.

CVE-2017-7184
Signed-off-by: Andy Whitcroft 
Acked-by: Steffen Klassert 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 net/xfrm/xfrm_user.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 9a6bd448468d..52fe9a77a1b1 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -390,7 +390,11 @@ static inline int xfrm_replay_verify_len(struct 
xfrm_replay_state_esn *replay_es
up = nla_data(rp);
ulen = xfrm_replay_state_esn_len(up);
 
-   if (nla_len(rp) < ulen || xfrm_replay_state_esn_len(replay_esn) != ulen)
+   /* Check the overall length and the internal bitmap length to avoid
+* potential overflow. */
+   if (nla_len(rp) < ulen ||
+   xfrm_replay_state_esn_len(replay_esn) != ulen ||
+   replay_esn->bmp_len != up->bmp_len)
return -EINVAL;
 
if (up->replay_window > up->bmp_len * sizeof(__u32) * 8)
-- 
2.12.2

Re: [GIT PULL] PCI: Support for configurable PCI endpoint

[Bjorn Helgaas]

On Wed, Apr 05, 2017 at 02:22:20PM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> Please find the pull request for PCI endpoint support below. I've
> also included all the history here.

Thanks, I applied these (with v7 of the first patch) to pci/host-designware
for v4.12.

> Changes from v5:
> *) remove #syscon-cells property added in v5 and used 
>of_parse_phandle_with_fixed_args
> *) fix compilation error in make.cross ARCH=blackfin that was because
>pci_endpoint_test.c driver depends on COMPILE_TEST.
> 
> Changes from v4:
> *) add #syscon-cells property and used of_parse_phandle_with_args
>to perform a configuration in syscon module (as suggested by
>Rob Herring)
> *) Remove unnecessary white space.
> 
> Changes from v3:
> *) fixed a typo and adapted to https://lkml.org/lkml/2017/3/13/562.
> 
> Changes from v2:
> *) changed the configfs structure as suggested by Christoph Hellwig. With
>this change the framework creates configfs entry for EP function driver
>and EP controller. Previously these entries have to be created by the
>the user. (Haven't changed the epc core or epf core except for invoking
>configfs APIs to create entries for EP function driver and EP controller.
>That's mostly because the EP function device can still be created by
>directly invoking the epf core API without using configfs).
> *) Now the user has to use configfs entry 'start' to start the link.
>This was previously done by the function driver. However in the case of
>multi function EP, the function driver shouldn't start the link.
> 
> Changes from v1:
> *) The preparation patches for adding EP support is removed and is sent
>separately
> *) Added device ID for DRA74x/DRA72x and used it instead of
>using "PCI_ANY_ID"
> *) Added userguide for PCI endpoint test function
> 
> Major Improvements from RFC:
>  *) support multi-function devices (hw supported not virtual)
>  *) Access host side buffers
>  *) Raise MSI interrupts
>  *) Add user space program to use the host side PCI driver
>  *) Adapt all other users of designware to use the new design (only
> compile tested. Since I have only dra7xx boards, the new design
> has only been tested in dra7xx. I'd require the help of others
> to test the platforms they have access to).
> 
> This is based on
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
> pci/host-designware
> 
> Thanks
> Kishon
> 
> The following changes since commit 7ea64dcf602c21b3e5062ca90111ca4459fab403:
> 
>   __end__ (2017-04-04 15:29:37 -0500)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/pci-endpoint.git 
> tags/pci-endpoint-for-4.12
> 
> for you to fetch changes up to a5c85ba45c9682456077d7277196e91f8ea5fd5c:
> 
>   ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to 
> SW_WKUP (2017-04-05 14:05:28 +0530)
> 
> 
> pci: endpoint: for 4.12
> 
>  *) Add PCI endpoint core layer
>  *) Modify designware and dra7xx driver to be configured in EP mode
>  *) Add a PCI endpoint *test* function driver and corresponding host
> driver
> 
> Signed-off-by: Kishon Vijay Abraham I 
> 
> 
> Kishon Vijay Abraham I (23):
>   PCI: endpoint: Add EP core layer to enable EP controller and EP 
> functions
>   Documentation: PCI: Guide to use PCI Endpoint Core Layer
>   PCI: endpoint: Introduce configfs entry for configuring EP functions
>   Documentation: PCI: Guide to use PCI endpoint configfs
>   PCI: endpoint: Create configfs entry for EPC device and EPF driver
>   Documentation: PCI: Add specification for the *PCI test* function device
>   PCI: endpoint: functions: Add an EP function to test PCI
>   Documentation: PCI: Add binding documentation for pci-test endpoint 
> function
>   PCI: dwc: designware: Add EP mode support
>   dt-bindings: PCI: Add DT bindings for PCI designware EP mode
>   PCI: dwc: dra7xx: Facilitate wrapper and MSI interrupts to be enabled 
> independently
>   PCI: dwc: dra7xx: Add EP mode support
>   dt-bindings: PCI: dra7xx: Add DT bindings for PCI dra7xx EP mode
>   PCI: dwc: dra7xx: Workaround for errata id i870
>   dt-bindings: PCI: dra7xx: Add DT bindings to enable unaligned access
>   PCI: Add device IDs for DRA74x and DRA72x
>   misc: Add host side PCI driver for PCI test function device
>   Documentation: misc-devices: Add Documentation for pci-endpoint-test 
> driver
>   tools: PCI: Add a userspace tool to test PCI endpoint
>   tools: PCI: Add sample test script to invoke pcitest
>   Documentation: PCI: Add userguide for PCI endpoint test function
>   MAINTAINERS: Add PCI Endpoint maintainer
>   ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to 
> SW_WKUP
> 
>  Documentation/PCI/00-INDEX

[PATCH 3.12 111/142] scsi: mpt3sas: fix hang on ata passthrough commands

[Jiri Slaby]

From: James Bottomley 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit ffb58456589443ca572221fabbdef3db8483a779 upstream.

mpt3sas has a firmware failure where it can only handle one pass through
ATA command at a time.  If another comes in, contrary to the SAT
standard, it will hang until the first one completes (causing long
commands like secure erase to timeout).  The original fix was to block
the device when an ATA command came in, but this caused a regression
with

commit 669f044170d8933c3d66d231b69ea97cb8447338
Author: Bart Van Assche 
Date:   Tue Nov 22 16:17:13 2016 -0800

scsi: srp_transport: Move queuecommand() wait code to SCSI core

So fix the original fix of the secure erase timeout by properly
returning SAM_STAT_BUSY like the SAT recommends.  The original patch
also had a concurrency problem since scsih_qcmd is lockless at that
point (this is fixed by using atomic bitops to set and test the flag).

[mkp: addressed feedback wrt. test_bit and fixed whitespace]

Fixes: 18f6084a989ba1b (mpt3sas: Fix secure erase premature termination)
Signed-off-by: James Bottomley 
Acked-by: Sreekanth Reddy 
Reviewed-by: Christoph Hellwig 
Reported-by: Ingo Molnar 
Tested-by: Ingo Molnar 
Signed-off-by: Martin K. Petersen 
Cc: Joe Korty 
Signed-off-by: Jiri Slaby 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h  | 12 
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 36 +---
 2 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 0ebf5d913c80..c56ac73a8d05 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -219,6 +219,7 @@ struct MPT3SAS_TARGET {
  * @eedp_enable: eedp support enable bit
  * @eedp_type: 0(type_1), 1(type_2), 2(type_3)
  * @eedp_block_length: block size
+ * @ata_command_pending: SATL passthrough outstanding for device
  */
 struct MPT3SAS_DEVICE {
struct MPT3SAS_TARGET *sas_target;
@@ -227,6 +228,17 @@ struct MPT3SAS_DEVICE {
u8  configured_lun;
u8  block;
u8  tlr_snoop_check;
+   /*
+* Bug workaround for SATL handling: the mpt2/3sas firmware
+* doesn't return BUSY or TASK_SET_FULL for subsequent
+* commands while a SATL pass through is in operation as the
+* spec requires, it simply does nothing with them until the
+* pass through completes, causing them possibly to timeout if
+* the passthrough is a long executing command (like format or
+* secure erase).  This variable allows us to do the right
+* thing while a SATL command is pending.
+*/
+   unsigned long ata_command_pending;
 };
 
 #define MPT3_CMD_NOT_USED  0x8000  /* free */
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index ae1db5499ca6..3d3d37e4b37c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3516,9 +3516,18 @@ _scsih_eedp_error_handling(struct scsi_cmnd *scmd, u16 
ioc_status)
SAM_STAT_CHECK_CONDITION;
 }
 
-static inline bool ata_12_16_cmd(struct scsi_cmnd *scmd)
+static int _scsih_set_satl_pending(struct scsi_cmnd *scmd, bool pending)
 {
-   return (scmd->cmnd[0] == ATA_12 || scmd->cmnd[0] == ATA_16);
+   struct MPT3SAS_DEVICE *priv = scmd->device->hostdata;
+
+   if (scmd->cmnd[0] != ATA_12 && scmd->cmnd[0] != ATA_16)
+   return 0;
+
+   if (pending)
+   return test_and_set_bit(0, &priv->ata_command_pending);
+
+   clear_bit(0, &priv->ata_command_pending);
+   return 0;
 }
 
 /**
@@ -3548,13 +3557,6 @@ _scsih_qcmd_lck(struct scsi_cmnd *scmd, void 
(*done)(struct scsi_cmnd *))
scsi_print_command(scmd);
 #endif
 
-   /*
-* Lock the device for any subsequent command until command is
-* done.
-*/
-   if (ata_12_16_cmd(scmd))
-   scsi_internal_device_block(scmd->device);
-
scmd->scsi_done = done;
sas_device_priv_data = scmd->device->hostdata;
if (!sas_device_priv_data || !sas_device_priv_data->sas_target) {
@@ -3569,6 +3571,19 @@ _scsih_qcmd_lck(struct scsi_cmnd *scmd, void 
(*done)(struct scsi_cmnd *))
return 0;
}
 
+   /*
+* Bug work around for firmware SATL handling.  The loop
+* is based on atomic operations and ensures consistency
+* since we're lockless at this point
+*/
+   do {
+   if (test_bit(0, &sas_device_priv_data->ata_command_pending)) {
+   scmd->result = SAM_STAT_BUSY;
+   scmd->scsi_done(scmd);
+   return 0;
+   }
+   } while (_scsih_set_satl_pending(scmd, true));
+
sas_target_priv_data = sas_device_priv_data->sas_target;
 
/* invalid device handle */
@@ -4058,8 +4073,7 @@ _scsi

[PATCH 3.12 112/142] scsi: libsas: fix ata xfer length

[Jiri Slaby]

From: John Garry 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit 9702c67c6066f583b629cf037d2056245bb7a8e6 upstream.

The total ata xfer length may not be calculated properly, in that we do
not use the proper method to get an sg element dma length.

According to the code comment, sg_dma_len() should be used after
dma_map_sg() is called.

This issue was found by turning on the SMMUv3 in front of the hisi_sas
controller in hip07. Multiple sg elements were being combined into a
single element, but the original first element length was being use as
the total xfer length.

Fixes: ff2aeb1eb64c8a4770a6 ("libata: convert to chained sg")
Signed-off-by: John Garry 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Jiri Slaby 
---
 drivers/scsi/libsas/sas_ata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index d2895836f9fa..83e3ca703cd1 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -219,7 +219,7 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd 
*qc)
task->num_scatter = qc->n_elem;
} else {
for_each_sg(qc->sg, sg, qc->n_elem, si)
-   xfer += sg->length;
+   xfer += sg_dma_len(sg);
 
task->total_xfer_len = xfer;
task->num_scatter = si;
-- 
2.12.2

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

[Reza Arbab]

On Mon, Apr 10, 2017 at 01:03:42PM +0200, Michal Hocko wrote:
This patchset aims at making the onlining semantic more usable. First 
of all it allows to online memory movable as long as it doesn't clash 
with the existing ZONE_NORMAL. That means that ZONE_NORMAL and 
ZONE_MOVABLE cannot overlap. Currently I preserve the original ordering 
semantic so the zone always precedes the movable zone but I have plans 
to remove this restriction in future because it is not really 
necessary.


Thanks for addressing my issues. I see Igor found a few other things to 
square away, but FWIW,


Tested-by: Reza Arbab 

--
Reza Arbab

[PATCH 3.12 106/142] metag/ptrace: Preserve previous registers for short regset write

[Jiri Slaby]

From: Dave Martin 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit a78ce80d2c9178351b34d78fec805140c29c193e upstream.

Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET
to fill all the registers, the thread's old registers are preserved.

Signed-off-by: Dave Martin 
Acked-by: James Hogan 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 arch/metag/kernel/ptrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/metag/kernel/ptrace.c b/arch/metag/kernel/ptrace.c
index 7563628822bd..ae659ba61948 100644
--- a/arch/metag/kernel/ptrace.c
+++ b/arch/metag/kernel/ptrace.c
@@ -303,7 +303,7 @@ static int metag_tls_set(struct task_struct *target,
const void *kbuf, const void __user *ubuf)
 {
int ret;
-   void __user *tls;
+   void __user *tls = target->thread.tls_ptr;
 
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &tls, 0, -1);
if (ret)
-- 
2.12.2

[PATCH 3.12 104/142] c6x/ptrace: Remove useless PTRACE_SETREGSET implementation

[Jiri Slaby]

From: Dave Martin 

3.12-stable review patch.  If anyone has any objections, please let me know.

===

commit fb411b837b587a32046dc4f369acb93a10b1def8 upstream.

gpr_set won't work correctly and can never have been tested, and the
correct behaviour is not clear due to the endianness-dependent task
layout.

So, just remove it.  The core code will now return -EOPNOTSUPPORT when
trying to set NT_PRSTATUS on this architecture until/unless a correct
implementation is supplied.

Signed-off-by: Dave Martin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jiri Slaby 
---
 arch/c6x/kernel/ptrace.c | 41 -
 1 file changed, 41 deletions(-)

diff --git a/arch/c6x/kernel/ptrace.c b/arch/c6x/kernel/ptrace.c
index 3c494e8d..a511ac16a8e3 100644
--- a/arch/c6x/kernel/ptrace.c
+++ b/arch/c6x/kernel/ptrace.c
@@ -69,46 +69,6 @@ static int gpr_get(struct task_struct *target,
   0, sizeof(*regs));
 }
 
-static int gpr_set(struct task_struct *target,
-  const struct user_regset *regset,
-  unsigned int pos, unsigned int count,
-  const void *kbuf, const void __user *ubuf)
-{
-   int ret;
-   struct pt_regs *regs = task_pt_regs(target);
-
-   /* Don't copyin TSR or CSR */
-   ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
-®s,
-0, PT_TSR * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
-   PT_TSR * sizeof(long),
-   (PT_TSR + 1) * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
-®s,
-(PT_TSR + 1) * sizeof(long),
-PT_CSR * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
-   PT_CSR * sizeof(long),
-   (PT_CSR + 1) * sizeof(long));
-   if (ret)
-   return ret;
-
-   ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
-®s,
-(PT_CSR + 1) * sizeof(long), -1);
-   return ret;
-}
-
 enum c6x_regset {
REGSET_GPR,
 };
@@ -120,7 +80,6 @@ static const struct user_regset c6x_regsets[] = {
.size = sizeof(u32),
.align = sizeof(u32),
.get = gpr_get,
-   .set = gpr_set
},
 };
 
-- 
2.12.2

Re: [PATCH RFC v2 2/3] security: add the ModAutoRestrict Linux Security Module

[Casey Schaufler]

On 4/9/2017 3:42 AM, Djalal Harouni wrote:
> This adds the ModAutoRestrict Linux Security Module. The new module
> is a stackable LSM that has been tested with Yama and SELinux, all
> the three modules running.
>
> The module applies restrictions on automatic module loading operations.
> If it is selected, every request to use a kernel feature that is implemented
> by modules that are not loaded will first have to satisfy the access rules
> of ModAutoRestrict LSM. If the access is authorized then the module will
> be automatically loaded. Furthermore, this allows system administrators
> or sandbox mechanisms to prevent loading unneeded modules or abuse the
> interface.
>
> The settings can be applied globally using a sysctl interface which
> completes the core kernel interface "modules_disable" that works only
> on two modes: allow or deny, ignoring that module loading can be either
> an explicit operation or an implicit one via automatic loading. The
> CAP_SYS_MODULE capability can be used to restrict explicit operations,
> however implicit module loading is in general not subject to permission
> checks which allows unprivileged to insert modules.
>
> Using the new ModAutoRestrict settings allow to control if implicit
> operations are allowed or denied.
> This behaviour was inspired from grsecurity's GRKERNSEC_MODHARDEN option.
>
> The feature is also available as a prctl() interface. This allows to
> apply restrictions when sandboxing processes. On embedded Linux systems,
> or containers where only some containers/processes should have the
> right privileges to load modules, this allows to restrict those
> processes from inserting modules through the autoload feature, only
> privileged processes can be allowed to perform so. A more restrictive
> access can be applied where the module autoload feature is completely
> disabled.
> In this schema the access rules are per-process and inherited by
> children created by fork(2) and clone(2), and preserved across execve(2).
>
> Current interface:
>
> *) The per-process prctl() settings are:
>
>  prctl(PR_MOD_AUTO_RESTRICT_OPTS, PR_SET_MOD_AUTO_RESTRICT, value, 0, 0)
>
>  Where value means:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - The current process must have CAP_SYS_MODULE to be able to
>  auto-load modules. CAP_NET_ADMIN should allow to auto-load
>  modules with a 'netdev-%s' alias.
>
>  2 - Current process can not auto-load modules. Once set, this prctl
>  value can not be changed.
>
>  The per-process value may only be increased, never decreased, thus ensuring
>  that once applied, processes can never relaxe their setting.
>
> *) The global sysctl setting can be set by writting an integer value to
>'/proc/sys/kernel/modautorestrict/autoload'
>
>  The valid values are:
>
>  0 - Classic module auto-load permissions, nothing changes.
>
>  1 - Processes must have CAP_SYS_MODULE to be able to auto-load modules.
>  CAP_NET_ADMIN should allow to auto-load modules with a 'netdev-%s'
>  alias.
>
>  2 - Processes can not auto-load modules. Once set, this sysctl value
>  can not be changed.
>
> *) Access rules:
>First the prctl() settings are checked, if the access is not denied
>then the global sysctl settings are checked.
>
> Cc: Andy Lutomirski 
> Cc: James Morris 
> Cc: Tetsuo Handa 
> Cc: Kees Cook 
> Signed-off-by: Djalal Harouni 
> ---
>  MAINTAINERS|   7 +
>  include/linux/lsm_hooks.h  |   5 +
>  include/uapi/linux/prctl.h |   5 +
>  security/Kconfig   |   1 +
>  security/Makefile  |  16 +-
>  security/modautorestrict/Kconfig   |  15 ++
>  security/modautorestrict/Makefile  |   3 +
>  security/modautorestrict/modauto_lsm.c | 372 
> +
>  security/security.c|   1 +
>  9 files changed, 418 insertions(+), 7 deletions(-)
>  create mode 100644 security/modautorestrict/Kconfig
>  create mode 100644 security/modautorestrict/Makefile
>  create mode 100644 security/modautorestrict/modauto_lsm.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c45c02b..38d17cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11326,6 +11326,13 @@ T:   git 
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git yama/tip
>  S:   Supported
>  F:   security/yama/
>  
> +MODAUTORESTRICT SECURITY MODULE
> +M:   Djalal Harouni 
> +L:   kernel-harden...@lists.openwall.com
> +L:   linux-security-mod...@vger.kernel.org
> +S:   Supported
> +F:   security/modautorestrict/
> +
>  SENSABLE PHANTOM
>  M:   Jiri Slaby 
>  S:   Maintained
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index ca19cdb..679800c 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1950,6 +1950,11 @@ void __init loadpin_add_hooks(void);
>  #else
>  static inline void loadpin_add_hooks(void) { };
>  #endif
> +#ifdef CONFIG_SECURITY_MODAUTORESTRICT
>