· 6 years ago · Sep 11, 2019, 03:39 PM
1commit 0c468cadbbc7a65c11042113b63838b16affa5d0
2Author: Sabrina Dubroca <sd@queasysnail.net>
3Date: Wed Nov 4 14:47:53 2015 +0100
4
5 ipv6: clean up dev_snmp6 proc entry when we fail to initialize inet6_dev
6
7 [ Upstream commit 2a189f9e57650e9f310ddf4aad75d66c1233a064 ]
8
9 In ipv6_add_dev, when addrconf_sysctl_register fails, we do not clean up
10 the dev_snmp6 entry that we have already registered for this device.
11 Call snmp6_unregister_dev in this case.
12
13 Fixes: a317a2f19da7d ("ipv6: fail early when creating netdev named all or default")
14 Reported-by: Dmitry Vyukov <dvyukov@google.com>
15 Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
16 Signed-off-by: David S. Miller <davem@davemloft.net>
17 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
18
19commit b724151849d9b60289ff4f829a544defc5e31881
20Author: Martin Habets <mhabets@solarflare.com>
21Date: Mon Nov 2 12:51:31 2015 +0000
22
23 sfc: push partner queue for skb->xmit_more
24
25 [ Upstream commit b2663a4f30e85ec606b806f5135413e6d5c78d1e ]
26
27 When the IP stack passes SKBs the sfc driver puts them in 2 different TX
28 queues (called partners), one for checksummed and one for not checksummed.
29 If the SKB has xmit_more set the driver will delay pushing the work to the
30 NIC.
31
32 When later it does decide to push the buffers this patch ensures it also
33 pushes the partner queue, if that also has any delayed work. Before this
34 fix the work in the partner queue would be left for a long time and cause
35 a netdev watchdog.
36
37 Fixes: 70b33fb ("sfc: add support for skb->xmit_more")
38 Reported-by: Jianlin Shi <jishi@redhat.com>
39 Signed-off-by: Martin Habets <mhabets@solarflare.com>
40 Signed-off-by: David S. Miller <davem@davemloft.net>
41 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
42
43commit 5a38002ee58d2ac061b289fc4f34c4da72598583
44Author: Eric Dumazet <edumazet@google.com>
45Date: Mon Nov 2 17:08:19 2015 -0800
46
47 sit: fix sit0 percpu double allocations
48
49 [ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ]
50
51 sit0 device allocates its percpu storage twice :
52 - One time in ipip6_tunnel_init()
53 - One time in ipip6_fb_tunnel_init()
54
55 Thus we leak 48 bytes per possible cpu per network namespace dismantle.
56
57 ipip6_fb_tunnel_init() can be much simpler and does not
58 return an error, and should be called after register_netdev()
59
60 Note that ipip6_tunnel_clone_6rd() also needs to be called
61 after register_netdev() (calling ipip6_tunnel_init())
62
63 Fixes: ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.")
64 Signed-off-by: Eric Dumazet <edumazet@google.com>
65 Reported-by: Dmitry Vyukov <dvyukov@google.com>
66 Cc: Steffen Klassert <steffen.klassert@secunet.com>
67 Signed-off-by: David S. Miller <davem@davemloft.net>
68 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
69
70commit c48cc8bb582a83b2c64044abb73ad43900b13ef4
71Author: Eric Dumazet <edumazet@google.com>
72Date: Sat Oct 24 05:47:44 2015 -0700
73
74 ipv6: gre: support SIT encapsulation
75
76 [ Upstream commit 7e3b6e7423d5f994257c1de88e06b509673fdbcf ]
77
78 gre_gso_segment() chokes if SIT frames were aggregated by GRO engine.
79
80 Fixes: 61c1db7fae21e ("ipv6: sit: add GSO/TSO support")
81 Signed-off-by: Eric Dumazet <edumazet@google.com>
82 Signed-off-by: David S. Miller <davem@davemloft.net>
83 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
84
85commit a83ab982ddbf61296f323c709ba7c0a3622a16a6
86Author: Bjørn Mork <bjorn@mork.no>
87Date: Thu Oct 22 14:15:58 2015 +0200
88
89 qmi_wwan: add Sierra Wireless MC74xx/EM74xx
90
91 [ Upstream commit 0db65fcfcded76fe4f74e3ca9f4e2baf67b683ef ]
92
93 New device IDs shamelessly lifted from the vendor driver.
94
95 Signed-off-by: Bjørn Mork <bjorn@mork.no>
96 Signed-off-by: David S. Miller <davem@davemloft.net>
97 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
98
99commit f20b58288d77730caa69f8767977f7fc25d10f95
100Author: Jason Wang <jasowang@redhat.com>
101Date: Wed Aug 5 10:34:04 2015 +0800
102
103 virtio-net: drop NETIF_F_FRAGLIST
104
105 [ Upstream commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 ]
106
107 virtio declares support for NETIF_F_FRAGLIST, but assumes
108 that there are at most MAX_SKB_FRAGS + 2 fragments which isn't
109 always true with a fraglist.
110
111 A longer fraglist in the skb will make the call to skb_to_sgvec overflow
112 the sg array, leading to memory corruption.
113
114 Drop NETIF_F_FRAGLIST so we only get what we can handle.
115
116 Cc: Michael S. Tsirkin <mst@redhat.com>
117 Signed-off-by: Jason Wang <jasowang@redhat.com>
118 Acked-by: Michael S. Tsirkin <mst@redhat.com>
119 Signed-off-by: David S. Miller <davem@davemloft.net>
120 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
121
122commit 65dcc613f928ec6ed8f7bfbce217720a7f6c0ebc
123Author: Eric Dumazet <edumazet@google.com>
124Date: Mon Nov 9 17:51:23 2015 -0800
125
126 net: fix a race in dst_release()
127
128 [ Upstream commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 ]
129
130 Only cpu seeing dst refcount going to 0 can safely
131 dereference dst->flags.
132
133 Otherwise an other cpu might already have freed the dst.
134
135 Fixes: 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
136 Reported-by: Greg Thelen <gthelen@google.com>
137 Signed-off-by: Eric Dumazet <edumazet@google.com>
138 Signed-off-by: David S. Miller <davem@davemloft.net>
139 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
140
141commit 59c3d7e9dadeb4960db61fc97239beb5d12a5773
142Author: Eric Dumazet <edumazet@google.com>
143Date: Fri Oct 2 16:54:31 2015 -0700
144
145 net: avoid NULL deref in inet_ctl_sock_destroy()
146
147 [ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ]
148
149 Under low memory conditions, tcp_sk_init() and icmp_sk_init()
150 can both iterate on all possible cpus and call inet_ctl_sock_destroy(),
151 with eventual NULL pointer.
152
153 Signed-off-by: Eric Dumazet <edumazet@google.com>
154 Reported-by: Dmitry Vyukov <dvyukov@google.com>
155 Signed-off-by: David S. Miller <davem@davemloft.net>
156 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
157
158commit 66858ce4963d3b5ea33920f104cdd7919554ce81
159Author: Bjørn Mork <bjorn@mork.no>
160Date: Thu Oct 1 16:54:31 2015 -0700
161
162 qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module
163
164 [ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ]
165
166 The lt4112 is a HP branded Huawei me906e modem. Like other Huawei
167 modems, it does not have a fixed interface to function mapping.
168 Instead it uses a Huawei specific scheme: functions are mapped by
169 subclass and protocol.
170
171 However, the HP vendor ID is used for modems from many different
172 manufacturers using different schemes, so we cannot apply a generic
173 vendor rule like we do for the Huawei vendor ID.
174
175 Replace the previous lt4112 entry pointing to an arbitrary interface
176 number with a device specific subclass + protocol match.
177
178 Reported-and-tested-by: Muri Nicanor <muri+libqmi@immerda.ch>
179 Tested-by: Martin Hauke <mardnh@gmx.de>
180 Fixes: bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem")
181 Signed-off-by: Bjørn Mork <bjorn@mork.no>
182 Signed-off-by: David S. Miller <davem@davemloft.net>
183 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
184
185commit ecc599de1f4b9db6f71025c8ad24b0bf682a8bfc
186Author: Ani Sinha <ani@arista.com>
187Date: Fri Oct 30 16:54:31 2015 -0700
188
189 ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.
190
191 [ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ]
192
193 Fixes the following kernel BUG :
194
195 BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
196 caller is __this_cpu_preempt_check+0x13/0x15
197 CPU: 0 PID: 2758 Comm: bash Tainted: P O 3.18.19 #2
198 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
199 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
200 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
201 Call Trace:
202 [<ffffffff81482b2a>] dump_stack+0x52/0x80
203 [<ffffffff812010ae>] check_preemption_disabled+0xce/0xe1
204 [<ffffffff812010d4>] __this_cpu_preempt_check+0x13/0x15
205 [<ffffffff81419d60>] ipmr_queue_xmit+0x647/0x70c
206 [<ffffffff8141a154>] ip_mr_forward+0x32f/0x34e
207 [<ffffffff8141af76>] ip_mroute_setsockopt+0xe03/0x108c
208 [<ffffffff810553fc>] ? get_parent_ip+0x11/0x42
209 [<ffffffff810e6974>] ? pollwake+0x4d/0x51
210 [<ffffffff81058ac0>] ? default_wake_function+0x0/0xf
211 [<ffffffff810553fc>] ? get_parent_ip+0x11/0x42
212 [<ffffffff810613d9>] ? __wake_up_common+0x45/0x77
213 [<ffffffff81486ea9>] ? _raw_spin_unlock_irqrestore+0x1d/0x32
214 [<ffffffff810618bc>] ? __wake_up_sync_key+0x4a/0x53
215 [<ffffffff8139a519>] ? sock_def_readable+0x71/0x75
216 [<ffffffff813dd226>] do_ip_setsockopt+0x9d/0xb55
217 [<ffffffff81429818>] ? unix_seqpacket_sendmsg+0x3f/0x41
218 [<ffffffff813963fe>] ? sock_sendmsg+0x6d/0x86
219 [<ffffffff813959d4>] ? sockfd_lookup_light+0x12/0x5d
220 [<ffffffff8139650a>] ? SyS_sendto+0xf3/0x11b
221 [<ffffffff810d5738>] ? new_sync_read+0x82/0xaa
222 [<ffffffff813ddd19>] compat_ip_setsockopt+0x3b/0x99
223 [<ffffffff813fb24a>] compat_raw_setsockopt+0x11/0x32
224 [<ffffffff81399052>] compat_sock_common_setsockopt+0x18/0x1f
225 [<ffffffff813c4d05>] compat_SyS_setsockopt+0x1a9/0x1cf
226 [<ffffffff813c4149>] compat_SyS_socketcall+0x180/0x1e3
227 [<ffffffff81488ea1>] cstar_dispatch+0x7/0x1e
228
229 Signed-off-by: Ani Sinha <ani@arista.com>
230 Acked-by: Eric Dumazet <edumazet@google.com>
231 Signed-off-by: David S. Miller <davem@davemloft.net>
232 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
233
234commit 468880892e5f3dfac1176c01dccdffb9551cf45e
235Author: Phil Reid <preid@electromag.com.au>
236Date: Fri Oct 30 16:43:55 2015 +0800
237
238 stmmac: Correctly report PTP capabilities.
239
240 [ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ]
241
242 priv->hwts_*_en indicate if timestamping is enabled/disabled at run
243 time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp
244 indicates HW is support for PTPv1/PTPv2.
245
246 Signed-off-by: Phil Reid <preid@electromag.com.au>
247 Acked-by: Richard Cochran <richardcochran@gmail.com>
248 Signed-off-by: David S. Miller <davem@davemloft.net>
249 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
250
251commit b9eb1e61a9a96922a67c10822751ec5eeb5cc45f
252Author: Carol L Soto <clsoto@linux.vnet.ibm.com>
253Date: Tue Oct 27 17:36:20 2015 +0200
254
255 net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes
256
257 [ Upstream commit c02b05011fadf8e409e41910217ca689f2fc9d91 ]
258
259 When doing memcpy/memset of EQEs, we should use sizeof struct
260 mlx4_eqe as the base size and not caps.eqe_size which could be bigger.
261
262 If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt
263 data in the master context.
264
265 When using a 64 byte stride, the memcpy copied over 63 bytes to the
266 slave_eq structure. This resulted in copying over the entire eqe of
267 interest, including its ownership bit -- and also 31 bytes of garbage
268 into the next WQE in the slave EQ -- which did NOT include the ownership
269 bit (and therefore had no impact).
270
271 However, once the stride is increased to 128, we are overwriting the
272 ownership bits of *three* eqes in the slave_eq struct. This results
273 in an incorrect ownership bit for those eqes, which causes the eq to
274 seem to be full. The issue therefore surfaced only once 128-byte EQEs
275 started being used in SRIOV and (overarchitectures that have 128/256
276 byte cache-lines such as PPC) - e.g after commit 77507aa249ae
277 "net/mlx4_core: Enable CQE/EQE stride support".
278
279 Fixes: 08ff32352d6f ('mlx4: 64-byte CQE/EQE support')
280 Signed-off-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
281 Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
282 Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
283 Signed-off-by: David S. Miller <davem@davemloft.net>
284 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
285
286commit fe9583e4721327a089e841713baa63b4fa27c07d
287Author: Sowmini Varadhan <sowmini.varadhan@oracle.com>
288Date: Mon Oct 26 12:46:37 2015 -0400
289
290 RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv
291
292 [ Upstream commit 8ce675ff39b9958d1c10f86cf58e357efaafc856 ]
293
294 Either of pskb_pull() or pskb_trim() may fail under low memory conditions.
295 If rds_tcp_data_recv() ignores such failures, the application will
296 receive corrupted data because the skb has not been correctly
297 carved to the RDS datagram size.
298
299 Avoid this by handling pskb_pull/pskb_trim failure in the same
300 manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and
301 retry via the deferred call to rds_send_worker() that gets set up on
302 ENOMEM from rds_tcp_read_sock()
303
304 Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
305 Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
306 Signed-off-by: David S. Miller <davem@davemloft.net>
307 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
308
309commit b7491ba5218ead37c335f6457848c8e93c655055
310Author: Guillaume Nault <g.nault@alphalink.fr>
311Date: Thu Oct 22 16:57:10 2015 +0200
312
313 ppp: fix pppoe_dev deletion condition in pppoe_release()
314
315 [ Upstream commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 ]
316
317 We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev.
318 PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is
319 NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies
320 (po->pppoe_dev != NULL).
321 Since we're releasing a PPPoE socket, we want to release the pppoe_dev
322 if it exists and reset sk_state to PPPOX_DEAD, no matter the previous
323 value of sk_state. So we can just check for po->pppoe_dev and avoid any
324 assumption on sk->sk_state.
325
326 Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
327 Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
328 Signed-off-by: David S. Miller <davem@davemloft.net>
329 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
330
331commit 08b66c123bd04c501b3f2299c4dd885aca9160c5
332Author: Jason Wang <jasowang@redhat.com>
333Date: Fri Oct 23 00:57:05 2015 -0400
334
335 macvtap: unbreak receiving of gro skb with frag list
336
337 [ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ]
338
339 We don't have fraglist support in TAP_FEATURES. This will lead
340 software segmentation of gro skb with frag list. Fixes by having
341 frag list support in TAP_FEATURES.
342
343 With this patch single session of netperf receiving were restored from
344 about 5Gb/s to about 12Gb/s on mlx4.
345
346 Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
347 Cc: Vlad Yasevich <vyasevic@redhat.com>
348 Cc: Michael S. Tsirkin <mst@redhat.com>
349 Signed-off-by: Jason Wang <jasowang@redhat.com>
350 Signed-off-by: David S. Miller <davem@davemloft.net>
351
352 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
353
354commit 7d2c8abc68d63e287fe36a9df9bc59e5a47719ba
355Author: Dan Carpenter <dan.carpenter@oracle.com>
356Date: Mon Oct 19 13:16:49 2015 +0300
357
358 irda: precedence bug in irlmp_seq_hb_idx()
359
360 [ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ]
361
362 This is decrementing the pointer, instead of the value stored in the
363 pointer. KASan detects it as an out of bounds reference.
364
365 Reported-by: "Berry Cheng 程君(成淼)" <chengmiao.cj@alibaba-inc.com>
366 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
367 Signed-off-by: David S. Miller <davem@davemloft.net>
368 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
369
370commit b32d475dbf53b9be47ea1092539012dad1f7932b
371Author: Paul Moore <pmoore@redhat.com>
372Date: Tue Dec 30 09:26:21 2014 -0500
373
374 audit: create private file name copies when auditing inodes
375
376 [ Upstream commit fcf22d8267ad2601fe9b6c549d1be96401c23e0b ]
377
378 Unfortunately, while commit 4a928436 ("audit: correctly record file
379 names with different path name types") fixed a problem where we were
380 not recording filenames, it created a new problem by attempting to use
381 these file names after they had been freed. This patch resolves the
382 issue by creating a copy of the filename which the audit subsystem
383 frees after it is done with the string.
384
385 At some point it would be nice to resolve this issue with refcounts,
386 or something similar, instead of having to allocate/copy strings, but
387 that is almost surely beyond the scope of a -rcX patch so we'll defer
388 that for later. On the plus side, only audit users should be impacted
389 by the string copying.
390
391 Reported-by: Toralf Foerster <toralf.foerster@gmx.de>
392 Signed-off-by: Paul Moore <pmoore@redhat.com>
393 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
394
395commit 2f1d09037eeab4f3c89465fcb876a76ff651e12a
396Author: Paul Moore <pmoore@redhat.com>
397Date: Mon Dec 22 12:27:39 2014 -0500
398
399 audit: correctly record file names with different path name types
400
401 [ Upstream commit 4a92843601ad0f5067f441d2f0dca55bbe18c076 ]
402
403 There is a problem with the audit system when multiple audit records
404 are created for the same path, each with a different path name type.
405 The root cause of the problem is in __audit_inode() when an exact
406 match (both the path name and path name type) is not found for a
407 path name record; the existing code creates a new path name record,
408 but it never sets the path name in this record, leaving it NULL.
409 This patch corrects this problem by assigning the path name to these
410 newly created records.
411
412 There are many ways to reproduce this problem, but one of the
413 easiest is the following (assuming auditd is running):
414
415 # mkdir /root/tmp/test
416 # touch /root/tmp/test/567
417 # auditctl -a always,exit -F dir=/root/tmp/test
418 # touch /root/tmp/test/567
419
420 Afterwards, or while the commands above are running, check the audit
421 log and pay special attention to the PATH records. A faulty kernel
422 will display something like the following for the file creation:
423
424 type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2
425 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
426 type=CWD msg=audit(1416957442.025:93): cwd="/root/tmp"
427 type=PATH msg=audit(1416957442.025:93): item=0 name="test/"
428 inode=401409 ... nametype=PARENT
429 type=PATH msg=audit(1416957442.025:93): item=1 name=(null)
430 inode=393804 ... nametype=NORMAL
431 type=PATH msg=audit(1416957442.025:93): item=2 name=(null)
432 inode=393804 ... nametype=NORMAL
433
434 While a patched kernel will show the following:
435
436 type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2
437 success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
438 type=CWD msg=audit(1416955786.566:89): cwd="/root/tmp"
439 type=PATH msg=audit(1416955786.566:89): item=0 name="test/"
440 inode=401409 ... nametype=PARENT
441 type=PATH msg=audit(1416955786.566:89): item=1 name="test/567"
442 inode=393804 ... nametype=NORMAL
443
444 This issue was brought up by a number of people, but special credit
445 should go to hujianyang@huawei.com for reporting the problem along
446 with an explanation of the problem and a patch. While the original
447 patch did have some problems (see the archive link below), it did
448 demonstrate the problem and helped kickstart the fix presented here.
449
450 * https://lkml.org/lkml/2014/9/5/66
451
452 Reported-by: hujianyang <hujianyang@huawei.com>
453 Signed-off-by: Paul Moore <pmoore@redhat.com>
454 Acked-by: Richard Guy Briggs <rgb@redhat.com>
455 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
456
457commit f0146c7ff3129ad8137ade130c0a804e63d1579d
458Author: Dan Carpenter <dan.carpenter@oracle.com>
459Date: Fri Jul 3 11:53:03 2015 +0300
460
461 mptfusion: prevent some memory corruption
462
463 [ Upstream commit e819cdb198319cccf4af4fc12ac4d796109d8c23 ]
464
465 These are signed values the come from the user, we put a cap on the
466 upper bounds but not on the lower bounds.
467
468 We use "karg.dataSgeOffset" to calculate "sz". We verify "sz" and
469 proceed as if that means that "karg.dataSgeOffset" is correct but this
470 fails to consider that the "sz" calculations can have integer overflows.
471
472 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
473 Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
474 Signed-off-by: James Bottomley <JBottomley@Odin.com>
475 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
476
477commit fd9ffdd1f79f1fd442b186c6fd702b4d71459c3c
478Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
479Date: Tue Jul 7 15:28:13 2015 +0100
480
481 mfd: wm5110: Add register patch for rev E and above
482
483 [ Upstream commit 81207880cef207cd89db863f9aa1d65f22b4f2a2 ]
484
485 Add a register patch for rev E and above that configures the location of
486 some write sequences to assist with the headphone enables.
487
488 Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
489 Acked-by: Lee Jones <lee.jones@linaro.org>
490 Signed-off-by: Mark Brown <broonie@kernel.org>
491 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
492
493commit 1da953c20a7eca9d2dfe9c260c3f1a61ed44969e
494Author: Nicholas Mc Guire <hofrat@osadl.org>
495Date: Sun Jun 7 11:34:40 2015 -0300
496
497 [media] gscpa_m5602: use msecs_to_jiffies for conversions
498
499 [ Upstream commit 63f2f417526fc54191f2b813f72dc1d5322bede8 ]
500
501 API compliance scanning with coccinelle flagged:
502 ./drivers/media/usb/gspca/m5602/m5602_s5k83a.c:180:9-25:
503 WARNING: timeout (100) seems HZ dependent
504
505 Numeric constants passed to schedule_timeout() make the effective
506 timeout HZ dependent which makes little sense in a polling loop for
507 the cameras rotation state.
508 Fixed up by converting the constant to jiffies with msecs_to_jiffies()
509
510 Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
511 Signed-off-by: Hans de Goede <hdegoede@redhat.com>
512 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
513 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
514
515commit 52d42a7c1aac255fa0699497b5adeebe921da9bf
516Author: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
517Date: Wed Jan 28 22:53:53 2015 -0200
518
519 [media] v4l: vsp1: Fix VI6_WPF_SZCLIP_SIZE_MASK macro
520
521 [ Upstream commit 03b36e4dcf422a10da8b67bce2ed00b34ec58aac ]
522
523 Clipping size bit of VI6_WPFn _HSZCLIP and VI6_WPFn _VSZCLIP register are from
524 0 bit to 11 bit. But VI6_WPF_SZCLIP_SIZE_MASK is set to 0x1FFF, this will mask
525 until the reserve bits. This fixes size for VI6_WPF_SZCLIP_SIZE_MASK.
526
527 Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
528 Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
529 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
530 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
531
532commit 8a6f1ccc84f161442f80fc8a6dfe7eebcac18d0e
533Author: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
534Date: Wed Jan 28 22:53:54 2015 -0200
535
536 [media] v4l: vsp1: Fix VI6_DPR_ROUTE_FP_MASK macro
537
538 [ Upstream commit 1aa7890324b497f96f07c20673fae58f26fabfe7 ]
539
540 FP bit of VI6_DPR_mod_ROUTE register is 6bit. But VI6_DPR_ROUTE_FP_MASK is set
541 to 0xFF, this will mask until the reserve bit.
542 This fixes size for VI6_DPR_ROUTE_FP_MASK.
543
544 Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
545 Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
546 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
547 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
548
549commit 0d4bca31e2974e42e6df0519b8a0b8bad1d463a8
550Author: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
551Date: Wed Jan 28 22:53:55 2015 -0200
552
553 [media] v4l: vsp1: Fix VI6_DPR_ROUTE_FXA_MASK macro
554
555 [ Upstream commit 45008ee9295b3ae96d7413ab91871907a671ca82 ]
556
557 FXA bit of VI6_DPR_mod_ROUTE register starts from 16bit. But VI6_DPR_ROUTE_FXA_MASK
558 is set to become start from 8bit. This fixes shift size for VI6_DPR_ROUTE_FXA_MASK.
559
560 Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
561 Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
562 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
563 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
564
565commit 23e0e849bb6f3a6ea2f58c779a3876de012da152
566Author: Hans Verkuil <hans.verkuil@cisco.com>
567Date: Mon Jul 20 09:59:35 2015 -0300
568
569 [media] usbvision: fix locking error
570
571 [ Upstream commit e2c84ccb0fbe5e524d15bb09c042a6ca634adaed ]
572
573 If remove_pending is non-zero, then the v4l2_lock is never unlocked.
574
575 Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
576 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
577 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
578
579commit ccee6c265e76bdc9f7ea4a42c0db27e28b39dcbf
580Author: Andrew Morton <akpm@linux-foundation.org>
581Date: Mon Sep 28 16:38:07 2015 -0700
582
583 Input: zhenhua - ensure we have BITREVERSE
584
585 [ Upstream commit d3b367bc26ea2e07a83fe73f0ccbddd729cb1f9a ]
586
587 It uses bitrev8(), so it must ensure that lib/bitrev.o gets included in
588 vmlinux.
589
590 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
591 Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
592 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
593
594commit c9366743e025947f8ec2e0b9fb2dca60bed947db
595Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
596Date: Mon Sep 28 15:59:22 2015 -0700
597
598 Input: omap4-keypad - fix memory leak
599
600 [ Upstream commit d79bdc7f004404204a6ac07785f8d6717070ecdb ]
601
602 If omap4_keypad_parse_dt() fails we returned the error code but we
603 missed releasing keypad_data.
604
605 Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
606 Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
607 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
608
609commit e6004b4d70df3607e2c258e69d2ada8234f9c7cb
610Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
611Date: Sun Sep 27 17:13:55 2015 -0700
612
613 Input: serio - fix blocking of parport
614
615 [ Upstream commit 1a5e251996e1b602f2ddc9261ee9de0ca1875bfa ]
616
617 If parkbd_allocate_serio() fails to allocate memory we are releasing the
618 parport but we missed unregistering the device. As a result this device
619 with exclusive access to that parport remains registered. And no other
620 device will be able to use that parport even though this driver has
621 failed to load.
622
623 Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
624 Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
625 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
626
627commit 7c4e78f59a93be4b62c7eee2aa7e14b92d38270c
628Author: Stefan Assmann <sassmann@kpanic.de>
629Date: Wed Aug 26 13:11:49 2015 -0700
630
631 Input: psmouse - add small delay for IBM trackpoint pass-through mode
632
633 [ Upstream commit 66bc2f51ef7deabc8b8f3baa98ae64b65e5e973a ]
634
635 There are trackpoint devices that fail to respond to the PS2 command
636 PSMOUSE_CMD_GETID if immediately queried after the parent device is
637 deactivated. Add a small delay for the hardware to get in a sane state
638 before sending any PS2 commands.
639
640 One example of such a system is:
641 Lenovo ThinkPad X120e, model 30515QG
642 synaptics: Touchpad model: 1, fw: 8.0, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x121c00, board id: 1811, fw id: 797391
643
644 Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
645 Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
646 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
647
648commit 4af4b38c1078c66b4d55a55a60393c414eb03602
649Author: Benjamin Tissoires <benjamin.tissoires@redhat.com>
650Date: Fri Aug 21 10:18:08 2015 -0400
651
652 HID: quirks: add QUIRK_NOGET for an other TPV touchscreen
653
654 [ Upstream commit c9b57724b38d4c1555ee49418be3d76801e3327c ]
655
656 Looks like 0x8882 needs the same quirk than 0x8883.
657 Given that both devices claim they are "TPV OpticalTouchScreen" rename
658 the 0x8883 to add its PID in the #define.
659
660 Reported-by: Blaine Lee <blaine.j.lee@medtronic.com>
661 Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
662 Signed-off-by: Jiri Kosina <jkosina@suse.cz>
663 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
664
665commit 850ab913a9af3d87c7b5e240e1004e480691fee9
666Author: Henrik Rydberg <rydberg@bitmath.org>
667Date: Fri Jul 24 14:45:05 2015 -0700
668
669 HID: apple: Add support for the 2015 Macbook Pro
670
671 [ Upstream commit a4a2c54560f2c57b88ba0283f141b44f594c2337 ]
672
673 This patch adds keyboard support for MacbookPro12,1 as WELLSPRING9
674 (0x0272, 0x0273, 0x0274). The touchpad is handled in a separate
675 bcm5974 patch, as usual.
676
677 Tested-by: John Horan <knasher@gmail.com>
678 Tested-by: Jochen Radmacher <jradmacher@gmx.de>
679 Tested-by: Yang Hongyang <burnef@gmail.com>
680 Tested-by: Yen-Chin, Lee <coldnew.tw@gmail.com>
681 Tested-by: George Hilios <ghilios@gmail.com>
682 Tested-by: Janez Urevc <janez@janezurevc.name>
683 Signed-off-by: Henrik Rydberg <rydberg@bitmath.org>
684 Acked-by: Jiri Kosina <jkosina@suse.com>
685 Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
686 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
687
688commit 9f5c910b9c85796629adfc35fab903cb90b9b97a
689Author: Bin Liu <b-liu@ti.com>
690Date: Mon Aug 24 15:28:37 2015 -0500
691
692 usb: musb: fix cppi channel teardown for isoch transfer
693
694 [ Upstream commit b431ba8803666e56c1d178a421b3cbc36e8d3d33 ]
695
696 After a few iterations of start/stop UVC camera streaming, the streaming
697 stops.
698
699 This patch adds 250us delay in the cppi channel abort path to let cppi
700 drain properly.
701
702 Using 50us delay seems to be too aggressive, some webcams are still
703 broken. 250us is the original value used in TI 3.2 kernel.
704
705 Signed-off-by: Bin Liu <b-liu@ti.com>
706 Signed-off-by: Felipe Balbi <balbi@ti.com>
707 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
708
709commit 9a032d2a1f8a7453dd47cb0e3870ad02590499cd
710Author: Bin Liu <b-liu@ti.com>
711Date: Mon Jan 26 16:22:07 2015 -0600
712
713 usb: musb: cppi41: improve rx channel abort routine
714
715 [ Upstream commit cb83df77f3ec151d68a1b6be957207e6fc7b7f50 ]
716
717 1. set AUTOREQ to NONE at the beginning of teardown;
718
719 2. add delay for dma pipeline to drain;
720
721 3. Do not set USB_TDOWN bit for RX teardown.
722
723 The CPPI hw has an issue that when tearing down a RX channel, if
724 another RX channel is receiving data, the CPPI will lockup.
725
726 To workaround the issue, do not set the CPPI TD bit. The steps before
727 this point ensures the CPPI channel will be torn down properly.
728
729 Signed-off-by: Bin Liu <b-liu@ti.com>
730 Signed-off-by: Felipe Balbi <balbi@ti.com>
731 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
732
733commit 039a1e26d6f0fb392ae4ca82e91dc78228b024f9
734Author: Philipp Hachtmann <hachti@hachti.de>
735Date: Mon Aug 17 17:31:47 2015 +0200
736
737 USB: symbolserial: Correct transferred data size
738
739 [ Upstream commit 8ae25a355b5969e12f3185e8cb8eb08b871c9084 ]
740
741 The scanner (here DS3508) always returns 64 bytes per urb buffer. The first
742 byte indicates the data length used in the current buffer. There even was
743 a comment describing this. But the comment also said that we'll send
744 everything in the buffer to the tty layer. That means sending the actual
745 barcode data and lots of trailing zeroes. This patch lets the driver only
746 send the real data.
747
748 Signed-off-by: Philipp Hachtmann <hachti@hachti.de>
749 Acked-by: Johan Hovold <johan@kernel.org>
750 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
751 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
752
753commit c357a87557409fe0c9a0b21ccfd85edf4f7eb948
754Author: Li Jun <jun.li@freescale.com>
755Date: Wed Jul 29 13:11:11 2015 +0800
756
757 usb: chipidea: debug: add runtime pm for register access
758
759 [ Upstream commit bc24937943d9f71a1e32b5dc4e2f0ef8fcc07b64 ]
760
761 Add runtime pm operations for registers access to avoid system hang.
762
763 Signed-off-by: Li Jun <jun.li@freescale.com>
764 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
765
766commit 448753c5cc07b5fade57b8ebbaf14ea25b652950
767Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
768Date: Wed Aug 19 16:50:10 2015 +0200
769
770 s390/3270: redraw screen on unsolicited device end
771
772 [ Upstream commit 05bfd70bcdd3cd12c061cb77b73a11ba6f87379d ]
773
774 If a 3270 terminal is disconnected and later reconnected again,
775 it gets an unsolicited device end. This is currently ignored and
776 you have to hit the clear key to get the screen redrawn.
777 Add an automatic full redraw of the screen for this case.
778
779 Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
780 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
781
782commit df3a9927e47952b55a1695c0cb583530f98c9ce1
783Author: Joerg Roedel <jroedel@suse.de>
784Date: Wed May 27 09:26:09 2015 +0200
785
786 iommu/amd: Handle integer overflow in dma_ops_area_alloc
787
788 [ Upstream commit e6aabee05f41c9d18e0b92194819edd84f352ac9 ]
789
790 Handle this case to make sure boundary_size does not become
791 0 and trigger a BUG_ON later.
792
793 Signed-off-by: Joerg Roedel <jroedel@suse.de>
794 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
795
796commit fa52a8d9469cc7e46acdbe92b6568f7216ac9cb6
797Author: Noel Power <noel.power@suse.com>
798Date: Wed May 27 09:22:10 2015 +0100
799
800 client MUST ignore EncryptionKeyLength if CAP_EXTENDED_SECURITY is set
801
802 [ Upstream commit f291095f340db986271e951e3891bb95624a93ea ]
803
804 [MS-SMB] 2.2.4.5.2.1 states:
805
806 "ChallengeLength (1 byte): When the CAP_EXTENDED_SECURITY bit is set,
807 the server MUST set this value to zero and clients MUST ignore this
808 value."
809
810 Signed-off-by: Noel Power <noel.power@suse.com>
811 Signed-off-by: Steve French <smfrench@gmail.com>
812 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
813
814commit e59fd940129c83888ec2605b065c116cd21643d1
815Author: Teunis van Beelen <teuniz@gmail.com>
816Date: Sun May 31 09:36:22 2015 +0200
817
818 USB: usbtmc: add device quirk for Rigol DS6104
819
820 [ Upstream commit f50420223071b6ff4b586308f5c27eec54694a81 ]
821
822 Recently we purchased the Rigol DS6104 and when I try to operate it from
823 my Linux pc, everything works well with the default usbtmc driver,
824 except when I want to download a big datachunk like a screenshot. This
825 bitmapfile has a size of 1152054 bytes but I receive a smaller file and
826 no new packets can be read.
827
828 When I took a look at the driver source, I found this "Rigol quirk" and
829 I added the id of the new DS series oscilloscopes to this list. I
830 compiled it and loaded the new driver and now everything seems to work
831 fine.
832
833 Signed-off-by: Teunis van Beelen <teuniz@gmail.com>
834 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
835 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
836
837commit 3bb4005ca26162ab0c64d8901b7b323904bbb890
838Author: Jan H. Schönherr <jschoenh@amazon.de>
839Date: Wed Aug 12 21:35:56 2015 +0200
840
841 sched: Fix cpu_active_mask/cpu_online_mask race
842
843 [ Upstream commit dd9d3843755da95f63dd3a376f62b3e45c011210 ]
844
845 There is a race condition in SMP bootup code, which may result
846 in
847
848 WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
849 workqueue_cpu_up_callback()
850 or
851 kernel BUG at kernel/smpboot.c:135!
852
853 It can be triggered with a bit of luck in Linux guests running
854 on busy hosts.
855
856 CPU0 CPUn
857 ==== ====
858
859 _cpu_up()
860 __cpu_up()
861 start_secondary()
862 set_cpu_online()
863 cpumask_set_cpu(cpu,
864 to_cpumask(cpu_online_bits));
865 cpu_notify(CPU_ONLINE)
866 <do stuff, see below>
867 cpumask_set_cpu(cpu,
868 to_cpumask(cpu_active_bits));
869
870 During the various CPU_ONLINE callbacks CPUn is online but not
871 active. Several things can go wrong at that point, depending on
872 the scheduling of tasks on CPU0.
873
874 Variant 1:
875
876 cpu_notify(CPU_ONLINE)
877 workqueue_cpu_up_callback()
878 rebind_workers()
879 set_cpus_allowed_ptr()
880
881 This call fails because it requires an active CPU; rebind_workers()
882 ends with a warning:
883
884 WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418
885 workqueue_cpu_up_callback()
886
887 Variant 2:
888
889 cpu_notify(CPU_ONLINE)
890 smpboot_thread_call()
891 smpboot_unpark_threads()
892 ..
893 __kthread_unpark()
894 __kthread_bind()
895 wake_up_state()
896 ..
897 select_task_rq()
898 select_fallback_rq()
899
900 The ->wake_cpu of the unparked thread is not allowed, making a call
901 to select_fallback_rq() necessary. Then, select_fallback_rq() cannot
902 find an allowed, active CPU and promptly resets the allowed CPUs, so
903 that the task in question ends up on CPU0.
904
905 When those unparked tasks are eventually executed, they run
906 immediately into a BUG:
907
908 kernel BUG at kernel/smpboot.c:135!
909
910 Just changing the order in which the online/active bits are set
911 (and adding some memory barriers), would solve the two issues
912 above. However, it would change the order of operations back to
913 the one before commit 6acbfb96976f ("sched: Fix hotplug vs.
914 set_cpus_allowed_ptr()"), thus, reintroducing that particular
915 problem.
916
917 Going further back into history, we have at least the following
918 commits touching this topic:
919 - commit 2baab4e90495 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online")
920 - commit 5fbd036b552f ("sched: Cleanup cpu_active madness")
921
922 Together, these give us the following non-working solutions:
923
924 - secondary CPU sets active before online, because active is assumed to
925 be a subset of online;
926
927 - secondary CPU sets online before active, because the primary CPU
928 assumes that an online CPU is also active;
929
930 - secondary CPU sets online and waits for primary CPU to set active,
931 because it might deadlock.
932
933 Commit 875ebe940d77 ("powerpc/smp: Wait until secondaries are
934 active & online") introduces an arch-specific solution to this
935 arch-independent problem.
936
937 Now, go for a more general solution without explicit waiting and
938 simply set active twice: once on the secondary CPU after online
939 was set and once on the primary CPU after online was seen.
940
941 set_cpus_allowed_ptr()")
942
943 Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
944 Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
945 Cc: <stable@vger.kernel.org>
946 Cc: Anton Blanchard <anton@samba.org>
947 Cc: Borislav Petkov <bp@alien8.de>
948 Cc: Joerg Roedel <jroedel@suse.de>
949 Cc: Linus Torvalds <torvalds@linux-foundation.org>
950 Cc: Matt Wilson <msw@amazon.com>
951 Cc: Michael Ellerman <mpe@ellerman.id.au>
952 Cc: Peter Zijlstra <peterz@infradead.org>
953 Cc: Thomas Gleixner <tglx@linutronix.de>
954 Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
955 Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.de
956 Signed-off-by: Ingo Molnar <mingo@kernel.org>
957 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
958
959commit 9caa36f324a300c0a35929e79a3e4ecb5442b955
960Author: Mark Rustad <mark.d.rustad@intel.com>
961Date: Mon Jul 13 11:40:07 2015 -0700
962
963 PCI: Add VPD function 0 quirk for Intel Ethernet devices
964
965 [ Upstream commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 ]
966
967 Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
968 functions other than function 0, so that on multi-function devices, we will
969 always read VPD from function 0 instead of from the other functions.
970
971 [bhelgaas: changelog]
972 Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
973 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
974 Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
975 CC: stable@vger.kernel.org
976
977 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
978
979commit e4ef8c343517e5ba5a42d3372e2dc655efde8f36
980Author: Mark Rustad <mark.d.rustad@intel.com>
981Date: Mon Jul 13 11:40:02 2015 -0700
982
983 PCI: Add dev_flags bit to access VPD through function 0
984
985 [ Upstream commit 91a37c794cf2cf7ec1f9afc4cbf4a118df7e085e ]
986
987 commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.
988
989 Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
990 function 0 to provide VPD access on other functions. This is for hardware
991 devices that provide copies of the same VPD capability registers in
992 multiple functions. Because the kernel expects that each function has its
993 own registers, both the locking and the state tracking are affected by VPD
994 accesses to different functions.
995
996 On such devices for example, if a VPD write is performed on function 0,
997 *any* later attempt to read VPD from any other function of that device will
998 hang. This has to do with how the kernel tracks the expected value of the
999 F bit per function.
1000
1001 Concurrent accesses to different functions of the same device can not only
1002 hang but also corrupt both read and write VPD data.
1003
1004 When hangs occur, typically the error message:
1005
1006 vpd r/w failed. This is likely a firmware bug on this device.
1007
1008 will be seen.
1009
1010 Never set this bit on function 0 or there will be an infinite recursion.
1011
1012 Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
1013 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
1014 Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
1015 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1016 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1017
1018commit a0e38ca669beedd225ecddda70db61aad3da1694
1019Author: Alex Williamson <alex.williamson@redhat.com>
1020Date: Fri Nov 21 11:24:08 2014 -0700
1021
1022 PCI: Add flag for devices that don't reset on D3hot->D0 transition
1023
1024 [ Upstream commit 51e537387990dc1f00752103f314fd135cb94bc6 ]
1025
1026 Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises
1027 No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-")
1028 should perform an internal reset when transitioning from D3hot to D0 via
1029 software control. Configuration context is lost and the device requires a
1030 full reinitialization sequence.
1031
1032 Unfortunately the definition of "internal reset", beyond the application of
1033 the configuration context, is largely left to the interpretation of the
1034 specific device. Some devices don't seem to perform an "internal reset"
1035 even if they report No_Soft_Reset == 0.
1036
1037 We still need to honor the PCI specification and restore PCI config context
1038 in the event that we do a PM reset, so we don't cache and modify the
1039 PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the
1040 intention is to reset the device, like pci_reset_function(), we need a
1041 mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform
1042 any significant "internal reset" of the device.
1043
1044 Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
1045 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
1046 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1047
1048commit ec4d789161f852d8131df242b97c84331d1f09f0
1049Author: David Howells <dhowells@redhat.com>
1050Date: Thu Oct 15 17:21:37 2015 +0100
1051
1052 KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring
1053
1054 [ Upstream commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 ]
1055
1056 The following sequence of commands:
1057
1058 i=`keyctl add user a a @s`
1059 keyctl request2 keyring foo bar @t
1060 keyctl unlink $i @s
1061
1062 tries to invoke an upcall to instantiate a keyring if one doesn't already
1063 exist by that name within the user's keyring set. However, if the upcall
1064 fails, the code sets keyring->type_data.reject_error to -ENOKEY or some
1065 other error code. When the key is garbage collected, the key destroy
1066 function is called unconditionally and keyring_destroy() uses list_empty()
1067 on keyring->type_data.link - which is in a union with reject_error.
1068 Subsequently, the kernel tries to unlink the keyring from the keyring names
1069 list - which oopses like this:
1070
1071 BUG: unable to handle kernel paging request at 00000000ffffff8a
1072 IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
1073 ...
1074 Workqueue: events key_garbage_collector
1075 ...
1076 RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
1077 RSP: 0018:ffff88003e2f3d30 EFLAGS: 00010203
1078 RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
1079 RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
1080 RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
1081 R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
1082 R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
1083 ...
1084 CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
1085 ...
1086 Call Trace:
1087 [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
1088 [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
1089 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
1090 [<ffffffff8105fd17>] worker_thread+0x26e/0x361
1091 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
1092 [<ffffffff810648ad>] kthread+0xf3/0xfb
1093 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
1094 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
1095 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
1096
1097 Note the value in RAX. This is a 32-bit representation of -ENOKEY.
1098
1099 The solution is to only call ->destroy() if the key was successfully
1100 instantiated.
1101
1102 Reported-by: Dmitry Vyukov <dvyukov@google.com>
1103 Signed-off-by: David Howells <dhowells@redhat.com>
1104 Tested-by: Dmitry Vyukov <dvyukov@google.com>
1105 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1106
1107commit 9485c5aa5bfbbcbd656afdd06df905614ba2946a
1108Author: David Howells <dhowells@redhat.com>
1109Date: Fri Sep 25 16:30:08 2015 +0100
1110
1111 KEYS: Fix race between key destruction and finding a keyring by name
1112
1113 [ Upstream commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 ]
1114
1115 There appears to be a race between:
1116
1117 (1) key_gc_unused_keys() which frees key->security and then calls
1118 keyring_destroy() to unlink the name from the name list
1119
1120 (2) find_keyring_by_name() which calls key_permission(), thus accessing
1121 key->security, on a key before checking to see whether the key usage is 0
1122 (ie. the key is dead and might be cleaned up).
1123
1124 Fix this by calling ->destroy() before cleaning up the core key data -
1125 including key->security.
1126
1127 Reported-by: Petr Matousek <pmatouse@redhat.com>
1128 Signed-off-by: David Howells <dhowells@redhat.com>
1129 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1130
1131commit 4a72f9130bb9afc3d18f5a2c0a8c3856c430080c
1132Author: Eric Whitney <enwlinux@gmail.com>
1133Date: Fri Apr 3 00:13:42 2015 -0400
1134
1135 ext4: fix loss of delalloc extent info in ext4_zero_range()
1136
1137 [ Upstream commit 94426f4b9648154dc5a6760b59e6953e640ab3b1 ]
1138
1139 In ext4_zero_range(), removing a file's entire block range from the
1140 extent status tree removes all records of that file's delalloc extents.
1141 The delalloc accounting code uses this information, and its loss can
1142 then lead to accounting errors and kernel warnings at writeback time and
1143 subsequent file system damage. This is most noticeable on bigalloc
1144 file systems where code in ext4_ext_map_blocks() handles cases where
1145 delalloc extents share clusters with a newly allocated extent.
1146
1147 Because we're not deleting a block range and are correctly updating the
1148 status of its associated extent, there is no need to remove anything
1149 from the extent status tree.
1150
1151 When this patch is combined with an unrelated bug fix for
1152 ext4_zero_range(), kernel warnings and e2fsck errors reported during
1153 xfstests runs on bigalloc filesystems are greatly reduced without
1154 introducing regressions on other xfstests-bld test scenarios.
1155
1156 Signed-off-by: Eric Whitney <enwlinux@gmail.com>
1157 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
1158 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1159
1160commit ecca2fb1f47b4cc4267de9d76d16c356a65601b3
1161Author: Lukas Czerner <lczerner@redhat.com>
1162Date: Fri Apr 3 00:09:13 2015 -0400
1163
1164 ext4: allocate entire range in zero range
1165
1166 [ Upstream commit 0f2af21aae11972fa924374ddcf52e88347cf5a8 ]
1167
1168 Currently there is a bug in zero range code which causes zero range
1169 calls to only allocate block aligned portion of the range, while
1170 ignoring the rest in some cases.
1171
1172 In some cases, namely if the end of the range is past i_size, we do
1173 attempt to preallocate the last nonaligned block. However this might
1174 cause kernel to BUG() in some carefully designed zero range requests
1175 on setups where page size > block size.
1176
1177 Fix this problem by first preallocating the entire range, including
1178 the nonaligned edges and converting the written extents to unwritten
1179 in the next step. This approach will also give us the advantage of
1180 having the range to be as linearly contiguous as possible.
1181
1182 Signed-off-by: Lukas Czerner <lczerner@redhat.com>
1183 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
1184 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1185
1186commit 6169a11a8fa06796cf15d64cd79c4dd4cccd651c
1187Author: Dan Carpenter <dan.carpenter@oracle.com>
1188Date: Thu Feb 5 10:37:33 2015 +0300
1189
1190 vhost/scsi: potential memory corruption
1191
1192 [ Upstream commit 59c816c1f24df0204e01851431d3bab3eb76719c ]
1193
1194 This code in vhost_scsi_make_tpg() is confusing because we limit "tpgt"
1195 to UINT_MAX but the data type of "tpg->tport_tpgt" and that is a u16.
1196
1197 I looked at the context and it turns out that in
1198 vhost_scsi_set_endpoint(), "tpg->tport_tpgt" is used as an offset into
1199 the vs_tpg[] array which has VHOST_SCSI_MAX_TARGET (256) elements so
1200 anything higher than 255 then it is invalid. I have made that the limit
1201 now.
1202
1203 In vhost_scsi_send_evt() we mask away values higher than 255, but now
1204 that the limit has changed, we don't need the mask.
1205
1206 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
1207 Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
1208 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1209
1210commit 9b85836ec94666957c2a1ae1adfd6da4a2b8d078
1211Author: Soeren Grunewald <soeren.grunewald@desy.de>
1212Date: Thu Jun 11 09:25:04 2015 +0200
1213
1214 serial: 8250_pci: Add support for 12 port Exar boards
1215
1216 [ Upstream commit be32c0cf0462c36f482b5ddcff1d8371be1e183c ]
1217
1218 The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
1219 single 12 port chip. This works the same way as the combining two XR17V358
1220 chips. But the reported device id then is 0x4358.
1221
1222 Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
1223 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1224 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1225
1226commit e7509898c3936faf643dba8e105dfdf90f23b0a9
1227Author: Soeren Grunewald <soeren.grunewald@desy.de>
1228Date: Tue Apr 28 16:29:49 2015 +0200
1229
1230 serial: 8250_pci: Add support for 16 port Exar boards
1231
1232 [ Upstream commit 96a5d18bc1338786fecac73599f1681f59a59a8e ]
1233
1234 The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
1235 combined to act as a single 16 port chip. Therefor one chip is configured
1236 as master the second as slave by connecting the mode pin to VCC (master)
1237 or GND (slave).
1238
1239 Then the master chip is reporting a different device-id depending on
1240 whether a slave is detected or not. The UARTs 8-15 are addressed from
1241 0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
1242 address all 16 ports as before.
1243
1244 See: https://www.exar.com/common/content/document.ashx?id=1587 page 11
1245
1246 Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
1247 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1248 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1249
1250commit cc908bc41a0ecc4be8db97521362e608f80a3077
1251Author: Roman Gushchin <klamm@yandex-team.ru>
1252Date: Sat Oct 31 10:53:50 2015 +1100
1253
1254 md/raid5: fix locking in handle_stripe_clean_event()
1255
1256 [ Upstream commit b8a9d66d043ffac116100775a469f05f5158c16f ]
1257
1258 After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
1259 __find_stripe() is called under conf->hash_locks + hash.
1260 But handle_stripe_clean_event() calls remove_hash() under
1261 conf->device_lock.
1262
1263 Under some cirscumstances the hash chain can be circuited,
1264 and we get an infinite loop with disabled interrupts and locked hash
1265 lock in __find_stripe(). This leads to hard lockup on multiple CPUs
1266 and following system crash.
1267
1268 I was able to reproduce this behavior on raid6 over 6 ssd disks.
1269 The devices_handle_discard_safely option should be set to enable trim
1270 support. The following script was used:
1271
1272 for i in `seq 1 32`; do
1273 dd if=/dev/zero of=large$i bs=10M count=100 &
1274 done
1275
1276 neilb: original was against a 3.x kernel. I forward-ported
1277 to 4.3-rc. This verison is suitable for any kernel since
1278 Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write")
1279 (v4.1+). I'll post a version for earlier kernels to stable.
1280
1281 Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
1282 Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
1283 Signed-off-by: NeilBrown <neilb@suse.com>
1284 Cc: Shaohua Li <shli@kernel.org>
1285 Cc: <stable@vger.kernel.org> # 3.13 - 4.2
1286 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1287
1288commit 53d59e5595f3d3c91a5668866a981037a319bc82
1289Author: Doron Tsur <doront@mellanox.com>
1290Date: Sun Oct 11 15:58:17 2015 +0300
1291
1292 IB/cm: Fix rb-tree duplicate free and use-after-free
1293
1294 [ Upstream commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 ]
1295
1296 ib_send_cm_sidr_rep could sometimes erase the node from the sidr
1297 (depending on errors in the process). Since ib_send_cm_sidr_rep is
1298 called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
1299 could be either erased from the rb_tree twice or not erased at all.
1300 Fixing that by making sure it's erased only once before freeing
1301 cm_id_priv.
1302
1303 Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
1304 Signed-off-by: Doron Tsur <doront@mellanox.com>
1305 Signed-off-by: Matan Barak <matanb@mellanox.com>
1306 Signed-off-by: Doug Ledford <dledford@redhat.com>
1307 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1308
1309commit 37dfbd826b48df45b5e2bf7aecb3036450a66ecc
1310Author: Dāvis Mosāns <davispuh@gmail.com>
1311Date: Fri Aug 21 07:29:22 2015 +0300
1312
1313 mvsas: Fix NULL pointer dereference in mvs_slot_task_free
1314
1315 [ Upstream commit 2280521719e81919283b82902ac24058f87dfc1b ]
1316
1317 When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays
1318 NULL but it's later used in mvs_abort_task as slot which is passed
1319 to mvs_slot_task_free causing NULL pointer dereference.
1320
1321 Just return from mvs_slot_task_free when passed with NULL slot.
1322
1323 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891
1324 Signed-off-by: Dāvis Mosāns <davispuh@gmail.com>
1325 Reviewed-by: Tomas Henzl <thenzl@redhat.com>
1326 Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
1327 Cc: stable@vger.kernel.org
1328 Signed-off-by: James Bottomley <JBottomley@Odin.com>
1329 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1330
1331commit e456c19869192bc51aa098f510f1df3e913c2a1d
1332Author: NeilBrown <neilb@suse.com>
1333Date: Sat Oct 31 11:00:56 2015 +1100
1334
1335 Revert "md: allow a partially recovered device to be hot-added to an array."
1336
1337 [ Upstream commit d01552a76d71f9879af448e9142389ee9be6e95b ]
1338
1339 This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57.
1340
1341 This commit is poorly justified, I can find not discusison in email,
1342 and it clearly causes a problem.
1343
1344 If a device which is being recovered fails and is subsequently
1345 re-added to an array, there could easily have been changes to the
1346 array *before* the point where the recovery was up to. So the
1347 recovery must start again from the beginning.
1348
1349 If a spare is being recovered and fails, then when it is re-added we
1350 really should do a bitmap-based recovery up to the recovery-offset,
1351 and then a full recovery from there. Before this reversion, we only
1352 did the "full recovery from there" which is not corect. After this
1353 reversion with will do a full recovery from the start, which is safer
1354 but not ideal.
1355
1356 It will be left to a future patch to arrange the two different styles
1357 of recovery.
1358
1359 Reported-and-tested-by: Nate Dailey <nate.dailey@stratus.com>
1360 Signed-off-by: NeilBrown <neilb@suse.com>
1361 Cc: stable@vger.kernel.org (3.14+)
1362 Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.")
1363 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1364
1365commit aab9369e905c132ceeb03924e6ecfd73cea9c3dd
1366Author: Jes Sorensen <Jes.Sorensen@redhat.com>
1367Date: Tue Oct 20 12:09:13 2015 -0400
1368
1369 md/raid10: submit_bio_wait() returns 0 on success
1370
1371 [ Upstream commit 681ab4696062f5aa939c9e04d058732306a97176 ]
1372
1373 This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
1374 which changed the return value of submit_bio_wait() to return != 0 on
1375 error, but didn't update the caller accordingly.
1376
1377 Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
1378 Cc: stable@vger.kernel.org (v3.10)
1379 Reported-by: Bill Kuzeja <William.Kuzeja@stratus.com>
1380 Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
1381 Signed-off-by: NeilBrown <neilb@suse.com>
1382 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1383
1384commit 3ae3d7f7d36d7776a8284024374c11879b3577fb
1385Author: Jes Sorensen <Jes.Sorensen@redhat.com>
1386Date: Tue Oct 20 12:09:12 2015 -0400
1387
1388 md/raid1: submit_bio_wait() returns 0 on success
1389
1390 [ Upstream commit 203d27b0226a05202438ddb39ef0ef1acb14a759 ]
1391
1392 This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
1393 which changed the return value of submit_bio_wait() to return != 0 on
1394 error, but didn't update the caller accordingly.
1395
1396 Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
1397 Cc: stable@vger.kernel.org (v3.10)
1398 Reported-by: Bill Kuzeja <William.Kuzeja@stratus.com>
1399 Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
1400 Signed-off-by: NeilBrown <neilb@suse.com>
1401 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1402
1403commit 287819b75d1b56163ac9cc2ee6c8b3cca7483650
1404Author: Herbert Xu <herbert@gondor.apana.org.au>
1405Date: Mon Oct 19 18:23:57 2015 +0800
1406
1407 crypto: api - Only abort operations on fatal signal
1408
1409 [ Upstream commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 ]
1410
1411 Currently a number of Crypto API operations may fail when a signal
1412 occurs. This causes nasty problems as the caller of those operations
1413 are often not in a good position to restart the operation.
1414
1415 In fact there is currently no need for those operations to be
1416 interrupted by user signals at all. All we need is for them to
1417 be killable.
1418
1419 This patch replaces the relevant calls of signal_pending with
1420 fatal_signal_pending, and wait_for_completion_interruptible with
1421 wait_for_completion_killable, respectively.
1422
1423 Cc: stable@vger.kernel.org
1424 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
1425 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1426
1427commit 2b23192757b42e2774516e170712aac0759038e1
1428Author: Peter Zijlstra <peterz@infradead.org>
1429Date: Thu Aug 20 10:34:59 2015 +0930
1430
1431 module: Fix locking in symbol_put_addr()
1432
1433 [ Upstream commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 ]
1434
1435 Poma (on the way to another bug) reported an assertion triggering:
1436
1437 [<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
1438 [<ffffffff81150822>] __module_address+0x32/0x150
1439 [<ffffffff81150956>] __module_text_address+0x16/0x70
1440 [<ffffffff81150f19>] symbol_put_addr+0x29/0x40
1441 [<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]
1442
1443 Laura Abbott <labbott@redhat.com> produced a patch which lead us to
1444 inspect symbol_put_addr(). This function has a comment claiming it
1445 doesn't need to disable preemption around the module lookup
1446 because it holds a reference to the module it wants to find, which
1447 therefore cannot go away.
1448
1449 This is wrong (and a false optimization too, preempt_disable() is really
1450 rather cheap, and I doubt any of this is on uber critical paths,
1451 otherwise it would've retained a pointer to the actual module anyway and
1452 avoided the second lookup).
1453
1454 While its true that the module cannot go away while we hold a reference
1455 on it, the data structure we do the lookup in very much _CAN_ change
1456 while we do the lookup. Therefore fix the comment and add the
1457 required preempt_disable().
1458
1459 Reported-by: poma <pomidorabelisima@gmail.com>
1460 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
1461 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1462 Fixes: a6e6abd575fc ("module: remove module_text_address()")
1463 Cc: stable@kernel.org
1464 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1465
1466commit 01d978039a585c712e51cccf3e8c30b24c5e0215
1467Author: Cathy Avery <cathy.avery@oracle.com>
1468Date: Fri Oct 2 09:35:01 2015 -0400
1469
1470 xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)
1471
1472 [ Upstream commit a54c8f0f2d7df525ff997e2afe71866a1a013064 ]
1473
1474 xen-blkfront will crash if the check to talk_to_blkback()
1475 in blkback_changed()(XenbusStateInitWait) returns an error.
1476 The driver data is freed and info is set to NULL. Later during
1477 the close process via talk_to_blkback's call to xenbus_dev_fatal()
1478 the null pointer is passed to and dereference in blkfront_closing.
1479
1480 CC: stable@vger.kernel.org
1481 Signed-off-by: Cathy Avery <cathy.avery@oracle.com>
1482 Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
1483 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1484
1485commit 244cebd7d0c7cf5a9d807449622b98d444b292b8
1486Author: Laura Abbott <labbott@fedoraproject.org>
1487Date: Mon Oct 12 11:30:13 2015 +0300
1488
1489 xhci: Add spurious wakeup quirk for LynxPoint-LP controllers
1490
1491 [ Upstream commit fd7cd061adcf5f7503515ba52b6a724642a839c8 ]
1492
1493 We received several reports of systems rebooting and powering on
1494 after an attempted shutdown. Testing showed that setting
1495 XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
1496 quirk allowed the system to shutdown as expected for LynxPoint-LP
1497 xHCI controllers. Set the quirk back.
1498
1499 Note that the quirk was originally introduced for LynxPoint and
1500 LynxPoint-LP just for this same reason. See:
1501
1502 commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")
1503
1504 It was later limited to only concern HP machines as it caused
1505 regression on some machines, see both bug and commit:
1506
1507 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
1508 commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")
1509
1510 Later it was discovered that the powering on after shutdown
1511 was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
1512 machine suffered from spontaneous resume from S3 (which should
1513 not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
1514 to fix this then removed the SPURIOUS_WAKEUP flag usage completely.
1515
1516 commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")
1517
1518 Current understanding is that LynxPoint-LP (Haswell ULT) machines
1519 need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
1520 plain Lynxpoint (Haswell) machines may _not_ have the quirk
1521 set otherwise they again will restart.
1522
1523 Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
1524 Cc: Takashi Iwai <tiwai@suse.de>
1525 Cc: Oliver Neukum <oneukum@suse.com>
1526 [Added more history to commit message -Mathias]
1527 Cc: stable <stable@vger.kernel.org>
1528 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
1529 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1530
1531 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1532
1533commit 24cd9f6f26d25f9ca1939abaeab327c483b9a742
1534Author: Mathias Nyman <mathias.nyman@linux.intel.com>
1535Date: Mon Oct 12 11:30:12 2015 +0300
1536
1537 xhci: handle no ping response error properly
1538
1539 [ Upstream commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 ]
1540
1541 If a host fails to wake up a isochronous SuperSpeed device from U1/U2
1542 in time for a isoch transfer it will generate a "No ping response error"
1543 Host will then move to the next transfer descriptor.
1544
1545 Handle this case in the same way as missed service errors, tag the
1546 current TD as skipped and handle it on the next transfer event.
1547
1548 Cc: stable <stable@vger.kernel.org>
1549 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
1550 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1551 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1552
1553commit c74505b714a06ca639dbfdf07349f67009508326
1554Author: Mike Snitzer <snitzer@redhat.com>
1555Date: Thu Oct 22 10:56:40 2015 -0400
1556
1557 dm btree: fix leak of bufio-backed block in btree_split_beneath error path
1558
1559 [ Upstream commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be ]
1560
1561 btree_split_beneath()'s error path had an outstanding FIXME that speaks
1562 directly to the potential for _not_ cleaning up a previously allocated
1563 bufio-backed block.
1564
1565 Fix this by releasing the previously allocated bufio block using
1566 unlock_block().
1567
1568 Reported-by: Mikulas Patocka <mpatocka@redhat.com>
1569 Signed-off-by: Mike Snitzer <snitzer@redhat.com>
1570 Acked-by: Joe Thornber <thornber@redhat.com>
1571 Cc: stable@vger.kernel.org
1572 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1573
1574commit 297ce6f9c494be69cc3106c7be437038ee842344
1575Author: Joe Thornber <ejt@redhat.com>
1576Date: Wed Oct 21 18:36:49 2015 +0100
1577
1578 dm btree remove: fix a bug when rebalancing nodes after removal
1579
1580 [ Upstream commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b ]
1581
1582 Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
1583 a complete fix for redistribute3().
1584
1585 The redistribute3 function takes 3 btree nodes and shares out the entries
1586 evenly between them. If the three nodes in total contained
1587 (MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
1588 rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
1589 the center.
1590
1591 Fix this issue by being more careful about calculating the target number
1592 of entries for the left and right nodes.
1593
1594 Unit tested in userspace using this program:
1595 https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c
1596
1597 Signed-off-by: Joe Thornber <ejt@redhat.com>
1598 Signed-off-by: Mike Snitzer <snitzer@redhat.com>
1599 Cc: stable@vger.kernel.org
1600 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1601
1602commit 1895f1b79e22b18b1b46b845572b9bd36a4ebd20
1603Author: Will Deacon <will.deacon@arm.com>
1604Date: Wed Oct 28 16:56:13 2015 +0000
1605
1606 Revert "ARM64: unwind: Fix PC calculation"
1607
1608 [ Upstream commit 9702970c7bd3e2d6fecb642a190269131d4ac16c ]
1609
1610 This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.
1611
1612 With this patch applied, we were the only architecture making this sort
1613 of adjustment to the PC calculation in the unwinder. This causes
1614 problems for ftrace, where the PC values are matched against the
1615 contents of the stack frames in the callchain and fail to match any
1616 records after the address adjustment.
1617
1618 Whilst there has been some effort to change ftrace to workaround this,
1619 those patches are not yet ready for mainline and, since we're the odd
1620 architecture in this regard, let's just step in line with other
1621 architectures (like arch/arm/) for now.
1622
1623 Cc: <stable@vger.kernel.org>
1624 Signed-off-by: Will Deacon <will.deacon@arm.com>
1625 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1626
1627commit 51c083f34d4545f49749327242e69475187a2b98
1628Author: Ronny Hegewald <ronny.hegewald@online.de>
1629Date: Thu Oct 15 18:50:46 2015 +0000
1630
1631 rbd: require stable pages if message data CRCs are enabled
1632
1633 [ Upstream commit bae818ee1577c27356093901a0ea48f672eda514 ]
1634
1635 rbd requires stable pages, as it performs a crc of the page data before
1636 they are send to the OSDs.
1637
1638 But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0
1639 "mm: only enforce stable page writes if the backing device requires
1640 it") it is not assumed anymore that block devices require stable pages.
1641
1642 This patch sets the necessary flag to get stable pages back for rbd.
1643
1644 In a ceph installation that provides multiple ext4 formatted rbd
1645 devices "bad crc" messages appeared regularly (ca 1 message every 1-2
1646 minutes on every OSD that provided the data for the rbd) in the
1647 OSD-logs before this patch. After this patch this messages are pretty
1648 much gone (only ca 1-2 / month / OSD).
1649
1650 Cc: stable@vger.kernel.org # 3.9+, needs backporting
1651 Signed-off-by: Ronny Hegewald <Ronny.Hegewald@online.de>
1652 [idryomov@gmail.com: require stable pages only in crc case, changelog]
1653 Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
1654
1655 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1656
1657commit a1c0361f5dad79729ec1dcb503d773e11f801b8c
1658Author: Alexandre Belloni <alexandre.belloni@free-electrons.com>
1659Date: Wed Oct 7 13:10:54 2015 +0200
1660
1661 iio: mxs-lradc: Fix temperature offset
1662
1663 [ Upstream commit b94e22805a2224061bb263a82b72e09544a5fbb3 ]
1664
1665 0° Kelvin is actually −273.15°C, not -272.15°C. Fix the temperature offset.
1666 Also improve the comment explaining the calculation.
1667
1668 Reported-by: Janusz Użycki <j.uzycki@elpromaelectronics.com>
1669 Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
1670 Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
1671 Acked-by: Marek Vasut <marex@denx.de>
1672 Cc: <stable@vger.kernel.org>
1673 Signed-off-by: Jonathan Cameron <jic23@kernel.org>
1674 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1675
1676commit cb6e0c1eda88038175cd848f10ae330744067558
1677Author: Alex Deucher <alexander.deucher@amd.com>
1678Date: Fri Oct 23 10:38:52 2015 -0400
1679
1680 drm/radeon: don't try to recreate sysfs entries on resume
1681
1682 [ Upstream commit 49abb26651167c892393cd9f2ad23df429645ed9 ]
1683
1684 Fixes a harmless error message caused by:
1685 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5
1686
1687 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
1688 Cc: stable@vger.kernel.org
1689 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1690
1691commit a83d675ed2f83b40e539e859f8d624f2ac1b4404
1692Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
1693Date: Wed Oct 7 22:08:24 2015 +0300
1694
1695 drm/i915: Restore lost DPLL register write on gen2-4
1696
1697 [ Upstream commit 8e7a65aa70bcc1235a44e40ae0da5056525fe081 ]
1698
1699 We accidentally lost the initial DPLL register write in
1700 1c4e02746147 drm/i915: Fix DVO 2x clock enable on 830M
1701
1702 The "three times for luck" hack probably saved us from a total
1703 disaster. But anyway, bring the initial write back so that the
1704 code actually makes some sense.
1705
1706 Reported-and-tested-by: Nick Bowler <nbowler@draconx.ca>
1707 References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
1708 Cc: stable@vger.kernel.org
1709 Cc: Nick Bowler <nbowler@draconx.ca>
1710 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
1711 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1712 Signed-off-by: Jani Nikula <jani.nikula@intel.com>
1713 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1714
1715commit 239030251b6e6187f55831aa44e2aee415dabed4
1716Author: Ilia Mirkin <imirkin@alum.mit.edu>
1717Date: Tue Oct 20 01:15:39 2015 -0400
1718
1719 drm/nouveau/gem: return only valid domain when there's only one
1720
1721 [ Upstream commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 ]
1722
1723 On nv50+, we restrict the valid domains to just the one where the buffer
1724 was originally created. However after the buffer is evicted to system
1725 memory, we might move it back to a different domain that was not
1726 originally valid. When sharing the buffer and retrieving its GEM_INFO
1727 data, we still want the domain that will be valid for this buffer in a
1728 pushbuf, not the one where it currently happens to be.
1729
1730 This resolves fdo#92504 and several others. These are due to suspend
1731 evicting all buffers, making it more likely that they temporarily end up
1732 in the wrong place.
1733
1734 Cc: stable@vger.kernel.org
1735 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
1736 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
1737 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
1738 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1739
1740commit 499cf5fb763ce3271b5190ef1a00c5404c7f43b9
1741Author: Lad, Prabhakar <prabhakar.csengg@gmail.com>
1742Date: Thu Dec 4 14:56:04 2014 +0000
1743
1744 power: bq24190_charger: suppress build warning
1745
1746 [ Upstream commit 31f50e48e3e4ea9d503285a389d6a1b5349d66c0 ]
1747
1748 This patch fixes following build warning:
1749
1750 In file included from include/linux/printk.h:261:0,
1751 from include/linux/kernel.h:13,
1752 from include/linux/list.h:8,
1753 from include/linux/module.h:9,
1754 from drivers/power/bq24190_charger.c:11:
1755 drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’:
1756 include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1757 __dynamic_dev_dbg(&descriptor, dev, fmt, \
1758 ^
1759 drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here
1760 u8 ss_reg, f_reg;
1761 ^
1762 In file included from include/linux/printk.h:261:0,
1763 from include/linux/kernel.h:13,
1764 from include/linux/list.h:8,
1765 from include/linux/module.h:9,
1766 from drivers/power/bq24190_charger.c:11:
1767 include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
1768 __dynamic_dev_dbg(&descriptor, dev, fmt, \
1769 ^
1770 drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here
1771 u8 ss_reg, f_reg;
1772
1773 Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
1774 Signed-off-by: Sebastian Reichel <sre@kernel.org>
1775 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1776
1777commit a6a0076803a901f499bc60ce379807cf4eda8aaa
1778Author: David S. Miller <davem@davemloft.net>
1779Date: Fri Apr 17 15:15:40 2015 -0400
1780
1781 sfc: Fix memcpy() with const destination compiler warning.
1782
1783 [ Upstream commit 1d20a16062e771b6e26b843c0cde3b17c1146e00 ]
1784
1785 drivers/net/ethernet/sfc/selftest.c: In function ‘efx_iterate_state’:
1786 drivers/net/ethernet/sfc/selftest.c:388:9: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]
1787
1788 This is because the msg[] member of struct efx_loopback_payload
1789 is marked as 'const'. Remove that.
1790
1791 Signed-off-by: David S. Miller <davem@davemloft.net>
1792 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1793
1794commit 4084246db34ccb9c58cd6b5a85bfe74af0d4620a
1795Author: Jan Kara <jack@suse.com>
1796Date: Thu Oct 22 13:32:21 2015 -0700
1797
1798 mm: make sendfile(2) killable
1799
1800 [ Upstream commit 296291cdd1629c308114504b850dc343eabc2782 ]
1801
1802 Currently a simple program below issues a sendfile(2) system call which
1803 takes about 62 days to complete in my test KVM instance.
1804
1805 int fd;
1806 off_t off = 0;
1807
1808 fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
1809 ftruncate(fd, 2);
1810 lseek(fd, 0, SEEK_END);
1811 sendfile(fd, fd, &off, 0xfffffff);
1812
1813 Now you should not ask kernel to do a stupid stuff like copying 256MB in
1814 2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
1815 should have a way to stop you.
1816
1817 We actually do have a check for fatal_signal_pending() in
1818 generic_perform_write() which triggers in this path however because we
1819 always succeed in writing something before the check is done, we return
1820 value > 0 from generic_perform_write() and thus the information about
1821 signal gets lost.
1822
1823 Fix the problem by doing the signal check before writing anything. That
1824 way generic_perform_write() returns -EINTR, the error gets propagated up
1825 and the sendfile loop terminates early.
1826
1827 Signed-off-by: Jan Kara <jack@suse.com>
1828 Reported-by: Dmitry Vyukov <dvyukov@google.com>
1829 Cc: Al Viro <viro@ZenIV.linux.org.uk>
1830 Cc: <stable@vger.kernel.org>
1831 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
1832 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1833 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1834
1835commit 7b516b5f395b0610008c7d2638fd293440ab2f8a
1836Author: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
1837Date: Tue Oct 20 10:25:58 2015 +0100
1838
1839 ASoC: wm8904: Correct number of EQ registers
1840
1841 [ Upstream commit 97aff2c03a1e4d343266adadb52313613efb027f ]
1842
1843 There are 24 EQ registers not 25, I suspect this bug came about because
1844 the registers start at EQ1 not zero. The bug is relatively harmless as
1845 the extra register written is an unused one.
1846
1847 Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
1848 Signed-off-by: Mark Brown <broonie@kernel.org>
1849 Cc: stable@vger.kernel.org
1850 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1851
1852commit 074ea6f13f7617cccf074ba8401bfb83dc0b4420
1853Author: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
1854Date: Fri Oct 16 15:53:29 2015 +0530
1855
1856 powerpc/rtas: Validate rtas.entry before calling enter_rtas()
1857
1858 [ Upstream commit 8832317f662c06f5c06e638f57bfe89a71c9b266 ]
1859
1860 Currently we do not validate rtas.entry before calling enter_rtas(). This
1861 leads to a kernel oops when user space calls rtas system call on a powernv
1862 platform (see below). This patch adds code to validate rtas.entry before
1863 making enter_rtas() call.
1864
1865 Oops: Exception in kernel mode, sig: 4 [#1]
1866 SMP NR_CPUS=1024 NUMA PowerNV
1867 task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000
1868 NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140
1869 REGS: c0000007e1a7b920 TRAP: 0e40 Not tainted (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le)
1870 MSR: 1000000000081000 <HV,ME> CR: 00000000 XER: 00000000
1871 CFAR: c000000000009c0c SOFTE: 0
1872 NIP [0000000000000000] (null)
1873 LR [0000000000009c14] 0x9c14
1874 Call Trace:
1875 [c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable)
1876 [c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0
1877 [c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98
1878
1879 Cc: stable@vger.kernel.org # v3.2+
1880 Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform")
1881 Reported-by: NAGESWARA R. SASTRY <nasastry@in.ibm.com>
1882 Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
1883 [mpe: Reword change log, trim oops, and add stable + fixes]
1884 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
1885
1886 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1887
1888commit b6a84ee5b14652021a9d34c43206eb36a081a2d7
1889Author: Joerg Roedel <jroedel@suse.de>
1890Date: Tue Oct 20 14:59:36 2015 +0200
1891
1892 iommu/amd: Don't clear DTE flags when modifying it
1893
1894 [ Upstream commit cbf3ccd09d683abf1cacd36e3640872ee912d99b ]
1895
1896 During device assignment/deassignment the flags in the DTE
1897 get lost, which might cause spurious faults, for example
1898 when the device tries to access the system management range.
1899 Fix this by not clearing the flags with the rest of the DTE.
1900
1901 Reported-by: G. Richard Bellamy <rbellamy@pteradigm.com>
1902 Tested-by: G. Richard Bellamy <rbellamy@pteradigm.com>
1903 Cc: stable@vger.kernel.org
1904 Signed-off-by: Joerg Roedel <jroedel@suse.de>
1905 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1906
1907commit 09d7738b387bc229eda6df0a705ec8f09d9ff75f
1908Author: Luca Coelho <luciano.coelho@intel.com>
1909Date: Tue Sep 22 09:44:39 2015 +0300
1910
1911 iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series
1912
1913 [ Upstream commit f08f625876476b6c4a87834dc86e3b927f4697d2 ]
1914
1915 Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B
1916 device ID.
1917
1918 Cc: <stable@vger.kernerl.org> [3.13+]
1919 Reported-by: Jeremy <jeremy.bomkamp@gmail.com>
1920 Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
1921 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1922
1923commit e9bdf3b3913dd77c463c6e01c2901a232ead7289
1924Author: Johannes Berg <johannes.berg@intel.com>
1925Date: Tue Sep 15 14:36:09 2015 +0200
1926
1927 iwlwifi: mvm: fix D3 firmware PN programming
1928
1929 [ Upstream commit 2cf5eb3ab7bb7f2e3a70edcef236cd62c87db030 ]
1930
1931 The code to send the RX PN data (for each TID) to the firmware
1932 has a devastating bug: it overwrites the data for TID 0 with
1933 all the TID data, leaving the remaining TIDs zeroed. This will
1934 allow replays to actually be accepted by the firmware, which
1935 could allow waking up the system.
1936
1937 Cc: <stable@vger.kernel.org> [3.1+]
1938 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1939 Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
1940 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1941
1942commit 1b0151756149d603927e1a590429d8ae4ee51876
1943Author: Johannes Berg <johannes.berg@intel.com>
1944Date: Tue Nov 18 15:39:51 2014 +0100
1945
1946 iwlwifi: pcie: support 7265-D devices
1947
1948 [ Upstream commit 3fd0d3c170ad6ba8b64e16938f699d0b43cc782e ]
1949
1950 Identify 7265-D devices using the hardware revision (they have the
1951 same PCI IDs as 7265) and change the configuration for them taking
1952 the differences (currently only the firmware image) into account.
1953
1954 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1955 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
1956 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1957
1958commit b2845e18999b1f9e51eefadd0b9e64a62bfcff90
1959Author: Johannes Berg <johannes.berg@intel.com>
1960Date: Tue Sep 22 10:47:27 2015 +0200
1961
1962 iwlwifi: fix firmware filename for 3160
1963
1964 [ Upstream commit b5a48134f8af08f5243328f8a0b05fc5ae7cf343 ]
1965
1966 The MODULE_FIRMWARE() for 3160 should be using the 7260 version as
1967 it's done in the device configuration struct instead of referencing
1968 IWL3160_UCODE_API_OK which doesn't even exist.
1969
1970 Cc: <stable@vger.kernel.org> [3.8+]
1971 Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
1972 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1973 Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
1974 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1975
1976commit ae9b626a28912f18a61b8963da60deef0609a93d
1977Author: Johannes Berg <johannes.berg@intel.com>
1978Date: Tue Sep 15 14:36:09 2015 +0200
1979
1980 iwlwifi: dvm: fix D3 firmware PN programming
1981
1982 [ Upstream commit 5bd166872d8f99f156fac191299d24f828bb2348 ]
1983
1984 The code to send the RX PN data (for each TID) to the firmware
1985 has a devastating bug: it overwrites the data for TID 0 with
1986 all the TID data, leaving the remaining TIDs zeroed. This will
1987 allow replays to actually be accepted by the firmware, which
1988 could allow waking up the system.
1989
1990 Cc: <stable@vger.kernel.org> [3.1+]
1991 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
1992 Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
1993 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
1994
1995commit c66c8ccae54d30a47a1a9d793a1790fc612d3842
1996Author: Felix Fietkau <nbd@openwrt.org>
1997Date: Thu Sep 24 16:59:46 2015 +0200
1998
1999 ath9k: declare required extra tx headroom
2000
2001 [ Upstream commit 029cd0370241641eb70235d205aa0b90c84dce44 ]
2002
2003 ath9k inserts padding between the 802.11 header and the data area (to
2004 align it). Since it didn't declare this extra required headroom, this
2005 led to some nasty issues like randomly dropped packets in some setups.
2006
2007 Cc: stable@vger.kernel.org
2008 Signed-off-by: Felix Fietkau <nbd@openwrt.org>
2009 Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2010 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2011
2012commit ca7c3488286856a30fdd8c376360ebc7b687518b
2013Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2014Date: Thu Feb 12 15:03:05 2015 -0800
2015
2016 lib/radix-tree.c: change to simpler include
2017
2018 [ Upstream commit 886d3dfa85d5aa6f11813c319e50f5402c7cf4e4 ]
2019
2020 The comment helpfully explains why hardirq.h is included, but since
2021 commit 2d4b84739f0a ("hardirq: Split preempt count mask definitions")
2022 in_interrupt() has been provided by preempt_mask.h. Use that instead,
2023 saving around 40 lines in the generated dependency file.
2024
2025 Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
2026 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2027 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2028 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2029
2030commit f5c09209ca16bd7329e4255aca7ad6bca31cfaff
2031Author: Ilya Dryomov <idryomov@gmail.com>
2032Date: Mon Aug 31 15:21:39 2015 +0300
2033
2034 rbd: fix double free on rbd_dev->header_name
2035
2036 [ Upstream commit 3ebe138ac642a195c7f2efdb918f464734421fd6 ]
2037
2038 If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name
2039 is freed twice: once in rbd_dev_probe_parent() and then in its caller
2040 rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to
2041 handle parent images).
2042
2043 rbd_dev_probe_parent() is responsible for probing the parent, so it
2044 shouldn't muck with clone's fields.
2045
2046 Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
2047 Reviewed-by: Alex Elder <elder@linaro.org>
2048 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2049
2050commit 21f6ebb8ddf3d7940bc6a752df0ddc62667915c1
2051Author: Mike Snitzer <snitzer@redhat.com>
2052Date: Tue Oct 13 12:04:28 2015 -0400
2053
2054 dm thin: fix missing pool reference count decrement in pool_ctr error path
2055
2056 [ Upstream commit ba30670f4d5292c4e7f7980bbd5071f7c4794cdd ]
2057
2058 Fixes: ac8c3f3df ("dm thin: generate event when metadata threshold passed")
2059 Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2060 Cc: stable@vger.kernel.org # 3.10+
2061 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2062
2063commit 5ab6262ccf4d1a622ab8fb63636a24a1028ffd92
2064Author: Alex Deucher <alexander.deucher@amd.com>
2065Date: Wed Sep 30 16:45:52 2015 -0400
2066
2067 drm/radeon: add pm sysfs files late
2068
2069 [ Upstream commit 51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5 ]
2070
2071 They were added relatively early in the driver init process
2072 which meant that in some cases the driver was not finished
2073 initializing before external tools tried to use them which
2074 could result in a crash depending on the timing.
2075
2076 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2077 Cc: stable@vger.kernel.org
2078 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2079
2080commit a7138587d56380902237cec784fbc09048a17003
2081Author: Ben Skeggs <bskeggs@redhat.com>
2082Date: Fri Oct 2 14:03:19 2015 +1000
2083
2084 drm/nouveau/fbcon: take runpm reference when userspace has an open fd
2085
2086 [ Upstream commit f231976c2e8964ceaa9250e57d27c35ff03825c2 ]
2087
2088 We need to do this in order to prevent accesses to the device while it's
2089 powered down. Userspace may have an mmap of the fb, and there's no good
2090 way (that I know of) to prevent it from touching the device otherwise.
2091
2092 This fixes some nasty races between runpm and plymouth on some systems,
2093 which result in the GPU getting very upset and hanging the boot.
2094
2095 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2096 Cc: stable@vger.kernel.org
2097 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2098
2099commit 43ac913d76a9ae3894337654effc3ff2f931e106
2100Author: Shaohua Li <shli@fb.com>
2101Date: Wed Sep 30 09:05:30 2015 -0700
2102
2103 workqueue: make sure delayed work run in local cpu
2104
2105 [ Upstream commit 874bbfe600a660cba9c776b3957b1ce393151b76 ]
2106
2107 My system keeps crashing with below message. vmstat_update() schedules a delayed
2108 work in current cpu and expects the work runs in the cpu.
2109 schedule_delayed_work() is expected to make delayed work run in local cpu. The
2110 problem is timer can be migrated with NO_HZ. __queue_work() queues work in
2111 timer handler, which could run in a different cpu other than where the delayed
2112 work is scheduled. The end result is the delayed work runs in different cpu.
2113 The patch makes __queue_delayed_work records local cpu earlier. Where the timer
2114 runs doesn't change where the work runs with the change.
2115
2116 [ 28.010131] ------------[ cut here ]------------
2117 [ 28.010609] kernel BUG at ../mm/vmstat.c:1392!
2118 [ 28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
2119 [ 28.011860] Modules linked in:
2120 [ 28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G W4.3.0-rc3+ #634
2121 [ 28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
2122 [ 28.014160] Workqueue: events vmstat_update
2123 [ 28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000
2124 [ 28.015445] RIP: 0010:[<ffffffff8115f921>] [<ffffffff8115f921>]vmstat_update+0x31/0x80
2125 [ 28.016282] RSP: 0018:ffff8800ba42fd80 EFLAGS: 00010297
2126 [ 28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000
2127 [ 28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d
2128 [ 28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000
2129 [ 28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640
2130 [ 28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000
2131 [ 28.020071] FS: 0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000
2132 [ 28.020071] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
2133 [ 28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0
2134 [ 28.020071] Stack:
2135 [ 28.020071] ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88
2136 [ 28.020071] ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8
2137 [ 28.020071] ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340
2138 [ 28.020071] Call Trace:
2139 [ 28.020071] [<ffffffff8106bd88>] process_one_work+0x1c8/0x540
2140 [ 28.020071] [<ffffffff8106bd0b>] ? process_one_work+0x14b/0x540
2141 [ 28.020071] [<ffffffff8106c214>] worker_thread+0x114/0x460
2142 [ 28.020071] [<ffffffff8106c100>] ? process_one_work+0x540/0x540
2143 [ 28.020071] [<ffffffff81071bf8>] kthread+0xf8/0x110
2144 [ 28.020071] [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
2145 [ 28.020071] [<ffffffff81a6522f>] ret_from_fork+0x3f/0x70
2146 [ 28.020071] [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
2147
2148 Signed-off-by: Shaohua Li <shli@fb.com>
2149 Signed-off-by: Tejun Heo <tj@kernel.org>
2150 Cc: stable@vger.kernel.org # v2.6.31+
2151 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2152
2153commit cd351c29c369fc45102590d60a136436360f8e11
2154Author: Mika Westerberg <mika.westerberg@linux.intel.com>
2155Date: Thu Sep 24 12:06:54 2015 +0300
2156
2157 i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348
2158
2159 [ Upstream commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 ]
2160
2161 ACPI SSCN/FMCN methods were originally added because then the platform can
2162 provide the most accurate HCNT/LCNT values to the driver. However, this
2163 seems not to be true for Dell Inspiron 7348 where using these causes the
2164 touchpad to fail in boot:
2165
2166 i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
2167 i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
2168 i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
2169 i2c_designware INT3433:00: controller timed out
2170
2171 The values received from ACPI are (in fast mode):
2172
2173 HCNT: 72
2174 LCNT: 160
2175
2176 this translates to following timings (input clock is 100MHz on Broadwell):
2177
2178 tHIGH: 720 ns (spec min 600 ns)
2179 tLOW: 1600 ns (spec min 1300 ns)
2180 Bus period: 2920 ns (assuming 300 ns tf and tr)
2181 Bus speed: 342.5 kHz
2182
2183 Both tHIGH and tLOW are within the I2C specification.
2184
2185 The calculated values when ACPI parameters are not used are (in fast mode):
2186
2187 HCNT: 87
2188 LCNT: 159
2189
2190 which translates to:
2191
2192 tHIGH: 870 ns (spec min 600 ns)
2193 tLOW: 1590 ns (spec min 1300 ns)
2194 Bus period 3060 ns (assuming 300 ns tf and tr)
2195 Bus speed 326.8 kHz
2196
2197 These values are also within the I2C specification.
2198
2199 Since both ACPI and calculated values meet the I2C specification timing
2200 requirements it is hard to say why the touchpad does not function properly
2201 with the ACPI values except that the bus speed is higher in this case (but
2202 still well below the max 400kHz).
2203
2204 Solve this by adding DMI quirk to the driver that disables using ACPI
2205 parameters on this particulare machine.
2206
2207 Reported-by: Pavel Roskin <plroskin@gmail.com>
2208 Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2209 Tested-by: Pavel Roskin <plroskin@gmail.com>
2210 Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2211 Cc: stable@kernel.org
2212 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2213
2214commit d8b06f6fe0481d5bb79994b31f284a6609c46286
2215Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
2216Date: Sat Oct 10 08:24:23 2015 +0100
2217
2218 i2c: s3c2410: enable RuntimePM before registering to the core
2219
2220 [ Upstream commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 ]
2221
2222 The core may register clients attached to this master which may use
2223 funtionality from the master. So, RuntimePM must be enabled before, otherwise
2224 this will fail. While here, move drvdata, too.
2225
2226 Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2227 Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
2228 Acked-by: Kukjin Kim <kgene@kernel.org>
2229 Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2230 Cc: stable@kernel.org
2231 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2232
2233commit d1edec87b14e67ff76d97eb8d6434270d8286efc
2234Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
2235Date: Fri Oct 9 10:39:25 2015 +0100
2236
2237 i2c: rcar: enable RuntimePM before registering to the core
2238
2239 [ Upstream commit 4f7effddf4549d57114289f273710f077c4c330a ]
2240
2241 The core may register clients attached to this master which may use
2242 funtionality from the master. So, RuntimePM must be enabled before, otherwise
2243 this will fail. While here, move drvdata, too.
2244
2245 Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
2246 Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2247 Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2248 Cc: stable@kernel.org
2249 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2250
2251commit b2a40bdea04d1b212e4c26e68953ec5d8151d218
2252Author: Will Deacon <will.deacon@arm.com>
2253Date: Thu Oct 8 11:11:17 2015 +0100
2254
2255 arm64: errata: use KBUILD_CFLAGS_MODULE for erratum #843419
2256
2257 [ Upstream commit b6dd8e0719c0d2d01429639a11b7bc2677de240c ]
2258
2259 Commit df057cc7b4fa ("arm64: errata: add module build workaround for
2260 erratum #843419") sets CFLAGS_MODULE to ensure that the large memory
2261 model is used by the compiler when building kernel modules.
2262
2263 However, CFLAGS_MODULE is an environment variable and intended to be
2264 overridden on the command line, which appears to be the case with the
2265 Ubuntu kernel packaging system, so use KBUILD_CFLAGS_MODULE instead.
2266
2267 Cc: <stable@vger.kernel.org>
2268 Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2269 Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419")
2270 Reported-by: Dann Frazier <dann.frazier@canonical.com>
2271 Tested-by: Dann Frazier <dann.frazier@canonical.com>
2272 Signed-off-by: Will Deacon <will.deacon@arm.com>
2273 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2274
2275commit 431baf4cb7d25cd47bb9c81c08eff0a835f6536e
2276Author: Chris Mason <clm@fb.com>
2277Date: Tue Oct 13 14:06:48 2015 -0400
2278
2279 btrfs: fix use after free iterating extrefs
2280
2281 [ Upstream commit dc6c5fb3b514221f2e9d21ee626a9d95d3418dff ]
2282
2283 The code for btrfs inode-resolve has never worked properly for
2284 files with enough hard links to trigger extrefs. It was trying to
2285 get the leaf out of a path after freeing the path:
2286
2287 btrfs_release_path(path);
2288 leaf = path->nodes[0];
2289 item_size = btrfs_item_size_nr(leaf, slot);
2290
2291 The fix here is to use the extent buffer we cloned just a little higher
2292 up to avoid deadlocks caused by using the leaf in the path.
2293
2294 Signed-off-by: Chris Mason <clm@fb.com>
2295 cc: stable@vger.kernel.org # v3.7+
2296 cc: Mark Fasheh <mfasheh@suse.de>
2297 Reviewed-by: Filipe Manana <fdmanana@suse.com>
2298 Reviewed-by: Mark Fasheh <mfasheh@suse.de>
2299 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2300
2301commit 0202b0dfe93fe7d0179b80013dbac5c15f2c81c3
2302Author: Russell King <rmk+kernel@arm.linux.org.uk>
2303Date: Fri Oct 9 20:43:33 2015 +0100
2304
2305 crypto: ahash - ensure statesize is non-zero
2306
2307 [ Upstream commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a ]
2308
2309 Unlike shash algorithms, ahash drivers must implement export
2310 and import as their descriptors may contain hardware state and
2311 cannot be exported as is. Unfortunately some ahash drivers did
2312 not provide them and end up causing crashes with algif_hash.
2313
2314 This patch adds a check to prevent these drivers from registering
2315 ahash algorithms until they are fixed.
2316
2317 Cc: stable@vger.kernel.org
2318 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2319 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2320 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2321
2322commit 27874987e9b9eba00c17aa5590befe3ebe8723ba
2323Author: Dave Kleikamp <dave.kleikamp@oracle.com>
2324Date: Mon Oct 5 10:08:51 2015 -0500
2325
2326 crypto: sparc - initialize blkcipher.ivsize
2327
2328 [ Upstream commit a66d7f724a96d6fd279bfbd2ee488def6b081bea ]
2329
2330 Some of the crypto algorithms write to the initialization vector,
2331 but no space has been allocated for it. This clobbers adjacent memory.
2332
2333 Cc: stable@vger.kernel.org
2334 Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
2335 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2336 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2337
2338commit f5f7e02d8bd8f173aa74bfa006d696c83cc39119
2339Author: Joe Perches <joe@perches.com>
2340Date: Wed Oct 14 01:09:40 2015 -0700
2341
2342 ethtool: Use kcalloc instead of kmalloc for ethtool_get_strings
2343
2344 [ Upstream commit 077cb37fcf6f00a45f375161200b5ee0cd4e937b ]
2345
2346 It seems that kernel memory can leak into userspace by a
2347 kmalloc, ethtool_get_strings, then copy_to_user sequence.
2348
2349 Avoid this by using kcalloc to zero fill the copied buffer.
2350
2351 Signed-off-by: Joe Perches <joe@perches.com>
2352 Acked-by: Ben Hutchings <ben@decadent.org.uk>
2353 Signed-off-by: David S. Miller <davem@davemloft.net>
2354 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2355
2356commit 2191851fa6974677c5cbb0c4b131cd768c18c4ec
2357Author: Guillaume Nault <g.nault@alphalink.fr>
2358Date: Wed Sep 30 11:45:33 2015 +0200
2359
2360 ppp: don't override sk->sk_state in pppoe_flush_dev()
2361
2362 [ Upstream commit e6740165b8f7f06d8caee0fceab3fb9d790a6fed ]
2363
2364 Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
2365 pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
2366 PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
2367 PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
2368 following oops:
2369
2370 [ 570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
2371 [ 570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
2372 [ 570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
2373 [ 570.144601] Oops: 0000 [#1] SMP
2374 [ 570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
2375 [ 570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
2376 [ 570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
2377 [ 570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
2378 [ 570.144601] RIP: 0010:[<ffffffffa018c701>] [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
2379 [ 570.144601] RSP: 0018:ffff880036b63e08 EFLAGS: 00010202
2380 [ 570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
2381 [ 570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
2382 [ 570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
2383 [ 570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
2384 [ 570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
2385 [ 570.144601] FS: 00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
2386 [ 570.144601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2387 [ 570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
2388 [ 570.144601] Stack:
2389 [ 570.144601] ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
2390 [ 570.144601] ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
2391 [ 570.144601] ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
2392 [ 570.144601] Call Trace:
2393 [ 570.144601] [<ffffffff812caabe>] sock_release+0x1a/0x75
2394 [ 570.144601] [<ffffffff812cabad>] sock_close+0xd/0x11
2395 [ 570.144601] [<ffffffff811347f5>] __fput+0xff/0x1a5
2396 [ 570.144601] [<ffffffff811348cb>] ____fput+0x9/0xb
2397 [ 570.144601] [<ffffffff81056682>] task_work_run+0x66/0x90
2398 [ 570.144601] [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
2399 [ 570.144601] [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
2400 [ 570.144601] [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
2401 [ 570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
2402 [ 570.144601] RIP [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
2403 [ 570.144601] RSP <ffff880036b63e08>
2404 [ 570.144601] CR2: 00000000000004e0
2405 [ 570.200518] ---[ end trace 46956baf17349563 ]---
2406
2407 pppoe_flush_dev() has no reason to override sk->sk_state with
2408 PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
2409 PPPOX_DEAD, which is the correct state given that sk is unbound and
2410 po->pppoe_dev is NULL.
2411
2412 Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
2413 Tested-by: Oleksii Berezhniak <core@irc.lg.ua>
2414 Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
2415 Signed-off-by: David S. Miller <davem@davemloft.net>
2416 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2417
2418commit 5ca907c8d1e928e88f6a3cf877a8d39c5193de64
2419Author: Eric Dumazet <edumazet@google.com>
2420Date: Tue Sep 29 18:52:25 2015 -0700
2421
2422 net: add pfmemalloc check in sk_add_backlog()
2423
2424 [ Upstream commit c7c49b8fde26b74277188bdc6c9dca38db6fa35b ]
2425
2426 Greg reported crashes hitting the following check in __sk_backlog_rcv()
2427
2428 BUG_ON(!sock_flag(sk, SOCK_MEMALLOC));
2429
2430 The pfmemalloc bit is currently checked in sk_filter().
2431
2432 This works correctly for TCP, because sk_filter() is ran in
2433 tcp_v[46]_rcv() before hitting the prequeue or backlog checks.
2434
2435 For UDP or other protocols, this does not work, because the sk_filter()
2436 is ran from sock_queue_rcv_skb(), which might be called _after_ backlog
2437 queuing if socket is owned by user by the time packet is processed by
2438 softirq handler.
2439
2440 Fixes: b4b9e35585089 ("netvm: set PF_MEMALLOC as appropriate during SKB processing")
2441 Signed-off-by: Eric Dumazet <edumazet@google.com>
2442 Reported-by: Greg Thelen <gthelen@google.com>
2443 Signed-off-by: David S. Miller <davem@davemloft.net>
2444 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2445
2446commit 22f7f93333ef1dd1466cc205e8644c025da65c3e
2447Author: Pravin B Shelar <pshelar@nicira.com>
2448Date: Mon Sep 28 17:24:25 2015 -0700
2449
2450 skbuff: Fix skb checksum partial check.
2451
2452 [ Upstream commit 31b33dfb0a144469dd805514c9e63f4993729a48 ]
2453
2454 Earlier patch 6ae459bda tried to detect void ckecksum partial
2455 skb by comparing pull length to checksum offset. But it does
2456 not work for all cases since checksum-offset depends on
2457 updates to skb->data.
2458
2459 Following patch fixes it by validating checksum start offset
2460 after skb-data pointer is updated. Negative value of checksum
2461 offset start means there is no need to checksum.
2462
2463 Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull")
2464 Reported-by: Andrew Vagin <avagin@odin.com>
2465 Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
2466 Signed-off-by: David S. Miller <davem@davemloft.net>
2467 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2468
2469commit 97582070de7ca5d50db3e2659b55906d73ab908d
2470Author: Pravin B Shelar <pshelar@nicira.com>
2471Date: Tue Sep 22 12:57:53 2015 -0700
2472
2473 skbuff: Fix skb checksum flag on skb pull
2474
2475 [ Upstream commit 6ae459bdaaeebc632b16e54dcbabb490c6931d61 ]
2476
2477 VXLAN device can receive skb with checksum partial. But the checksum
2478 offset could be in outer header which is pulled on receive. This results
2479 in negative checksum offset for the skb. Such skb can cause the assert
2480 failure in skb_checksum_help(). Following patch fixes the bug by setting
2481 checksum-none while pulling outer header.
2482
2483 Following is the kernel panic msg from old kernel hitting the bug.
2484
2485 ------------[ cut here ]------------
2486 kernel BUG at net/core/dev.c:1906!
2487 RIP: 0010:[<ffffffff81518034>] skb_checksum_help+0x144/0x150
2488 Call Trace:
2489 <IRQ>
2490 [<ffffffffa0164c28>] queue_userspace_packet+0x408/0x470 [openvswitch]
2491 [<ffffffffa016614d>] ovs_dp_upcall+0x5d/0x60 [openvswitch]
2492 [<ffffffffa0166236>] ovs_dp_process_packet_with_key+0xe6/0x100 [openvswitch]
2493 [<ffffffffa016629b>] ovs_dp_process_received_packet+0x4b/0x80 [openvswitch]
2494 [<ffffffffa016c51a>] ovs_vport_receive+0x2a/0x30 [openvswitch]
2495 [<ffffffffa0171383>] vxlan_rcv+0x53/0x60 [openvswitch]
2496 [<ffffffffa01734cb>] vxlan_udp_encap_recv+0x8b/0xf0 [openvswitch]
2497 [<ffffffff8157addc>] udp_queue_rcv_skb+0x2dc/0x3b0
2498 [<ffffffff8157b56f>] __udp4_lib_rcv+0x1cf/0x6c0
2499 [<ffffffff8157ba7a>] udp_rcv+0x1a/0x20
2500 [<ffffffff8154fdbd>] ip_local_deliver_finish+0xdd/0x280
2501 [<ffffffff81550128>] ip_local_deliver+0x88/0x90
2502 [<ffffffff8154fa7d>] ip_rcv_finish+0x10d/0x370
2503 [<ffffffff81550365>] ip_rcv+0x235/0x300
2504 [<ffffffff8151ba1d>] __netif_receive_skb+0x55d/0x620
2505 [<ffffffff8151c360>] netif_receive_skb+0x80/0x90
2506 [<ffffffff81459935>] virtnet_poll+0x555/0x6f0
2507 [<ffffffff8151cd04>] net_rx_action+0x134/0x290
2508 [<ffffffff810683d8>] __do_softirq+0xa8/0x210
2509 [<ffffffff8162fe6c>] call_softirq+0x1c/0x30
2510 [<ffffffff810161a5>] do_softirq+0x65/0xa0
2511 [<ffffffff810687be>] irq_exit+0x8e/0xb0
2512 [<ffffffff81630733>] do_IRQ+0x63/0xe0
2513 [<ffffffff81625f2e>] common_interrupt+0x6e/0x6e
2514
2515 Reported-by: Anupam Chanda <achanda@vmware.com>
2516 Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
2517 Acked-by: Tom Herbert <tom@herbertland.com>
2518 Signed-off-by: David S. Miller <davem@davemloft.net>
2519 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2520
2521commit 9afa56cff10e209bb9910ef5460f87c0e8f89d3a
2522Author: Andrey Vagin <avagin@openvz.org>
2523Date: Fri Oct 2 00:05:36 2015 +0300
2524
2525 net/unix: fix logic about sk_peek_offset
2526
2527 [ Upstream commit e9193d60d363e4dff75ff6d43a48f22be26d59c7 ]
2528
2529 Now send with MSG_PEEK can return data from multiple SKBs.
2530
2531 Unfortunately we take into account the peek offset for each skb,
2532 that is wrong. We need to apply the peek offset only once.
2533
2534 In addition, the peek offset should be used only if MSG_PEEK is set.
2535
2536 Cc: "David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING
2537 Cc: Eric Dumazet <edumazet@google.com> (commit_signer:1/14=7%)
2538 Cc: Aaron Conole <aconole@bytheb.org>
2539 Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag")
2540 Signed-off-by: Andrey Vagin <avagin@openvz.org>
2541 Tested-by: Aaron Conole <aconole@bytheb.org>
2542 Signed-off-by: David S. Miller <davem@davemloft.net>
2543 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2544
2545commit aa7940ce4d64d03444e093d4b15a66b8a63e9626
2546Author: Aaron Conole <aconole@bytheb.org>
2547Date: Sat Sep 26 18:50:43 2015 -0400
2548
2549 af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag
2550
2551 [ Upstream commit 9f389e35674f5b086edd70ed524ca0f287259725 ]
2552
2553 AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag
2554 is set.
2555
2556 This is referenced in kernel bugzilla #12323 @
2557 https://bugzilla.kernel.org/show_bug.cgi?id=12323
2558
2559 As described both in the BZ and lkml thread @
2560 http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an
2561 AF_UNIX socket only reads a single skb, where the desired effect is
2562 to return as much skb data has been queued, until hitting the recv
2563 buffer size (whichever comes first).
2564
2565 The modified MSG_PEEK path will now move to the next skb in the tree
2566 and jump to the again: label, rather than following the natural loop
2567 structure. This requires duplicating some of the loop head actions.
2568
2569 This was tested using the python socketpair python code attached to
2570 the bugzilla issue.
2571
2572 Signed-off-by: Aaron Conole <aconole@bytheb.org>
2573 Signed-off-by: David S. Miller <davem@davemloft.net>
2574 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2575
2576commit 38bd9af57d22d9de63c8a8ebb647fbea1f55d887
2577Author: Aaron Conole <aconole@bytheb.org>
2578Date: Sat Sep 26 18:50:42 2015 -0400
2579
2580 af_unix: Convert the unix_sk macro to an inline function for type safety
2581
2582 [ Upstream commit 4613012db1d911f80897f9446a49de817b2c4c47 ]
2583
2584 As suggested by Eric Dumazet this change replaces the
2585 #define with a static inline function to enjoy
2586 complaints by the compiler when misusing the API.
2587
2588 Signed-off-by: Aaron Conole <aconole@bytheb.org>
2589 Signed-off-by: David S. Miller <davem@davemloft.net>
2590 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2591
2592commit c859b74e5a49244ddf6734ef42f365f3814f3227
2593Author: Alexander Couzens <lynxis@fe80.eu>
2594Date: Mon Sep 28 11:32:42 2015 +0200
2595
2596 l2tp: protect tunnel->del_work by ref_count
2597
2598 [ Upstream commit 06a15f51cf3618e32a73871ee6a547ef7fd902b5 ]
2599
2600 There is a small chance that tunnel_free() is called before tunnel->del_work scheduled
2601 resulting in a zero pointer dereference.
2602
2603 Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
2604 Acked-by: James Chapman <jchapman@katalix.com>
2605 Signed-off-by: David S. Miller <davem@davemloft.net>
2606 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2607
2608commit 645d5160d3e33b256e897b26270f8c944eec67d8
2609Author: Jan Kara <jack@suse.com>
2610Date: Tue Jul 28 14:57:14 2015 -0400
2611
2612 jbd2: avoid infinite loop when destroying aborted journal
2613
2614 [ Upstream commit 841df7df196237ea63233f0f9eaa41db53afd70f ]
2615
2616 Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal
2617 superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
2618 when the journal is aborted. That makes logic in
2619 jbd2_log_do_checkpoint() bail out which is fine, except that
2620 jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
2621 a progress in cleaning the journal. Without it jbd2_journal_destroy()
2622 just loops in an infinite loop.
2623
2624 Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
2625 jbd2_log_do_checkpoint() fails with error.
2626
2627 Reported-by: Eryu Guan <guaneryu@gmail.com>
2628 Tested-by: Eryu Guan <guaneryu@gmail.com>
2629 Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a
2630 Signed-off-by: Jan Kara <jack@suse.com>
2631 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2632 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2633
2634commit 6df34de6c5d05d6fa7d99d000a18b84a446095e8
2635Author: Sasha Levin <sasha.levin@oracle.com>
2636Date: Sat Oct 31 16:39:51 2015 -0400
2637
2638 Linux 3.18.24
2639
2640 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2641
2642commit 5f8c7ff19975a9d78d07265a00d79bff3e168a78
2643Author: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
2644Date: Fri Oct 2 08:27:05 2015 +0000
2645
2646 tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c
2647
2648 [ Upstream commit e81107d4c6bd098878af9796b24edc8d4a9524fd ]
2649
2650 My colleague ran into a program stall on a x86_64 server, where
2651 n_tty_read() was waiting for data even if there was data in the buffer
2652 in the pty. kernel stack for the stuck process looks like below.
2653 #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
2654 #1 [ffff88303d107bd0] schedule at ffffffff815c513e
2655 #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
2656 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
2657 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
2658 #5 [ffff88303d107dd0] tty_read at ffffffff81368013
2659 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
2660 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
2661 #8 [ffff88303d107f00] sys_read at ffffffff811a4306
2662 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7
2663
2664 There seems to be two problems causing this issue.
2665
2666 First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
2667 updates ldata->commit_head using smp_store_release() and then checks
2668 the wait queue using waitqueue_active(). However, since there is no
2669 memory barrier, __receive_buf() could return without calling
2670 wake_up_interactive_poll(), and at the same time, n_tty_read() could
2671 start to wait in wait_woken() as in the following chart.
2672
2673 __receive_buf() n_tty_read()
2674 ------------------------------------------------------------------------
2675 if (waitqueue_active(&tty->read_wait))
2676 /* Memory operations issued after the
2677 RELEASE may be completed before the
2678 RELEASE operation has completed */
2679 add_wait_queue(&tty->read_wait, &wait);
2680 ...
2681 if (!input_available_p(tty, 0)) {
2682 smp_store_release(&ldata->commit_head,
2683 ldata->read_head);
2684 ...
2685 timeout = wait_woken(&wait,
2686 TASK_INTERRUPTIBLE, timeout);
2687 ------------------------------------------------------------------------
2688
2689 The second problem is that n_tty_read() also lacks a memory barrier
2690 call and could also cause __receive_buf() to return without calling
2691 wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
2692 as in the chart below.
2693
2694 __receive_buf() n_tty_read()
2695 ------------------------------------------------------------------------
2696 spin_lock_irqsave(&q->lock, flags);
2697 /* from add_wait_queue() */
2698 ...
2699 if (!input_available_p(tty, 0)) {
2700 /* Memory operations issued after the
2701 RELEASE may be completed before the
2702 RELEASE operation has completed */
2703 smp_store_release(&ldata->commit_head,
2704 ldata->read_head);
2705 if (waitqueue_active(&tty->read_wait))
2706 __add_wait_queue(q, wait);
2707 spin_unlock_irqrestore(&q->lock,flags);
2708 /* from add_wait_queue() */
2709 ...
2710 timeout = wait_woken(&wait,
2711 TASK_INTERRUPTIBLE, timeout);
2712 ------------------------------------------------------------------------
2713
2714 There are also other places in drivers/tty/n_tty.c which have similar
2715 calls to waitqueue_active(), so instead of adding many memory barrier
2716 calls, this patch simply removes the call to waitqueue_active(),
2717 leaving just wake_up*() behind.
2718
2719 This fixes both problems because, even though the memory access before
2720 or after the spinlocks in both wake_up*() and add_wait_queue() can
2721 sneak into the critical section, it cannot go past it and the critical
2722 section assures that they will be serialized (please see "INTER-CPU
2723 ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
2724 better explanation). Moreover, the resulting code is much simpler.
2725
2726 Latency measurement using a ping-pong test over a pty doesn't show any
2727 visible performance drop.
2728
2729 Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
2730 Cc: stable@vger.kernel.org
2731 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2732 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2733
2734commit cfe6deeecd4098b743a4d50825a112893465738e
2735Author: Sasha Levin <sasha.levin@oracle.com>
2736Date: Sat Oct 31 08:54:32 2015 -0400
2737
2738 Revert "tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c"
2739
2740 This reverts commit af32cc7bde6304dac92e6a74fe4b2cc8120cb29a.
2741
2742 The commit was incorrectly backported and was causing hangs.
2743
2744 Reported-by: Corey Wright <undefined@pobox.com>
2745 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2746
2747commit 343f9bd48a7d3b6399542bf50762371ee44ed70f
2748Author: Sasha Levin <sasha.levin@oracle.com>
2749Date: Wed Oct 28 22:49:46 2015 -0400
2750
2751 Linux 3.18.23
2752
2753 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2754
2755commit 5ef609bbdc4845085488543b1c67d550f705e090
2756Author: Steven Rostedt <rostedt@goodmis.org>
2757Date: Fri Feb 27 14:50:19 2015 -0500
2758
2759 x86: Init per-cpu shadow copy of CR4 on 32-bit CPUs too
2760
2761 [ Upstream commit 5b2bdbc84556774afbe11bcfd24c2f6411cfa92b ]
2762
2763 Commit:
2764
2765 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
2766
2767 added a shadow CR4 such that reads and writes that do not
2768 modify the CR4 execute much faster than always reading the
2769 register itself.
2770
2771 The change modified cpu_init() in common.c, so that the
2772 shadow CR4 gets initialized before anything uses it.
2773
2774 Unfortunately, there's two cpu_init()s in common.c. There's
2775 one for 64-bit and one for 32-bit. The commit only added
2776 the shadow init to the 64-bit path, but the 32-bit path
2777 needs the init too.
2778
2779 Link: http://lkml.kernel.org/r/20150227125208.71c36402@gandalf.local.home Fixes: 1e02ce4cccdc "x86: Store a per-cpu shadow copy of CR4"
2780 Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2781 Acked-by: Andy Lutomirski <luto@amacapital.net>
2782 Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
2783 Cc: Linus Torvalds <torvalds@linux-foundation.org>
2784 Link: http://lkml.kernel.org/r/20150227145019.2bdd4354@gandalf.local.home
2785 Signed-off-by: Ingo Molnar <mingo@kernel.org>
2786 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2787
2788commit 12b34f06d178859239282182dc2951873ec8818f
2789Author: Christoph Hellwig <hch@lst.de>
2790Date: Sat Oct 3 19:16:07 2015 +0200
2791
2792 3w-9xxx: don't unmap bounce buffered commands
2793
2794 [ Upstream commit 15e3d5a285ab9283136dba34bbf72886d9146706 ]
2795
2796 3w controller don't dma map small single SGL entry commands but instead
2797 bounce buffer them. Add a helper to identify these commands and don't
2798 call scsi_dma_unmap for them.
2799
2800 Based on an earlier patch from James Bottomley.
2801
2802 Fixes: 118c85 ("3w-9xxx: fix command completion race")
2803 Reported-by: Tóth Attila <atoth@atoth.sote.hu>
2804 Tested-by: Tóth Attila <atoth@atoth.sote.hu>
2805 Signed-off-by: Christoph Hellwig <hch@lst.de>
2806 Acked-by: Adam Radford <aradford@gmail.com>
2807 Signed-off-by: James Bottomley <JBottomley@Odin.com>
2808 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2809
2810commit 2c74d22246d30a2c6205e30d8b52b93870586200
2811Author: Roland Dreier <roland@purestorage.com>
2812Date: Mon Oct 5 10:29:28 2015 -0700
2813
2814 fib_rules: Fix dump_rules() not to exit early
2815
2816 [ Upstream commit 8ea4b34355189e1f1eacaf2d825f2dce776b3b9c ]
2817
2818 Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
2819 multiple skbs") introduced a regression in "ip rule show" - it ends up
2820 dumping the first rule over and over and never exiting, because 3.19
2821 and earlier are missing commit 053c095a82cf ("netlink: make
2822 nlmsg_end() and genlmsg_end() void"), so fib_nl_fill_rule() ends up
2823 returning skb->len (i.e. > 0) in the success case.
2824
2825 Fix this by checking the return code for < 0 instead of != 0.
2826
2827 Signed-off-by: Roland Dreier <roland@purestorage.com>
2828 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2829 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2830
2831commit 36afb7233c204099f1f81395e72d0aa2ec3230ac
2832Author: Eric W. Biederman <ebiederm@xmission.com>
2833Date: Sat Aug 15 20:27:13 2015 -0500
2834
2835 vfs: Test for and handle paths that are unreachable from their mnt_root
2836
2837 [ Upstream commit 397d425dc26da728396e66d392d5dcb8dac30c37 ]
2838
2839 In rare cases a directory can be renamed out from under a bind mount.
2840 In those cases without special handling it becomes possible to walk up
2841 the directory tree to the root dentry of the filesystem and down
2842 from the root dentry to every other file or directory on the filesystem.
2843
2844 Like division by zero .. from an unconnected path can not be given
2845 a useful semantic as there is no predicting at which path component
2846 the code will realize it is unconnected. We certainly can not match
2847 the current behavior as the current behavior is a security hole.
2848
2849 Therefore when encounting .. when following an unconnected path
2850 return -ENOENT.
2851
2852 - Add a function path_connected to verify path->dentry is reachable
2853 from path->mnt.mnt_root. AKA to validate that rename did not do
2854 something nasty to the bind mount.
2855
2856 To avoid races path_connected must be called after following a path
2857 component to it's next path component.
2858
2859 Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2860 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2861 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2862
2863commit 846a6c3fdedbea41f9787f6dbc9f1b0b081fb518
2864Author: NeilBrown <neilb@suse.com>
2865Date: Wed Jul 22 10:20:07 2015 +1000
2866
2867 md: flush ->event_work before stopping array.
2868
2869 [ Upstream commit ee5d004fd0591536a061451eba2b187092e9127c ]
2870
2871 The 'event_work' worker used by dm-raid may still be running
2872 when the array is stopped. This can result in an oops.
2873
2874 So flush the workqueue on which it is run after detaching
2875 and before destroying the device.
2876
2877 Reported-by: Heinz Mauelshagen <heinzm@redhat.com>
2878 Signed-off-by: NeilBrown <neilb@suse.com>
2879 Cc: stable@vger.kernel.org (2.6.38+ please delay 2 weeks after -final release)
2880 Fixes: 9d09e663d550 ("dm: raid456 basic support")
2881 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2882
2883commit 307a1c1213513f41dd39b40aae0291f16adc6b7b
2884Author: Andy Lutomirski <luto@kernel.org>
2885Date: Sun Sep 20 16:32:05 2015 -0700
2886
2887 x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code
2888
2889 [ Upstream commit 83c133cf11fb0e68a51681447e372489f052d40e ]
2890
2891 The NMI entry code that switches to the normal kernel stack needs to
2892 be very careful not to clobber any extra stack slots on the NMI
2893 stack. The code is fine under the assumption that SWAPGS is just a
2894 normal instruction, but that assumption isn't really true. Use
2895 SWAPGS_UNSAFE_STACK instead.
2896
2897 This is part of a fix for some random crashes that Sasha saw.
2898
2899 Fixes: 9b6e6a8334d5 ("x86/nmi/64: Switch stacks on userspace NMI entry")
2900 Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com>
2901 Signed-off-by: Andy Lutomirski <luto@kernel.org>
2902 Cc: stable@vger.kernel.org
2903 Link: http://lkml.kernel.org/r/974bc40edffdb5c2950a5c4977f821a446b76178.1442791737.git.luto@kernel.org
2904 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2905 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2906
2907commit c93f6e1ee3a8db372b6527030f6bd2eb97474476
2908Author: Markus Pargmann <mpa@pengutronix.de>
2909Date: Wed Jul 29 15:46:03 2015 +0200
2910
2911 Revert "iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required"
2912
2913 [ Upstream commit HEAD ]
2914
2915 This reverts commit 279c039ca63acbd69e69d6d7ddfed50346fb2185 which was
2916 commit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 upstream as it should
2917 not have been applied.
2918
2919 Reported-by: Luis Henriques <luis.henriques@canonical.com>
2920 Cc: Markus Pargmann <mpa@pengutronix.de>
2921 Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
2922 Cc: Jonathan Cameron <jic23@kernel.org>
2923 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2924
2925 (cherry picked from commit 934d9b907aeec5f344ca801ed7361551199dfc69)
2926 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2927
2928commit c1b3815f362ef76e27553e70d4ec54ce8951aeac
2929Author: Herbert Xu <herbert@gondor.apana.org.au>
2930Date: Mon Jul 13 16:04:13 2015 +0800
2931
2932 net: Fix skb_set_peeked use-after-free bug
2933
2934 [ Upstream commit a0a2a6602496a45ae838a96db8b8173794b5d398 ]
2935
2936 The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone
2937 skb before setting peeked flag") introduced a use-after-free bug
2938 in skb_recv_datagram. This is because skb_set_peeked may create
2939 a new skb and free the existing one. As it stands the caller will
2940 continue to use the old freed skb.
2941
2942 This patch fixes it by making skb_set_peeked return the new skb
2943 (or the old one if unchanged).
2944
2945 Fixes: 738ac1ebb96d ("net: Clone skb before setting peeked flag")
2946 Reported-by: Brenden Blanco <bblanco@plumgrid.com>
2947 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2948 Tested-by: Brenden Blanco <bblanco@plumgrid.com>
2949 Reviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
2950 Signed-off-by: David S. Miller <davem@davemloft.net>
2951 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
2952
2953commit 6402732251519e7cc44949e7621cb24c8a3dd5dc
2954Author: Yinghai Lu <yinghai@kernel.org>
2955Date: Fri Sep 4 15:42:39 2015 -0700
2956
2957 mm: check if section present during memory block registering
2958
2959 [ Upstream commit 04697858d89e4bf2650364f8d6956e2554e8ef88 ]
2960
2961 Tony Luck found on his setup, if memory block size 512M will cause crash
2962 during booting.
2963
2964 BUG: unable to handle kernel paging request at ffffea0074000020
2965 IP: get_nid_for_pfn+0x17/0x40
2966 PGD 128ffcb067 PUD 128ffc9067 PMD 0
2967 Oops: 0000 [#1] SMP
2968 Modules linked in:
2969 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
2970 ...
2971 Call Trace:
2972 ? register_mem_sect_under_node+0x66/0xe0
2973 register_one_node+0x17b/0x240
2974 ? pci_iommu_alloc+0x6e/0x6e
2975 topology_init+0x3c/0x95
2976 do_one_initcall+0xcd/0x1f0
2977
2978 The system has non continuous RAM address:
2979 BIOS-e820: [mem 0x0000001300000000-0x0000001cffffffff] usable
2980 BIOS-e820: [mem 0x0000001d70000000-0x0000001ec7ffefff] usable
2981 BIOS-e820: [mem 0x0000001f00000000-0x0000002bffffffff] usable
2982 BIOS-e820: [mem 0x0000002c18000000-0x0000002d6fffefff] usable
2983 BIOS-e820: [mem 0x0000002e00000000-0x00000039ffffffff] usable
2984
2985 So there are start sections in memory block not present. For example:
2986
2987 memory block : [0x2c18000000, 0x2c20000000) 512M
2988
2989 first three sections are not present.
2990
2991 The current register_mem_sect_under_node() assume first section is
2992 present, but memory block section number range [start_section_nr,
2993 end_section_nr] would include not present section.
2994
2995 For arch that support vmemmap, we don't setup memmap for struct page
2996 area within not present sections area.
2997
2998 So skip the pfn range that belong to absent section.
2999
3000 [akpm@linux-foundation.org: simplification]
3001 [rientjes@google.com: more simplification]
3002 Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory x86-64 systems")
3003 Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
3004 Signed-off-by: Yinghai Lu <yinghai@kernel.org>
3005 Signed-off-by: David Rientjes <rientjes@google.com>
3006 Reported-by: Tony Luck <tony.luck@intel.com>
3007 Tested-by: Tony Luck <tony.luck@intel.com>
3008 Cc: Greg KH <greg@kroah.com>
3009 Cc: Ingo Molnar <mingo@elte.hu>
3010 Tested-by: David Rientjes <rientjes@google.com>
3011 Cc: <stable@vger.kernel.org> [3.15+]
3012 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3013 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
3014
3015 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3016
3017commit 49577c854b5dbf004acb57037596ab5b39c800aa
3018Author: Mikulas Patocka <mikulas@twibright.com>
3019Date: Wed Sep 2 22:51:53 2015 +0200
3020
3021 hpfs: update ctime and mtime on directory modification
3022
3023 [ Upstream commit f49a26e7718dd30b49e3541e3e25aecf5e7294e2 ]
3024
3025 Update ctime and mtime when a directory is modified. (though OS/2 doesn't
3026 update them anyway)
3027
3028 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
3029 Cc: stable@kernel.org # v3.3+
3030 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
3031 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3032
3033commit 84d2f08ca422687a306f31388c3cfda000eae355
3034Author: Grant Likely <grant.likely@linaro.org>
3035Date: Sun Jun 7 15:20:11 2015 +0100
3036
3037 drivercore: Fix unregistration path of platform devices
3038
3039 [ Upstream commit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 ]
3040
3041 The unregister path of platform_device is broken. On registration, it
3042 will register all resources with either a parent already set, or
3043 type==IORESOURCE_{IO,MEM}. However, on unregister it will release
3044 everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
3045 are also cases where resources don't get registered in the first place,
3046 like with devices created by of_platform_populate()*.
3047
3048 Fix the unregister path to be symmetrical with the register path by
3049 checking the parent pointer instead of the type field to decide which
3050 resources to unregister. This is safe because the upshot of the
3051 registration path algorithm is that registered resources have a parent
3052 pointer, and non-registered resources do not.
3053
3054 * It can be argued that of_platform_populate() should be registering
3055 it's resources, and they argument has some merit. However, there are
3056 quite a few platforms that end up broken if we try to do that due to
3057 overlapping resources in the device tree. Until that is fixed, we need
3058 to solve the immediate problem.
3059
3060 Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
3061 Cc: Wolfram Sang <wsa@the-dreams.de>
3062 Cc: Rob Herring <robh@kernel.org>
3063 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3064 Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
3065 Signed-off-by: Grant Likely <grant.likely@linaro.org>
3066 Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
3067 Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
3068 Cc: stable@vger.kernel.org
3069 Signed-off-by: Rob Herring <robh@kernel.org>
3070 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3071
3072commit ee491c0c341c43a9aac4a44255e8a801e8233955
3073Author: Vignesh R <vigneshr@ti.com>
3074Date: Wed Jun 3 17:21:20 2015 +0530
3075
3076 ARM: OMAP2+: DRA7: clockdomain: change l4per2_7xx_clkdm to SW_WKUP
3077
3078 [ Upstream commit b9e23f321940d2db2c9def8ff723b8464fb86343 ]
3079
3080 Legacy IPs like PWMSS, present under l4per2_7xx_clkdm, cannot support
3081 smart-idle when its clock domain is in HW_AUTO on DRA7 SoCs. Hence,
3082 program clock domain to SW_WKUP.
3083
3084 Signed-off-by: Vignesh R <vigneshr@ti.com>
3085 Acked-by: Tero Kristo <t-kristo@ti.com>
3086 Reviewed-by: Paul Walmsley <paul@pwsan.com>
3087 Signed-off-by: Paul Walmsley <paul@pwsan.com>
3088 Cc: <stable@vger.kernel.org>
3089 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3090
3091commit 6e95689dd460d525a65be7158f31f52323812654
3092Author: David Daney <david.daney@cavium.com>
3093Date: Wed Aug 19 13:17:47 2015 -0700
3094
3095 of/address: Don't loop forever in of_find_matching_node_by_address().
3096
3097 [ Upstream commit 3a496b00b6f90c41bd21a410871dfc97d4f3c7ab ]
3098
3099 If the internal call to of_address_to_resource() fails, we end up
3100 looping forever in of_find_matching_node_by_address(). This can be
3101 caused by a defective device tree, or calling with an incorrect
3102 matches argument.
3103
3104 Fix by calling of_find_matching_node() unconditionally at the end of
3105 the loop.
3106
3107 Signed-off-by: David Daney <david.daney@cavium.com>
3108 Cc: stable@vger.kernel.org
3109 Signed-off-by: Rob Herring <robh@kernel.org>
3110 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3111
3112commit e5c96a79865c62e593b41eb69153be15cc66b41e
3113Author: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
3114Date: Mon Jul 20 17:27:21 2015 +0530
3115
3116 auxdisplay: ks0108: fix refcount
3117
3118 [ Upstream commit bab383de3b84e584b0f09227151020b2a43dc34c ]
3119
3120 parport_find_base() will implicitly do parport_get_port() which
3121 increases the refcount. Then parport_register_device() will again
3122 increment the refcount. But while unloading the module we are only
3123 doing parport_unregister_device() decrementing the refcount only once.
3124 We add an parport_put_port() to neutralize the effect of
3125 parport_get_port().
3126
3127 Cc: <stable@vger.kernel.org> # 2.6.32+
3128 Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
3129 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3130 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3131
3132commit e451bf46db1a1fda75428c29de0137b20946580f
3133Author: Peter Chen <peter.chen@freescale.com>
3134Date: Fri Jul 31 16:36:29 2015 +0800
3135
3136 Doc: ABI: testing: configfs-usb-gadget-sourcesink
3137
3138 [ Upstream commit 4bc58eb16bb2352854b9c664cc36c1c68d2bfbb7 ]
3139
3140 Fix the name of attribute
3141
3142 Cc: <stable@vger.kernel.org>
3143 Signed-off-by: Peter Chen <peter.chen@freescale.com>
3144 Signed-off-by: Felipe Balbi <balbi@ti.com>
3145 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3146
3147commit 930acc5024169d705c7debdf5fa30a8e8ae84788
3148Author: Peter Chen <peter.chen@freescale.com>
3149Date: Fri Jul 31 16:36:28 2015 +0800
3150
3151 Doc: ABI: testing: configfs-usb-gadget-loopback
3152
3153 [ Upstream commit 8cd50626823c00ca7472b2f61cb8c0eb9798ddc0 ]
3154
3155 Fix the name of attribute
3156
3157 Cc: <stable@vger.kernel.org>
3158 Signed-off-by: Peter Chen <peter.chen@freescale.com>
3159 Signed-off-by: Felipe Balbi <balbi@ti.com>
3160 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3161
3162commit 5062f6012e4022cde01727b831454e981a070306
3163Author: Masahiro Yamada <yamada.masahiro@socionext.com>
3164Date: Wed Jul 15 10:29:00 2015 +0900
3165
3166 devres: fix devres_get()
3167
3168 [ Upstream commit 64526370d11ce8868ca495723d595b61e8697fbf ]
3169
3170 Currently, devres_get() passes devres_free() the pointer to devres,
3171 but devres_free() should be given with the pointer to resource data.
3172
3173 Fixes: 9ac7849e35f7 ("devres: device resource management")
3174 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
3175 Acked-by: Tejun Heo <tj@kernel.org>
3176 Cc: stable <stable@vger.kernel.org> # 2.6.21+
3177 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3178 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3179
3180commit 75f411869a2a2b72cadc077e1bf44338bb869d82
3181Author: Max Filippov <jcmvbkbc@gmail.com>
3182Date: Thu Jul 16 10:41:02 2015 +0300
3183
3184 xtensa: fix kernel register spilling
3185
3186 [ Upstream commit 77d6273e79e3a86552fcf10cdd31a69b46ed2ce6 ]
3187
3188 call12 can't be safely used as the first call in the inline function,
3189 because the compiler does not extend the stack frame of the bounding
3190 function accordingly, which may result in corruption of local variables.
3191
3192 If a call needs to be done, do call8 first followed by call12.
3193
3194 For pure assembly code in _switch_to increase stack frame size of the
3195 bounding function.
3196
3197 Cc: stable@vger.kernel.org
3198 Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
3199 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3200
3201commit 493c0e290d349e4821558a575061d98193ba5115
3202Author: Max Filippov <jcmvbkbc@gmail.com>
3203Date: Sat Jul 4 15:27:39 2015 +0300
3204
3205 xtensa: fix threadptr reload on return to userspace
3206
3207 [ Upstream commit 4229fb12a03e5da5882b420b0aa4a02e77447b86 ]
3208
3209 Userspace return code may skip restoring THREADPTR register if there are
3210 no registers that need to be zeroed. This leads to spurious failures in
3211 libc NPTL tests.
3212
3213 Always restore THREADPTR on return to userspace.
3214
3215 Cc: stable@vger.kernel.org
3216 Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
3217 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3218
3219commit 3d5f09649ae556201f93c1e4be967aaf2b920744
3220Author: Xiao Guangrong <guangrong.xiao@linux.intel.com>
3221Date: Wed Aug 5 12:04:19 2015 +0800
3222
3223 KVM: MMU: fix validation of mmio page fault
3224
3225 [ Upstream commit 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e ]
3226
3227 We got the bug that qemu complained with "KVM: unknown exit, hardware
3228 reason 31" and KVM shown these info:
3229 [84245.284948] EPT: Misconfiguration.
3230 [84245.285056] EPT: GPA: 0xfeda848
3231 [84245.285154] ept_misconfig_inspect_spte: spte 0x5eaef50107 level 4
3232 [84245.285344] ept_misconfig_inspect_spte: spte 0x5f5fadc107 level 3
3233 [84245.285532] ept_misconfig_inspect_spte: spte 0x5141d18107 level 2
3234 [84245.285723] ept_misconfig_inspect_spte: spte 0x52e40dad77 level 1
3235
3236 This is because we got a mmio #PF and the handler see the mmio spte becomes
3237 normal (points to the ram page)
3238
3239 However, this is valid after introducing fast mmio spte invalidation which
3240 increases the generation-number instead of zapping mmio sptes, a example
3241 is as follows:
3242 1. QEMU drops mmio region by adding a new memslot
3243 2. invalidate all mmio sptes
3244 3.
3245
3246 VCPU 0 VCPU 1
3247 access the invalid mmio spte
3248 access the region originally was MMIO before
3249 set the spte to the normal ram map
3250
3251 mmio #PF
3252 check the spte and see it becomes normal ram mapping !!!
3253
3254 This patch fixes the bug just by dropping the check in mmio handler, it's
3255 good for backport. Full check will be introduced in later patches
3256
3257 Reported-by: Pavel Shirshov <ru.pchel@gmail.com>
3258 Tested-by: Pavel Shirshov <ru.pchel@gmail.com>
3259 Signed-off-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
3260 Cc: stable@vger.kernel.org
3261 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
3262 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3263
3264commit 06cab2593619a6ed6fee26dbdd55fa521f14f9f0
3265Author: Don Zickus <dzickus@redhat.com>
3266Date: Mon Aug 10 12:06:53 2015 -0400
3267
3268 HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
3269
3270 [ Upstream commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d ]
3271
3272 It was reported that after 10-20 reboots, a usb keyboard plugged
3273 into a docking station would not work unless it was replugged in.
3274
3275 Using usbmon, it turns out the interrupt URBs were streaming with
3276 callback errors of -71 for some reason. The hid-core.c::hid_io_error was
3277 supposed to retry and then reset, but the reset wasn't really happening.
3278
3279 The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
3280
3281 Tested by reporter and locally by me by unplugging a keyboard halfway until I
3282 could recreate a stream of errors but no disconnect.
3283
3284 Signed-off-by: Don Zickus <dzickus@redhat.com>
3285 Cc: stable@vger.kernel.org
3286 Signed-off-by: Jiri Kosina <jkosina@suse.cz>
3287 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3288
3289commit d72174a6d7cbdf965458c586eb736e40bd81f215
3290Author: Andrey Ryabinin <aryabinin@odin.com>
3291Date: Thu Sep 3 14:32:01 2015 +0300
3292
3293 crypto: ghash-clmulni: specify context size for ghash async algorithm
3294
3295 [ Upstream commit 71c6da846be478a61556717ef1ee1cea91f5d6a8 ]
3296
3297 Currently context size (cra_ctxsize) doesn't specified for
3298 ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
3299 doesn't allocate needed space for ghash_async_ctx, so any
3300 read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.
3301
3302 Cc: stable@vger.kernel.org
3303 Signed-off-by: Andrey Ryabinin <aryabinin@odin.com>
3304 Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
3305 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3306
3307commit 0df02ec634dc9ace6854b1e11c692c116aaf35fe
3308Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
3309Date: Sun Aug 2 23:11:52 2015 +0200
3310
3311 serial: 8250: don't bind to SMSC IrCC IR port
3312
3313 [ Upstream commit ffa34de03bcfbfa88d8352942bc238bb48e94e2d ]
3314
3315 SMSC IrCC SIR/FIR port should not be bound to by
3316 (legacy) serial driver so its own driver (smsc-ircc2)
3317 can bind to it.
3318
3319 Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
3320 Cc: stable <stable@vger.kernel.org>
3321 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3322 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3323
3324commit 63bdd88aebe05c01c64bfce68ffeaf2697c7007d
3325Author: Peter Chen <peter.chen@freescale.com>
3326Date: Mon Aug 17 10:23:03 2015 +0800
3327
3328 usb: host: ehci-sys: delete useless bus_to_hcd conversion
3329
3330 [ Upstream commit 0521cfd06e1ebcd575e7ae36aab068b38df23850 ]
3331
3332 The ehci platform device's drvdata is the pointer of struct usb_hcd
3333 already, so we doesn't need to call bus_to_hcd conversion again.
3334
3335 Cc: <stable@vger.kernel.org>
3336 Signed-off-by: Peter Chen <peter.chen@freescale.com>
3337 Acked-by: Alan Stern <stern@rowland.harvard.edu>
3338 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3339 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3340
3341commit 2c9fef0a33b224c6e3b9083d6b3ac1966f5e5df2
3342Author: Kishon Vijay Abraham I <kishon@ti.com>
3343Date: Mon Jul 27 12:25:27 2015 +0530
3344
3345 usb: dwc3: ep0: Fix mem corruption on OUT transfers of more than 512 bytes
3346
3347 [ Upstream commit b2fb5b1a0f50d3ebc12342c8d8dead245e9c9d4e ]
3348
3349 DWC3 uses bounce buffer to handle non max packet aligned OUT transfers and
3350 the size of bounce buffer is 512 bytes. However if the host initiates OUT
3351 transfers of size more than 512 bytes (and non max packet aligned), the
3352 driver throws a WARN dump but still programs the TRB to receive more than
3353 512 bytes. This will cause bounce buffer to overflow and corrupt the
3354 adjacent memory locations which can be fatal.
3355
3356 Fix it by programming the TRB to receive a maximum of DWC3_EP0_BOUNCE_SIZE
3357 (512) bytes.
3358
3359 Cc: <stable@vger.kernel.org> # 3.4+
3360 Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
3361 Signed-off-by: Felipe Balbi <balbi@ti.com>
3362 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3363
3364commit a3c1260650e176f211f9cbc1cfc8cbad570784dd
3365Author: Matthijs Kooijman <matthijs@stdin.nl>
3366Date: Tue Aug 18 10:33:56 2015 +0200
3367
3368 USB: ftdi_sio: Added custom PID for CustomWare products
3369
3370 [ Upstream commit 1fb8dc36384ae1140ee6ccc470de74397606a9d5 ]
3371
3372 CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
3373 products.
3374
3375 Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl>
3376 Cc: stable <stable@vger.kernel.org>
3377 Signed-off-by: Johan Hovold <johan@kernel.org>
3378 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3379 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3380
3381commit 2d2438f4ad4f57732fc2c44380c95ad5955984d2
3382Author: Philipp Hachtmann <hachti@hachti.de>
3383Date: Mon Aug 17 17:31:46 2015 +0200
3384
3385 USB: symbolserial: Use usb_get_serial_port_data
3386
3387 [ Upstream commit 951d3793bbfc0a441d791d820183aa3085c83ea9 ]
3388
3389 The driver used usb_get_serial_data(port->serial) which compiled but resulted
3390 in a NULL pointer being returned (and subsequently used). I did not go deeper
3391 into this but I guess this is a regression.
3392
3393 Signed-off-by: Philipp Hachtmann <hachti@hachti.de>
3394 Fixes: a85796ee5149 ("USB: symbolserial: move private-data allocation to
3395 port_probe")
3396 Cc: stable <stable@vger.kernel.org> # v3.10
3397 Acked-by: Johan Hovold <johan@kernel.org>
3398 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3399
3400 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3401
3402commit 28fe0e4f55fd669f5f629bc763d3b8cf399e2467
3403Author: Bjorn Helgaas <bhelgaas@google.com>
3404Date: Fri Jun 19 15:58:24 2015 -0500
3405
3406 PCI: Fix TI816X class code quirk
3407
3408 [ Upstream commit d1541dc977d376406f4584d8eb055488655c98ec ]
3409
3410 In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
3411 But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
3412 and needs to be shifted to make space for the low-order interface byte.
3413
3414 Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.
3415
3416 Fixes: 63c4408074cb ("PCI: Add quirk for setting valid class for TI816X Endpoint")
3417 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
3418 CC: Hemant Pedanekar <hemantp@ti.com>
3419 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3420
3421commit 63f29ebd76d06f0eadd2de6987b94bfb86ca7dab
3422Author: Dan Carpenter <dan.carpenter@oracle.com>
3423Date: Wed Jul 29 13:17:06 2015 +0300
3424
3425 clk: versatile: off by one in clk_sp810_timerclken_of_get()
3426
3427 [ Upstream commit 3294bee87091be5f179474f6c39d1d87769635e2 ]
3428
3429 The ">" should be ">=" or we end up reading beyond the end of the array.
3430
3431 Fixes: 6e973d2c4385 ('clk: vexpress: Add separate SP810 driver')
3432 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
3433 Acked-by: Pawel Moll <pawel.moll@arm.com>
3434 Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
3435 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3436
3437commit 25eabc9328cbd27e52d20010682151f0493cd0c8
3438Author: Ian Abbott <abbotti@mev.co.uk>
3439Date: Tue Aug 11 13:05:10 2015 +0100
3440
3441 staging: comedi: adl_pci7x3x: fix digital output on PCI-7230
3442
3443 [ Upstream commit ad83dbd974feb2e2a8cc071a1d28782bd4d2c70e ]
3444
3445 The "adl_pci7x3x" driver replaced the "adl_pci7230" and "adl_pci7432"
3446 drivers in commits 8f567c373c4b ("staging: comedi: new adl_pci7x3x
3447 driver") and 657f77d173d3 ("staging: comedi: remove adl_pci7230 and
3448 adl_pci7432 drivers"). Although the new driver code agrees with the
3449 user manuals for the respective boards, digital outputs stopped working
3450 on the PCI-7230. This has 16 digital output channels and the previous
3451 adl_pci7230 driver shifted the 16 bit output state left by 16 bits
3452 before writing to the hardware register. The new adl_pci7x3x driver
3453 doesn't do that. Fix it in `adl_pci7x3x_do_insn_bits()` by checking
3454 for the special case of the subdevice having only 16 channels and
3455 duplicating the 16 bit output state into both halves of the 32-bit
3456 register. That should work both for what the board actually does and
3457 for what the user manual says it should do.
3458
3459 Fixes: 8f567c373c4b ("staging: comedi: new adl_pci7x3x driver")
3460 Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
3461 Cc: <stable@vger.kernel.org> # 3.13+, needs backporting for 3.7 to 3.12
3462 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3463 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3464
3465commit f452eb1887c18b83ea991781c413cf9e88a86863
3466Author: Lars-Peter Clausen <lars@metafoo.de>
3467Date: Wed Aug 5 15:38:15 2015 +0200
3468
3469 iio: adis16480: Fix scale factors
3470
3471 [ Upstream commit 7abad1063deb0f77d275c61f58863ec319c58c5c ]
3472
3473 The different devices support by the adis16480 driver have slightly
3474 different scales for the gyroscope and accelerometer channels.
3475
3476 Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
3477 Cc: <Stable@vger.kernel.org>
3478 Signed-off-by: Jonathan Cameron <jic23@kernel.org>
3479 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3480
3481commit 12958c6062a0075074e16131ef4837cfecc3b8de
3482Author: Lars-Peter Clausen <lars@metafoo.de>
3483Date: Wed Aug 5 15:38:14 2015 +0200
3484
3485 iio: Add inverse unit conversion macros
3486
3487 [ Upstream commit c689a923c867eac40ed3826c1d9328edea8b6bc7 ]
3488
3489 Add inverse unit conversion macro to convert from standard IIO units to
3490 units that might be used by some devices.
3491
3492 Those are useful in combination with scale factors that are specified as
3493 IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will
3494 contain the maximum raw value the sensor will generate and the numerator
3495 the value it maps to in a specific unit. Sometimes datasheets specify those
3496 in different units than the standard IIO units (e.g. degree/s instead of
3497 rad/s) and so we need to do a unit conversion.
3498
3499 From a mathematical point of view it does not make a difference whether we
3500 apply the unit conversion to the numerator or the inverse unit conversion
3501 to the denominator since (x / y) / z = x / (y * z). But as the denominator
3502 is typically a larger value and we are rounding both the numerator and
3503 denominator to integer values using the later method gives us a better
3504 precision (E.g. the relative error is smaller if we round 8000.3 to 8000
3505 rather than rounding 8.3 to 8).
3506
3507 This is where in inverse unit conversion macros will be used.
3508
3509 Marked for stable as used by some upcoming fixes.
3510
3511 Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
3512 Cc: <Stable@vger.kernel.org>
3513 Signed-off-by: Jonathan Cameron <jic23@kernel.org>
3514 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3515
3516commit 32163777a11a84449114c304848a884f3f5ed887
3517Author: Cristina Opriceana <cristina.opriceana@gmail.com>
3518Date: Mon Aug 3 13:37:40 2015 +0300
3519
3520 iio: industrialio-buffer: Fix iio_buffer_poll return value
3521
3522 [ Upstream commit 1bdc0293901cbea23c6dc29432e81919d4719844 ]
3523
3524 Change return value to 0 if no device is bound since
3525 unsigned int cannot support negative error codes.
3526
3527 Fixes: f18e7a068 ("iio: Return -ENODEV for file operations if the
3528 device has been unregistered")
3529
3530 Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
3531 Cc: <Stable@vger.kernel.org>
3532 Signed-off-by: Jonathan Cameron <jic23@kernel.org>
3533 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3534
3535commit 1c979a10452b6bb7b22a3756fa0b374720179543
3536Author: Cristina Opriceana <cristina.opriceana@gmail.com>
3537Date: Mon Aug 3 13:00:47 2015 +0300
3538
3539 iio: event: Remove negative error code from iio_event_poll
3540
3541 [ Upstream commit 41d903c00051d8f31c98a8136edbac67e6f8688f ]
3542
3543 Negative return values are not supported by iio_event_poll since
3544 its return type is unsigned int.
3545
3546 Fixes: f18e7a068a0a3 ("iio: Return -ENODEV for file operations if the device has been unregistered")
3547
3548 Signed-off-by: Cristina Opriceana <cristina.opriceana@gmail.com>
3549 Cc: <Stable@vger.kernel.org>
3550 Signed-off-by: Jonathan Cameron <jic23@kernel.org>
3551 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3552
3553commit 0b7a7c0416bd481cb4c9e10cca496f3b1dc56c35
3554Author: Markus Pargmann <mpa@pengutronix.de>
3555Date: Wed Jul 29 15:46:03 2015 +0200
3556
3557 iio: bmg160: IIO_BUFFER and IIO_TRIGGERED_BUFFER are required
3558
3559 [ Upstream commit 06d2f6ca5a38abe92f1f3a132b331eee773868c3 ]
3560
3561 This patch adds selects for IIO_BUFFER and IIO_TRIGGERED_BUFFER. Without
3562 IIO_BUFFER, the driver does not compile.
3563
3564 Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
3565 Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
3566 Cc: <Stable@vger.kernel.org>
3567 Signed-off-by: Jonathan Cameron <jic23@kernel.org>
3568 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3569
3570commit a03140d0a726899c457fe95b81dfd2bd49d967f4
3571Author: Sebastian Ott <sebott@linux.vnet.ibm.com>
3572Date: Thu Jun 25 09:32:22 2015 +0200
3573
3574 s390/sclp: fix compile error
3575
3576 [ Upstream commit a313bdc5310dd807655d3ca3eb2219cd65dfe45a ]
3577
3578 Fix this error when compiling with CONFIG_SMP=n and
3579 CONFIG_DYNAMIC_DEBUG=y:
3580
3581 drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early':
3582 drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function)
3583 } while (rc == -EBUSY);
3584 ^
3585
3586 Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
3587 Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
3588 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3589
3590commit 510b6c73f2ba293b6c69af9353f6989bbd213e19
3591Author: Jonathon Jongsma <jjongsma@redhat.com>
3592Date: Thu Aug 20 14:04:32 2015 -0500
3593
3594 drm/qxl: validate monitors config modes
3595
3596 [ Upstream commit bd3e1c7c6de9f5f70d97cdb6c817151c0477c5e3 ]
3597
3598 Due to some recent changes in
3599 drm_helper_probe_single_connector_modes_merge_bits(), old custom modes
3600 were not being pruned properly. In current kernels,
3601 drm_mode_validate_basic() is called to sanity-check each mode in the
3602 list. If the sanity-check passes, the mode's status gets set to to
3603 MODE_OK. In older kernels this check was not done, so old custom modes
3604 would still have a status of MODE_UNVERIFIED at this point, and would
3605 therefore be pruned later in the function.
3606
3607 As a result of this new behavior, the list of modes for a device always
3608 includes every custom mode ever configured for the device, with the
3609 largest one listed first. Since desktop environments usually choose the
3610 first preferred mode when a hotplug event is emitted, this had the
3611 result of making it very difficult for the user to reduce the size of
3612 the display.
3613
3614 The qxl driver did implement the mode_valid connector function, but it
3615 was empty. In order to restore the old behavior where old custom modes
3616 are pruned, we implement a proper mode_valid function for the qxl
3617 driver. This function now checks each mode against the last configured
3618 custom mode and the list of standard modes. If the mode doesn't match
3619 any of these, its status is set to MODE_BAD so that it will be pruned as
3620 expected.
3621
3622 Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
3623 Cc: stable@vger.kernel.org
3624 Signed-off-by: Dave Airlie <airlied@redhat.com>
3625 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3626
3627commit 97c4f73e690d584945ace96f2dc10ebae63a2180
3628Author: Stephen Chandler Paul <cpaul@redhat.com>
3629Date: Fri Aug 21 14:16:12 2015 -0400
3630
3631 drm/amdgpu: Don't link train DisplayPort on HPD until we get the dpcd
3632
3633 [ Upstream commit a887adadb7b9ef9eb4ee48e4ad575aefcfd1db14 ]
3634
3635 This is a port of:
3636 DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd
3637 to amdgpu.
3638
3639 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
3640 Cc: stable@vger.kernel.org
3641 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3642
3643commit 2c8818052d31bdc57b78ccbdbc1298479bc80d51
3644Author: Joonsoo Kim <js1304@gmail.com>
3645Date: Thu Oct 1 15:36:54 2015 -0700
3646
3647 mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1)
3648
3649 [ Upstream commit 03a2d2a3eafe4015412cf4e9675ca0e2d9204074 ]
3650
3651 Commit description is copied from the original post of this bug:
3652
3653 http://comments.gmane.org/gmane.linux.kernel.mm/135349
3654
3655 Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next
3656 larger cache size than the size index INDEX_NODE mapping. In kernels
3657 3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.
3658
3659 However, sometimes we can't get the right output we expected via
3660 kmalloc_size(INDEX_NODE + 1), causing a BUG().
3661
3662 The mapping table in the latest kernel is like:
3663 index = {0, 1, 2 , 3, 4, 5, 6, n}
3664 size = {0, 96, 192, 8, 16, 32, 64, 2^n}
3665 The mapping table before 3.10 is like this:
3666 index = {0 , 1 , 2, 3, 4 , 5 , 6, n}
3667 size = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}
3668
3669 The problem on my mips64 machine is as follows:
3670
3671 (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
3672 && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
3673 and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
3674 kmalloc_index(sizeof(struct kmem_cache_node))
3675
3676 (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.
3677
3678 (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
3679 = PAGE_SIZE".
3680
3681 (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
3682 "flags |= CFLGS_OFF_SLAB" will be covered.
3683
3684 (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
3685 "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
3686 here may be NULL while kernel bootup.
3687
3688 (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
3689 BUG info as the following shows (may be only mips64 has this problem):
3690
3691 This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes
3692 the BUG by adding 'size >= 256' check to guarantee that all necessary
3693 small sized slabs are initialized regardless sequence of slab size in
3694 mapping table.
3695
3696 Fixes: e33660165c90 ("slab: Use common kmalloc_index/kmalloc_size...")
3697 Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
3698 Reported-by: Liuhailong <liu.hailong6@zte.com.cn>
3699 Acked-by: Christoph Lameter <cl@linux.com>
3700 Cc: Pekka Enberg <penberg@kernel.org>
3701 Cc: David Rientjes <rientjes@google.com>
3702 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
3703 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
3704 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3705
3706commit e3c2669ff76d4636d41907f08a31129cb2e02eac
3707Author: Prarit Bhargava <prarit@redhat.com>
3708Date: Mon Jun 15 13:43:29 2015 -0400
3709
3710 intel_pstate: Fix overflow in busy_scaled due to long delay
3711
3712 [ Upstream commit 7180dddf7c32c49975c7e7babf2b60ed450cb760 ]
3713
3714 The kernel may delay interrupts for a long time which can result in timers
3715 being delayed. If this occurs the intel_pstate driver will crash with a
3716 divide by zero error:
3717
3718 divide error: 0000 [#1] SMP
3719 Modules linked in: btrfs zlib_deflate raid6_pq xor msdos ext4 mbcache jbd2 binfmt_misc arc4 md4 nls_utf8 cifs dns_resolver tcp_lp bnep bluetooth rfkill fuse dm_service_time iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ftp ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables intel_powerclamp coretemp vfat fat kvm_intel iTCO_wdt iTCO_vendor_support ipmi_devintf sr_mod kvm crct10dif_pclmul
3720 crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel cdc_ether lrw usbnet cdrom mii gf128mul glue_helper ablk_helper cryptd lpc_ich mfd_core pcspkr sb_edac edac_core ipmi_si ipmi_msghandler ioatdma wmi shpchp acpi_pad nfsd auth_rpcgss nfs_acl lockd uinput dm_multipath sunrpc xfs libcrc32c usb_storage sd_mod crc_t10dif crct10dif_common ixgbe mgag200 syscopyarea sysfillrect sysimgblt mdio drm_kms_helper ttm igb drm ptp pps_core dca i2c_algo_bit megaraid_sas i2c_core dm_mirror dm_region_hash dm_log dm_mod
3721 CPU: 113 PID: 0 Comm: swapper/113 Tainted: G W -------------- 3.10.0-229.1.2.el7.x86_64 #1
3722 Hardware name: IBM x3950 X6 -[3837AC2]-/00FN827, BIOS -[A8E112BUS-1.00]- 08/27/2014
3723 task: ffff880fe8abe660 ti: ffff880fe8ae4000 task.ti: ffff880fe8ae4000
3724 RIP: 0010:[<ffffffff814a9279>] [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0
3725 RSP: 0018:ffff883fff4e3db8 EFLAGS: 00010206
3726 RAX: 0000000027100000 RBX: ffff883fe6965100 RCX: 0000000000000000
3727 RDX: 0000000000000000 RSI: 0000000000000010 RDI: 000000002e53632d
3728 RBP: ffff883fff4e3e20 R08: 000e6f69a5a125c0 R09: ffff883fe84ec001
3729 R10: 0000000000000002 R11: 0000000000000005 R12: 00000000000049f5
3730 R13: 0000000000271000 R14: 00000000000049f5 R15: 0000000000000246
3731 FS: 0000000000000000(0000) GS:ffff883fff4e0000(0000) knlGS:0000000000000000
3732 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
3733 CR2: 00007f7668601000 CR3: 000000000190a000 CR4: 00000000001407e0
3734 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
3735 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
3736 Stack:
3737 ffff883fff4e3e58 ffffffff81099dc1 0000000000000086 0000000000000071
3738 ffff883fff4f3680 0000000000000071 fbdc8a965e33afee ffffffff810b69dd
3739 ffff883fe84ec000 ffff883fe6965108 0000000000000100 ffffffff814a9100
3740 Call Trace:
3741 <IRQ>
3742
3743 [<ffffffff81099dc1>] ? run_posix_cpu_timers+0x51/0x840
3744 [<ffffffff810b69dd>] ? trigger_load_balance+0x5d/0x200
3745 [<ffffffff814a9100>] ? pid_param_set+0x130/0x130
3746 [<ffffffff8107df56>] call_timer_fn+0x36/0x110
3747 [<ffffffff814a9100>] ? pid_param_set+0x130/0x130
3748 [<ffffffff8107fdcf>] run_timer_softirq+0x21f/0x320
3749 [<ffffffff81077b2f>] __do_softirq+0xef/0x280
3750 [<ffffffff816156dc>] call_softirq+0x1c/0x30
3751 [<ffffffff81015d95>] do_softirq+0x65/0xa0
3752 [<ffffffff81077ec5>] irq_exit+0x115/0x120
3753 [<ffffffff81616355>] smp_apic_timer_interrupt+0x45/0x60
3754 [<ffffffff81614a1d>] apic_timer_interrupt+0x6d/0x80
3755 <EOI>
3756
3757 [<ffffffff814a9c32>] ? cpuidle_enter_state+0x52/0xc0
3758 [<ffffffff814a9c28>] ? cpuidle_enter_state+0x48/0xc0
3759 [<ffffffff814a9d65>] cpuidle_idle_call+0xc5/0x200
3760 [<ffffffff8101d14e>] arch_cpu_idle+0xe/0x30
3761 [<ffffffff810c67c1>] cpu_startup_entry+0xf1/0x290
3762 [<ffffffff8104228a>] start_secondary+0x1ba/0x230
3763 Code: 42 0f 00 45 89 e6 48 01 c2 43 8d 44 6d 00 39 d0 73 26 49 c1 e5 08 89 d2 4d 63 f4 49 63 c5 48 c1 e2 08 48 c1 e0 08 48 63 ca 48 99 <48> f7 f9 48 98 4c 0f af f0 49 c1 ee 08 8b 43 78 c1 e0 08 44 29
3764 RIP [<ffffffff814a9279>] intel_pstate_timer_func+0x179/0x3d0
3765 RSP <ffff883fff4e3db8>
3766
3767 The kernel values for cpudata for CPU 113 were:
3768
3769 struct cpudata {
3770 cpu = 113,
3771 timer = {
3772 entry = {
3773 next = 0x0,
3774 prev = 0xdead000000200200
3775 },
3776 expires = 8357799745,
3777 base = 0xffff883fe84ec001,
3778 function = 0xffffffff814a9100 <intel_pstate_timer_func>,
3779 data = 18446612406765768960,
3780 <snip>
3781 i_gain = 0,
3782 d_gain = 0,
3783 deadband = 0,
3784 last_err = 22489
3785 },
3786 last_sample_time = {
3787 tv64 = 4063132438017305
3788 },
3789 prev_aperf = 287326796397463,
3790 prev_mperf = 251427432090198,
3791 sample = {
3792 core_pct_busy = 23081,
3793 aperf = 2937407,
3794 mperf = 3257884,
3795 freq = 2524484,
3796 time = {
3797 tv64 = 4063149215234118
3798 }
3799 }
3800 }
3801
3802 which results in the time between samples = last_sample_time - sample.time
3803 = 4063149215234118 - 4063132438017305 = 16777216813 which is 16.777 seconds.
3804
3805 The duration between reads of the APERF and MPERF registers overflowed a s32
3806 sized integer in intel_pstate_get_scaled_busy()'s call to div_fp(). The result
3807 is that int_tofp(duration_us) == 0, and the kernel attempts to divide by 0.
3808
3809 While the kernel shouldn't be delaying for a long time, it can and does
3810 happen and the intel_pstate driver should not panic in this situation. This
3811 patch changes the div_fp() function to use div64_s64() to allow for "long"
3812 division. This will avoid the overflow condition on long delays.
3813
3814 [v2]: use div64_s64() in div_fp()
3815
3816 Signed-off-by: Prarit Bhargava <prarit@redhat.com>
3817 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
3818 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3819
3820commit e892880767a6dacbbc53841bfe4b7c38b90f3a52
3821Author: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
3822Date: Fri Oct 2 08:27:05 2015 +0000
3823
3824 tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c
3825
3826 [ Upstream commit e81107d4c6bd098878af9796b24edc8d4a9524fd ]
3827
3828 My colleague ran into a program stall on a x86_64 server, where
3829 n_tty_read() was waiting for data even if there was data in the buffer
3830 in the pty. kernel stack for the stuck process looks like below.
3831 #0 [ffff88303d107b58] __schedule at ffffffff815c4b20
3832 #1 [ffff88303d107bd0] schedule at ffffffff815c513e
3833 #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
3834 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
3835 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
3836 #5 [ffff88303d107dd0] tty_read at ffffffff81368013
3837 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
3838 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
3839 #8 [ffff88303d107f00] sys_read at ffffffff811a4306
3840 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7
3841
3842 There seems to be two problems causing this issue.
3843
3844 First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
3845 updates ldata->commit_head using smp_store_release() and then checks
3846 the wait queue using waitqueue_active(). However, since there is no
3847 memory barrier, __receive_buf() could return without calling
3848 wake_up_interactive_poll(), and at the same time, n_tty_read() could
3849 start to wait in wait_woken() as in the following chart.
3850
3851 __receive_buf() n_tty_read()
3852 ------------------------------------------------------------------------
3853 if (waitqueue_active(&tty->read_wait))
3854 /* Memory operations issued after the
3855 RELEASE may be completed before the
3856 RELEASE operation has completed */
3857 add_wait_queue(&tty->read_wait, &wait);
3858 ...
3859 if (!input_available_p(tty, 0)) {
3860 smp_store_release(&ldata->commit_head,
3861 ldata->read_head);
3862 ...
3863 timeout = wait_woken(&wait,
3864 TASK_INTERRUPTIBLE, timeout);
3865 ------------------------------------------------------------------------
3866
3867 The second problem is that n_tty_read() also lacks a memory barrier
3868 call and could also cause __receive_buf() to return without calling
3869 wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
3870 as in the chart below.
3871
3872 __receive_buf() n_tty_read()
3873 ------------------------------------------------------------------------
3874 spin_lock_irqsave(&q->lock, flags);
3875 /* from add_wait_queue() */
3876 ...
3877 if (!input_available_p(tty, 0)) {
3878 /* Memory operations issued after the
3879 RELEASE may be completed before the
3880 RELEASE operation has completed */
3881 smp_store_release(&ldata->commit_head,
3882 ldata->read_head);
3883 if (waitqueue_active(&tty->read_wait))
3884 __add_wait_queue(q, wait);
3885 spin_unlock_irqrestore(&q->lock,flags);
3886 /* from add_wait_queue() */
3887 ...
3888 timeout = wait_woken(&wait,
3889 TASK_INTERRUPTIBLE, timeout);
3890 ------------------------------------------------------------------------
3891
3892 There are also other places in drivers/tty/n_tty.c which have similar
3893 calls to waitqueue_active(), so instead of adding many memory barrier
3894 calls, this patch simply removes the call to waitqueue_active(),
3895 leaving just wake_up*() behind.
3896
3897 This fixes both problems because, even though the memory access before
3898 or after the spinlocks in both wake_up*() and add_wait_queue() can
3899 sneak into the critical section, it cannot go past it and the critical
3900 section assures that they will be serialized (please see "INTER-CPU
3901 ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
3902 better explanation). Moreover, the resulting code is much simpler.
3903
3904 Latency measurement using a ping-pong test over a pty doesn't show any
3905 visible performance drop.
3906
3907 Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
3908 Cc: stable@vger.kernel.org
3909 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3910 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3911
3912commit ae7799addbd7e6830e613e252009bb07a43ec52d
3913Author: covici@ccs.covici.com <covici@ccs.covici.com>
3914Date: Wed May 20 05:44:11 2015 -0400
3915
3916 staging: speakup: fix speakup-r regression
3917
3918 [ Upstream commit b1d562acc78f0af46de0dfe447410bc40bdb7ece ]
3919
3920 Here is a patch to make speakup-r work again.
3921
3922 It broke in 3.6 due to commit 4369c64c79a22b98d3b7eff9d089196cd878a10a
3923 "Input: Send events one packet at a time)
3924
3925 The problem was that the fakekey.c routine to fake a down arrow no
3926 longer functioned properly and putting the input_sync fixed it.
3927
3928 Fixes: 4369c64c79a22b98d3b7eff9d089196cd878a10a
3929 Cc: stable <stable@vger.kernel.org>
3930 Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
3931 Signed-off-by: John Covici <covici@ccs.covici.com>
3932 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3933 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3934
3935commit 5db13a87a598b3b8045a11658686feb3f689826a
3936Author: Joe Thornber <ejt@redhat.com>
3937Date: Fri Oct 9 14:03:38 2015 +0100
3938
3939 dm cache: fix NULL pointer when switching from cleaner policy
3940
3941 [ Upstream commit 2bffa1503c5c06192eb1459180fac4416575a966 ]
3942
3943 The cleaner policy doesn't make use of the per cache block hint space in
3944 the metadata (unlike the other policies). When switching from the
3945 cleaner policy to mq or smq a NULL pointer crash (in dm_tm_new_block)
3946 was observed. The crash was caused by bugs in dm-cache-metadata.c
3947 when trying to skip creation of the hint btree.
3948
3949 The minimal fix is to change hint size for the cleaner policy to 4 bytes
3950 (only hint size supported).
3951
3952 Signed-off-by: Joe Thornber <ejt@redhat.com>
3953 Signed-off-by: Mike Snitzer <snitzer@redhat.com>
3954 Cc: stable@vger.kernel.org
3955 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3956
3957commit 4af768733ce0fb8f8a6788791471375c0ac3aba7
3958Author: Ben Dooks <ben.dooks@codethink.co.uk>
3959Date: Tue Sep 29 15:01:08 2015 +0100
3960
3961 clk: ti: fix dual-registration of uart4_ick
3962
3963 [ Upstream commit 19e79687de22f23bcfb5e79cce3daba20af228d1 ]
3964
3965 On the OMAP AM3517 platform the uart4_ick gets registered
3966 twice, causing any power management to /dev/ttyO3 to fail
3967 when trying to wake the device up.
3968
3969 This solves the following oops:
3970
3971 [] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
3972 [] PC is at serial_omap_pm+0x48/0x15c
3973 [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
3974
3975 Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file")
3976 Cc: stable@vger.kernel.org
3977 Cc: mturquette@baylibre.com
3978 Cc: sboyd@codeaurora.org
3979 Cc: linux-clk@vger.kernel.org
3980 Cc: linux-omap@vger.kernel.org
3981 Cc: linux-kernel@lists.codethink.co.uk
3982 Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
3983 Signed-off-by: Tero Kristo <t-kristo@ti.com>
3984 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
3985
3986commit 9d8248b629a7f2fb16802b09fb6dfb6bc862e460
3987Author: Kinglong Mee <kinglongmee@gmail.com>
3988Date: Mon Sep 14 20:12:21 2015 +0800
3989
3990 nfs/filelayout: Fix NULL reference caused by double freeing of fh_array
3991
3992 [ Upstream commit 3ec0c97959abff33a42db9081c22132bcff5b4f2 ]
3993
3994 If filelayout_decode_layout fail, _filelayout_free_lseg will causes
3995 a double freeing of fh_array.
3996
3997 [ 1179.279800] BUG: unable to handle kernel NULL pointer dereference at (null)
3998 [ 1179.280198] IP: [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
3999 [ 1179.281010] PGD 0
4000 [ 1179.281443] Oops: 0000 [#1]
4001 [ 1179.281831] Modules linked in: nfs_layout_nfsv41_files(OE) nfsv4(OE) nfs(OE) fscache(E) xfs libcrc32c coretemp nfsd crct10dif_pclmul ppdev crc32_pclmul crc32c_intel auth_rpcgss ghash_clmulni_intel nfs_acl lockd vmw_balloon grace sunrpc parport_pc vmw_vmci parport shpchp i2c_piix4 vmwgfx drm_kms_helper ttm drm serio_raw mptspi scsi_transport_spi mptscsih e1000 mptbase ata_generic pata_acpi [last unloaded: fscache]
4002 [ 1179.283891] CPU: 0 PID: 13336 Comm: cat Tainted: G OE 4.3.0-rc1-pnfs+ #244
4003 [ 1179.284323] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
4004 [ 1179.285206] task: ffff8800501d48c0 ti: ffff88003e3c4000 task.ti: ffff88003e3c4000
4005 [ 1179.285668] RIP: 0010:[<ffffffffa027222d>] [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
4006 [ 1179.286612] RSP: 0018:ffff88003e3c77f8 EFLAGS: 00010202
4007 [ 1179.287092] RAX: 0000000000000000 RBX: ffff88001fe78900 RCX: 0000000000000000
4008 [ 1179.287731] RDX: ffffea0000f40760 RSI: ffff88001fe789c8 RDI: ffff88001fe789c0
4009 [ 1179.288383] RBP: ffff88003e3c7810 R08: ffffea0000f40760 R09: 0000000000000000
4010 [ 1179.289170] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001fe789c8
4011 [ 1179.289959] R13: ffff88001fe789c0 R14: ffff88004ec05a80 R15: ffff88004f935b88
4012 [ 1179.290791] FS: 00007f4e66bb5700(0000) GS:ffffffff81c29000(0000) knlGS:0000000000000000
4013 [ 1179.291580] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
4014 [ 1179.292209] CR2: 0000000000000000 CR3: 00000000203f8000 CR4: 00000000001406f0
4015 [ 1179.292731] Stack:
4016 [ 1179.293195] ffff88001fe78900 00000000000000d0 ffff88001fe78178 ffff88003e3c7868
4017 [ 1179.293676] ffffffffa0272737 0000000000000001 0000000000000001 ffff88001fe78800
4018 [ 1179.294151] 00000000614fffce ffffffff81727671 ffff88001fe78100 ffff88001fe78100
4019 [ 1179.294623] Call Trace:
4020 [ 1179.295092] [<ffffffffa0272737>] filelayout_alloc_lseg+0xa7/0x2d0 [nfs_layout_nfsv41_files]
4021 [ 1179.295625] [<ffffffff81727671>] ? out_of_line_wait_on_bit+0x81/0xb0
4022 [ 1179.296133] [<ffffffffa040407e>] pnfs_layout_process+0xae/0x320 [nfsv4]
4023 [ 1179.296632] [<ffffffffa03e0a01>] nfs4_proc_layoutget+0x2b1/0x360 [nfsv4]
4024 [ 1179.297134] [<ffffffffa0402983>] pnfs_update_layout+0x853/0xb30 [nfsv4]
4025 [ 1179.297632] [<ffffffffa039db24>] ? nfs_get_lock_context+0x74/0x170 [nfs]
4026 [ 1179.298158] [<ffffffffa0271807>] filelayout_pg_init_read+0x37/0x50 [nfs_layout_nfsv41_files]
4027 [ 1179.298834] [<ffffffffa03a72d9>] __nfs_pageio_add_request+0x119/0x460 [nfs]
4028 [ 1179.299385] [<ffffffffa03a6bd7>] ? nfs_create_request.part.9+0x37/0x2e0 [nfs]
4029 [ 1179.299872] [<ffffffffa03a7cc3>] nfs_pageio_add_request+0xa3/0x1b0 [nfs]
4030 [ 1179.300362] [<ffffffffa03a8635>] readpage_async_filler+0x85/0x260 [nfs]
4031 [ 1179.300907] [<ffffffff81180cb1>] read_cache_pages+0x91/0xd0
4032 [ 1179.301391] [<ffffffffa03a85b0>] ? nfs_read_completion+0x220/0x220 [nfs]
4033 [ 1179.301867] [<ffffffffa03a8dc8>] nfs_readpages+0x128/0x200 [nfs]
4034 [ 1179.302330] [<ffffffff81180ef3>] __do_page_cache_readahead+0x203/0x280
4035 [ 1179.302784] [<ffffffff81180dc8>] ? __do_page_cache_readahead+0xd8/0x280
4036 [ 1179.303413] [<ffffffff81181116>] ondemand_readahead+0x1a6/0x2f0
4037 [ 1179.303855] [<ffffffff81181371>] page_cache_sync_readahead+0x31/0x50
4038 [ 1179.304286] [<ffffffff811750a6>] generic_file_read_iter+0x4a6/0x5c0
4039 [ 1179.304711] [<ffffffffa03a0316>] ? __nfs_revalidate_mapping+0x1f6/0x240 [nfs]
4040 [ 1179.305132] [<ffffffffa039ccf2>] nfs_file_read+0x52/0xa0 [nfs]
4041 [ 1179.305540] [<ffffffff811e343c>] __vfs_read+0xcc/0x100
4042 [ 1179.305936] [<ffffffff811e3d15>] vfs_read+0x85/0x130
4043 [ 1179.306326] [<ffffffff811e4a98>] SyS_read+0x58/0xd0
4044 [ 1179.306708] [<ffffffff8172caaf>] entry_SYSCALL_64_fastpath+0x12/0x76
4045 [ 1179.307094] Code: c4 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 8b 07 49 89 f4 85 c0 74 47 48 8b 06 49 89 fd <48> 8b 38 48 85 ff 74 22 31 db eb 0c 48 63 d3 48 8b 3c d0 48 85
4046 [ 1179.308357] RIP [<ffffffffa027222d>] filelayout_free_fh_array.isra.11+0x1d/0x70 [nfs_layout_nfsv41_files]
4047 [ 1179.309177] RSP <ffff88003e3c77f8>
4048 [ 1179.309582] CR2: 0000000000000000
4049
4050 Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
4051 Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
4052 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4053
4054commit 184f42a146a071392aae4fa2eeefdf87886db1d1
4055Author: Al Viro <viro@zeniv.linux.org.uk>
4056Date: Sun Jul 12 10:39:45 2015 -0400
4057
4058 fix a braino in ovl_d_select_inode()
4059
4060 [ Upstream commit 9391dd00d13c853ab4f2a85435288ae2202e0e43 ]
4061
4062 when opening a directory we want the overlayfs inode, not one from
4063 the topmost layer.
4064
4065 Reported-By: Andrey Jr. Melnikov <temnota.am@gmail.com>
4066 Tested-By: Andrey Jr. Melnikov <temnota.am@gmail.com>
4067 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
4068 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4069
4070commit 687fad0d4610e4211ede26c6785a738c44e9db29
4071Author: David Howells <dhowells@redhat.com>
4072Date: Thu Jun 18 14:32:31 2015 +0100
4073
4074 overlayfs: Make f_path always point to the overlay and f_inode to the underlay
4075
4076 [ Upstream commit 4bacc9c9234c7c8eec44f5ed4e960d9f96fa0f01 ]
4077
4078 Make file->f_path always point to the overlay dentry so that the path in
4079 /proc/pid/fd is correct and to ensure that label-based LSMs have access to the
4080 overlay as well as the underlay (path-based LSMs probably don't need it).
4081
4082 Using my union testsuite to set things up, before the patch I see:
4083
4084 [root@andromeda union-testsuite]# bash 5</mnt/a/foo107
4085 [root@andromeda union-testsuite]# ls -l /proc/$$/fd/
4086 ...
4087 lr-x------. 1 root root 64 Jun 5 14:38 5 -> /a/foo107
4088 [root@andromeda union-testsuite]# stat /mnt/a/foo107
4089 ...
4090 Device: 23h/35d Inode: 13381 Links: 1
4091 ...
4092 [root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
4093 ...
4094 Device: 23h/35d Inode: 13381 Links: 1
4095 ...
4096
4097 After the patch:
4098
4099 [root@andromeda union-testsuite]# bash 5</mnt/a/foo107
4100 [root@andromeda union-testsuite]# ls -l /proc/$$/fd/
4101 ...
4102 lr-x------. 1 root root 64 Jun 5 14:22 5 -> /mnt/a/foo107
4103 [root@andromeda union-testsuite]# stat /mnt/a/foo107
4104 ...
4105 Device: 23h/35d Inode: 40346 Links: 1
4106 ...
4107 [root@andromeda union-testsuite]# stat -L /proc/$$/fd/5
4108 ...
4109 Device: 23h/35d Inode: 40346 Links: 1
4110 ...
4111
4112 Note the change in where /proc/$$/fd/5 points to in the ls command. It was
4113 pointing to /a/foo107 (which doesn't exist) and now points to /mnt/a/foo107
4114 (which is correct).
4115
4116 The inode accessed, however, is the lower layer. The union layer is on device
4117 25h/37d and the upper layer on 24h/36d.
4118
4119 Signed-off-by: David Howells <dhowells@redhat.com>
4120 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
4121 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4122
4123commit 3ed7df6411ed4038c9962bfef9725e79396e581b
4124Author: David Howells <dhowells@redhat.com>
4125Date: Thu Jan 29 12:02:27 2015 +0000
4126
4127 VFS: Introduce inode-getting helpers for layered/unioned fs environments
4128
4129 [ Upstream commit 155e35d4daa804582f75acaa2c74ec797a89c615 ]
4130
4131 Introduce some function for getting the inode (and also the dentry) in an
4132 environment where layered/unioned filesystems are in operation.
4133
4134 The problem is that we have places where we need *both* the union dentry and
4135 the lower source or workspace inode or dentry available, but we can only have
4136 a handle on one of them. Therefore we need to derive the handle to the other
4137 from that.
4138
4139 The idea is to introduce an extra field in struct dentry that allows the union
4140 dentry to refer to and pin the lower dentry.
4141
4142 Signed-off-by: David Howells <dhowells@redhat.com>
4143 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
4144 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4145
4146commit c098c356cb19574036c82652d978ba319f1693ea
4147Author: David Howells <dhowells@redhat.com>
4148Date: Thu Jun 18 14:32:23 2015 +0100
4149
4150 overlay: Call ovl_drop_write() earlier in ovl_dentry_open()
4151
4152 [ Upstream commit f25801ee4680ef1db21e15c112e6e5fe3ffe8da5 ]
4153
4154 Call ovl_drop_write() earlier in ovl_dentry_open() before we call vfs_open()
4155 as we've done the copy up for which we needed the freeze-write lock by that
4156 point.
4157
4158 Signed-off-by: David Howells <dhowells@redhat.com>
4159 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
4160 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4161
4162commit 7750e25bbf2b4c9dafe9777e11c2ac8355d777ba
4163Author: Ben Hutchings <ben@decadent.org.uk>
4164Date: Sat Sep 26 12:23:56 2015 +0100
4165
4166 genirq: Fix race in register_irq_proc()
4167
4168 [ Upstream commit 95c2b17534654829db428f11bcf4297c059a2a7e ]
4169
4170 Per-IRQ directories in procfs are created only when a handler is first
4171 added to the irqdesc, not when the irqdesc is created. In the case of
4172 a shared IRQ, multiple tasks can race to create a directory. This
4173 race condition seems to have been present forever, but is easier to
4174 hit with async probing.
4175
4176 Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
4177 Link: http://lkml.kernel.org/r/1443266636.2004.2.camel@decadent.org.uk
4178 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
4179 Cc: stable@vger.kernel.org
4180 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4181
4182commit 1ace5c6e26cdb135f9fc5ca36e020400ca5e4fb8
4183Author: Stefan Assmann <sassmann@kpanic.de>
4184Date: Fri Jul 10 15:01:12 2015 +0200
4185
4186 igb: do not re-init SR-IOV during probe
4187
4188 [ Upstream commit 6423fc34160939142d72ffeaa2db6408317f54df ]
4189
4190 During driver probing the following code path is triggered.
4191 igb_probe
4192 ->igb_sw_init
4193 ->igb_probe_vfs
4194 ->igb_pci_enable_sriov
4195 ->igb_sriov_reinit
4196
4197 Doing the SR-IOV re-init is not necessary during probing since we're
4198 starting from scratch. Here we can call igb_enable_sriov() right away.
4199
4200 Running igb_sriov_reinit() during igb_probe() also seems to cause
4201 occasional packet loss on some onboard 82576 NICs. Reproduced on
4202 Dell and HP servers with onboard 82576 NICs.
4203 Example:
4204 Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
4205 Subsystem: Dell Device [1028:0481]
4206
4207 Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
4208 Tested-by: Aaron Brown <aaron.f.brown@intel.com>
4209 Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
4210 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4211
4212commit 382aec5dbe7315540ae37a797e344f8f2a316393
4213Author: Chas Williams <3chas3@gmail.com>
4214Date: Thu Aug 27 12:28:46 2015 -0400
4215
4216 net/xen-netfront: only napi_synchronize() if running
4217
4218 [ Upstream commit 274b045509175db0405c784be85e8cce116e6f7d ]
4219
4220 If an interface isn't running napi_synchronize() will hang forever.
4221
4222 [ 392.248403] rmmod R running task 0 359 343 0x00000000
4223 [ 392.257671] ffff88003760fc88 ffff880037193b40 ffff880037193160 ffff88003760fc88
4224 [ 392.267644] ffff880037610000 ffff88003760fcd8 0000000100014c22 ffffffff81f75c40
4225 [ 392.277524] 0000000000bc7010 ffff88003760fca8 ffffffff81796927 ffffffff81f75c40
4226 [ 392.287323] Call Trace:
4227 [ 392.291599] [<ffffffff81796927>] schedule+0x37/0x90
4228 [ 392.298553] [<ffffffff8179985b>] schedule_timeout+0x14b/0x280
4229 [ 392.306421] [<ffffffff810f91b9>] ? irq_free_descs+0x69/0x80
4230 [ 392.314006] [<ffffffff811084d0>] ? internal_add_timer+0xb0/0xb0
4231 [ 392.322125] [<ffffffff81109d07>] msleep+0x37/0x50
4232 [ 392.329037] [<ffffffffa00ec79a>] xennet_disconnect_backend.isra.24+0xda/0x390 [xen_netfront]
4233 [ 392.339658] [<ffffffffa00ecadc>] xennet_remove+0x2c/0x80 [xen_netfront]
4234 [ 392.348516] [<ffffffff81481c69>] xenbus_dev_remove+0x59/0xc0
4235 [ 392.356257] [<ffffffff814e7217>] __device_release_driver+0x87/0x120
4236 [ 392.364645] [<ffffffff814e7cf8>] driver_detach+0xb8/0xc0
4237 [ 392.371989] [<ffffffff814e6e69>] bus_remove_driver+0x59/0xe0
4238 [ 392.379883] [<ffffffff814e84f0>] driver_unregister+0x30/0x70
4239 [ 392.387495] [<ffffffff814814b2>] xenbus_unregister_driver+0x12/0x20
4240 [ 392.395908] [<ffffffffa00ed89b>] netif_exit+0x10/0x775 [xen_netfront]
4241 [ 392.404877] [<ffffffff81124e08>] SyS_delete_module+0x1d8/0x230
4242 [ 392.412804] [<ffffffff8179a8ee>] system_call_fastpath+0x12/0x71
4243
4244 Signed-off-by: Chas Williams <3chas3@gmail.com>
4245 Signed-off-by: David S. Miller <davem@davemloft.net>
4246 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4247
4248commit 51302cb3b7c918b7d58c7a9004c48b80646da332
4249Author: Andreas Schwab <schwab@linux-m68k.org>
4250Date: Wed Sep 23 23:12:09 2015 +0200
4251
4252 m68k: Define asmlinkage_protect
4253
4254 [ Upstream commit 8474ba74193d302e8340dddd1e16c85cc4b98caf ]
4255
4256 Make sure the compiler does not modify arguments of syscall functions.
4257 This can happen if the compiler generates a tailcall to another
4258 function. For example, without asmlinkage_protect sys_openat is compiled
4259 into this function:
4260
4261 sys_openat:
4262 clr.l %d0
4263 move.w 18(%sp),%d0
4264 move.l %d0,16(%sp)
4265 jbra do_sys_open
4266
4267 Note how the fourth argument is modified in place, modifying the register
4268 %d4 that gets restored from this stack slot when the function returns to
4269 user-space. The caller may expect the register to be unmodified across
4270 system calls.
4271
4272 Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
4273 Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
4274 Cc: stable@vger.kernel.org
4275 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4276
4277commit 36c8fcc207bfb55731e1f8a454d6ab2fab20f0d1
4278Author: Li Bin <huawei.libin@huawei.com>
4279Date: Wed Sep 30 10:49:55 2015 +0800
4280
4281 arm64: ftrace: fix function_graph tracer panic
4282
4283 [ Upstream commit ee556d00cf20012e889344a0adbbf809ab5015a3 ]
4284
4285 When function graph tracer is enabled, the following operation
4286 will trigger panic:
4287
4288 mount -t debugfs nodev /sys/kernel
4289 echo next_tgid > /sys/kernel/tracing/set_ftrace_filter
4290 echo function_graph > /sys/kernel/tracing/current_tracer
4291 ls /proc/
4292
4293 ------------[ cut here ]------------
4294 [ 198.501417] Unable to handle kernel paging request at virtual address cb88537fdc8ba316
4295 [ 198.506126] pgd = ffffffc008f79000
4296 [ 198.509363] [cb88537fdc8ba316] *pgd=00000000488c6003, *pud=00000000488c6003, *pmd=0000000000000000
4297 [ 198.517726] Internal error: Oops: 94000005 [#1] SMP
4298 [ 198.518798] Modules linked in:
4299 [ 198.520582] CPU: 1 PID: 1388 Comm: ls Tainted: G
4300 [ 198.521800] Hardware name: linux,dummy-virt (DT)
4301 [ 198.522852] task: ffffffc0fa9e8000 ti: ffffffc0f9ab0000 task.ti: ffffffc0f9ab0000
4302 [ 198.524306] PC is at next_tgid+0x30/0x100
4303 [ 198.525205] LR is at return_to_handler+0x0/0x20
4304 [ 198.526090] pc : [<ffffffc0002a1070>] lr : [<ffffffc0000907c0>] pstate: 60000145
4305 [ 198.527392] sp : ffffffc0f9ab3d40
4306 [ 198.528084] x29: ffffffc0f9ab3d40 x28: ffffffc0f9ab0000
4307 [ 198.529406] x27: ffffffc000d6a000 x26: ffffffc000b786e8
4308 [ 198.530659] x25: ffffffc0002a1900 x24: ffffffc0faf16c00
4309 [ 198.531942] x23: ffffffc0f9ab3ea0 x22: 0000000000000002
4310 [ 198.533202] x21: ffffffc000d85050 x20: 0000000000000002
4311 [ 198.534446] x19: 0000000000000002 x18: 0000000000000000
4312 [ 198.535719] x17: 000000000049fa08 x16: ffffffc000242efc
4313 [ 198.537030] x15: 0000007fa472b54c x14: ffffffffff000000
4314 [ 198.538347] x13: ffffffc0fada84a0 x12: 0000000000000001
4315 [ 198.539634] x11: ffffffc0f9ab3d70 x10: ffffffc0f9ab3d70
4316 [ 198.540915] x9 : ffffffc0000907c0 x8 : ffffffc0f9ab3d40
4317 [ 198.542215] x7 : 0000002e330f08f0 x6 : 0000000000000015
4318 [ 198.543508] x5 : 0000000000000f08 x4 : ffffffc0f9835ec0
4319 [ 198.544792] x3 : cb88537fdc8ba316 x2 : cb88537fdc8ba306
4320 [ 198.546108] x1 : 0000000000000002 x0 : ffffffc000d85050
4321 [ 198.547432]
4322 [ 198.547920] Process ls (pid: 1388, stack limit = 0xffffffc0f9ab0020)
4323 [ 198.549170] Stack: (0xffffffc0f9ab3d40 to 0xffffffc0f9ab4000)
4324 [ 198.582568] Call trace:
4325 [ 198.583313] [<ffffffc0002a1070>] next_tgid+0x30/0x100
4326 [ 198.584359] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
4327 [ 198.585503] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
4328 [ 198.586574] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
4329 [ 198.587660] [<ffffffc0000907bc>] ftrace_graph_caller+0x6c/0x70
4330 [ 198.588896] Code: aa0003f5 2a0103f4 b4000102 91004043 (885f7c60)
4331 [ 198.591092] ---[ end trace 6a346f8f20949ac8 ]---
4332
4333 This is because when using function graph tracer, if the traced
4334 function return value is in multi regs ([x0-x7]), return_to_handler
4335 may corrupt them. So in return_to_handler, the parameter regs should
4336 be protected properly.
4337
4338 Cc: <stable@vger.kernel.org> # 3.18+
4339 Signed-off-by: Li Bin <huawei.libin@huawei.com>
4340 Acked-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
4341 Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
4342 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4343
4344commit b94ee9f4e5475b89378dce8c923705f204a474dd
4345Author: Eric W. Biederman <ebiederm@xmission.com>
4346Date: Sat Aug 15 13:36:12 2015 -0500
4347
4348 dcache: Handle escaped paths in prepend_path
4349
4350 [ Upstream commit cde93be45a8a90d8c264c776fab63487b5038a65 ]
4351
4352 A rename can result in a dentry that by walking up d_parent
4353 will never reach it's mnt_root. For lack of a better term
4354 I call this an escaped path.
4355
4356 prepend_path is called by four different functions __d_path,
4357 d_absolute_path, d_path, and getcwd.
4358
4359 __d_path only wants to see paths are connected to the root it passes
4360 in. So __d_path needs prepend_path to return an error.
4361
4362 d_absolute_path similarly wants to see paths that are connected to
4363 some root. Escaped paths are not connected to any mnt_root so
4364 d_absolute_path needs prepend_path to return an error greater
4365 than 1. So escaped paths will be treated like paths on lazily
4366 unmounted mounts.
4367
4368 getcwd needs to prepend "(unreachable)" so getcwd also needs
4369 prepend_path to return an error.
4370
4371 d_path is the interesting hold out. d_path just wants to print
4372 something, and does not care about the weird cases. Which raises
4373 the question what should be printed?
4374
4375 Given that <escaped_path>/<anything> should result in -ENOENT I
4376 believe it is desirable for escaped paths to be printed as empty
4377 paths. As there are not really any meaninful path components when
4378 considered from the perspective of a mount tree.
4379
4380 So tweak prepend_path to return an empty path with an new error
4381 code of 3 when it encounters an escaped path.
4382
4383 Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
4384 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
4385 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4386
4387commit 683846ae9c03e7c1a8c7a0588a222b1b35075b4f
4388Author: shengyong <shengyong1@huawei.com>
4389Date: Mon Sep 28 17:57:19 2015 +0000
4390
4391 UBI: return ENOSPC if no enough space available
4392
4393 [ Upstream commit 7c7feb2ebfc9c0552c51f0c050db1d1a004faac5 ]
4394
4395 UBI: attaching mtd1 to ubi0
4396 UBI: scanning is finished
4397 UBI error: init_volumes: not enough PEBs, required 706, available 686
4398 UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
4399 UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
4400 UBI error: ubi_init: cannot attach mtd1
4401
4402 If available PEBs are not enough when initializing volumes, return -ENOSPC
4403 directly. If available PEBs are not enough when initializing WL, return
4404 -ENOSPC instead of -ENOMEM.
4405
4406 Cc: stable@vger.kernel.org
4407 Signed-off-by: Sheng Yong <shengyong1@huawei.com>
4408 Signed-off-by: Richard Weinberger <richard@nod.at>
4409 Reviewed-by: David Gstir <david@sigma-star.at>
4410 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4411
4412commit 65521fa80cfaa5d19dd4f5d1171fe295169709ac
4413Author: Richard Weinberger <richard@nod.at>
4414Date: Tue Sep 22 23:58:07 2015 +0200
4415
4416 UBI: Validate data_size
4417
4418 [ Upstream commit 281fda27673f833a01d516658a64d22a32c8e072 ]
4419
4420 Make sure that data_size is less than LEB size.
4421 Otherwise a handcrafted UBI image is able to trigger
4422 an out of bounds memory access in ubi_compare_lebs().
4423
4424 Cc: stable@vger.kernel.org
4425 Signed-off-by: Richard Weinberger <richard@nod.at>
4426 Reviewed-by: David Gstir <david@sigma-star.at>
4427 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4428
4429commit 751a99634e13731cc0d9f95425de36c902a058f9
4430Author: Paul Mackerras <paulus@ozlabs.org>
4431Date: Thu Sep 10 14:36:21 2015 +1000
4432
4433 powerpc/MSI: Fix race condition in tearing down MSI interrupts
4434
4435 [ Upstream commit e297c939b745e420ef0b9dc989cb87bda617b399 ]
4436
4437 This fixes a race which can result in the same virtual IRQ number
4438 being assigned to two different MSI interrupts. The most visible
4439 consequence of that is usually a warning and stack trace from the
4440 sysfs code about an attempt to create a duplicate entry in sysfs.
4441
4442 The race happens when one CPU (say CPU 0) is disposing of an MSI
4443 while another CPU (say CPU 1) is setting up an MSI. CPU 0 calls
4444 (for example) pnv_teardown_msi_irqs(), which calls
4445 msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its
4446 hardware IRQ number) is no longer in use. Then, before CPU 0 gets
4447 to calling irq_dispose_mapping() to free up the virtal IRQ number,
4448 CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an
4449 MSI, and gets the same hardware IRQ number that CPU 0 just freed.
4450 CPU 1 then calls irq_create_mapping() to get a virtual IRQ number,
4451 which sees that there is currently a mapping for that hardware IRQ
4452 number and returns the corresponding virtual IRQ number (which is
4453 the same virtual IRQ number that CPU 0 was using). CPU 0 then
4454 calls irq_dispose_mapping() and frees that virtual IRQ number.
4455 Now, if another CPU comes along and calls irq_create_mapping(), it
4456 is likely to get the virtual IRQ number that was just freed,
4457 resulting in the same virtual IRQ number apparently being used for
4458 two different hardware interrupts.
4459
4460 To fix this race, we just move the call to msi_bitmap_free_hwirqs()
4461 to after the call to irq_dispose_mapping(). Since virq_to_hw()
4462 doesn't work for the virtual IRQ number after irq_dispose_mapping()
4463 has been called, we need to call it before irq_dispose_mapping() and
4464 remember the result for the msi_bitmap_free_hwirqs() call.
4465
4466 The pattern of calling msi_bitmap_free_hwirqs() before
4467 irq_dispose_mapping() appears in 5 places under arch/powerpc, and
4468 appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC
4469 U3/U4 MSI backend") from 2007.
4470
4471 Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend")
4472 Cc: stable@vger.kernel.org # v2.6.22+
4473 Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
4474 Signed-off-by: Paul Mackerras <paulus@samba.org>
4475 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
4476 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4477
4478commit c49426e98f62651d79eca5f0bc0bcbfd5f7eb36d
4479Author: Kapileshwar Singh <kapileshwar.singh@arm.com>
4480Date: Tue Sep 22 14:22:03 2015 +0100
4481
4482 tools lib traceevent: Fix string handling in heterogeneous arch environments
4483
4484 [ Upstream commit c2e4b24ff848bb180f9b9cd873a38327cd219ad2 ]
4485
4486 When a trace recorded on a 32-bit device is processed with a 64-bit
4487 binary, the higher 32-bits of the address need to ignored.
4488
4489 The lack of this results in the output of the 64-bit pointer
4490 value to the trace as the 32-bit address lookup fails in find_printk().
4491
4492 Before:
4493
4494 burn-1778 [003] 548.600305: bputs: 0xc0046db2s: 2cec5c058d98c
4495
4496 After:
4497
4498 burn-1778 [003] 548.600305: bputs: 0xc0046db2s: RT throttling activated
4499
4500 The problem occurs in PRINT_FIELD when the field is recognized as a
4501 pointer to a string (of the type const char *)
4502
4503 Heterogeneous architectures cases below can arise and should be handled:
4504
4505 * Traces recorded using 32-bit addresses processed on a 64-bit machine
4506 * Traces recorded using 64-bit addresses processed on a 32-bit machine
4507
4508 Reported-by: Juri Lelli <juri.lelli@arm.com>
4509 Signed-off-by: Kapileshwar Singh <kapileshwar.singh@arm.com>
4510 Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
4511 Cc: David Ahern <dsahern@gmail.com>
4512 Cc: Javi Merino <javi.merino@arm.com>
4513 Cc: Jiri Olsa <jolsa@kernel.org>
4514 Cc: Namhyung Kim <namhyung@kernel.org>
4515 Cc: stable@vger.kernel.org
4516 Link: http://lkml.kernel.org/r/1442928123-13824-1-git-send-email-kapileshwar.singh@arm.com
4517 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
4518 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4519
4520commit 32435867973da5100ee4ecb3aee0db664af61379
4521Author: Linus Lüssing <linus.luessing@c0d3.blue>
4522Date: Tue Jun 30 23:45:26 2015 +0200
4523
4524 batman-adv: Fix potentially broken skb network header access
4525
4526 [ Upstream commit 53cf037bf846417fd92dc92ddf97267f69b110f4 ]
4527
4528 The two commits noted below added calls to ip_hdr() and ipv6_hdr(). They
4529 need a correctly set skb network header.
4530
4531 Unfortunately we cannot rely on the device drivers to set it for us.
4532 Therefore setting it in the beginning of the according ndo_start_xmit
4533 handler.
4534
4535 Fixes: 1d8ab8d3c176 ("batman-adv: Modified forwarding behaviour for multicast packets")
4536 Fixes: ab49886e3da7 ("batman-adv: Add IPv4 link-local/IPv6-ll-all-nodes multicast support")
4537 Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
4538 Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
4539 Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
4540 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4541
4542commit a5516389f7813170c593bc8106bcc20c1a086cb8
4543Author: Linus Lüssing <linus.luessing@c0d3.blue>
4544Date: Tue Jun 16 17:10:24 2015 +0200
4545
4546 batman-adv: Make TT capability changes atomic
4547
4548 [ Upstream commit ac4eebd48461ec993e7cb614d5afe7df8c72e6b7 ]
4549
4550 Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
4551 OGM handler might undo the set/clear of a specific bit from another
4552 handler run in between.
4553
4554 Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions.
4555
4556 Fixes: e17931d1a61d ("batman-adv: introduce capability initialization bitfield")
4557 Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
4558 Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
4559 Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
4560 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4561
4562commit 9a1f325d7c9f0a56af6b5111f4c8514422f4b02d
4563Author: Linus Lüssing <linus.luessing@c0d3.blue>
4564Date: Tue Jun 16 17:10:23 2015 +0200
4565
4566 batman-adv: Make NC capability changes atomic
4567
4568 [ Upstream commit 4635469f5c617282f18c69643af36cd8c0acf707 ]
4569
4570 Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
4571 OGM handler might undo the set/clear of a specific bit from another
4572 handler run in between.
4573
4574 Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions.
4575
4576 Fixes: 3f4841ffb336 ("batman-adv: tvlv - add network coding container")
4577 Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
4578 Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
4579 Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
4580 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4581
4582commit 993b87dfa9ba01cdfc7026bbb8d6365f892dcb33
4583Author: James Hogan <james.hogan@imgtec.com>
4584Date: Fri Mar 27 08:33:43 2015 +0000
4585
4586 MIPS: dma-default: Fix 32-bit fall back to GFP_DMA
4587
4588 [ Upstream commit 53960059d56ecef67d4ddd546731623641a3d2d1 ]
4589
4590 If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
4591 zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
4592 will cause DMA memory allocated for devices with a 32..63-bit
4593 coherent_dma_mask to fall back to using __GFP_DMA, even though there may
4594 only be 32-bits of physical address available anyway.
4595
4596 Correct that case to compare against a mask the size of phys_addr_t
4597 instead of always using a 64-bit mask.
4598
4599 Signed-off-by: James Hogan <james.hogan@imgtec.com>
4600 Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
4601 Cc: Ralf Baechle <ralf@linux-mips.org>
4602 Cc: linux-mips@linux-mips.org
4603 Cc: <stable@vger.kernel.org> # 2.6.36+
4604 Patchwork: https://patchwork.linux-mips.org/patch/9610/
4605 Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
4606 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4607
4608commit 178adb782b60a76981bf041736c27c06bedb20f2
4609Author: Viresh Kumar <viresh.kumar@linaro.org>
4610Date: Wed Sep 2 14:36:50 2015 +0530
4611
4612 cpufreq: dt: Tolerance applies on both sides of target voltage
4613
4614 [ Upstream commit a2022001cebd0825b96aa0f3345ea3ad44ae79d4 ]
4615
4616 Tolerance applies on both sides of the target voltage, i.e. both min and
4617 max sides. But while checking if a voltage is supported by the regulator
4618 or not, we haven't taken care of tolerance on the lower side. Fix that.
4619
4620 Cc: Lucas Stach <l.stach@pengutronix.de>
4621 Fixes: 045ee45c4ff2 ("cpufreq: cpufreq-dt: disable unsupported OPPs")
4622 Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
4623 Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
4624 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
4625 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4626
4627commit 317a43bb95155b991644de5c8f152a3c2586fecb
4628Author: Yao-Wen Mao <yaowen@google.com>
4629Date: Mon Aug 31 14:24:09 2015 +0800
4630
4631 USB: Add reset-resume quirk for two Plantronics usb headphones.
4632
4633 [ Upstream commit 8484bf2981b3d006426ac052a3642c9ce1d8d980 ]
4634
4635 These two headphones need a reset-resume quirk to properly resume to
4636 original volume level.
4637
4638 Signed-off-by: Yao-Wen Mao <yaowen@google.com>
4639 Cc: stable <stable@vger.kernel.org>
4640 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4641 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4642
4643commit d9345b0c2b7b828b8208f2a2a064cdc76293e1dc
4644Author: Vincent Palatin <vpalatin@chromium.org>
4645Date: Thu Oct 1 14:10:22 2015 -0700
4646
4647 usb: Add device quirk for Logitech PTZ cameras
4648
4649 [ Upstream commit 72194739f54607bbf8cfded159627a2015381557 ]
4650
4651 Add a device quirk for the Logitech PTZ Pro Camera and its sibling the
4652 ConferenceCam CC3000e Camera.
4653 This fixes the failed camera enumeration on some boot, particularly on
4654 machines with fast CPU.
4655
4656 Tested by connecting a Logitech PTZ Pro Camera to a machine with a
4657 Haswell Core i7-4600U CPU @ 2.10GHz, and doing thousands of reboot cycles
4658 while recording the kernel logs and taking camera picture after each boot.
4659 Before the patch, more than 7% of the boots show some enumeration transfer
4660 failures and in a few of them, the kernel is giving up before actually
4661 enumerating the webcam. After the patch, the enumeration has been correct
4662 on every reboot.
4663
4664 Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
4665 Cc: stable <stable@vger.kernel.org>
4666 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4667 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4668
4669commit 9ea9f8ee0be93e9b90a64616391a32e461660d3a
4670Author: Felipe Balbi <balbi@ti.com>
4671Date: Thu Aug 6 10:51:29 2015 -0500
4672
4673 usb: musb: cppi41: allow it to work again
4674
4675 [ Upstream commit b0a688ddcc5015eb26000c63841db7c46cfb380a ]
4676
4677 since commit 33c300cb90a6 ("usb: musb: dsps:
4678 don't fake of_node to musb core") we have been
4679 preventing CPPI 4.1 from probing due to NULL
4680 of_node. We can't revert said commit otherwise
4681 a different regression would show up, so the fix
4682 is to look for the parent device's (glue layer's)
4683 of_node instead, since that's the thing which
4684 is actually described in DTS.
4685
4686 Signed-off-by: Felipe Balbi <balbi@ti.com>
4687 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4688
4689commit 2180f6799fe3594149ec4d7e185cc694f37ca055
4690Author: Mathias Nyman <mathias.nyman@linux.intel.com>
4691Date: Mon Sep 21 17:46:09 2015 +0300
4692
4693 usb: Use the USB_SS_MULT() macro to get the burst multiplier.
4694
4695 [ Upstream commit ff30cbc8da425754e8ab96904db1d295bd034f27 ]
4696
4697 Bits 1:0 of the bmAttributes are used for the burst multiplier.
4698 The rest of the bits used to be reserved (zero), but USB3.1 takes bit 7
4699 into use.
4700
4701 Use the existing USB_SS_MULT() macro instead to make sure the mult value
4702 and hence max packet calculations are correct for USB3.1 devices.
4703
4704 Note that burst multiplier in bmAttributes is zero based and that
4705 the USB_SS_MULT() macro adds one.
4706
4707 Cc: <stable@vger.kernel.org>
4708 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
4709 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4710 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4711
4712commit 110fda8090a2f3131c8e2035b4ca3ffef0dc9cdd
4713Author: Peter Chen <peter.chen@freescale.com>
4714Date: Mon Aug 24 14:10:07 2015 +0800
4715
4716 usb: chipidea: udc: using the correct stall implementation
4717
4718 [ Upstream commit 56ffa1d154c7e12af16273f0cdc42690dd05caf5 ]
4719
4720 According to spec, there are functional and protocol stalls.
4721
4722 For functional stall, it is for bulk and interrupt endpoints,
4723 below are cases for it:
4724 - Host sends SET_FEATURE request for Set-Halt, the udc driver
4725 needs to set stall, and return true unconditionally.
4726 - The gadget driver may call usb_ep_set_halt to stall certain
4727 endpoints, if there is a transfer in pending, the udc driver
4728 should not set stall, and return -EAGAIN accordingly.
4729 These two kinds of stall need to be cleared by host using CLEAR_FEATURE
4730 request (Clear-Halt).
4731
4732 For protocol stall, it is for control endpoint, this stall will
4733 be set if the control request has failed. This stall will be
4734 cleared by next setup request (hardware will do it).
4735
4736 It fixed usbtest (drivers/usb/misc/usbtest.c) Test 13 "set/clear halt"
4737 test failure, meanwhile, this change has been verified by
4738 USB2 CV Compliance Test and MSC Tests.
4739
4740 Cc: <stable@vger.kernel.org> #3.10+
4741 Cc: Alan Stern <stern@rowland.harvard.edu>
4742 Cc: Felipe Balbi <balbi@ti.com>
4743 Signed-off-by: Peter Chen <peter.chen@freescale.com>
4744 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4745
4746commit 37371a15850eafb5f7dc831a6cf76e80a727d16f
4747Author: Jann Horn <jann@thejh.net>
4748Date: Fri Sep 18 23:41:23 2015 +0200
4749
4750 security: fix typo in security_task_prctl
4751
4752 [ Upstream commit b7f76ea2ef6739ee484a165ffbac98deb855d3d3 ]
4753
4754 Signed-off-by: Jann Horn <jann@thejh.net>
4755 Reviewed-by: Andy Lutomirski <luto@kernel.org>
4756 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
4757 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4758
4759commit afeda4748db04805d0fe7905fc93518118e65251
4760Author: Mark Brown <broonie@kernel.org>
4761Date: Sat Sep 19 07:12:34 2015 -0700
4762
4763 regmap: debugfs: Don't bother actually printing when calculating max length
4764
4765 [ Upstream commit 176fc2d5770a0990eebff903ba680d2edd32e718 ]
4766
4767 The in kernel snprintf() will conveniently return the actual length of
4768 the printed string even if not given an output beffer at all so just do
4769 that rather than relying on the user to pass in a suitable buffer,
4770 ensuring that we don't need to worry if the buffer was truncated due to
4771 the size of the buffer passed in.
4772
4773 Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
4774 Signed-off-by: Mark Brown <broonie@kernel.org>
4775 Cc: stable@vger.kernel.org
4776 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4777
4778commit c53a219f7f9b7462fdf4a8fd2d20fadad811e97f
4779Author: Mark Brown <broonie@kernel.org>
4780Date: Sat Sep 19 07:00:18 2015 -0700
4781
4782 regmap: debugfs: Ensure we don't underflow when printing access masks
4783
4784 [ Upstream commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 ]
4785
4786 If a read is attempted which is smaller than the line length then we may
4787 underflow the subtraction we're doing with the unsigned size_t type so
4788 move some of the calculation to be additions on the right hand side
4789 instead in order to avoid this.
4790
4791 Reported-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
4792 Signed-off-by: Mark Brown <broonie@kernel.org>
4793 Cc: stable@vger.kernel.org
4794 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4795
4796commit df1dc5e8cb68325743fda1c745b2f9cb6901cf9e
4797Author: Heiko Stuebner <heiko@sntech.de>
4798Date: Tue Aug 4 21:36:12 2015 +0200
4799
4800 PM / AVS: rockchip-io: depend on CONFIG_POWER_AVS
4801
4802 [ Upstream commit 28c1f1628ee4b163e615eefe1b6463e3d229a873 ]
4803
4804 The rockchip io-domain driver currently only depends on ARCH_ROCKCHIP
4805 itself. This makes it possible to select the power-domain driver, but
4806 not the POWER_AVS class and results in the iodomain-driver not getting
4807 build in this case.
4808
4809 So add the additional dependency, which also results in the driver
4810 config option now being placed nicely into the AVS submenu.
4811
4812 Fixes: 662a958638bd ("PM / AVS: rockchip-io: add driver handling Rockchip io domains")
4813 Signed-off-by: Heiko Stuebner <heiko@sntech.de>
4814 Acked-by: Kevin Hilman <khilman@linaro.org>
4815 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
4816 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4817
4818commit 101755ff61aa274657aba98670282b185144dcd9
4819Author: Antoine Ténart <antoine.tenart@free-electrons.com>
4820Date: Tue Aug 18 10:59:10 2015 +0200
4821
4822 mtd: pxa3xx_nand: add a default chunk size
4823
4824 [ Upstream commit bc3e00f04cc1fe033a289c2fc2e5c73c0168d360 ]
4825
4826 When keeping the configuration set by the bootloader (by using
4827 the marvell,nand-keep-config property), the pxa3xx_nand_detect_config()
4828 function is called and set the chunk size to 512 as a default value if
4829 NDCR_PAGE_SZ is not set.
4830
4831 In the other case, when not keeping the bootloader configuration, no
4832 chunk size is set. Fix this by adding a default chunk size of 512.
4833
4834 Fixes: 70ed85232a93 ("mtd: nand: pxa3xx: Introduce multiple page I/O
4835 support")
4836
4837 Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
4838 Acked-by: Robert Jarzmik <robert.jarzmik@free>
4839 Signed-off-by: Brian Norris <computersforpeace@gmail.com>
4840 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4841
4842commit 7a41fbe7baec500e8a94fe76a09fb9d3370c07ec
4843Author: Mario Carrillo <mario.alfredo.c.arevalo@intel.com>
4844Date: Mon Aug 24 09:33:09 2015 -0500
4845
4846 docs: update HOWTO for 3.x -> 4.x versioning
4847
4848 [ Upstream commit e4144fe5d47c91c92d36cdbd5f31ed8d6e3a57ab ]
4849
4850 The HOWTO document needed updating for the new kernel versioning.
4851
4852 Signed-off-by: Mario Carrillo <mario.alfredo.c.arevalo@intel.com>
4853 Signed-off-by: Jonathan Corbet <corbet@lwn.net>
4854 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4855
4856commit ec30985f6dfadd1b5e3d9a833fd872b01ab28058
4857Author: Peter Seiderer <ps.report@gmx.net>
4858Date: Thu Sep 17 21:40:12 2015 +0200
4859
4860 cifs: use server timestamp for ntlmv2 authentication
4861
4862 [ Upstream commit 98ce94c8df762d413b3ecb849e2b966b21606d04 ]
4863
4864 Linux cifs mount with ntlmssp against an Mac OS X (Yosemite
4865 10.10.5) share fails in case the clocks differ more than +/-2h:
4866
4867 digest-service: digest-request: od failed with 2 proto=ntlmv2
4868 digest-service: digest-request: kdc failed with -1561745592 proto=ntlmv2
4869
4870 Fix this by (re-)using the given server timestamp for the
4871 ntlmv2 authentication (as Windows 7 does).
4872
4873 A related problem was also reported earlier by Namjae Jaen (see below):
4874
4875 Windows machine has extended security feature which refuse to allow
4876 authentication when there is time difference between server time and
4877 client time when ntlmv2 negotiation is used. This problem is prevalent
4878 in embedded enviornment where system time is set to default 1970.
4879
4880 Modern servers send the server timestamp in the TargetInfo Av_Pair
4881 structure in the challenge message [see MS-NLMP 2.2.2.1]
4882 In [MS-NLMP 3.1.5.1.2] it is explicitly mentioned that the client must
4883 use the server provided timestamp if present OR current time if it is
4884 not
4885
4886 Reported-by: Namjae Jeon <namjae.jeon@samsung.com>
4887 Signed-off-by: Peter Seiderer <ps.report@gmx.net>
4888 Signed-off-by: Steve French <smfrench@gmail.com>
4889 CC: Stable <stable@vger.kernel.org>
4890 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4891
4892commit 56b4f4e1e72aaaebab94c0fdddb132a5f4cbfab6
4893Author: Dong Aisheng <aisheng.dong@freescale.com>
4894Date: Wed Jul 22 20:53:03 2015 +0800
4895
4896 dts: imx25: fix sd card gpio polarity specified in device tree
4897
4898 [ Upstream commit cf75eb15be2bdd054a76aeef6458beaa4a6ab770 ]
4899
4900 cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
4901 should be changed to GPIO_ACTIVE_HIGH.
4902 Otherwise, the SD may not work properly due to wrong polarity inversion
4903 specified in DT after switch to common parsing function mmc_of_parse().
4904
4905 Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
4906 Acked-by: Shawn Guo <shawnguo@kernel.org>
4907 Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
4908 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4909
4910commit 776aefbd399915fd4ddd6c9de4a12f989a62699e
4911Author: Dong Aisheng <aisheng.dong@freescale.com>
4912Date: Wed Jul 22 20:53:01 2015 +0800
4913
4914 dts: imx53: fix sd card gpio polarity specified in device tree
4915
4916 [ Upstream commit 94d76946859b4bcfa0da373357f14feda2af0622 ]
4917
4918 cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
4919 should be changed to GPIO_ACTIVE_HIGH.
4920 Otherwise, the SD may not work properly due to wrong polarity inversion
4921 specified in DT after switch to common parsing function mmc_of_parse().
4922
4923 Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
4924 Acked-by: Shawn Guo <shawnguo@kernel.org>
4925 Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
4926 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4927
4928commit ea16b55dc40e466bd18f3f42a97625614f5d2c95
4929Author: Dong Aisheng <aisheng.dong@freescale.com>
4930Date: Wed Jul 22 20:53:00 2015 +0800
4931
4932 dts: imx51: fix sd card gpio polarity specified in device tree
4933
4934 [ Upstream commit aca45c0e95dad1c4ba4d38da192756b0e10cbbbd ]
4935
4936 cd-gpios polarity should be changed to GPIO_ACTIVE_LOW and wp-gpios
4937 should be changed to GPIO_ACTIVE_HIGH.
4938 Otherwise, the SD may not work properly due to wrong polarity inversion
4939 specified in DT after switch to common parsing function mmc_of_parse().
4940
4941 Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
4942 Acked-by: Shawn Guo <shawnguo@kernel.org>
4943 Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
4944 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4945
4946commit f4896bf8e3783a0358de738739881b6142c12ea2
4947Author: Linus Lüssing <linus.luessing@c0d3.blue>
4948Date: Tue Jun 16 17:10:22 2015 +0200
4949
4950 batman-adv: Make DAT capability changes atomic
4951
4952 [ Upstream commit 65d7d46050704bcdb8121ddbf4110bfbf2b38baa ]
4953
4954 Bitwise OR/AND assignments in C aren't guaranteed to be atomic. One
4955 OGM handler might undo the set/clear of a specific bit from another
4956 handler run in between.
4957
4958 Fix this by using the atomic set_bit()/clear_bit()/test_bit() functions.
4959
4960 Fixes: 17cf0ea455f1 ("batman-adv: tvlv - add distributed arp table container")
4961 Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
4962 Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
4963 Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
4964 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4965
4966commit cd7d25e2e12f9e3aef73417f0937276ca5b5c451
4967Author: Marek Lindner <mareklindner@neomailbox.ch>
4968Date: Wed Jun 17 20:01:36 2015 +0800
4969
4970 batman-adv: protect tt_local_entry from concurrent delete events
4971
4972 [ Upstream commit ef72706a0543d0c3a5ab29bd6378fdfb368118d9 ]
4973
4974 The tt_local_entry deletion performed in batadv_tt_local_remove() was neither
4975 protecting against simultaneous deletes nor checking whether the element was
4976 still part of the list before calling hlist_del_rcu().
4977
4978 Replacing the hlist_del_rcu() call with batadv_hash_remove() provides adequate
4979 protection via hash spinlocks as well as an is-element-still-in-hash check to
4980 avoid 'blind' hash removal.
4981
4982 Fixes: 068ee6e204e1 ("batman-adv: roaming handling mechanism redesign")
4983 Reported-by: alfonsname@web.de
4984 Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
4985 Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
4986 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
4987
4988commit ab8311e07dad19e7c45822e1b8493a79205658d7
4989Author: Linus Walleij <linus.walleij@linaro.org>
4990Date: Tue Jul 28 15:31:12 2015 +0200
4991
4992 fbdev: select versatile helpers for the integrator
4993
4994 [ Upstream commit 2701fa0864ecb9e49d47a4aa1c02f172ab79639a ]
4995
4996 Commit 11c32d7b6274cb0f554943d65bd4a126c4a86dcd
4997 "video: move Versatile CLCD helpers" missed the fact
4998 that the Integrator/CP is also using the helper, and
4999 as a result the platform got only stubs and no graphics.
5000 Add this as a default selection to Kconfig so we have
5001 graphics again.
5002
5003 Fixes: 11c32d7b6274 (video: move Versatile CLCD helpers)
5004 Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
5005 Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
5006 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5007
5008commit a7fadae31bf58178f39838ad00d6f467eeb13da0
5009Author: Julian Anastasov <ja@ssi.bg>
5010Date: Wed Jul 8 08:31:33 2015 +0300
5011
5012 ipvs: fix crash with sync protocol v0 and FTP
5013
5014 [ Upstream commit 56184858d1fc95c46723436b455cb7261cd8be6f ]
5015
5016 Fix crash in 3.5+ if FTP is used after switching
5017 sync_version to 0.
5018
5019 Fixes: 749c42b620a9 ("ipvs: reduce sync rate with time thresholds")
5020 Signed-off-by: Julian Anastasov <ja@ssi.bg>
5021 Signed-off-by: Simon Horman <horms@verge.net.au>
5022 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5023
5024commit 8e891d1e7d0f1e0f1ef129ed47f405af4f38c3a4
5025Author: Alex Gartrell <agartrell@fb.com>
5026Date: Sun Jul 5 14:28:26 2015 -0700
5027
5028 ipvs: skb_orphan in case of forwarding
5029
5030 [ Upstream commit 71563f3414e917c62acd8e0fb0edf8ed6af63e4b ]
5031
5032 It is possible that we bind against a local socket in early_demux when we
5033 are actually going to want to forward it. In this case, the socket serves
5034 no purpose and only serves to confuse things (particularly functions which
5035 implicitly expect sk_fullsock to be true, like ip_local_out).
5036 Additionally, skb_set_owner_w is totally broken for non full-socks.
5037
5038 Signed-off-by: Alex Gartrell <agartrell@fb.com>
5039 Fixes: 41063e9dd119 ("ipv4: Early TCP socket demux.")
5040 Acked-by: Julian Anastasov <ja@ssi.bg>
5041 Signed-off-by: Simon Horman <horms@verge.net.au>
5042 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5043
5044commit 0932d43cda2bde73fa8f7c12e2e0834ecdef5e9c
5045Author: Julian Anastasov <ja@ssi.bg>
5046Date: Mon Jun 29 21:51:40 2015 +0300
5047
5048 ipvs: fix crash if scheduler is changed
5049
5050 [ Upstream commit 05f00505a89acd21f5d0d20f5797dfbc4cf85243 ]
5051
5052 I overlooked the svc->sched_data usage from schedulers
5053 when the services were converted to RCU in 3.10. Now
5054 the rare ipvsadm -E command can change the scheduler
5055 but due to the reverse order of ip_vs_bind_scheduler
5056 and ip_vs_unbind_scheduler we provide new sched_data
5057 to the old scheduler resulting in a crash.
5058
5059 To fix it without changing the scheduler methods we
5060 have to use synchronize_rcu() only for the editing case.
5061 It means all svc->scheduler readers should expect a
5062 NULL value. To avoid breakage for the service listing
5063 and ipvsadm -R we can use the "none" name to indicate
5064 that scheduler is not assigned, a state when we drop
5065 new connections.
5066
5067 Reported-by: Alexander Vasiliev <a.vasylev@404-group.com>
5068 Fixes: ceec4c381681 ("ipvs: convert services to rcu")
5069 Signed-off-by: Julian Anastasov <ja@ssi.bg>
5070 Signed-off-by: Simon Horman <horms@verge.net.au>
5071 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5072
5073commit fd33c09af14f6786fed65c8319743a8d709e5996
5074Author: Julian Anastasov <ja@ssi.bg>
5075Date: Sat Jun 27 14:39:30 2015 +0300
5076
5077 ipvs: do not use random local source address for tunnels
5078
5079 [ Upstream commit 4754957f04f5f368792a0eb7dab0ae89fb93dcfd ]
5080
5081 Michael Vallaly reports about wrong source address used
5082 in rare cases for tunneled traffic. Looks like
5083 __ip_vs_get_out_rt in 3.10+ is providing uninitialized
5084 dest_dst->dst_saddr.ip because ip_vs_dest_dst_alloc uses
5085 kmalloc. While we retry after seeing EINVAL from routing
5086 for data that does not look like valid local address, it
5087 still succeeded when this memory was previously used from
5088 other dests and with different local addresses. As result,
5089 we can use valid local address that is not suitable for
5090 our real server.
5091
5092 Fix it by providing 0.0.0.0 every time our cache is refreshed.
5093 By this way we will get preferred source address from routing.
5094
5095 Reported-by: Michael Vallaly <lvs@nolatency.com>
5096 Fixes: 026ace060dfe ("ipvs: optimize dst usage for real server")
5097 Signed-off-by: Julian Anastasov <ja@ssi.bg>
5098 Signed-off-by: Simon Horman <horms@verge.net.au>
5099 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5100
5101commit a7596ac980aae5ddbba5ac8954e4651551c35b61
5102Author: Ben Segall <bsegall@google.com>
5103Date: Mon Apr 6 15:28:10 2015 -0700
5104
5105 sched/fair: Prevent throttling in early pick_next_task_fair()
5106
5107 [ Upstream commit 54d27365cae88fbcc853b391dcd561e71acb81fa ]
5108
5109 The optimized task selection logic optimistically selects a new task
5110 to run without first doing a full put_prev_task(). This is so that we
5111 can avoid a put/set on the common ancestors of the old and new task.
5112
5113 Similarly, we should only call check_cfs_rq_runtime() to throttle
5114 eligible groups if they're part of the common ancestry, otherwise it
5115 is possible to end up with no eligible task in the simple task
5116 selection.
5117
5118 Imagine:
5119 /root
5120 /prev /next
5121 /A /B
5122
5123 If our optimistic selection ends up throttling /next, we goto simple
5124 and our put_prev_task() ends up throttling /prev, after which we're
5125 going to bug out in set_next_entity() because there aren't any tasks
5126 left.
5127
5128 Avoid this scenario by only throttling common ancestors.
5129
5130 Reported-by: Mohammed Naser <mnaser@vexxhost.com>
5131 Reported-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
5132 Signed-off-by: Ben Segall <bsegall@google.com>
5133 [ munged Changelog ]
5134 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
5135 Cc: Andrew Morton <akpm@linux-foundation.org>
5136 Cc: H. Peter Anvin <hpa@zytor.com>
5137 Cc: Linus Torvalds <torvalds@linux-foundation.org>
5138 Cc: Peter Zijlstra <peterz@infradead.org>
5139 Cc: Roman Gushchin <klamm@yandex-team.ru>
5140 Cc: Thomas Gleixner <tglx@linutronix.de>
5141 Cc: pjt@google.com
5142 Fixes: 678d5718d8d0 ("sched/fair: Optimize cgroup pick_next_task_fair()")
5143 Link: http://lkml.kernel.org/r/xm26wq1oswoq.fsf@sword-of-the-dawn.mtv.corp.google.com
5144 Signed-off-by: Ingo Molnar <mingo@kernel.org>
5145
5146 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5147
5148commit 5240c25c81adef4633d173424ee133637e8ed8b4
5149Author: Reyad Attiyat <reyad.attiyat@gmail.com>
5150Date: Thu Aug 6 19:23:58 2015 +0300
5151
5152 usb: xhci: Add support for URB_ZERO_PACKET to bulk/sg transfers
5153
5154 [ Upstream commit 4758dcd19a7d9ba9610b38fecb93f65f56f86346 ]
5155
5156 This commit checks for the URB_ZERO_PACKET flag and creates an extra
5157 zero-length td if the urb transfer length is a multiple of the endpoint's
5158 max packet length.
5159
5160 Signed-off-by: Reyad Attiyat <reyad.attiyat@gmail.com>
5161 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
5162 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5163 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5164
5165commit 923a0e8f49af962a51734a19943b89bb1c2fc709
5166Author: Mathias Nyman <mathias.nyman@linux.intel.com>
5167Date: Mon Sep 21 17:46:17 2015 +0300
5168
5169 xhci: init command timeout timer earlier to avoid deleting it uninitialized
5170
5171 [ Upstream commit cc8e4fc0c3b5e8340bc8358990515d116a3c274c ]
5172
5173 Don't check if timer is running with a timer_pending() before
5174 deleting it with del_timer_sync(), this defies the whole point of
5175 the sync part and can cause a possible race.
5176
5177 Instead we just want to make sure the timer is initialized early enough
5178 before we have a chance to delete it.
5179
5180 Cc: <stable@vger.kernel.org>
5181 Reported-by: Oliver Neukum <oneukum@suse.com>
5182 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
5183 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5184 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5185
5186commit a15f9f60fb8ed89793e72d08a5537a4ca99d8982
5187Author: Mathias Nyman <mathias.nyman@linux.intel.com>
5188Date: Mon Sep 21 17:46:16 2015 +0300
5189
5190 xhci: change xhci 1.0 only restrictions to support xhci 1.1
5191
5192 [ Upstream commit dca7794539eff04b786fb6907186989e5eaaa9c2 ]
5193
5194 Some changes between xhci 0.96 and xhci 1.0 specifications forced us to
5195 check the hci version in code, some of these checks were implemented as
5196 hci_version == 1.0, which will not work with new xhci 1.1 controllers.
5197
5198 xhci 1.1 behaves similar to xhci 1.0 in these cases, so change these
5199 checks to hci_version >= 1.0
5200
5201 Cc: <stable@vger.kernel.org>
5202 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
5203 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5204 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5205
5206commit 4b025c015cf467efd35ccad202784d3ff75874e2
5207Author: Roger Quadros <rogerq@ti.com>
5208Date: Mon Sep 21 17:46:15 2015 +0300
5209
5210 usb: xhci: exit early in xhci_setup_device() if we're halted or dying
5211
5212 [ Upstream commit 448116bfa856d3c076fa7178ed96661a008a5d45 ]
5213
5214 During quick plug/removal of OTG adapter during dual-role testing
5215 it can happen that xhci_alloc_device() is called for the newly
5216 detected device after the DRD library has called xhci_stop to
5217 remove the HCD.
5218
5219 If that is the case, just fail early to prevent the following warning.
5220
5221 [ 154.732649] hub 4-0:1.0: USB hub found
5222 [ 154.742204] hub 4-0:1.0: 1 port detected
5223 [ 154.824458] hub 3-0:1.0: state 7 ports 1 chg 0002 evt 0000
5224 [ 154.854609] hub 4-0:1.0: state 7 ports 1 chg 0000 evt 0000
5225 [ 154.944430] usb 3-1: new high-speed USB device number 2 using xhci-hcd
5226 [ 154.951009] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
5227 [ 155.038191] xhci-hcd xhci-hcd.0.auto: remove, state 4
5228 [ 155.043315] usb usb4: USB disconnect, device number 1
5229 [ 155.055270] xhci-hcd xhci-hcd.0.auto: xhci_stop
5230 [ 155.060094] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered
5231 [ 155.066576] xhci-hcd xhci-hcd.0.auto: remove, state 1
5232 [ 155.071710] usb usb3: USB disconnect, device number 1
5233 [ 155.077124] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
5234 [ 155.082389] ------------[ cut here ]------------
5235 [ 155.087690] WARNING: CPU: 0 PID: 72 at drivers/usb/host/xhci.c:3800 xhci_setup_device+0x410/0x484 [xhci_hcd]()
5236 [ 155.097861] Modules linked in: sd_mod usb_storage scsi_mod usb_f_ss_lb g_zero libcomposite ipv6 xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core evdev ti_am335x_adc joydev kfifo_buf industrialio snd_soc_simple_cc
5237 [ 155.146734] CPU: 0 PID: 72 Comm: kworker/0:3 Tainted: G W 4.1.4-00834-gcd9380b-dirty #50
5238 [ 155.156073] Hardware name: Generic AM43 (Flattened Device Tree)
5239 [ 155.162117] Workqueue: usb_hub_wq hub_event [usbcore]
5240 [ 155.167249] Backtrace:
5241 [ 155.169751] [<c0012af0>] (dump_backtrace) from [<c0012c8c>] (show_stack+0x18/0x1c)
5242 [ 155.177390] r6:c089d4a4 r5:ffffffff r4:00000000 r3:ee46c000
5243 [ 155.183137] [<c0012c74>] (show_stack) from [<c05f7c14>] (dump_stack+0x84/0xd0)
5244 [ 155.190446] [<c05f7b90>] (dump_stack) from [<c00439ac>] (warn_slowpath_common+0x80/0xbc)
5245 [ 155.198605] r7:00000009 r6:00000ed8 r5:bf27eb70 r4:00000000
5246 [ 155.204348] [<c004392c>] (warn_slowpath_common) from [<c0043a0c>] (warn_slowpath_null+0x24/0x2c)
5247 [ 155.213202] r8:ee49f000 r7:ee7c0004 r6:00000000 r5:ee7c0158 r4:ee7c0000
5248 [ 155.220051] [<c00439e8>] (warn_slowpath_null) from [<bf27eb70>] (xhci_setup_device+0x410/0x484 [xhci_hcd])
5249 [ 155.229816] [<bf27e760>] (xhci_setup_device [xhci_hcd]) from [<bf27ec10>] (xhci_address_device+0x14/0x18 [xhci_hcd])
5250 [ 155.240415] r10:ee598200 r9:00000001 r8:00000002 r7:00000001 r6:00000003 r5:00000002
5251 [ 155.248363] r4:ee49f000
5252 [ 155.250978] [<bf27ebfc>] (xhci_address_device [xhci_hcd]) from [<bf20cb94>] (hub_port_init+0x1b8/0xa9c [usbcore])
5253 [ 155.261403] [<bf20c9dc>] (hub_port_init [usbcore]) from [<bf2101e0>] (hub_event+0x738/0x1020 [usbcore])
5254 [ 155.270874] r10:ee598200 r9:ee7c0000 r8:ee7c0038 r7:ee518800 r6:ee49f000 r5:00000001
5255 [ 155.278822] r4:00000000
5256 [ 155.281426] [<bf20faa8>] (hub_event [usbcore]) from [<c005754c>] (process_one_work+0x128/0x340)
5257 [ 155.290196] r10:00000000 r9:00000003 r8:00000000 r7:fedfa000 r6:eeec5400 r5:ee598314
5258 [ 155.298151] r4:ee434380
5259 [ 155.300718] [<c0057424>] (process_one_work) from [<c00578f8>] (worker_thread+0x158/0x49c)
5260 [ 155.308963] r10:ee434380 r9:00000003 r8:eeec5400 r7:00000008 r6:ee434398 r5:eeec5400
5261 [ 155.316913] r4:eeec5414
5262 [ 155.319482] [<c00577a0>] (worker_thread) from [<c005cc40>] (kthread+0xdc/0xf8)
5263 [ 155.326765] r10:00000000 r9:00000000 r8:00000000 r7:c00577a0 r6:ee434380 r5:ee4441c0
5264 [ 155.334713] r4:00000000 r3:00000000
5265 [ 155.338341] [<c005cb64>] (kthread) from [<c000fc08>] (ret_from_fork+0x14/0x2c)
5266 [ 155.345626] r7:00000000 r6:00000000 r5:c005cb64 r4:ee4441c0
5267 [ 155.356108] ---[ end trace a58d34c223b190e6 ]---
5268 [ 155.360783] xhci-hcd xhci-hcd.0.auto: Virt dev invalid for slot_id 0x1!
5269 [ 155.574404] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
5270 [ 155.579667] ------------[ cut here ]------------
5271
5272 Cc: <stable@vger.kernel.org>
5273 Signed-off-by: Roger Quadros <rogerq@ti.com>
5274 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
5275 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5276 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5277
5278commit b78034d9af682dd587aa49884b559f9ff51e8ef7
5279Author: Roger Quadros <rogerq@ti.com>
5280Date: Mon Sep 21 17:46:13 2015 +0300
5281
5282 usb: xhci: Clear XHCI_STATE_DYING on start
5283
5284 [ Upstream commit e5bfeab0ad515b4f6df39fe716603e9dc6d3dfd0 ]
5285
5286 For whatever reason if XHCI died in the previous instant
5287 then it will never recover on the next xhci_start unless we
5288 clear the DYING flag.
5289
5290 Cc: <stable@vger.kernel.org>
5291 Signed-off-by: Roger Quadros <rogerq@ti.com>
5292 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
5293 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5294 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5295
5296commit ad0473dde67387a9c5b3e25429cb8adac090a0af
5297Author: Johan Hovold <johan@kernel.org>
5298Date: Wed Sep 23 11:41:42 2015 -0700
5299
5300 USB: whiteheat: fix potential null-deref at probe
5301
5302 [ Upstream commit cbb4be652d374f64661137756b8f357a1827d6a4 ]
5303
5304 Fix potential null-pointer dereference at probe by making sure that the
5305 required endpoints are present.
5306
5307 The whiteheat driver assumes there are at least five pairs of bulk
5308 endpoints, of which the final pair is used for the "command port". An
5309 attempt to bind to an interface with fewer bulk endpoints would
5310 currently lead to an oops.
5311
5312 Fixes CVE-2015-5257.
5313
5314 Reported-by: Moein Ghasemzadeh <moein@istuary.com>
5315 Cc: stable <stable@vger.kernel.org>
5316 Signed-off-by: Johan Hovold <johan@kernel.org>
5317 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5318 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5319
5320commit 51bd52fb41d3f8669d2df20b63e1aa4b61cc9f8d
5321Author: Michel Dänzer <michel.daenzer@amd.com>
5322Date: Mon Sep 28 18:16:31 2015 +0900
5323
5324 drm/amdgpu: Restore LCD backlight level on resume
5325
5326 [ Upstream commit 74b3112e95073b351e3b0b9799795bc76f8415fa ]
5327
5328 Instead of only enabling the backlight (which seems to set it to max
5329 brightness), just re-set the current backlight level, which also takes
5330 care of enabling the backlight if necessary.
5331
5332 Port of radeon commit:
5333 drm/radeon: Restore LCD backlight level on resume (>= R5xx)
5334
5335 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
5336 Cc: stable@vger.kernel.org
5337 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5338
5339commit 6131d99de4a7a2d2e24f59dea3698006011f791e
5340Author: Daniel Vetter <daniel.vetter@ffwll.ch>
5341Date: Tue Jun 23 11:34:21 2015 +0200
5342
5343 drm: Reject DRI1 hw lock ioctl functions for kms drivers
5344
5345 [ Upstream commit da168d81b44898404d281d5dbe70154ab5f117c1 ]
5346
5347 I've done some extensive history digging across libdrm, mesa and
5348 xf86-video-{intel,nouveau,ati}. The only potential user of this with
5349 kms drivers I could find was ttmtest, which once used drmGetLock
5350 still. But that mistake was quickly fixed up. Even the intel xvmc
5351 library (which otherwise was really good with using dri1 stuff in kms
5352 mode) managed to never take the hw lock for dri2 (and hence kms).
5353
5354 Hence it should be save to unconditionally disallow this.
5355
5356 Cc: Peter Antoine <peter.antoine@intel.com>
5357 Reviewed-by: Peter Antoine <peter.antoine@intel.com>
5358 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
5359 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5360
5361commit 21330a631016d627759be437d992000b5bdbf7d2
5362Author: Jani Nikula <jani.nikula@intel.com>
5363Date: Thu Sep 17 16:42:07 2015 +0300
5364
5365 drm/i915/bios: handle MIPI Sequence Block v3+ gracefully
5366
5367 [ Upstream commit cd67d226ebd909d239d2c6e5a6abd6e2a338d1cd ]
5368
5369 The VBT MIPI Sequence Block version 3 has forward incompatible changes:
5370
5371 First, the block size in the header has been specified reserved, and the
5372 actual size is a separate 32-bit value within the block. The current
5373 find_section() function to will only look at the size in the block
5374 header, and, depending on what's in that now reserved size field,
5375 continue looking for other sections in the wrong place.
5376
5377 Fix this by taking the new block size field into account. This will
5378 ensure that the lookups for other sections will work properly, as long
5379 as the new 32-bit size does not go beyond the opregion VBT mailbox size.
5380
5381 Second, the contents of the block have been completely
5382 changed. Gracefully refuse parsing the yet unknown data version.
5383
5384 Cc: Deepak M <m.deepak@intel.com>
5385 Cc: stable@vger.kernel.org
5386 Reviewed-by: Deepak M <m.deepak@intel.com>
5387 Signed-off-by: Jani Nikula <jani.nikula@intel.com>
5388 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5389
5390commit 445e1554e787c657acb9c300c0556b71bddac8e7
5391Author: Fabiano Fidêncio <fidencio@redhat.com>
5392Date: Thu Sep 24 15:18:34 2015 +0200
5393
5394 drm/qxl: recreate the primary surface when the bo is not primary
5395
5396 [ Upstream commit 8d0d94015e96b8853c4f7f06eac3f269e1b3d866 ]
5397
5398 When disabling/enabling a crtc the primary area must be updated
5399 independently of which crtc has been disabled/enabled.
5400
5401 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735
5402
5403 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
5404 Cc: stable@vger.kernel.org
5405 Signed-off-by: Dave Airlie <airlied@redhat.com>
5406 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5407
5408commit dcd79cf88046986d1e4082ee12793124a0035798
5409Author: Dave Airlie <airlied@redhat.com>
5410Date: Mon Sep 14 10:28:34 2015 +1000
5411
5412 drm/qxl: only report first monitor as connected if we have no state
5413
5414 [ Upstream commit 69e5d3f893e19613486f300fd6e631810338aa4b ]
5415
5416 If the server isn't new enough to give us state, report the first
5417 monitor as always connected, otherwise believe the server side.
5418
5419 Cc: stable@vger.kernel.org
5420 Signed-off-by: Dave Airlie <airlied@redhat.com>
5421 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5422
5423commit ca5b6dad41ed3ceecc959b9a19b52c9aded89d39
5424Author: Steve French <smfrench@gmail.com>
5425Date: Mon Sep 28 17:21:07 2015 -0500
5426
5427 [SMB3] Do not fall back to SMBWriteX in set_file_size error cases
5428
5429 [ Upstream commit 646200a041203f440fb6fcf9cacd9efeda9de74c ]
5430
5431 The error paths in set_file_size for cifs and smb3 are incorrect.
5432
5433 In the unlikely event that a server did not support set file info
5434 of the file size, the code incorrectly falls back to trying SMBWriteX
5435 (note that only the original core SMB Write, used for example by DOS,
5436 can set the file size this way - this actually does not work for the more
5437 recent SMBWriteX). The idea was since the old DOS SMB Write could set
5438 the file size if you write zero bytes at that offset then use that if
5439 server rejects the normal set file info call.
5440
5441 Fortunately the SMBWriteX will never be sent on the wire (except when
5442 file size is zero) since the length and offset fields were reversed
5443 in the two places in this function that call SMBWriteX causing
5444 the fall back path to return an error. It is also important to never call
5445 an SMB request from an SMB2/sMB3 session (which theoretically would
5446 be possible, and can cause a brief session drop, although the client
5447 recovers) so this should be fixed. In practice this path does not happen
5448 with modern servers but the error fall back to SMBWriteX is clearly wrong.
5449
5450 Removing the calls to SMBWriteX in the error paths in cifs_set_file_size
5451
5452 Pointed out by PaX/grsecurity team
5453
5454 Signed-off-by: Steve French <steve.french@primarydata.com>
5455 Reported-by: PaX Team <pageexec@freemail.hu>
5456 CC: Emese Revfy <re.emese@gmail.com>
5457 CC: Brad Spengler <spender@grsecurity.net>
5458 CC: Stable <stable@vger.kernel.org>
5459 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5460
5461commit 27dc98701f026c09be9d459ae0bd432527be5ce5
5462Author: Steve French <smfrench@gmail.com>
5463Date: Tue Sep 22 09:29:38 2015 -0500
5464
5465 disabling oplocks/leases via module parm enable_oplocks broken for SMB3
5466
5467 [ Upstream commit e0ddde9d44e37fbc21ce893553094ecf1a633ab5 ]
5468
5469 leases (oplocks) were always requested for SMB2/SMB3 even when oplocks
5470 disabled in the cifs.ko module.
5471
5472 Signed-off-by: Steve French <steve.french@primarydata.com>
5473 Reviewed-by: Chandrika Srinivasan <chandrika.srinivasan@citrix.com>
5474 CC: Stable <stable@vger.kernel.org>
5475 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5476
5477commit 9c6e28cab8ebf2177dfe58930a8e17ca7043a4dc
5478Author: Peng Tao <tao.peng@primarydata.com>
5479Date: Fri Sep 11 11:14:06 2015 +0800
5480
5481 nfs: fix pg_test page count calculation
5482
5483 [ Upstream commit 048883e0b934d9a5103d40e209cb14b7f33d2933 ]
5484
5485 We really want sizeof(struct page *) instead. Otherwise we limit
5486 maximum IO size to 64 pages rather than 512 pages on a 64bit system.
5487
5488 Fixes 2e11f829(nfs: cap request size to fit a kmalloced page array).
5489
5490 Cc: Christoph Hellwig <hch@lst.de>
5491 Signed-off-by: Peng Tao <tao.peng@primarydata.com>
5492 Fixes: 2e11f8296d22 ("nfs: cap request size to fit a kmalloced page array")
5493 Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
5494 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5495
5496commit e79740704034182a5961d774f4c87025db4eb0e3
5497Author: Florian Westphal <fw@strlen.de>
5498Date: Wed Sep 9 02:57:21 2015 +0200
5499
5500 netfilter: nf_log: don't zap all loggers on unregister
5501
5502 [ Upstream commit 205ee117d4dc4a11ac3bd9638bb9b2e839f4de9a ]
5503
5504 like nf_log_unset, nf_log_unregister must not reset the list of loggers.
5505 Otherwise, a call to nf_log_unregister() will render loggers of other nf
5506 protocols unusable:
5507
5508 iptables -A INPUT -j LOG
5509 modprobe nf_log_arp ; rmmod nf_log_arp
5510 iptables -A INPUT -j LOG
5511 iptables: No chain/target/match by that name
5512
5513 Fixes: 30e0c6a6be ("netfilter: nf_log: prepare net namespace support for loggers")
5514 Signed-off-by: Florian Westphal <fw@strlen.de>
5515 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5516 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5517
5518commit 0496ef122e0b9296f27e1493aaaa217c9497f8d1
5519Author: Marcelo Leitner <mleitner@redhat.com>
5520Date: Wed Oct 29 10:04:51 2014 -0200
5521
5522 netfilter: nf_log: Introduce nft_log_dereference() macro
5523
5524 [ Upstream commit 0c26ed1c07f13ca27e2638ffdd1951013ed96c48 ]
5525
5526 Wrap up a common call pattern in an easier to handle call.
5527
5528 Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
5529 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5530 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5531
5532commit 0b41eaece3a6f675c3940ca694a10c449ea9d227
5533Author: Pablo Neira Ayuso <pablo@netfilter.org>
5534Date: Mon Sep 14 18:04:09 2015 +0200
5535
5536 netfilter: nft_compat: skip family comparison in case of NFPROTO_UNSPEC
5537
5538 [ Upstream commit ba378ca9c04a5fc1b2cf0f0274a9d02eb3d1bad9 ]
5539
5540 Fix lookup of existing match/target structures in the corresponding list
5541 by skipping the family check if NFPROTO_UNSPEC is used.
5542
5543 This is resulting in the allocation and insertion of one match/target
5544 structure for each use of them. So this not only bloats memory
5545 consumption but also severely affects the time to reload the ruleset
5546 from the iptables-compat utility.
5547
5548 After this patch, iptables-compat-restore and iptables-compat take
5549 almost the same time to reload large rulesets.
5550
5551 Fixes: 0ca743a55991 ("netfilter: nf_tables: add compatibility layer for x_tables")
5552 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5553 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5554
5555commit 1aaf3bed304e54b4e4d3cac938f5560bc6b8f52d
5556Author: Pablo Neira Ayuso <pablo@netfilter.org>
5557Date: Thu Sep 17 13:37:00 2015 +0200
5558
5559 netfilter: nf_log: wait for rcu grace after logger unregistration
5560
5561 [ Upstream commit ad5001cc7cdf9aaee5eb213fdee657e4a3c94776 ]
5562
5563 The nf_log_unregister() function needs to call synchronize_rcu() to make sure
5564 that the objects are not dereferenced anymore on module removal.
5565
5566 Fixes: 5962815a6a56 ("netfilter: nf_log: use an array of loggers instead of list")
5567 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5568 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5569
5570commit f71252c2c3d7bac9895de13bf6005bc34daee2ac
5571Author: Pablo Neira Ayuso <pablo@netfilter.org>
5572Date: Thu Jul 9 22:56:00 2015 +0200
5573
5574 netfilter: ctnetlink: put back references to master ct and expect objects
5575
5576 [ Upstream commit 95dd8653de658143770cb0e55a58d2aab97c79d2 ]
5577
5578 We have to put back the references to the master conntrack and the expectation
5579 that we just created, otherwise we'll leak them.
5580
5581 Fixes: 0ef71ee1a5b9 ("netfilter: ctnetlink: refactor ctnetlink_create_expect")
5582 Reported-by: Tim Wiess <Tim.Wiess@watchguard.com>
5583 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5584 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5585
5586commit a9108c7e36ad49c61e4f82a52f00e04bfa9b5882
5587Author: Joe Stringer <joestringer@nicira.com>
5588Date: Tue Jul 21 21:37:31 2015 -0700
5589
5590 netfilter: nf_conntrack: Support expectations in different zones
5591
5592 [ Upstream commit 4b31814d20cbe5cd4ccf18089751e77a04afe4f2 ]
5593
5594 When zones were originally introduced, the expectation functions were
5595 all extended to perform lookup using the zone. However, insertion was
5596 not modified to check the zone. This means that two expectations which
5597 are intended to apply for different connections that have the same tuple
5598 but exist in different zones cannot both be tracked.
5599
5600 Fixes: 5d0aa2ccd4 (netfilter: nf_conntrack: add support for "conntrack zones")
5601 Signed-off-by: Joe Stringer <joestringer@nicira.com>
5602 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5603 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5604
5605commit aef4db8e27803571e673ea2cf9c0e5c2a6dd1f49
5606Author: Pablo Neira Ayuso <pablo@netfilter.org>
5607Date: Fri Aug 28 21:01:43 2015 +0200
5608
5609 netfilter: nfnetlink: work around wrong endianess in res_id field
5610
5611 [ Upstream commit a9de9777d613500b089a7416f936bf3ae5f070d2 ]
5612
5613 The convention in nfnetlink is to use network byte order in every header field
5614 as well as in the attribute payload. The initial version of the batching
5615 infrastructure assumes that res_id comes in host byte order though.
5616
5617 The only client of the batching infrastructure is nf_tables, so let's add a
5618 workaround to address this inconsistency. We currently have 11 nfnetlink
5619 subsystems according to NFNL_SUBSYS_COUNT, so we can assume that the subsystem
5620 2560, ie. htons(10), will not be allocated anytime soon, so it can be an alias
5621 of nf_tables from the nfnetlink batching path when interpreting the res_id
5622 field.
5623
5624 Based on original patch from Florian Westphal.
5625
5626 Reported-by: Florian Westphal <fw@strlen.de>
5627 Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
5628 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5629
5630commit 7b4543bf7ea8f6018385a29ade02038d532e406a
5631Author: Mikulas Patocka <mpatocka@redhat.com>
5632Date: Fri Oct 2 11:17:37 2015 -0400
5633
5634 dm raid: fix round up of default region size
5635
5636 [ Upstream commit 042745ee53a0a7c1f5aff191a4a24213c6dcfb52 ]
5637
5638 Commit 3a0f9aaee028 ("dm raid: round region_size to power of two")
5639 intended to make sure that the default region size is a power of two.
5640 However, the logic in that commit is incorrect and sets the variable
5641 region_size to 0 or 1, depending on whether min_region_size is a power
5642 of two.
5643
5644 Fix this logic, using roundup_pow_of_two(), so that region_size is
5645 properly rounded up to the next power of two.
5646
5647 Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
5648 Fixes: 3a0f9aaee028 ("dm raid: round region_size to power of two")
5649 Cc: stable@vger.kernel.org # v3.8+
5650 Signed-off-by: Mike Snitzer <snitzer@redhat.com>
5651 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5652
5653commit ab92cac0bfb5e4c27ea8f6139118f13b982c51b9
5654Author: Liu.Zhao <lzsos369@163.com>
5655Date: Mon Aug 24 08:36:12 2015 -0700
5656
5657 USB: option: add ZTE PIDs
5658
5659 [ Upstream commit 19ab6bc5674a30fdb6a2436b068d19a3c17dc73e ]
5660
5661 This is intended to add ZTE device PIDs on kernel.
5662
5663 Signed-off-by: Liu.Zhao <lzsos369@163.com>
5664 Cc: stable <stable@vger.kernel.org>
5665 [johan: sort the new entries ]
5666 Signed-off-by: Johan Hovold <johan@kernel.org>
5667
5668 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5669
5670commit 5fdd843e65edc2727ba630519559430bd276cb9c
5671Author: Joe Thornber <ejt@redhat.com>
5672Date: Wed Aug 12 15:12:09 2015 +0100
5673
5674 dm btree: add ref counting ops for the leaves of top level btrees
5675
5676 [ Upstream commit b0dc3c8bc157c60b1d470163882be8c13e1950af ]
5677
5678 When using nested btrees, the top leaves of the top levels contain
5679 block addresses for the root of the next tree down. If we shadow a
5680 shared leaf node the leaf values (sub tree roots) should be incremented
5681 accordingly.
5682
5683 This is only an issue if there is metadata sharing in the top levels.
5684 Which only occurs if metadata snapshots are being used (as is possible
5685 with dm-thinp). And could result in a block from the thinp metadata
5686 snap being reused early, thus corrupting the thinp metadata snap.
5687
5688 Signed-off-by: Joe Thornber <ejt@redhat.com>
5689 Signed-off-by: Mike Snitzer <snitzer@redhat.com>
5690 Cc: stable@vger.kernel.org
5691 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5692
5693commit 11982b198b595fab7c996fa7b15d655e1a84e933
5694Author: Chuck Lever <chuck.lever@oracle.com>
5695Date: Thu Jul 9 16:45:18 2015 -0400
5696
5697 svcrdma: Fix send_reply() scatter/gather set-up
5698
5699 [ Upstream commit 9d11b51ce7c150a69e761e30518f294fc73d55ff ]
5700
5701 The Linux NFS server returns garbage in the data payload of inline
5702 NFS/RDMA READ replies. These are READs of under 1000 bytes or so
5703 where the client has not provided either a reply chunk or a write
5704 list.
5705
5706 The NFS server delivers the data payload for an NFS READ reply to
5707 the transport in an xdr_buf page list. If the NFS client did not
5708 provide a reply chunk or a write list, send_reply() is supposed to
5709 set up a separate sge for the page containing the READ data, and
5710 another sge for XDR padding if needed, then post all of the sges via
5711 a single SEND Work Request.
5712
5713 The problem is send_reply() does not advance through the xdr_buf
5714 when setting up scatter/gather entries for SEND WR. It always calls
5715 dma_map_xdr with xdr_off set to zero. When there's more than one
5716 sge, dma_map_xdr() sets up the SEND sge's so they all point to the
5717 xdr_buf's head.
5718
5719 The current Linux NFS/RDMA client always provides a reply chunk or
5720 a write list when performing an NFS READ over RDMA. Therefore, it
5721 does not exercise this particular case. The Linux server has never
5722 had to use more than one extra sge for building RPC/RDMA replies
5723 with a Linux client.
5724
5725 However, an NFS/RDMA client _is_ allowed to send small NFS READs
5726 without setting up a write list or reply chunk. The NFS READ reply
5727 fits entirely within the inline reply buffer in this case. This is
5728 perhaps a more efficient way of performing NFS READs that the Linux
5729 NFS/RDMA client may some day adopt.
5730
5731 Fixes: b432e6b3d9c1 ('svcrdma: Change DMA mapping logic to . . .')
5732 BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285
5733 Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
5734 Signed-off-by: J. Bruce Fields <bfields@redhat.com>
5735 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5736
5737commit 41d3120a5cd75117ac7f681514c27180cae7e8c2
5738Author: Michal Kazior <michal.kazior@tieto.com>
5739Date: Wed Aug 19 13:10:43 2015 +0200
5740
5741 ath10k: fix dma_mapping_error() handling
5742
5743 [ Upstream commit 5e55e3cbd1042cffa6249f22c10585e63f8a29bf ]
5744
5745 The function returns 1 when DMA mapping fails. The
5746 driver would return bogus values and could
5747 possibly confuse itself if DMA failed.
5748
5749 Fixes: 767d34fc67af ("ath10k: remove DMA mapping wrappers")
5750 Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
5751 Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
5752 Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
5753 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5754
5755commit b2abcec9c58d844e9cf506329cbff89521457702
5756Author: Filipe Manana <fdmanana@suse.com>
5757Date: Mon Sep 28 09:56:26 2015 +0100
5758
5759 Btrfs: update fix for read corruption of compressed and shared extents
5760
5761 [ Upstream commit 808f80b46790f27e145c72112189d6a3be2bc884 ]
5762
5763 My previous fix in commit 005efedf2c7d ("Btrfs: fix read corruption of
5764 compressed and shared extents") was effective only if the compressed
5765 extents cover a file range with a length that is not a multiple of 16
5766 pages. That's because the detection of when we reached a different range
5767 of the file that shares the same compressed extent as the previously
5768 processed range was done at extent_io.c:__do_contiguous_readpages(),
5769 which covers subranges with a length up to 16 pages, because
5770 extent_readpages() groups the pages in clusters no larger than 16 pages.
5771 So fix this by tracking the start of the previously processed file
5772 range's extent map at extent_readpages().
5773
5774 The following test case for fstests reproduces the issue:
5775
5776 seq=`basename $0`
5777 seqres=$RESULT_DIR/$seq
5778 echo "QA output created by $seq"
5779 tmp=/tmp/$$
5780 status=1 # failure is the default!
5781 trap "_cleanup; exit \$status" 0 1 2 3 15
5782
5783 _cleanup()
5784 {
5785 rm -f $tmp.*
5786 }
5787
5788 # get standard environment, filters and checks
5789 . ./common/rc
5790 . ./common/filter
5791
5792 # real QA test starts here
5793 _need_to_be_root
5794 _supported_fs btrfs
5795 _supported_os Linux
5796 _require_scratch
5797 _require_cloner
5798
5799 rm -f $seqres.full
5800
5801 test_clone_and_read_compressed_extent()
5802 {
5803 local mount_opts=$1
5804
5805 _scratch_mkfs >>$seqres.full 2>&1
5806 _scratch_mount $mount_opts
5807
5808 # Create our test file with a single extent of 64Kb that is going to
5809 # be compressed no matter which compression algo is used (zlib/lzo).
5810 $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 64K" \
5811 $SCRATCH_MNT/foo | _filter_xfs_io
5812
5813 # Now clone the compressed extent into an adjacent file offset.
5814 $CLONER_PROG -s 0 -d $((64 * 1024)) -l $((64 * 1024)) \
5815 $SCRATCH_MNT/foo $SCRATCH_MNT/foo
5816
5817 echo "File digest before unmount:"
5818 md5sum $SCRATCH_MNT/foo | _filter_scratch
5819
5820 # Remount the fs or clear the page cache to trigger the bug in
5821 # btrfs. Because the extent has an uncompressed length that is a
5822 # multiple of 16 pages, all the pages belonging to the second range
5823 # of the file (64K to 128K), which points to the same extent as the
5824 # first range (0K to 64K), had their contents full of zeroes instead
5825 # of the byte 0xaa. This was a bug exclusively in the read path of
5826 # compressed extents, the correct data was stored on disk, btrfs
5827 # just failed to fill in the pages correctly.
5828 _scratch_remount
5829
5830 echo "File digest after remount:"
5831 # Must match the digest we got before.
5832 md5sum $SCRATCH_MNT/foo | _filter_scratch
5833 }
5834
5835 echo -e "\nTesting with zlib compression..."
5836 test_clone_and_read_compressed_extent "-o compress=zlib"
5837
5838 _scratch_unmount
5839
5840 echo -e "\nTesting with lzo compression..."
5841 test_clone_and_read_compressed_extent "-o compress=lzo"
5842
5843 status=0
5844 exit
5845
5846 Cc: stable@vger.kernel.org
5847 Signed-off-by: Filipe Manana <fdmanana@suse.com>
5848 Tested-by: Timofey Titovets <nefelim4ag@gmail.com>
5849 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5850
5851commit fc6c5152944cc7462391953667a9ac214dad3a94
5852Author: Filipe Manana <fdmanana@suse.com>
5853Date: Mon Sep 14 09:09:31 2015 +0100
5854
5855 Btrfs: fix read corruption of compressed and shared extents
5856
5857 [ Upstream commit 005efedf2c7d0a270ffbe28d8997b03844f3e3e7 ]
5858
5859 If a file has a range pointing to a compressed extent, followed by
5860 another range that points to the same compressed extent and a read
5861 operation attempts to read both ranges (either completely or part of
5862 them), the pages that correspond to the second range are incorrectly
5863 filled with zeroes.
5864
5865 Consider the following example:
5866
5867 File layout
5868 [0 - 8K] [8K - 24K]
5869 | |
5870 | |
5871 points to extent X, points to extent X,
5872 offset 4K, length of 8K offset 0, length 16K
5873
5874 [extent X, compressed length = 4K uncompressed length = 16K]
5875
5876 If a readpages() call spans the 2 ranges, a single bio to read the extent
5877 is submitted - extent_io.c:submit_extent_page() would only create a new
5878 bio to cover the second range pointing to the extent if the extent it
5879 points to had a different logical address than the extent associated with
5880 the first range. This has a consequence of the compressed read end io
5881 handler (compression.c:end_compressed_bio_read()) finish once the extent
5882 is decompressed into the pages covering the first range, leaving the
5883 remaining pages (belonging to the second range) filled with zeroes (done
5884 by compression.c:btrfs_clear_biovec_end()).
5885
5886 So fix this by submitting the current bio whenever we find a range
5887 pointing to a compressed extent that was preceded by a range with a
5888 different extent map. This is the simplest solution for this corner
5889 case. Making the end io callback populate both ranges (or more, if we
5890 have multiple pointing to the same extent) is a much more complex
5891 solution since each bio is tightly coupled with a single extent map and
5892 the extent maps associated to the ranges pointing to the shared extent
5893 can have different offsets and lengths.
5894
5895 The following test case for fstests triggers the issue:
5896
5897 seq=`basename $0`
5898 seqres=$RESULT_DIR/$seq
5899 echo "QA output created by $seq"
5900 tmp=/tmp/$$
5901 status=1 # failure is the default!
5902 trap "_cleanup; exit \$status" 0 1 2 3 15
5903
5904 _cleanup()
5905 {
5906 rm -f $tmp.*
5907 }
5908
5909 # get standard environment, filters and checks
5910 . ./common/rc
5911 . ./common/filter
5912
5913 # real QA test starts here
5914 _need_to_be_root
5915 _supported_fs btrfs
5916 _supported_os Linux
5917 _require_scratch
5918 _require_cloner
5919
5920 rm -f $seqres.full
5921
5922 test_clone_and_read_compressed_extent()
5923 {
5924 local mount_opts=$1
5925
5926 _scratch_mkfs >>$seqres.full 2>&1
5927 _scratch_mount $mount_opts
5928
5929 # Create a test file with a single extent that is compressed (the
5930 # data we write into it is highly compressible no matter which
5931 # compression algorithm is used, zlib or lzo).
5932 $XFS_IO_PROG -f -c "pwrite -S 0xaa 0K 4K" \
5933 -c "pwrite -S 0xbb 4K 8K" \
5934 -c "pwrite -S 0xcc 12K 4K" \
5935 $SCRATCH_MNT/foo | _filter_xfs_io
5936
5937 # Now clone our extent into an adjacent offset.
5938 $CLONER_PROG -s $((4 * 1024)) -d $((16 * 1024)) -l $((8 * 1024)) \
5939 $SCRATCH_MNT/foo $SCRATCH_MNT/foo
5940
5941 # Same as before but for this file we clone the extent into a lower
5942 # file offset.
5943 $XFS_IO_PROG -f -c "pwrite -S 0xaa 8K 4K" \
5944 -c "pwrite -S 0xbb 12K 8K" \
5945 -c "pwrite -S 0xcc 20K 4K" \
5946 $SCRATCH_MNT/bar | _filter_xfs_io
5947
5948 $CLONER_PROG -s $((12 * 1024)) -d 0 -l $((8 * 1024)) \
5949 $SCRATCH_MNT/bar $SCRATCH_MNT/bar
5950
5951 echo "File digests before unmounting filesystem:"
5952 md5sum $SCRATCH_MNT/foo | _filter_scratch
5953 md5sum $SCRATCH_MNT/bar | _filter_scratch
5954
5955 # Evicting the inode or clearing the page cache before reading
5956 # again the file would also trigger the bug - reads were returning
5957 # all bytes in the range corresponding to the second reference to
5958 # the extent with a value of 0, but the correct data was persisted
5959 # (it was a bug exclusively in the read path). The issue happened
5960 # only if the same readpages() call targeted pages belonging to the
5961 # first and second ranges that point to the same compressed extent.
5962 _scratch_remount
5963
5964 echo "File digests after mounting filesystem again:"
5965 # Must match the same digests we got before.
5966 md5sum $SCRATCH_MNT/foo | _filter_scratch
5967 md5sum $SCRATCH_MNT/bar | _filter_scratch
5968 }
5969
5970 echo -e "\nTesting with zlib compression..."
5971 test_clone_and_read_compressed_extent "-o compress=zlib"
5972
5973 _scratch_unmount
5974
5975 echo -e "\nTesting with lzo compression..."
5976 test_clone_and_read_compressed_extent "-o compress=lzo"
5977
5978 status=0
5979 exit
5980
5981 Cc: stable@vger.kernel.org
5982 Signed-off-by: Filipe Manana <fdmanana@suse.com>
5983 Reviewed-by: Qu Wenruo<quwenruo@cn.fujitsu.com>
5984 Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
5985 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
5986
5987commit 1fb045a8b0bbfb757e114d5d0ad4dfb335346dc7
5988Author: Jeff Mahoney <jeffm@suse.com>
5989Date: Fri Sep 11 21:44:17 2015 -0400
5990
5991 btrfs: skip waiting on ordered range for special files
5992
5993 [ Upstream commit a30e577c96f59b1e1678ea5462432b09bf7d5cbc ]
5994
5995 In btrfs_evict_inode, we properly truncate the page cache for evicted
5996 inodes but then we call btrfs_wait_ordered_range for every inode as well.
5997 It's the right thing to do for regular files but results in incorrect
5998 behavior for device inodes for block devices.
5999
6000 filemap_fdatawrite_range gets called with inode->i_mapping which gets
6001 resolved to the block device inode before getting passed to
6002 wbc_attach_fdatawrite_inode and ultimately to inode_to_bdi. What happens
6003 next depends on whether there's an open file handle associated with the
6004 inode. If there is, we write to the block device, which is unexpected
6005 behavior. If there isn't, we through normally and inode->i_data is used.
6006 We can also end up racing against open/close which can result in crashes
6007 when i_mapping points to a block device inode that has been closed.
6008
6009 Since there can't be any page cache associated with special file inodes,
6010 it's safe to skip the btrfs_wait_ordered_range call entirely and avoid
6011 the problem.
6012
6013 Cc: <stable@vger.kernel.org>
6014 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100911
6015 Tested-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
6016 Signed-off-by: Jeff Mahoney <jeffm@suse.com>
6017 Reviewed-by: Filipe Manana <fdmanana@suse.com>
6018 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6019
6020commit e1a73316b1c356860a5d5ee7c7ecf30a3880516d
6021Author: Yitian Bu <buyitian@gmail.com>
6022Date: Fri Oct 2 15:18:41 2015 +0800
6023
6024 ASoC: dwc: correct irq clear method
6025
6026 [ Upstream commit 4873867e5f2bd90faad861dd94865099fc3140f3 ]
6027
6028 from Designware I2S datasheet, tx/rx XRUN irq is cleared by
6029 reading register TOR/ROR, rather than by writing into them.
6030
6031 Signed-off-by: Yitian Bu <yitian.bu@tangramtek.com>
6032 Signed-off-by: Mark Brown <broonie@kernel.org>
6033 Cc: stable@vger.kernel.org
6034 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6035
6036commit 44594dddabd8e4e6b0a388b8ff9b5e06a6e782db
6037Author: Robert Jarzmik <robert.jarzmik@free.fr>
6038Date: Tue Sep 15 20:51:31 2015 +0200
6039
6040 ASoC: fix broken pxa SoC support
6041
6042 [ Upstream commit 3c8f7710c1c44fb650bc29b6ef78ed8b60cfaa28 ]
6043
6044 The previous fix of pxa library support, which was introduced to fix the
6045 library dependency, broke the previous SoC behavior, where a machine
6046 code binding pxa2xx-ac97 with a coded relied on :
6047 - sound/soc/pxa/pxa2xx-ac97.c
6048 - sound/soc/codecs/XXX.c
6049
6050 For example, the mioa701_wm9713.c machine code is currently broken. The
6051 "select ARM" statement wrongly selects the soc/arm/pxa2xx-ac97 for
6052 compilation, as per an unfortunate fate SND_PXA2XX_AC97 is both declared
6053 in sound/arm/Kconfig and sound/soc/pxa/Kconfig.
6054
6055 Fix this by ensuring that SND_PXA2XX_SOC correctly triggers the correct
6056 pxa2xx-ac97 compilation.
6057
6058 Fixes: 846172dfe33c ("ASoC: fix SND_PXA2XX_LIB Kconfig warning")
6059 Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
6060 Signed-off-by: Mark Brown <broonie@kernel.org>
6061 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6062
6063commit b402bfb3dd7ae94cea9f9e583631f08837442a0a
6064Author: Robert Jarzmik <robert.jarzmik@free.fr>
6065Date: Tue Sep 22 21:20:22 2015 +0200
6066
6067 ASoC: pxa: pxa2xx-ac97: fix dma requestor lines
6068
6069 [ Upstream commit 8811191fdf7ed02ee07cb8469428158572d355a2 ]
6070
6071 PCM receive and transmit DMA requestor lines were reverted, breaking the
6072 PCM playback interface for PXA platforms using the sound/soc/ variant
6073 instead of the sound/arm variant.
6074
6075 The commit below shows the inversion in the requestor lines.
6076
6077 Fixes: d65a14587a9b ("ASoC: pxa: use snd_dmaengine_dai_dma_data")
6078 Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
6079 Signed-off-by: Mark Brown <broonie@kernel.org>
6080 Cc: stable@vger.kernel.org
6081 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6082
6083commit e7c645a25f3a201fd2e8d097a52d50a6ba01fec3
6084Author: John Flatness <john@zerocrates.org>
6085Date: Fri Oct 2 17:07:49 2015 -0400
6086
6087 ALSA: hda - Apply SPDIF pin ctl to MacBookPro 12,1
6088
6089 [ Upstream commit e8ff581f7ac2bc3b8886094b7ca635dcc4d1b0e9 ]
6090
6091 The MacBookPro 12,1 has the same setup as the 11 for controlling the
6092 status of the optical audio light. Simply apply the existing workaround
6093 to the subsystem ID for the 12,1.
6094
6095 [sorted the fixup entry by tiwai]
6096
6097 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105401
6098 Signed-off-by: John Flatness <john@zerocrates.org>
6099 Cc: <stable@vger.kernel.org>
6100 Signed-off-by: Takashi Iwai <tiwai@suse.de>
6101 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6102
6103commit f60c8a5f2697193ea4b08b0f554c7265df8bbb11
6104Author: Laura Abbott <labbott@fedoraproject.org>
6105Date: Fri Oct 2 11:09:54 2015 -0700
6106
6107 ALSA: hda: Add dock support for ThinkPad T550
6108
6109 [ Upstream commit d05ea7da0e8f6df3c62cfee75538f347cb3d89ef ]
6110
6111 Much like all the other Lenovo laptops, add a quirk to make
6112 sound work with docking.
6113
6114 Reported-and-tested-by: lacknerflo@gmail.com
6115 Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
6116 Cc: <stable@vger.kernel.org>
6117 Signed-off-by: Takashi Iwai <tiwai@suse.de>
6118 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6119
6120commit e701ac72198baa78ee26b1c6da77173371346122
6121Author: Takashi Iwai <tiwai@suse.de>
6122Date: Mon Oct 5 16:55:09 2015 +0200
6123
6124 ALSA: synth: Fix conflicting OSS device registration on AWE32
6125
6126 [ Upstream commit 225db5762dc1a35b26850477ffa06e5cd0097243 ]
6127
6128 When OSS emulation is loaded on ISA SB AWE32 chip, we get now kernel
6129 warnings like:
6130 WARNING: CPU: 0 PID: 2791 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x51/0x80()
6131 sysfs: cannot create duplicate filename '/devices/isa/sbawe.0/sound/card0/seq-oss-0-0'
6132
6133 It's because both emux synth and opl3 drivers try to register their
6134 OSS device object with the same static index number 0. This hasn't
6135 been a big problem until the recent rewrite of device management code
6136 (that exposes sysfs at the same time), but it's been an obvious bug.
6137
6138 This patch works around it just by using a different index number of
6139 emux synth object. There can be a more elegant way to fix, but it's
6140 enough for now, as this code won't be touched so often, in anyway.
6141
6142 Reported-and-tested-by: Michael Shell <list1@michaelshell.org>
6143 Cc: <stable@vger.kernel.org>
6144 Signed-off-by: Takashi Iwai <tiwai@suse.de>
6145 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6146
6147commit 0e4cfed8f063028430bfc6883217698fca3c35ab
6148Author: Mel Gorman <mgorman@techsingularity.net>
6149Date: Thu Oct 1 15:36:57 2015 -0700
6150
6151 mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault
6152
6153 [ Upstream commit 2f84a8990ebbe235c59716896e017c6b2ca1200f ]
6154
6155 SunDong reported the following on
6156
6157 https://bugzilla.kernel.org/show_bug.cgi?id=103841
6158
6159 I think I find a linux bug, I have the test cases is constructed. I
6160 can stable recurring problems in fedora22(4.0.4) kernel version,
6161 arch for x86_64. I construct transparent huge page, when the parent
6162 and child process with MAP_SHARE, MAP_PRIVATE way to access the same
6163 huge page area, it has the opportunity to lead to huge page copy on
6164 write failure, and then it will munmap the child corresponding mmap
6165 area, but then the child mmap area with VM_MAYSHARE attributes, child
6166 process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
6167 functions (vma - > vm_flags & VM_MAYSHARE).
6168
6169 There were a number of problems with the report (e.g. it's hugetlbfs that
6170 triggers this, not transparent huge pages) but it was fundamentally
6171 correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
6172 looks like this
6173
6174 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
6175 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
6176 prot 8000000000000027 anon_vma (null) vm_ops ffffffff8182a7a0
6177 pgoff 0 file ffff88106bdb9800 private_data (null)
6178 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
6179 ------------
6180 kernel BUG at mm/hugetlb.c:462!
6181 SMP
6182 Modules linked in: xt_pkttype xt_LOG xt_limit [..]
6183 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
6184 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
6185 set_vma_resv_flags+0x2d/0x30
6186
6187 The VM_BUG_ON is correct because private and shared mappings have
6188 different reservation accounting but the warning clearly shows that the
6189 VMA is shared.
6190
6191 When a private COW fails to allocate a new page then only the process
6192 that created the VMA gets the page -- all the children unmap the page.
6193 If the children access that data in the future then they get killed.
6194
6195 The problem is that the same file is mapped shared and private. During
6196 the COW, the allocation fails, the VMAs are traversed to unmap the other
6197 private pages but a shared VMA is found and the bug is triggered. This
6198 patch identifies such VMAs and skips them.
6199
6200 Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
6201 Reported-by: SunDong <sund_sky@126.com>
6202 Reviewed-by: Michal Hocko <mhocko@suse.com>
6203 Cc: Andrea Arcangeli <aarcange@redhat.com>
6204 Cc: Hugh Dickins <hughd@google.com>
6205 Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
6206 Cc: David Rientjes <rientjes@google.com>
6207 Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
6208 Cc: <stable@vger.kernel.org>
6209 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
6210 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
6211 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6212
6213commit efddc65b3ecb2d1e7043a96d5f673760f22742d2
6214Author: Joseph Qi <joseph.qi@huawei.com>
6215Date: Tue Sep 22 14:59:20 2015 -0700
6216
6217 ocfs2/dlm: fix deadlock when dispatch assert master
6218
6219 [ Upstream commit 012572d4fc2e4ddd5c8ec8614d51414ec6cae02a ]
6220
6221 The order of the following three spinlocks should be:
6222 dlm_domain_lock < dlm_ctxt->spinlock < dlm_lock_resource->spinlock
6223
6224 But dlm_dispatch_assert_master() is called while holding
6225 dlm_ctxt->spinlock and dlm_lock_resource->spinlock, and then it calls
6226 dlm_grab() which will take dlm_domain_lock.
6227
6228 Once another thread (for example, dlm_query_join_handler) has already
6229 taken dlm_domain_lock, and tries to take dlm_ctxt->spinlock deadlock
6230 happens.
6231
6232 Signed-off-by: Joseph Qi <joseph.qi@huawei.com>
6233 Cc: Joel Becker <jlbec@evilplan.org>
6234 Cc: Mark Fasheh <mfasheh@suse.com>
6235 Cc: "Junxiao Bi" <junxiao.bi@oracle.com>
6236 Cc: <stable@vger.kernel.org>
6237 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
6238 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
6239 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6240
6241commit bf61da4411682000a12ad7756d62fe7985fd8523
6242Author: Tan, Jui Nee <jui.nee.tan@intel.com>
6243Date: Tue Sep 1 10:22:51 2015 +0800
6244
6245 spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled
6246
6247 [ Upstream commit 02bc933ebb59208f42c2e6305b2c17fd306f695d ]
6248
6249 On Intel Baytrail, there is case when interrupt handler get called, no SPI
6250 message is captured. The RX FIFO is indeed empty when RX timeout pending
6251 interrupt (SSSR_TINT) happens.
6252
6253 Use the BIOS version where both HSUART and SPI are on the same IRQ. Both
6254 drivers are using IRQF_SHARED when calling the request_irq function. When
6255 running two separate and independent SPI and HSUART application that
6256 generate data traffic on both components, user will see messages like
6257 below on the console:
6258
6259 pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler
6260
6261 This commit will fix this by first checking Receiver Time-out Interrupt,
6262 if it is disabled, ignore the request and return without servicing.
6263
6264 Signed-off-by: Tan, Jui Nee <jui.nee.tan@intel.com>
6265 Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
6266 Signed-off-by: Mark Brown <broonie@kernel.org>
6267 Cc: stable@vger.kernel.org
6268 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6269
6270commit a94229eb62f288a04ddafa39abce4a0b9f6280fc
6271Author: Max Filippov <jcmvbkbc@gmail.com>
6272Date: Tue Sep 22 14:32:03 2015 +0300
6273
6274 spi: xtensa-xtfpga: fix register endianness
6275
6276 [ Upstream commit b0b4855099e301c8603ea37da9a0103a96c2e0b1 ]
6277
6278 XTFPGA SPI controller has native endian registers.
6279 Fix register acessors so that they work in big-endian configurations.
6280
6281 Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
6282 Signed-off-by: Mark Brown <broonie@kernel.org>
6283 Cc: stable@vger.kernel.org
6284 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6285
6286commit 628e5c38cf55892da4e202e6a4940617e1ec8ee8
6287Author: Guenter Roeck <linux@roeck-us.net>
6288Date: Sun Sep 6 01:46:54 2015 +0300
6289
6290 spi: Fix documentation of spi_alloc_master()
6291
6292 [ Upstream commit a394d635193b641f2c86ead5ada5b115d57c51f8 ]
6293
6294 Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
6295 by kfree(). The memory is already freed with the call to spi_master_put()
6296 through spi_master_class, which registers a release function. Calling both
6297 spi_master_put() and kfree() results in often nasty (and delayed) crashes
6298 elsewhere in the kernel, often in the networking stack.
6299
6300 This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.
6301
6302 Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269
6303 or
6304 http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html
6305
6306 Alexey Klimov: This revert becomes valid after
6307 94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c
6308 has been fixed and there is no need to call kfree() so comment
6309 for spi_alloc_master() should be fixed.
6310
6311 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
6312 Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
6313 Signed-off-by: Mark Brown <broonie@kernel.org>
6314 Cc: stable@vger.kernel.org
6315 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6316
6317commit 91f073fb956fa7e16d56b18be462059a203e97d3
6318Author: Christian Borntraeger <borntraeger@de.ibm.com>
6319Date: Mon Sep 28 22:47:42 2015 +0200
6320
6321 s390/boot/decompression: disable floating point in decompressor
6322
6323 [ Upstream commit adc0b7fbf6fe9967505c0254d9535ec7288186ae ]
6324
6325 my gcc 5.1 used an ldgr instruction with a register != 0,2,4,6 for
6326 spilling/filling into a floating point register in our decompressor.
6327
6328 This will cause an AFP-register data exception as the decompressor
6329 did not setup the additional floating point registers via cr0.
6330 That causes a program check loop that looked like a hang with
6331 one "Uncompressing Linux... " message (directly booted via kvm)
6332 or a loop of "Uncompressing Linux... " messages (when booted via
6333 zipl boot loader).
6334
6335 The offending code in my build was
6336
6337 48e400: e3 c0 af ff ff 71 lay %r12,-1(%r10)
6338 -->48e406: b3 c1 00 1c ldgr %f1,%r12
6339 48e40a: ec 6c 01 22 02 7f clij %r6,2,12,0x48e64e
6340
6341 but gcc could do spilling into an fpr at any function. We can
6342 simply disable floating point support at that early stage.
6343
6344 Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
6345 Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
6346 Cc: stable@vger.kernel.org
6347 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6348
6349commit ca49c6cc8e77980557c26c88f43b5699acb3d770
6350Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
6351Date: Tue Sep 8 15:25:39 2015 +0200
6352
6353 s390/compat: correct uc_sigmask of the compat signal frame
6354
6355 [ Upstream commit 8d4bd0ed0439dfc780aab801a085961925ed6838 ]
6356
6357 The uc_sigmask in the ucontext structure is an array of words to keep
6358 the 64 signal bits (or 1024 if you ask glibc but the kernel sigset_t
6359 only has 64 bits).
6360
6361 For 64 bit the sigset_t contains a single 8 byte word, but for 31 bit
6362 there are two 4 byte words. The compat signal handler code uses a
6363 simple copy of the 64 bit sigset_t to the 31 bit compat_sigset_t.
6364 As s390 is a big-endian architecture this is incorrect, the two words
6365 in the 31 bit sigset_t array need to be swapped.
6366
6367 Cc: <stable@vger.kernel.org>
6368 Reported-by: Stefan Liebler <stli@linux.vnet.ibm.com>
6369 Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
6370 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6371
6372commit fafb54dbf1d5dfba928085ae5532b7f2c9b6eb67
6373Author: Peter Zijlstra <peterz@infradead.org>
6374Date: Tue Sep 29 14:45:09 2015 +0200
6375
6376 sched/core: Fix TASK_DEAD race in finish_task_switch()
6377
6378 [ Upstream commit 95913d97914f44db2b81271c2e2ebd4d2ac2df83 ]
6379
6380 So the problem this patch is trying to address is as follows:
6381
6382 CPU0 CPU1
6383
6384 context_switch(A, B)
6385 ttwu(A)
6386 LOCK A->pi_lock
6387 A->on_cpu == 0
6388 finish_task_switch(A)
6389 prev_state = A->state <-.
6390 WMB |
6391 A->on_cpu = 0; |
6392 UNLOCK rq0->lock |
6393 | context_switch(C, A)
6394 `-- A->state = TASK_DEAD
6395 prev_state == TASK_DEAD
6396 put_task_struct(A)
6397 context_switch(A, C)
6398 finish_task_switch(A)
6399 A->state == TASK_DEAD
6400 put_task_struct(A)
6401
6402 The argument being that the WMB will allow the load of A->state on CPU0
6403 to cross over and observe CPU1's store of A->state, which will then
6404 result in a double-drop and use-after-free.
6405
6406 Now the comment states (and this was true once upon a long time ago)
6407 that we need to observe A->state while holding rq->lock because that
6408 will order us against the wakeup; however the wakeup will not in fact
6409 acquire (that) rq->lock; it takes A->pi_lock these days.
6410
6411 We can obviously fix this by upgrading the WMB to an MB, but that is
6412 expensive, so we'd rather avoid that.
6413
6414 The alternative this patch takes is: smp_store_release(&A->on_cpu, 0),
6415 which avoids the MB on some archs, but not important ones like ARM.
6416
6417 Reported-by: Oleg Nesterov <oleg@redhat.com>
6418 Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
6419 Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
6420 Cc: <stable@vger.kernel.org> # v3.1+
6421 Cc: Peter Zijlstra <peterz@infradead.org>
6422 Cc: Thomas Gleixner <tglx@linutronix.de>
6423 Cc: linux-kernel@vger.kernel.org
6424 Cc: manfred@colorfullife.com
6425 Cc: will.deacon@arm.com
6426 Fixes: e4a52bcb9a18 ("sched: Remove rq->lock from the first half of ttwu()")
6427 Link: http://lkml.kernel.org/r/20150929124509.GG3816@twins.programming.kicks-ass.net
6428 Signed-off-by: Ingo Molnar <mingo@kernel.org>
6429 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6430
6431commit 4de74d2037ad5bcd475c0fa113de00941dd7d567
6432Author: Vitaly Kuznetsov <vkuznets@redhat.com>
6433Date: Fri Sep 25 11:59:52 2015 +0200
6434
6435 x86/xen: Support kexec/kdump in HVM guests by doing a soft reset
6436
6437 [ Upstream commit 0b34a166f291d255755be46e43ed5497cdd194f2 ]
6438
6439 Currently there is a number of issues preventing PVHVM Xen guests from
6440 doing successful kexec/kdump:
6441
6442 - Bound event channels.
6443 - Registered vcpu_info.
6444 - PIRQ/emuirq mappings.
6445 - shared_info frame after XENMAPSPACE_shared_info operation.
6446 - Active grant mappings.
6447
6448 Basically, newly booted kernel stumbles upon already set up Xen
6449 interfaces and there is no way to reestablish them. In Xen-4.7 a new
6450 feature called 'soft reset' is coming. A guest performing kexec/kdump
6451 operation is supposed to call SCHEDOP_shutdown hypercall with
6452 SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor
6453 (with some help from toolstack) will do full domain cleanup (but
6454 keeping its memory and vCPU contexts intact) returning the guest to
6455 the state it had when it was first booted and thus allowing it to
6456 start over.
6457
6458 Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is
6459 probably OK as by default all unknown shutdown reasons cause domain
6460 destroy with a message in toolstack log: 'Unknown shutdown reason code
6461 5. Destroying domain.' which gives a clue to what the problem is and
6462 eliminates false expectations.
6463
6464 Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
6465 Cc: <stable@vger.kernel.org>
6466 Signed-off-by: David Vrabel <david.vrabel@citrix.com>
6467 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6468
6469commit da00c72eae91e6a72ab1fef7ab94fcc382c5edd2
6470Author: Stephen Smalley <sds@tycho.nsa.gov>
6471Date: Thu Oct 1 09:04:22 2015 -0400
6472
6473 x86/mm: Set NX on gap between __ex_table and rodata
6474
6475 [ Upstream commit ab76f7b4ab2397ffdd2f1eb07c55697d19991d10 ]
6476
6477 Unused space between the end of __ex_table and the start of
6478 rodata can be left W+x in the kernel page tables. Extend the
6479 setting of the NX bit to cover this gap by starting from
6480 text_end rather than rodata_start.
6481
6482 Before:
6483 ---[ High Kernel Mapping ]---
6484 0xffffffff80000000-0xffffffff81000000 16M pmd
6485 0xffffffff81000000-0xffffffff81600000 6M ro PSE GLB x pmd
6486 0xffffffff81600000-0xffffffff81754000 1360K ro GLB x pte
6487 0xffffffff81754000-0xffffffff81800000 688K RW GLB x pte
6488 0xffffffff81800000-0xffffffff81a00000 2M ro PSE GLB NX pmd
6489 0xffffffff81a00000-0xffffffff81b3b000 1260K ro GLB NX pte
6490 0xffffffff81b3b000-0xffffffff82000000 4884K RW GLB NX pte
6491 0xffffffff82000000-0xffffffff82200000 2M RW PSE GLB NX pmd
6492 0xffffffff82200000-0xffffffffa0000000 478M pmd
6493
6494 After:
6495 ---[ High Kernel Mapping ]---
6496 0xffffffff80000000-0xffffffff81000000 16M pmd
6497 0xffffffff81000000-0xffffffff81600000 6M ro PSE GLB x pmd
6498 0xffffffff81600000-0xffffffff81754000 1360K ro GLB x pte
6499 0xffffffff81754000-0xffffffff81800000 688K RW GLB NX pte
6500 0xffffffff81800000-0xffffffff81a00000 2M ro PSE GLB NX pmd
6501 0xffffffff81a00000-0xffffffff81b3b000 1260K ro GLB NX pte
6502 0xffffffff81b3b000-0xffffffff82000000 4884K RW GLB NX pte
6503 0xffffffff82000000-0xffffffff82200000 2M RW PSE GLB NX pmd
6504 0xffffffff82200000-0xffffffffa0000000 478M pmd
6505
6506 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
6507 Acked-by: Kees Cook <keescook@chromium.org>
6508 Cc: <stable@vger.kernel.org>
6509 Cc: Linus Torvalds <torvalds@linux-foundation.org>
6510 Cc: Mike Galbraith <efault@gmx.de>
6511 Cc: Peter Zijlstra <peterz@infradead.org>
6512 Cc: Thomas Gleixner <tglx@linutronix.de>
6513 Cc: linux-kernel@vger.kernel.org
6514 Link: http://lkml.kernel.org/r/1443704662-3138-1-git-send-email-sds@tycho.nsa.gov
6515 Signed-off-by: Ingo Molnar <mingo@kernel.org>
6516 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6517
6518commit a92668113fc5326cb3c09958a000e7130eaa651f
6519Author: Thomas Gleixner <tglx@linutronix.de>
6520Date: Wed Sep 30 08:38:22 2015 +0000
6521
6522 x86/process: Add proper bound checks in 64bit get_wchan()
6523
6524 [ Upstream commit eddd3826a1a0190e5235703d1e666affa4d13b96 ]
6525
6526 Dmitry Vyukov reported the following using trinity and the memory
6527 error detector AddressSanitizer
6528 (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
6529
6530 [ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on
6531 address ffff88002e280000
6532 [ 124.576801] ffff88002e280000 is located 131938492886538 bytes to
6533 the left of 28857600-byte region [ffffffff81282e0a, ffffffff82e0830a)
6534 [ 124.578633] Accessed by thread T10915:
6535 [ 124.579295] inlined in describe_heap_address
6536 ./arch/x86/mm/asan/report.c:164
6537 [ 124.579295] #0 ffffffff810dd277 in asan_report_error
6538 ./arch/x86/mm/asan/report.c:278
6539 [ 124.580137] #1 ffffffff810dc6a0 in asan_check_region
6540 ./arch/x86/mm/asan/asan.c:37
6541 [ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0
6542 [ 124.581893] #3 ffffffff8107c093 in get_wchan
6543 ./arch/x86/kernel/process_64.c:444
6544
6545 The address checks in the 64bit implementation of get_wchan() are
6546 wrong in several ways:
6547
6548 - The lower bound of the stack is not the start of the stack
6549 page. It's the start of the stack page plus sizeof (struct
6550 thread_info)
6551
6552 - The upper bound must be:
6553
6554 top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long).
6555
6556 The 2 * sizeof(unsigned long) is required because the stack pointer
6557 points at the frame pointer. The layout on the stack is: ... IP FP
6558 ... IP FP. So we need to make sure that both IP and FP are in the
6559 bounds.
6560
6561 Fix the bound checks and get rid of the mix of numeric constants, u64
6562 and unsigned long. Making all unsigned long allows us to use the same
6563 function for 32bit as well.
6564
6565 Use READ_ONCE() when accessing the stack. This does not prevent a
6566 concurrent wakeup of the task and the stack changing, but at least it
6567 avoids TOCTOU.
6568
6569 Also check task state at the end of the loop. Again that does not
6570 prevent concurrent changes, but it avoids walking for nothing.
6571
6572 Add proper comments while at it.
6573
6574 Reported-by: Dmitry Vyukov <dvyukov@google.com>
6575 Reported-by: Sasha Levin <sasha.levin@oracle.com>
6576 Based-on-patch-from: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
6577 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
6578 Reviewed-by: Borislav Petkov <bp@alien8.de>
6579 Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
6580 Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
6581 Cc: Andy Lutomirski <luto@amacapital.net>
6582 Cc: Andrey Konovalov <andreyknvl@google.com>
6583 Cc: Kostya Serebryany <kcc@google.com>
6584 Cc: Alexander Potapenko <glider@google.com>
6585 Cc: kasan-dev <kasan-dev@googlegroups.com>
6586 Cc: Denys Vlasenko <dvlasenk@redhat.com>
6587 Cc: Andi Kleen <ak@linux.intel.com>
6588 Cc: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
6589 Cc: stable@vger.kernel.org
6590 Link: http://lkml.kernel.org/r/20150930083302.694788319@linutronix.de
6591 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
6592 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6593
6594commit 4aa755567f1e664c985eb0fb55e2be4b1fe14f17
6595Author: Andy Lutomirski <luto@amacapital.net>
6596Date: Tue Mar 10 11:05:58 2015 -0700
6597
6598 x86/asm/entry: Create and use a 'TOP_OF_KERNEL_STACK_PADDING' macro
6599
6600 [ Upstream commit 3ee4298f440c81638cbb5ec06f2497fb7a9a9eb4 ]
6601
6602 x86_32, unlike x86_64, pads the top of the kernel stack, because the
6603 hardware stack frame formats are variable in size.
6604
6605 Document this padding and give it a name.
6606
6607 This should make no change whatsoever to the compiled kernel
6608 image. It also doesn't fix any of the current bugs in this area.
6609
6610 Signed-off-by: Andy Lutomirski <luto@amacapital.net>
6611 Acked-by: Denys Vlasenko <dvlasenk@redhat.com>
6612 Cc: Borislav Petkov <bp@alien8.de>
6613 Cc: H. Peter Anvin <hpa@zytor.com>
6614 Cc: Linus Torvalds <torvalds@linux-foundation.org>
6615 Cc: Oleg Nesterov <oleg@redhat.com>
6616 Cc: Thomas Gleixner <tglx@linutronix.de>
6617 Link: http://lkml.kernel.org/r/02bf2f54b8dcb76a62a142b6dfe07d4ef7fc582e.1426009661.git.luto@amacapital.net
6618 [ Fixed small details, such as a missed magic constant in entry_32.S pointed out by Denys Vlasenko. ]
6619 Signed-off-by: Ingo Molnar <mingo@kernel.org>
6620
6621 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6622
6623commit e0bc30ecd6debc5a9a88a45f589bc05795e871ec
6624Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
6625Date: Tue Sep 29 20:58:57 2015 +0800
6626
6627 x86/kexec: Fix kexec crash in syscall kexec_file_load()
6628
6629 [ Upstream commit e3c41e37b0f4b18cbd4dac76cbeece5a7558b909 ]
6630
6631 The original bug is a page fault crash that sometimes happens
6632 on big machines when preparing ELF headers:
6633
6634 BUG: unable to handle kernel paging request at ffffc90613fc9000
6635 IP: [<ffffffff8103d645>] prepare_elf64_ram_headers_callback+0x165/0x260
6636
6637 The bug is caused by us under-counting the number of memory ranges
6638 and subsequently not allocating enough ELF header space for them.
6639 The bug is typically masked on smaller systems, because the ELF header
6640 allocation is rounded up to the next page.
6641
6642 This patch modifies the code in fill_up_crash_elf_data() by using
6643 walk_system_ram_res() instead of walk_system_ram_range() to correctly
6644 count the max number of crash memory ranges. That's because the
6645 walk_system_ram_range() filters out small memory regions that
6646 reside in the same page, but walk_system_ram_res() does not.
6647
6648 Here's how I found the bug:
6649
6650 After tracing prepare_elf64_headers() and prepare_elf64_ram_headers_callback(),
6651 the code uses walk_system_ram_res() to fill-in crash memory regions information
6652 to the program header, so it counts those small memory regions that
6653 reside in a page area.
6654
6655 But, when the kernel was using walk_system_ram_range() in
6656 fill_up_crash_elf_data() to count the number of crash memory regions,
6657 it filters out small regions.
6658
6659 I printed those small memory regions, for example:
6660
6661 kexec: Get nr_ram ranges. vaddr=0xffff880077592258 paddr=0x77592258, sz=0xdc0
6662
6663 Based on the code in walk_system_ram_range(), this memory region
6664 will be filtered out:
6665
6666 pfn = (0x77592258 + 0x1000 - 1) >> 12 = 0x77593
6667 end_pfn = (0x77592258 + 0xfc0 -1 + 1) >> 12 = 0x77593
6668 end_pfn - pfn = 0x77593 - 0x77593 = 0 <=== if (end_pfn > pfn) is FALSE
6669
6670 So, the max_nr_ranges that's counted by the kernel doesn't include
6671 small memory regions - causing us to under-allocate the required space.
6672 That causes the page fault crash that happens in a later code path
6673 when preparing ELF headers.
6674
6675 This bug is not easy to reproduce on small machines that have few
6676 CPUs, because the allocated page aligned ELF buffer has more free
6677 space to cover those small memory regions' PT_LOAD headers.
6678
6679 Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
6680 Cc: Andy Lutomirski <luto@kernel.org>
6681 Cc: Baoquan He <bhe@redhat.com>
6682 Cc: Jiang Liu <jiang.liu@linux.intel.com>
6683 Cc: Linus Torvalds <torvalds@linux-foundation.org>
6684 Cc: Mike Galbraith <efault@gmx.de>
6685 Cc: Peter Zijlstra <peterz@infradead.org>
6686 Cc: Stephen Rothwell <sfr@canb.auug.org.au>
6687 Cc: Takashi Iwai <tiwai@suse.de>
6688 Cc: Thomas Gleixner <tglx@linutronix.de>
6689 Cc: Viresh Kumar <viresh.kumar@linaro.org>
6690 Cc: Vivek Goyal <vgoyal@redhat.com>
6691 Cc: kexec@lists.infradead.org
6692 Cc: linux-kernel@vger.kernel.org
6693 Cc: <stable@vger.kernel.org>
6694 Link: http://lkml.kernel.org/r/1443531537-29436-1-git-send-email-jlee@suse.com
6695 Signed-off-by: Ingo Molnar <mingo@kernel.org>
6696 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6697
6698commit 38b54f8d748555c3e34dade08f112461e8c1db03
6699Author: Matt Fleming <matt.fleming@intel.com>
6700Date: Fri Sep 25 23:02:18 2015 +0100
6701
6702 x86/efi: Fix boot crash by mapping EFI memmap entries bottom-up at runtime, instead of top-down
6703
6704 [ Upstream commit a5caa209ba9c29c6421292e7879d2387a2ef39c9 ]
6705
6706 Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced
6707 that signals that the firmware PE/COFF loader supports splitting
6708 code and data sections of PE/COFF images into separate EFI
6709 memory map entries. This allows the kernel to map those regions
6710 with strict memory protections, e.g. EFI_MEMORY_RO for code,
6711 EFI_MEMORY_XP for data, etc.
6712
6713 Unfortunately, an unwritten requirement of this new feature is
6714 that the regions need to be mapped with the same offsets
6715 relative to each other as observed in the EFI memory map. If
6716 this is not done crashes like this may occur,
6717
6718 BUG: unable to handle kernel paging request at fffffffefe6086dd
6719 IP: [<fffffffefe6086dd>] 0xfffffffefe6086dd
6720 Call Trace:
6721 [<ffffffff8104c90e>] efi_call+0x7e/0x100
6722 [<ffffffff81602091>] ? virt_efi_set_variable+0x61/0x90
6723 [<ffffffff8104c583>] efi_delete_dummy_variable+0x63/0x70
6724 [<ffffffff81f4e4aa>] efi_enter_virtual_mode+0x383/0x392
6725 [<ffffffff81f37e1b>] start_kernel+0x38a/0x417
6726 [<ffffffff81f37495>] x86_64_start_reservations+0x2a/0x2c
6727 [<ffffffff81f37582>] x86_64_start_kernel+0xeb/0xef
6728
6729 Here 0xfffffffefe6086dd refers to an address the firmware
6730 expects to be mapped but which the OS never claimed was mapped.
6731 The issue is that included in these regions are relative
6732 addresses to other regions which were emitted by the firmware
6733 toolchain before the "splitting" of sections occurred at
6734 runtime.
6735
6736 Needless to say, we don't satisfy this unwritten requirement on
6737 x86_64 and instead map the EFI memory map entries in reverse
6738 order. The above crash is almost certainly triggerable with any
6739 kernel newer than v3.13 because that's when we rewrote the EFI
6740 runtime region mapping code, in commit d2f7cbe7b26a ("x86/efi:
6741 Runtime services virtual mapping"). For kernel versions before
6742 v3.13 things may work by pure luck depending on the
6743 fragmentation of the kernel virtual address space at the time we
6744 map the EFI regions.
6745
6746 Instead of mapping the EFI memory map entries in reverse order,
6747 where entry N has a higher virtual address than entry N+1, map
6748 them in the same order as they appear in the EFI memory map to
6749 preserve this relative offset between regions.
6750
6751 This patch has been kept as small as possible with the intention
6752 that it should be applied aggressively to stable and
6753 distribution kernels. It is very much a bugfix rather than
6754 support for a new feature, since when EFI_PROPERTIES_TABLE is
6755 enabled we must map things as outlined above to even boot - we
6756 have no way of asking the firmware not to split the code/data
6757 regions.
6758
6759 In fact, this patch doesn't even make use of the more strict
6760 memory protections available in UEFI v2.5. That will come later.
6761
6762 Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
6763 Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
6764 Signed-off-by: Matt Fleming <matt.fleming@intel.com>
6765 Cc: <stable@vger.kernel.org>
6766 Cc: Borislav Petkov <bp@suse.de>
6767 Cc: Chun-Yi <jlee@suse.com>
6768 Cc: Dave Young <dyoung@redhat.com>
6769 Cc: H. Peter Anvin <hpa@zytor.com>
6770 Cc: James Bottomley <JBottomley@Odin.com>
6771 Cc: Lee, Chun-Yi <jlee@suse.com>
6772 Cc: Leif Lindholm <leif.lindholm@linaro.org>
6773 Cc: Linus Torvalds <torvalds@linux-foundation.org>
6774 Cc: Matthew Garrett <mjg59@srcf.ucam.org>
6775 Cc: Mike Galbraith <efault@gmx.de>
6776 Cc: Peter Jones <pjones@redhat.com>
6777 Cc: Peter Zijlstra <peterz@infradead.org>
6778 Cc: Thomas Gleixner <tglx@linutronix.de>
6779 Cc: linux-kernel@vger.kernel.org
6780 Link: http://lkml.kernel.org/r/1443218539-7610-2-git-send-email-matt@codeblueprint.co.uk
6781 Signed-off-by: Ingo Molnar <mingo@kernel.org>
6782 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6783
6784commit c2b75739d99428b5dd97e4afbfee4a892b7c51a9
6785Author: Dirk Müller <dmueller@suse.com>
6786Date: Thu Oct 1 13:43:42 2015 +0200
6787
6788 Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS
6789
6790 [ Upstream commit d2922422c48df93f3edff7d872ee4f3191fefb08 ]
6791
6792 The cpu feature flags are not ever going to change, so warning
6793 everytime can cause a lot of kernel log spam
6794 (in our case more than 10GB/hour).
6795
6796 The warning seems to only occur when nested virtualization is
6797 enabled, so it's probably triggered by a KVM bug. This is a
6798 sensible and safe change anyway, and the KVM bug fix might not
6799 be suitable for stable releases anyway.
6800
6801 Cc: stable@vger.kernel.org
6802 Signed-off-by: Dirk Mueller <dmueller@suse.com>
6803 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
6804 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6805
6806commit fc7030ab9d506cac49acbb50535f5437478434cd
6807Author: Andy Lutomirski <luto@kernel.org>
6808Date: Sun Sep 20 16:32:04 2015 -0700
6809
6810 x86/paravirt: Replace the paravirt nop with a bona fide empty function
6811
6812 [ Upstream commit fc57a7c68020dcf954428869eafd934c0ab1536f ]
6813
6814 PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an
6815 example, trimmed for readability):
6816
6817 ff 15 00 00 00 00 callq *0x0(%rip) # 2796 <nmi+0x6>
6818 2792: R_X86_64_PC32 pv_irq_ops+0x2c
6819
6820 That's a call through a function pointer to regular C function that
6821 does nothing on native boots, but that function isn't protected
6822 against kprobes, isn't marked notrace, and is certainly not
6823 guaranteed to preserve any registers if the compiler is feeling
6824 perverse. This is bad news for a CLBR_NONE operation.
6825
6826 Of course, if everything works correctly, once paravirt ops are
6827 patched, it gets nopped out, but what if we hit this code before
6828 paravirt ops are patched in? This can potentially cause breakage
6829 that is very difficult to debug.
6830
6831 A more subtle failure is possible here, too: if _paravirt_nop uses
6832 the stack at all (even just to push RBP), it will overwrite the "NMI
6833 executing" variable if it's called in the NMI prologue.
6834
6835 The Xen case, perhaps surprisingly, is fine, because it's already
6836 written in asm.
6837
6838 Fix all of the cases that default to paravirt_nop (including
6839 adjust_exception_frame) with a big hammer: replace paravirt_nop with
6840 an asm function that is just a ret instruction.
6841
6842 The Xen case may have other problems, so document them.
6843
6844 This is part of a fix for some random crashes that Sasha saw.
6845
6846 Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com>
6847 Signed-off-by: Andy Lutomirski <luto@kernel.org>
6848 Cc: stable@vger.kernel.org
6849 Link: http://lkml.kernel.org/r/8f5d2ba295f9d73751c33d97fda03e0495d9ade0.1442791737.git.luto@kernel.org
6850 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
6851 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6852
6853commit b4bc0132aee9d929b6b5affbbf77a709e872c155
6854Author: David Woodhouse <dwmw2@infradead.org>
6855Date: Wed Sep 16 14:10:03 2015 +0100
6856
6857 x86/platform: Fix Geode LX timekeeping in the generic x86 build
6858
6859 [ Upstream commit 03da3ff1cfcd7774c8780d2547ba0d995f7dc03d ]
6860
6861 In 2007, commit 07190a08eef36 ("Mark TSC on GeodeLX reliable")
6862 bypassed verification of the TSC on Geode LX. However, this code
6863 (now in the check_system_tsc_reliable() function in
6864 arch/x86/kernel/tsc.c) was only present if CONFIG_MGEODE_LX was
6865 set.
6866
6867 OpenWRT has recently started building its generic Geode target
6868 for Geode GX, not LX, to include support for additional
6869 platforms. This broke the timekeeping on LX-based devices,
6870 because the TSC wasn't marked as reliable:
6871 https://dev.openwrt.org/ticket/20531
6872
6873 By adding a runtime check on is_geode_lx(), we can also include
6874 the fix if CONFIG_MGEODEGX1 or CONFIG_X86_GENERIC are set, thus
6875 fixing the problem.
6876
6877 Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
6878 Cc: Andres Salomon <dilinger@queued.net>
6879 Cc: Linus Torvalds <torvalds@linux-foundation.org>
6880 Cc: Marcelo Tosatti <marcelo@kvack.org>
6881 Cc: Peter Zijlstra <peterz@infradead.org>
6882 Cc: Thomas Gleixner <tglx@linutronix.de>
6883 Cc: stable@vger.kernel.org
6884 Link: http://lkml.kernel.org/r/1442409003.131189.87.camel@infradead.org
6885 Signed-off-by: Ingo Molnar <mingo@kernel.org>
6886 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6887
6888commit 9789806a559e37d3d2f57024476e23f059e2d4fc
6889Author: Shaohua Li <shli@fb.com>
6890Date: Thu Jul 30 16:24:43 2015 -0700
6891
6892 x86/apic: Serialize LVTT and TSC_DEADLINE writes
6893
6894 [ Upstream commit 5d7c631d926b59aa16f3c56eaeb83f1036c81dc7 ]
6895
6896 The APIC LVTT register is MMIO mapped but the TSC_DEADLINE register is an
6897 MSR. The write to the TSC_DEADLINE MSR is not serializing, so it's not
6898 guaranteed that the write to LVTT has reached the APIC before the
6899 TSC_DEADLINE MSR is written. In such a case the write to the MSR is
6900 ignored and as a consequence the local timer interrupt never fires.
6901
6902 The SDM decribes this issue for xAPIC and x2APIC modes. The
6903 serialization methods recommended by the SDM differ.
6904
6905 xAPIC:
6906 "1. Memory-mapped write to LVT Timer Register, setting bits 18:17 to 10b.
6907 2. WRMSR to the IA32_TSC_DEADLINE MSR a value much larger than current time-stamp counter.
6908 3. If RDMSR of the IA32_TSC_DEADLINE MSR returns zero, go to step 2.
6909 4. WRMSR to the IA32_TSC_DEADLINE MSR the desired deadline."
6910
6911 x2APIC:
6912 "To allow for efficient access to the APIC registers in x2APIC mode,
6913 the serializing semantics of WRMSR are relaxed when writing to the
6914 APIC registers. Thus, system software should not use 'WRMSR to APIC
6915 registers in x2APIC mode' as a serializing instruction. Read and write
6916 accesses to the APIC registers will occur in program order. A WRMSR to
6917 an APIC register may complete before all preceding stores are globally
6918 visible; software can prevent this by inserting a serializing
6919 instruction, an SFENCE, or an MFENCE before the WRMSR."
6920
6921 The xAPIC method is to just wait for the memory mapped write to hit
6922 the LVTT by checking whether the MSR write has reached the hardware.
6923 There is no reason why a proper MFENCE after the memory mapped write would
6924 not do the same. Andi Kleen confirmed that MFENCE is sufficient for the
6925 xAPIC case as well.
6926
6927 Issue MFENCE before writing to the TSC_DEADLINE MSR. This can be done
6928 unconditionally as all CPUs which have TSC_DEADLINE also have MFENCE
6929 support.
6930
6931 [ tglx: Massaged the changelog ]
6932
6933 Signed-off-by: Shaohua Li <shli@fb.com>
6934 Reviewed-by: Ingo Molnar <mingo@kernel.org>
6935 Cc: <Kernel-team@fb.com>
6936 Cc: <lenb@kernel.org>
6937 Cc: <fenghua.yu@intel.com>
6938 Cc: Andi Kleen <ak@linux.intel.com>
6939 Cc: H. Peter Anvin <hpa@zytor.com>
6940 Cc: stable@vger.kernel.org #v3.7+
6941 Link: http://lkml.kernel.org/r/20150909041352.GA2059853@devbig257.prn2.facebook.com
6942 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
6943 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6944
6945commit 6848085e78fb3e5849646f3fe4ce1b95cc73cfb1
6946Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
6947Date: Mon Sep 28 18:57:03 2015 +0300
6948
6949 dmaengine: dw: properly read DWC_PARAMS register
6950
6951 [ Upstream commit 6bea0f6d1c47b07be88dfd93f013ae05fcb3d8bf ]
6952
6953 In case we have less than maximum allowed channels (8) and autoconfiguration is
6954 enabled the DWC_PARAMS read is wrong because it uses different arithmetic to
6955 what is needed for channel priority setup.
6956
6957 Re-do the caclulations properly. This now works on AVR32 board well.
6958
6959 Fixes: fed2574b3c9f (dw_dmac: introduce software emulation of LLP transfers)
6960 Cc: yitian.bu@tangramtek.com
6961 Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
6962 Signed-off-by: Vinod Koul <vinod.koul@intel.com>
6963 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6964
6965commit cf9499e2cbf0a0f082a48639e2ec75f5c1fb0ea8
6966Author: Felipe F. Tonello <eu@felipetonello.com>
6967Date: Wed Sep 16 18:40:32 2015 +0100
6968
6969 ARM: dts: fix usb pin control for imx-rex dts
6970
6971 [ Upstream commit 0af822110871400908d5b6f83a8908c45f881d8f ]
6972
6973 This fixes a duplicated pin control causing this error:
6974
6975 imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_GPIO_1 already
6976 requested by regulators:regulator@2; cannot claim for 2184000.usb
6977 imx6q-pinctrl 20e0000.iomuxc: pin-137 (2184000.usb) status -22
6978 imx6q-pinctrl 20e0000.iomuxc: could not request pin 137
6979 (MX6Q_PAD_GPIO_1) from group usbotggrp on device 20e0000.iomuxc
6980 imx_usb 2184000.usb: Error applying setting, reverse things
6981 back
6982 imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_EIM_D31 already
6983 requested by regulators:regulator@1; cannot claim for 2184200.usb
6984 imx6q-pinctrl 20e0000.iomuxc: pin-52 (2184200.usb) status -22
6985 imx6q-pinctrl 20e0000.iomuxc: could not request pin 52 (MX6Q_PAD_EIM_D31)
6986 from group usbh1grp on device 20e0000.iomuxc
6987 imx_usb 2184200.usb: Error applying setting, reverse things
6988 back
6989
6990 Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
6991 Fixes: e2047e33f2bd ("ARM: dts: add initial Rex Pro board support")
6992 Cc: <stable@vger.kernel.org>
6993 Signed-off-by: Shawn Guo <shawnguo@kernel.org>
6994 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
6995
6996commit 0c873b18c057d82d7ae10fc3b7a0b6cee5258927
6997Author: Carl Frederik Werner <frederik@cfbw.eu>
6998Date: Wed Sep 2 10:07:57 2015 +0900
6999
7000 ARM: dts: omap3-beagle: make i2c3, ddc and tfp410 gpio work again
7001
7002 [ Upstream commit 3a2fa775bd1d0579113666c1a2e37654a34018a0 ]
7003
7004 Let's fix pinmux address of gpio 170 used by tfp410 powerdown-gpio.
7005
7006 According to the OMAP35x Technical Reference Manual
7007 CONTROL_PADCONF_I2C3_SDA[15:0] 0x480021C4 mode0: i2c3_sda
7008 CONTROL_PADCONF_I2C3_SDA[31:16] 0x480021C4 mode4: gpio_170
7009 the pinmux address of gpio 170 must be 0x480021C6.
7010
7011 The former wrong address broke i2c3 (used by hdmi ddc), resulting in
7012 kernel message:
7013 omap_i2c 48060000.i2c: controller timed out
7014
7015 Fixes: 8cecf52befd7 ("ARM: omap3-beagle.dts: add display information")
7016 Cc: stable@vger.kernel.org # v3.15+
7017 Signed-off-by: Carl Frederik Werner <frederik@cfbw.eu>
7018 Signed-off-by: Tony Lindgren <tony@atomide.com>
7019 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7020
7021commit 11fdbfcd5ecbc2be8f0ee8e4f937f04edd943adf
7022Author: Grazvydas Ignotas <notasas@gmail.com>
7023Date: Wed Sep 16 01:34:31 2015 +0300
7024
7025 ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets
7026
7027 [ Upstream commit 1dbdad75074d16c3e3005180f81a01cdc04a7872 ]
7028
7029 The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
7030 pins up, communication with tca6424a doesn't work (controller timeouts)
7031 and it is not possible to enable HDMI.
7032
7033 Fixes: 9be495c42609 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
7034 Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
7035 Signed-off-by: Tony Lindgren <tony@atomide.com>
7036 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7037
7038commit 583d530162e8569818c1019b1e8666cc24b9f210
7039Author: Paul Bolle <pebolle@tiscali.nl>
7040Date: Fri Jul 31 14:08:58 2015 +0200
7041
7042 windfarm: decrement client count when unregistering
7043
7044 [ Upstream commit fe2b592173ff0274e70dc44d1d28c19bb995aa7c ]
7045
7046 wf_unregister_client() increments the client count when a client
7047 unregisters. That is obviously incorrect. Decrement that client count
7048 instead.
7049
7050 Fixes: 75722d3992f5 ("[PATCH] ppc64: Thermal control for SMU based machines")
7051
7052 Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
7053 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
7054 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7055
7056commit 0d665fe30603081abe412f630153b746e99a90a4
7057Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
7058Date: Thu Sep 3 13:24:40 2015 +0100
7059
7060 ARM: 8429/1: disable GCC SRA optimization
7061
7062 [ Upstream commit a077224fd35b2f7fbc93f14cf67074fc792fbac2 ]
7063
7064 While working on the 32-bit ARM port of UEFI, I noticed a strange
7065 corruption in the kernel log. The following snprintf() statement
7066 (in drivers/firmware/efi/efi.c:efi_md_typeattr_format())
7067
7068 snprintf(pos, size, "|%3s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
7069
7070 was producing the following output in the log:
7071
7072 | | | | | |WB|WT|WC|UC]
7073 | | | | | |WB|WT|WC|UC]
7074 | | | | | |WB|WT|WC|UC]
7075 |RUN| | | | |WB|WT|WC|UC]*
7076 |RUN| | | | |WB|WT|WC|UC]*
7077 | | | | | |WB|WT|WC|UC]
7078 |RUN| | | | |WB|WT|WC|UC]*
7079 | | | | | |WB|WT|WC|UC]
7080 |RUN| | | | | | | |UC]
7081 |RUN| | | | | | | |UC]
7082
7083 As it turns out, this is caused by incorrect code being emitted for
7084 the string() function in lib/vsprintf.c. The following code
7085
7086 if (!(spec.flags & LEFT)) {
7087 while (len < spec.field_width--) {
7088 if (buf < end)
7089 *buf = ' ';
7090 ++buf;
7091 }
7092 }
7093 for (i = 0; i < len; ++i) {
7094 if (buf < end)
7095 *buf = *s;
7096 ++buf; ++s;
7097 }
7098 while (len < spec.field_width--) {
7099 if (buf < end)
7100 *buf = ' ';
7101 ++buf;
7102 }
7103
7104 when called with len == 0, triggers an issue in the GCC SRA optimization
7105 pass (Scalar Replacement of Aggregates), which handles promotion of signed
7106 struct members incorrectly. This is a known but as yet unresolved issue.
7107 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932). In this particular
7108 case, it is causing the second while loop to be executed erroneously a
7109 single time, causing the additional space characters to be printed.
7110
7111 So disable the optimization by passing -fno-ipa-sra.
7112
7113 Cc: <stable@vger.kernel.org>
7114 Acked-by: Nicolas Pitre <nico@linaro.org>
7115 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
7116 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
7117 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7118
7119commit 56e1daf66f9ff64b5782a4fa796ab435f862b126
7120Author: Russell King <rmk+kernel@arm.linux.org.uk>
7121Date: Fri Sep 11 16:44:02 2015 +0100
7122
7123 ARM: fix Thumb2 signal handling when ARMv6 is enabled
7124
7125 [ Upstream commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab ]
7126
7127 When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
7128 IT state when entering a signal handler. This can cause the first
7129 few instructions to be conditionally executed depending on the parent
7130 context.
7131
7132 In any case, the original test for >= ARMv7 is broken - ARMv6 can have
7133 Thumb-2 support as well, and an ARMv6T2 specific build would omit this
7134 code too.
7135
7136 Relax the test back to ARMv6 or greater. This results in us always
7137 clearing the IT state bits in the PSR, even on CPUs where these bits
7138 are reserved. However, they're reserved for the IT state, so this
7139 should cause no harm.
7140
7141 Cc: <stable@vger.kernel.org>
7142 Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
7143 Acked-by: Tony Lindgren <tony@atomide.com>
7144 Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
7145 Tested-by: Grazvydas Ignotas <notasas@gmail.com>
7146 Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
7147 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7148
7149commit 494b66391df00c3261cbf0a5fc24a21da97760c2
7150Author: Guenter Roeck <linux@roeck-us.net>
7151Date: Mon Aug 31 16:13:47 2015 -0700
7152
7153 hwmon: (nct6775) Swap STEP_UP_TIME and STEP_DOWN_TIME registers for most chips
7154
7155 [ Upstream commit 728d29400488d54974d3317fe8a232b45fdb42ee ]
7156
7157 The STEP_UP_TIME and STEP_DOWN_TIME registers are swapped for all chips but
7158 NCT6775.
7159
7160 Reported-by: Grazvydas Ignotas <notasas@gmail.com>
7161 Reviewed-by: Jean Delvare <jdelvare@suse.de>
7162 Cc: stable@vger.kernel.org # v3.10+
7163 Signed-off-by: Guenter Roeck <linux@roeck-us.net>
7164 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7165
7166commit 19241b13ba1964e3bce3ee7e1944bbf5d193c45f
7167Author: Dominik Dingel <dingel@linux.vnet.ibm.com>
7168Date: Fri Sep 18 11:27:45 2015 +0200
7169
7170 sched: access local runqueue directly in single_task_running
7171
7172 [ Upstream commit 00cc1633816de8c95f337608a1ea64e228faf771 ]
7173
7174 Commit 2ee507c47293 ("sched: Add function single_task_running to let a task
7175 check if it is the only task running on a cpu") referenced the current
7176 runqueue with the smp_processor_id. When CONFIG_DEBUG_PREEMPT is enabled,
7177 that is only allowed if preemption is disabled or the currrent task is
7178 bound to the local cpu (e.g. kernel worker).
7179
7180 With commit f78195129963 ("kvm: add halt_poll_ns module parameter") KVM
7181 calls single_task_running. If CONFIG_DEBUG_PREEMPT is enabled that
7182 generates a lot of kernel messages.
7183
7184 To avoid adding preemption in that cases, as it would limit the usefulness,
7185 we change single_task_running to access directly the cpu local runqueue.
7186
7187 Cc: Tim Chen <tim.c.chen@linux.intel.com>
7188 Suggested-by: Peter Zijlstra <peterz@infradead.org>
7189 Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
7190 Cc: <stable@vger.kernel.org>
7191 Fixes: 2ee507c472939db4b146d545352b8a7c79ef47f8
7192 Signed-off-by: Dominik Dingel <dingel@linux.vnet.ibm.com>
7193 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7194 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7195
7196commit 91c16bc6d9d5195821a0d3a2c6a95855a1788e28
7197Author: Francesco Lavra <francescolavra.fl@gmail.com>
7198Date: Sat Jul 25 08:25:18 2015 +0200
7199
7200 watchdog: sunxi: fix activation of system reset
7201
7202 [ Upstream commit 0919e4445190da18496d31aac08b90828a47d45f ]
7203
7204 Commit f2147de33470 ("watchdog: sunxi: support parameterized compatible
7205 strings") introduced a regression in sunxi_wdt_start(), by which
7206 the system reset function of the watchdog is not enabled upon
7207 starting the watchdog. As a result, the system is not reset when the
7208 watchdog expires. Fix it.
7209
7210 Fixes: f2147de33470 ("watchdog: sunxi: support parameterized compatible strings")
7211 Signed-off-by: Francesco Lavra <francescolavra.fl@gmail.com>
7212 Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
7213 Reviewed-by: Guenter Roeck <linux@roeck-us.net>
7214 Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
7215 Cc: stable@vger.kernel.org
7216 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7217
7218commit 2e1e6fe49ec9c433da336f7234cb3432628d6414
7219Author: Arnaldo Carvalho de Melo <acme@redhat.com>
7220Date: Fri Sep 11 12:36:12 2015 -0300
7221
7222 perf header: Fixup reading of HEADER_NRCPUS feature
7223
7224 [ Upstream commit caa470475d9b59eeff093ae650800d34612c4379 ]
7225
7226 The original patch introducing this header wrote the number of CPUs available
7227 and online in one order and then swapped those values when reading, fix it.
7228
7229 Before:
7230
7231 # perf record usleep 1
7232 # perf report --header-only | grep 'nrcpus \(online\|avail\)'
7233 # nrcpus online : 4
7234 # nrcpus avail : 4
7235 # echo 0 > /sys/devices/system/cpu/cpu2/online
7236 # perf record usleep 1
7237 # perf report --header-only | grep 'nrcpus \(online\|avail\)'
7238 # nrcpus online : 4
7239 # nrcpus avail : 3
7240 # echo 0 > /sys/devices/system/cpu/cpu1/online
7241 # perf record usleep 1
7242 # perf report --header-only | grep 'nrcpus \(online\|avail\)'
7243 # nrcpus online : 4
7244 # nrcpus avail : 2
7245
7246 After the fix, bringing back the CPUs online:
7247
7248 # perf report --header-only | grep 'nrcpus \(online\|avail\)'
7249 # nrcpus online : 2
7250 # nrcpus avail : 4
7251 # echo 1 > /sys/devices/system/cpu/cpu2/online
7252 # perf record usleep 1
7253 # perf report --header-only | grep 'nrcpus \(online\|avail\)'
7254 # nrcpus online : 3
7255 # nrcpus avail : 4
7256 # echo 1 > /sys/devices/system/cpu/cpu1/online
7257 # perf record usleep 1
7258 # perf report --header-only | grep 'nrcpus \(online\|avail\)'
7259 # nrcpus online : 4
7260 # nrcpus avail : 4
7261
7262 Acked-by: Namhyung Kim <namhyung@kernel.org>
7263 Cc: Adrian Hunter <adrian.hunter@intel.com>
7264 Cc: Borislav Petkov <bp@suse.de>
7265 Cc: David Ahern <dsahern@gmail.com>
7266 Cc: Frederic Weisbecker <fweisbec@gmail.com>
7267 Cc: Jiri Olsa <jolsa@kernel.org>
7268 Cc: Kan Liang <kan.liang@intel.com>
7269 Cc: Stephane Eranian <eranian@google.com>
7270 Cc: Wang Nan <wangnan0@huawei.com>
7271 Fixes: fbe96f29ce4b ("perf tools: Make perf.data more self-descriptive (v8)")
7272 Link: http://lkml.kernel.org/r/20150911153323.GP23511@kernel.org
7273 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
7274 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7275
7276commit cea6abba6d7ffdcfe210ed65612ebc914fffdcfd
7277Author: Kan Liang <kan.liang@intel.com>
7278Date: Thu Jul 2 03:08:43 2015 -0400
7279
7280 perf stat: Get correct cpu id for print_aggr
7281
7282 [ Upstream commit 601083cffb7cabdcc55b8195d732f0f7028570fa ]
7283
7284 print_aggr() fails to print per-core/per-socket statistics after commit
7285 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events")
7286 if events have differnt cpus. Because in print_aggr(), aggr_get_id needs
7287 index (not cpu id) to find core/pkg id. Also, evsel cpu maps should be
7288 used to get aggregated id.
7289
7290 Here is an example:
7291
7292 Counting events cycles,uncore_imc_0/cas_count_read/. (Uncore event has
7293 cpumask 0,18)
7294
7295 $ perf stat -e cycles,uncore_imc_0/cas_count_read/ -C0,18 --per-core sleep 2
7296
7297 Without this patch, it failes to get CPU 18 result.
7298
7299 Performance counter stats for 'CPU(s) 0,18':
7300
7301 S0-C0 1 7526851 cycles
7302 S0-C0 1 1.05 MiB uncore_imc_0/cas_count_read/
7303 S1-C0 0 <not counted> cycles
7304 S1-C0 0 <not counted> MiB uncore_imc_0/cas_count_read/
7305
7306 With this patch, it can get both CPU0 and CPU18 result.
7307
7308 Performance counter stats for 'CPU(s) 0,18':
7309
7310 S0-C0 1 6327768 cycles
7311 S0-C0 1 0.47 MiB uncore_imc_0/cas_count_read/
7312 S1-C0 1 330228 cycles
7313 S1-C0 1 0.29 MiB uncore_imc_0/cas_count_read/
7314
7315 Signed-off-by: Kan Liang <kan.liang@intel.com>
7316 Acked-by: Jiri Olsa <jolsa@kernel.org>
7317 Acked-by: Stephane Eranian <eranian@google.com>
7318 Cc: Adrian Hunter <adrian.hunter@intel.com>
7319 Cc: Andi Kleen <ak@linux.intel.com>
7320 Cc: David Ahern <dsahern@gmail.com>
7321 Cc: Namhyung Kim <namhyung@kernel.org>
7322 Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
7323 Fixes: 582ec0829b3d ("perf stat: Fix per-socket output bug for uncore events")
7324 Link: http://lkml.kernel.org/r/1435820925-51091-1-git-send-email-kan.liang@intel.com
7325 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
7326 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7327
7328commit 9b81b4499a1a6bec228f622822d6fe95e45aca29
7329Author: Arnaldo Carvalho de Melo <acme@redhat.com>
7330Date: Mon Aug 10 16:53:54 2015 -0300
7331
7332 perf report: Add support for srcfile sort key
7333
7334 [ Upstream commit 31191a85fb875cf123cea56bbfd34f4b941f3c79 ]
7335
7336 In some cases it's useful to characterize samples by file. This is
7337 useful to get a higher level categorization, for example to map cost to
7338 subsystems.
7339
7340 Add a srcfile sort key to perf report. It builds on top of the existing
7341 srcline support.
7342
7343 Commiter notes:
7344
7345 E.g.:
7346
7347 # perf record -F 10000 usleep 1
7348 [ perf record: Woken up 1 times to write data ]
7349 [ perf record: Captured and wrote 0.016 MB perf.data (13 samples) ]
7350 [root@zoo ~]# perf report -s srcfile --stdio
7351 # Total Lost Samples: 0
7352 #
7353 # Samples: 13 of event 'cycles'
7354 # Event count (approx.): 869878
7355 #
7356 # Overhead Source File
7357 # ........ ...........
7358 60.99% .
7359 20.62% paravirt.h
7360 14.23% rmap.c
7361 4.04% signal.c
7362 0.11% msr.h
7363
7364 #
7365
7366 The first line is collecting all the files for which srcfiles couldn't somehow
7367 get resolved to:
7368
7369 # perf report -s srcfile,dso --stdio
7370 # Total Lost Samples: 0
7371 #
7372 # Samples: 13 of event 'cycles'
7373 # Event count (approx.): 869878
7374 #
7375 # Overhead Source File Shared Object
7376 # ........ ........... ................
7377 40.97% . ld-2.20.so
7378 20.62% paravirt.h [kernel.vmlinux]
7379 20.02% . libc-2.20.so
7380 14.23% rmap.c [kernel.vmlinux]
7381 4.04% signal.c [kernel.vmlinux]
7382 0.11% msr.h [kernel.vmlinux]
7383
7384 #
7385
7386 XXX: Investigate why that is not resolving on Fedora 21, Andi says he hasn't
7387 seen this on Fedora 22.
7388
7389 Signed-off-by: Andi Kleen <ak@linux.intel.com>
7390 Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
7391 Cc: Jiri Olsa <jolsa@kernel.org>
7392 Cc: Namhyung Kim <namhyung@kernel.org>
7393 Link: http://lkml.kernel.org/r/1438988064-21834-1-git-send-email-andi@firstfloor.org
7394 [ Added column length update, from 0e65bdb3f90f ('perf hists: Update the column width for the "srcline" sort key') ]
7395 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
7396
7397 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7398
7399commit ec50d9d6b275078f709a6192809e1ba42722335b
7400Author: Adrian Hunter <adrian.hunter@intel.com>
7401Date: Thu Sep 24 13:05:22 2015 +0300
7402
7403 perf tools: Fix copying of /proc/kcore
7404
7405 [ Upstream commit b5cabbcbd157a4bf5a92dfc85134999a3b55342d ]
7406
7407 A copy of /proc/kcore containing the kernel text can be made to the
7408 buildid cache. e.g.
7409
7410 perf buildid-cache -v -k /proc/kcore
7411
7412 To workaround objdump limitations, a copy is also made when annotating
7413 against /proc/kcore.
7414
7415 The copying process stops working from libelf about v1.62 onwards (the
7416 problem was found with v1.63).
7417
7418 The cause is that a call to gelf_getphdr() in kcore__add_phdr() fails
7419 because additional validation has been added to gelf_getphdr().
7420
7421 The use of gelf_getphdr() is a misguided attempt to get default
7422 initialization of the Gelf_Phdr structure. That should not be
7423 necessary because every member of the Gelf_Phdr structure is
7424 subsequently assigned. So just remove the call to gelf_getphdr().
7425
7426 Similarly, a call to gelf_getehdr() in gelf_kcore__init() can be
7427 removed also.
7428
7429 Committer notes:
7430
7431 Note to stable@kernel.org, from Adrian in the cover letter for this
7432 patchkit:
7433
7434 The "Fix copying of /proc/kcore" problem goes back to v3.13 if you think
7435 it is important enough for stable.
7436
7437 Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
7438 Cc: Jiri Olsa <jolsa@redhat.com>
7439 Cc: stable@kernel.org
7440 Link: http://lkml.kernel.org/r/1443089122-19082-3-git-send-email-adrian.hunter@intel.com
7441 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
7442 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7443
7444commit 722554c1a2811ca703dc9e5d7afa029b5b19f4da
7445Author: Jenny Derzhavetz <jennyf@mellanox.com>
7446Date: Sun Sep 6 14:52:20 2015 +0300
7447
7448 iser-target: remove command with state ISTATE_REMOVE
7449
7450 [ Upstream commit a4c15cd957cbd728f685645de7a150df5912591a ]
7451
7452 As documented in iscsit_sequence_cmd:
7453 /*
7454 * Existing callers for iscsit_sequence_cmd() will silently
7455 * ignore commands with CMDSN_LOWER_THAN_EXP, so force this
7456 * return for CMDSN_MAXCMDSN_OVERRUN as well..
7457 */
7458
7459 We need to silently finish a command when it's in ISTATE_REMOVE.
7460 This fixes an teardown hang we were seeing where a mis-behaved
7461 initiator (triggered by allocation error injections) sent us a
7462 cmdsn which was lower than expected.
7463
7464 Signed-off-by: Jenny Derzhavetz <jennyf@mellanox.com>
7465 Signed-off-by: Sagi Grimberg <sagig@mellanox.com>
7466 Cc: <stable@vger.kernel.org> # v3.10+
7467 Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
7468 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7469
7470commit 642f48476545bf45bde2047c7bd79ce0ddf121e0
7471Author: Michal Hocko <mhocko@suse.com>
7472Date: Thu Aug 27 20:16:37 2015 +0200
7473
7474 scsi: fix scsi_error_handler vs. scsi_host_dev_release race
7475
7476 [ Upstream commit 537b604c8b3aa8b96fe35f87dd085816552e294c ]
7477
7478 b9d5c6b7ef57 ("[SCSI] cleanup setting task state in
7479 scsi_error_handler()") has introduced a race between scsi_error_handler
7480 and scsi_host_dev_release resulting in the hang when the device goes
7481 away because scsi_error_handler might miss a wake up:
7482
7483 CPU0 CPU1
7484 scsi_error_handler scsi_host_dev_release
7485 kthread_stop()
7486 kthread_should_stop()
7487 test_bit(KTHREAD_SHOULD_STOP)
7488 set_bit(KTHREAD_SHOULD_STOP)
7489 wake_up_process()
7490 wait_for_completion()
7491
7492 set_current_state(TASK_INTERRUPTIBLE)
7493 schedule()
7494
7495 The most straightforward solution seems to be to invert the ordering of
7496 the set_current_state and kthread_should_stop.
7497
7498 The issue has been noticed during reboot test on a 3.0 based kernel but
7499 the current code seems to be affected in the same way.
7500
7501 [jejb: additional comment added]
7502 Cc: <stable@vger.kernel.org> # 3.6+
7503 Reported-and-debugged-by: Mike Mayer <Mike.Meyer@teradata.com>
7504 Signed-off-by: Michal Hocko <mhocko@suse.com>
7505 Reviewed-by: Dan Williams <dan.j.williams@intel.com>
7506 Reviewed-by: Hannes Reinecke <hare@suse.de>
7507 Signed-off-by: James Bottomley <JBottomley@Odin.com>
7508
7509 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7510
7511commit c8259f6224297e938da2023bed712f54a6876541
7512Author: Andy Grover <agrover@redhat.com>
7513Date: Mon Aug 24 10:26:03 2015 -0700
7514
7515 target/iscsi: Fix np_ip bracket issue by removing np_ip
7516
7517 [ Upstream commit 76c28f1fcfeb42b47f798fe498351ee1d60086ae ]
7518
7519 Revert commit 1997e6259, which causes double brackets on ipv6
7520 inaddr_any addresses.
7521
7522 Since we have np_sockaddr, if we need a textual representation we can
7523 use "%pISc".
7524
7525 Change iscsit_add_network_portal() and iscsit_add_np() signatures to remove
7526 *ip_str parameter.
7527
7528 Fix and extend some comments earlier in the function.
7529
7530 Tested to work for :: and ::1 via iscsiadm, previously :: failed, see
7531 https://bugzilla.redhat.com/show_bug.cgi?id=1249107 .
7532
7533 CC: stable@vger.kernel.org
7534 Signed-off-by: Andy Grover <agrover@redhat.com>
7535 Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
7536 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7537
7538commit 4c42a394e4158f92fa24867f52c18f0c196bbfb9
7539Author: John Stultz <john.stultz@linaro.org>
7540Date: Wed Sep 9 16:07:30 2015 -0700
7541
7542 time: Fix timekeeping_freqadjust()'s incorrect use of abs() instead of abs64()
7543
7544 [ Upstream commit 2619d7e9c92d524cb155ec89fd72875321512e5b ]
7545
7546 The internal clocksteering done for fine-grained error
7547 correction uses a logarithmic approximation, so any time
7548 adjtimex() adjusts the clock steering, timekeeping_freqadjust()
7549 quickly approximates the correct clock frequency over a series
7550 of ticks.
7551
7552 Unfortunately, the logic in timekeeping_freqadjust(), introduced
7553 in commit:
7554
7555 dc491596f639 ("timekeeping: Rework frequency adjustments to work better w/ nohz")
7556
7557 used the abs() function with a s64 error value to calculate the
7558 size of the approximated adjustment to be made.
7559
7560 Per include/linux/kernel.h:
7561
7562 "abs() should not be used for 64-bit types (s64, u64, long long) - use abs64()".
7563
7564 Thus on 32-bit platforms, this resulted in the clocksteering to
7565 take a quite dampended random walk trying to converge on the
7566 proper frequency, which caused the adjustments to be made much
7567 slower then intended (most easily observed when large
7568 adjustments are made).
7569
7570 This patch fixes the issue by using abs64() instead.
7571
7572 Reported-by: Nuno Gonçalves <nunojpg@gmail.com>
7573 Tested-by: Nuno Goncalves <nunojpg@gmail.com>
7574 Signed-off-by: John Stultz <john.stultz@linaro.org>
7575 Cc: <stable@vger.kernel.org> # v3.17+
7576 Cc: Linus Torvalds <torvalds@linux-foundation.org>
7577 Cc: Miroslav Lichvar <mlichvar@redhat.com>
7578 Cc: Peter Zijlstra <peterz@infradead.org>
7579 Cc: Prarit Bhargava <prarit@redhat.com>
7580 Cc: Richard Cochran <richardcochran@gmail.com>
7581 Cc: Thomas Gleixner <tglx@linutronix.de>
7582 Link: http://lkml.kernel.org/r/1441840051-20244-1-git-send-email-john.stultz@linaro.org
7583 Signed-off-by: Ingo Molnar <mingo@kernel.org>
7584 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7585
7586commit 1d2c99928fed10d937e9a7956a1d7a44dbd4196b
7587Author: Jason Wang <jasowang@redhat.com>
7588Date: Tue Sep 15 14:41:56 2015 +0800
7589
7590 kvm: fix double free for fast mmio eventfd
7591
7592 [ Upstream commit eefd6b06b17c5478e7c24bea6f64beaa2c431ca6 ]
7593
7594 We register wildcard mmio eventfd on two buses, once for KVM_MMIO_BUS
7595 and once on KVM_FAST_MMIO_BUS but with a single iodev
7596 instance. This will lead to an issue: kvm_io_bus_destroy() knows
7597 nothing about the devices on two buses pointing to a single dev. Which
7598 will lead to double free[1] during exit. Fix this by allocating two
7599 instances of iodevs then registering one on KVM_MMIO_BUS and another
7600 on KVM_FAST_MMIO_BUS.
7601
7602 CPU: 1 PID: 2894 Comm: qemu-system-x86 Not tainted 3.19.0-26-generic #28-Ubuntu
7603 Hardware name: LENOVO 2356BG6/2356BG6, BIOS G7ET96WW (2.56 ) 09/12/2013
7604 task: ffff88009ae0c4b0 ti: ffff88020e7f0000 task.ti: ffff88020e7f0000
7605 RIP: 0010:[<ffffffffc07e25d8>] [<ffffffffc07e25d8>] ioeventfd_release+0x28/0x60 [kvm]
7606 RSP: 0018:ffff88020e7f3bc8 EFLAGS: 00010292
7607 RAX: dead000000200200 RBX: ffff8801ec19c900 RCX: 000000018200016d
7608 RDX: ffff8801ec19cf80 RSI: ffffea0008bf1d40 RDI: ffff8801ec19c900
7609 RBP: ffff88020e7f3bd8 R08: 000000002fc75a01 R09: 000000018200016d
7610 R10: ffffffffc07df6ae R11: ffff88022fc75a98 R12: ffff88021e7cc000
7611 R13: ffff88021e7cca48 R14: ffff88021e7cca50 R15: ffff8801ec19c880
7612 FS: 00007fc1ee3e6700(0000) GS:ffff88023e240000(0000) knlGS:0000000000000000
7613 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
7614 CR2: 00007f8f389d8000 CR3: 000000023dc13000 CR4: 00000000001427e0
7615 Stack:
7616 ffff88021e7cc000 0000000000000000 ffff88020e7f3be8 ffffffffc07e2622
7617 ffff88020e7f3c38 ffffffffc07df69a ffff880232524160 ffff88020e792d80
7618 0000000000000000 ffff880219b78c00 0000000000000008 ffff8802321686a8
7619 Call Trace:
7620 [<ffffffffc07e2622>] ioeventfd_destructor+0x12/0x20 [kvm]
7621 [<ffffffffc07df69a>] kvm_put_kvm+0xca/0x210 [kvm]
7622 [<ffffffffc07df818>] kvm_vcpu_release+0x18/0x20 [kvm]
7623 [<ffffffff811f69f7>] __fput+0xe7/0x250
7624 [<ffffffff811f6bae>] ____fput+0xe/0x10
7625 [<ffffffff81093f04>] task_work_run+0xd4/0xf0
7626 [<ffffffff81079358>] do_exit+0x368/0xa50
7627 [<ffffffff81082c8f>] ? recalc_sigpending+0x1f/0x60
7628 [<ffffffff81079ad5>] do_group_exit+0x45/0xb0
7629 [<ffffffff81085c71>] get_signal+0x291/0x750
7630 [<ffffffff810144d8>] do_signal+0x28/0xab0
7631 [<ffffffff810f3a3b>] ? do_futex+0xdb/0x5d0
7632 [<ffffffff810b7028>] ? __wake_up_locked_key+0x18/0x20
7633 [<ffffffff810f3fa6>] ? SyS_futex+0x76/0x170
7634 [<ffffffff81014fc9>] do_notify_resume+0x69/0xb0
7635 [<ffffffff817cb9af>] int_signal+0x12/0x17
7636 Code: 5d c3 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 83 ec 08 48 8b 7f 20 e8 06 d6 a5 c0 48 8b 43 08 48 8b 13 48 89 df 48 89 42 08 <48> 89 10 48 b8 00 01 10 00 00
7637 RIP [<ffffffffc07e25d8>] ioeventfd_release+0x28/0x60 [kvm]
7638 RSP <ffff88020e7f3bc8>
7639
7640 Cc: stable@vger.kernel.org
7641 Cc: Gleb Natapov <gleb@kernel.org>
7642 Cc: Paolo Bonzini <pbonzini@redhat.com>
7643 Signed-off-by: Jason Wang <jasowang@redhat.com>
7644 Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
7645 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7646 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7647
7648commit e26876a7c059fc01dc32f7625e27c8e92b11ac02
7649Author: Jason Wang <jasowang@redhat.com>
7650Date: Tue Sep 15 14:41:55 2015 +0800
7651
7652 kvm: factor out core eventfd assign/deassign logic
7653
7654 [ Upstream commit 85da11ca587c8eb73993a1b503052391a73586f9 ]
7655
7656 This patch factors out core eventfd assign/deassign logic and leaves
7657 the argument checking and bus index selection to callers.
7658
7659 Cc: stable@vger.kernel.org
7660 Cc: Gleb Natapov <gleb@kernel.org>
7661 Cc: Paolo Bonzini <pbonzini@redhat.com>
7662 Signed-off-by: Jason Wang <jasowang@redhat.com>
7663 Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
7664 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7665 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7666
7667commit a5211987ae02a92988717ebbb39191ceb4d8269e
7668Author: Jason Wang <jasowang@redhat.com>
7669Date: Tue Sep 15 14:41:57 2015 +0800
7670
7671 kvm: fix zero length mmio searching
7672
7673 [ Upstream commit 8f4216c7d28976f7ec1b2bcbfa0a9f787133c45e ]
7674
7675 Currently, if we had a zero length mmio eventfd assigned on
7676 KVM_MMIO_BUS. It will never be found by kvm_io_bus_cmp() since it
7677 always compares the kvm_io_range() with the length that guest
7678 wrote. This will cause e.g for vhost, kick will be trapped by qemu
7679 userspace instead of vhost. Fixing this by using zero length if an
7680 iodevice is zero length.
7681
7682 Cc: stable@vger.kernel.org
7683 Cc: Gleb Natapov <gleb@kernel.org>
7684 Cc: Paolo Bonzini <pbonzini@redhat.com>
7685 Signed-off-by: Jason Wang <jasowang@redhat.com>
7686 Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
7687 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7688 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7689
7690commit 50c79062c4b65ec170f1ce21453fae743a7f25cd
7691Author: Jason Wang <jasowang@redhat.com>
7692Date: Tue Sep 15 14:41:54 2015 +0800
7693
7694 kvm: don't try to register to KVM_FAST_MMIO_BUS for non mmio eventfd
7695
7696 [ Upstream commit 8453fecbecae26edb3f278627376caab05d9a88d ]
7697
7698 We only want zero length mmio eventfd to be registered on
7699 KVM_FAST_MMIO_BUS. So check this explicitly when arg->len is zero to
7700 make sure this.
7701
7702 Cc: stable@vger.kernel.org
7703 Cc: Gleb Natapov <gleb@kernel.org>
7704 Cc: Paolo Bonzini <pbonzini@redhat.com>
7705 Signed-off-by: Jason Wang <jasowang@redhat.com>
7706 Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
7707 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
7708 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7709
7710commit 4dd2671da85b129bc287c26f6d9e56bf7af1b2ff
7711Author: Marek Majtyka <marek.majtyka@tieto.com>
7712Date: Wed Sep 16 12:04:55 2015 +0200
7713
7714 arm: KVM: Fix incorrect device to IPA mapping
7715
7716 [ Upstream commit ca09f02f122b2ecb0f5ddfc5fd47b29ed657d4fd ]
7717
7718 A critical bug has been found in device memory stage1 translation for
7719 VMs with more then 4GB of address space. Once vm_pgoff size is smaller
7720 then pa (which is true for LPAE case, u32 and u64 respectively) some
7721 more significant bits of pa may be lost as a shift operation is performed
7722 on u32 and later cast onto u64.
7723
7724 Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12
7725 expected pa(u64): 0x0000002010030000
7726 produced pa(u64): 0x0000000010030000
7727
7728 The fix is to change the order of operations (casting first onto phys_addr_t
7729 and then shifting).
7730
7731 Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
7732 [maz: fixed changelog and patch formatting]
7733 Cc: stable@vger.kernel.org
7734 Signed-off-by: Marek Majtyka <marek.majtyka@tieto.com>
7735 Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
7736
7737 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7738
7739commit a7fd9e578e016ff5cf597fb7dfdc08bd9d260693
7740Author: Kyle Evans <kvans32@gmail.com>
7741Date: Fri Sep 11 10:40:17 2015 -0500
7742
7743 hp-wmi: limit hotkey enable
7744
7745 [ Upstream commit 8a1513b49321e503fd6c8b6793e3b1f9a8a3285b ]
7746
7747 Do not write initialize magic on systems that do not have
7748 feature query 0xb. Fixes Bug #82451.
7749
7750 Redefine FEATURE_QUERY to align with 0xb and FEATURE2 with 0xd
7751 for code clearity.
7752
7753 Add a new test function, hp_wmi_bios_2008_later() & simplify
7754 hp_wmi_bios_2009_later(), which fixes a bug in cases where
7755 an improper value is returned. Probably also fixes Bug #69131.
7756
7757 Add missing __init tag.
7758
7759 Signed-off-by: Kyle Evans <kvans32@gmail.com>
7760 Cc: stable@vger.kernel.org
7761 Signed-off-by: Darren Hart <dvhart@linux.intel.com>
7762 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7763
7764commit a7e5b4e81bcdae0297594ab5917e40d5ce19fe36
7765Author: Luis Henriques <luis.henriques@canonical.com>
7766Date: Thu Sep 17 16:01:40 2015 -0700
7767
7768 zram: fix possible use after free in zcomp_create()
7769
7770 [ Upstream commit 3aaf14da807a4e9931a37f21e4251abb8a67021b ]
7771
7772 zcomp_create() verifies the success of zcomp_strm_{multi,single}_create()
7773 through comp->stream, which can potentially be pointing to memory that
7774 was freed if these functions returned an error.
7775
7776 While at it, replace a 'ERR_PTR(-ENOMEM)' by a more generic
7777 'ERR_PTR(error)' as in the future zcomp_strm_{multi,siggle}_create()
7778 could return other error codes. Function documentation updated
7779 accordingly.
7780
7781 Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
7782 Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
7783 Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
7784 Acked-by: Minchan Kim <minchan@kernel.org>
7785 Cc: <stable@vger.kernel.org>
7786 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
7787 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
7788 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7789
7790commit ae92f497561a09952ac913488f5844a61287d516
7791Author: Stas Sergeev <stsp@list.ru>
7792Date: Mon Jul 20 17:49:57 2015 -0700
7793
7794 of_mdio: add new DT property 'managed' to specify the PHY management type
7795
7796 [ Upstream commit 4cba5c2103657d43d0886e4cff8004d95a3d0def ]
7797
7798 Currently the PHY management type is selected by the MAC driver arbitrary.
7799 The decision is based on the presence of the "fixed-link" node and on a
7800 will of the driver's authors.
7801 This caused a regression recently, when mvneta driver suddenly started
7802 to use the in-band status for auto-negotiation on fixed links.
7803 It appears the auto-negotiation may not work when expected by the MAC driver.
7804 Sebastien Rannou explains:
7805 << Yes, I confirm that my HW does not generate an in-band status. AFAIK, it's
7806 a PHY that aggregates 4xSGMIIs to 1xQSGMII ; the MAC side of the PHY (with
7807 inband status) is connected to the switch through QSGMII, and in this context
7808 we are on the media side of the PHY. >>
7809 https://lkml.org/lkml/2015/7/10/206
7810
7811 This patch introduces the new string property 'managed' that allows
7812 the user to set the management type explicitly.
7813 The supported values are:
7814 "auto" - default. Uses either MDIO or nothing, depending on the presence
7815 of the fixed-link node
7816 "in-band-status" - use in-band status
7817
7818 Signed-off-by: Stas Sergeev <stsp@users.sourceforge.net>
7819
7820 CC: Rob Herring <robh+dt@kernel.org>
7821 CC: Pawel Moll <pawel.moll@arm.com>
7822 CC: Mark Rutland <mark.rutland@arm.com>
7823 CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
7824 CC: Kumar Gala <galak@codeaurora.org>
7825 CC: Florian Fainelli <f.fainelli@gmail.com>
7826 CC: Grant Likely <grant.likely@linaro.org>
7827 CC: devicetree@vger.kernel.org
7828 CC: linux-kernel@vger.kernel.org
7829 CC: netdev@vger.kernel.org
7830 Signed-off-by: David S. Miller <davem@davemloft.net>
7831 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7832
7833commit 8848902935b212be629e02c5b55d5c52119ba45c
7834Author: Florian Fainelli <f.fainelli@gmail.com>
7835Date: Mon Jul 20 17:49:55 2015 -0700
7836
7837 net: dsa: bcm_sf2: Do not override speed settings
7838
7839 [ Upstream commit d2eac98f7d1b950b762a7eca05a9ce0ea1d878d2 ]
7840
7841 The SF2 driver currently overrides speed settings for its port
7842 configured using a fixed PHY, this is both unnecessary and incorrect,
7843 because we keep feedback to the hardware parameters that we read from
7844 the PHY device, which in the case of a fixed PHY cannot possibly change
7845 speed.
7846
7847 This is a required change to allow the fixed PHY code to allow
7848 registering a PHY with a link configured as DOWN by default and avoid
7849 some sort of circular dependency where we require the link_update
7850 callback to run to program the hardware, and we then utilize the fixed
7851 PHY parameters to program the hardware with the same settings.
7852
7853 Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
7854 Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
7855 Signed-off-by: David S. Miller <davem@davemloft.net>
7856 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7857
7858commit 25da25549f1d08f135dcde8eeb09480e7fae6756
7859Author: Eric Dumazet <edumazet@google.com>
7860Date: Wed Sep 23 14:00:21 2015 -0700
7861
7862 tcp: add proper TS val into RST packets
7863
7864 [ Upstream commit 675ee231d960af2af3606b4480324e26797eb010 ]
7865
7866 RST packets sent on behalf of TCP connections with TS option (RFC 7323
7867 TCP timestamps) have incorrect TS val (set to 0), but correct TS ecr.
7868
7869 A > B: Flags [S], seq 0, win 65535, options [mss 1000,nop,nop,TS val 100
7870 ecr 0], length 0
7871 B > A: Flags [S.], seq 2444755794, ack 1, win 28960, options [mss
7872 1460,nop,nop,TS val 7264344 ecr 100], length 0
7873 A > B: Flags [.], ack 1, win 65535, options [nop,nop,TS val 110 ecr
7874 7264344], length 0
7875
7876 B > A: Flags [R.], seq 1, ack 1, win 28960, options [nop,nop,TS val 0
7877 ecr 110], length 0
7878
7879 We need to call skb_mstamp_get() to get proper TS val,
7880 derived from skb->skb_mstamp
7881
7882 Note that RFC 1323 was advocating to not send TS option in RST segment,
7883 but RFC 7323 recommends the opposite :
7884
7885 Once TSopt has been successfully negotiated, that is both <SYN> and
7886 <SYN,ACK> contain TSopt, the TSopt MUST be sent in every non-<RST>
7887 segment for the duration of the connection, and SHOULD be sent in an
7888 <RST> segment (see Section 5.2 for details)
7889
7890 Note this RFC recommends to send TS val = 0, but we believe it is
7891 premature : We do not know if all TCP stacks are properly
7892 handling the receive side :
7893
7894 When an <RST> segment is
7895 received, it MUST NOT be subjected to the PAWS check by verifying an
7896 acceptable value in SEG.TSval, and information from the Timestamps
7897 option MUST NOT be used to update connection state information.
7898 SEG.TSecr MAY be used to provide stricter <RST> acceptance checks.
7899
7900 In 5 years, if/when all TCP stack are RFC 7323 ready, we might consider
7901 to decide to send TS val = 0, if it buys something.
7902
7903 Fixes: 7faee5c0d514 ("tcp: remove TCP_SKB_CB(skb)->when")
7904 Signed-off-by: Eric Dumazet <edumazet@google.com>
7905 Acked-by: Yuchung Cheng <ycheng@google.com>
7906 Signed-off-by: David S. Miller <davem@davemloft.net>
7907 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7908
7909commit 0d79984cc01bf66e2c4a98673b4c6b3bb9a08f66
7910Author: Florian Fainelli <f.fainelli@gmail.com>
7911Date: Tue Sep 8 20:06:41 2015 -0700
7912
7913 net: dsa: bcm_sf2: Fix 64-bits register writes
7914
7915 [ Upstream commit 03679a14739a0d4c14b52ba65a69ff553bfba73b ]
7916
7917 The macro to write 64-bits quantities to the 32-bits register swapped
7918 the value and offsets arguments, we want to preserve the ordering of the
7919 arguments with respect to how writel() is implemented for instance:
7920 value first, offset/base second.
7921
7922 Fixes: 246d7f773c13 ("net: dsa: add Broadcom SF2 switch driver")
7923 Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
7924 Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
7925 Signed-off-by: David S. Miller <davem@davemloft.net>
7926 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7927
7928commit 21a8f4ec1874e08358b92cbca0263c23c9d72f16
7929Author: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
7930Date: Wed Sep 2 17:49:29 2015 +0900
7931
7932 net: eth: altera: fix napi poll_list corruption
7933
7934 [ Upstream commit 4548a697e4969d695047cebd6d9af5e2f6cc728e ]
7935
7936 tse_poll() calls __napi_complete() with irq enabled. This leads napi
7937 poll_list corruption and may stop all napi drivers working.
7938 Use napi_complete() instead of __napi_complete().
7939
7940 Signed-off-by: Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
7941 Signed-off-by: David S. Miller <davem@davemloft.net>
7942 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7943
7944commit 5fb432dcb91062176880d21d7249562c2aa75a19
7945Author: Eric Sandeen <sandeen@redhat.com>
7946Date: Sat Aug 15 10:45:06 2015 -0400
7947
7948 ext4: don't manipulate recovery flag when freezing no-journal fs
7949
7950 [ Upstream commit c642dc9e1aaed953597e7092d7df329e6234096e ]
7951
7952 At some point along this sequence of changes:
7953
7954 f6e63f9 ext4: fold ext4_nojournal_sops into ext4_sops
7955 bb04457 ext4: support freezing ext2 (nojournal) file systems
7956 9ca9238 ext4: Use separate super_operations structure for no_journal filesystems
7957
7958 ext4 started setting needs_recovery on filesystems without journals
7959 when they are unfrozen. This makes no sense, and in fact confuses
7960 blkid to the point where it doesn't recognize the filesystem at all.
7961
7962 (freeze ext2; unfreeze ext2; run blkid; see no output; run dumpe2fs,
7963 see needs_recovery set on fs w/ no journal).
7964
7965 To fix this, don't manipulate the INCOMPAT_RECOVER feature on
7966 filesystems without journals.
7967
7968 Reported-by: Stu Mark <smark@datto.com>
7969 Reviewed-by: Jan Kara <jack@suse.com>
7970 Signed-off-by: Eric Sandeen <sandeen@redhat.com>
7971 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
7972 Cc: stable@vger.kernel.org
7973 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
7974
7975commit f6efbdbc3a9bb1676d186d805a4e3475018146c1
7976Author: Daniel Axtens <dja@axtens.net>
7977Date: Tue Sep 15 15:04:07 2015 +1000
7978
7979 cxl: Fix unbalanced pci_dev_get in cxl_probe
7980
7981 [ Upstream commit 2925c2fdf1e0eb642482f5b30577e9435aaa8edb ]
7982
7983 Currently the first thing we do in cxl_probe is to grab a reference
7984 on the pci device. Later on, we call device_register on our adapter.
7985 In our remove path, we call device_unregister, but we never call
7986 pci_dev_put. We therefore leak the device every time we do a
7987 reflash.
7988
7989 device_register/unregister is sufficient to hold the reference.
7990 Therefore, drop the call to pci_dev_get.
7991
7992 Here's why this is safe.
7993 The proposed cxl_probe(pdev) calls cxl_adapter_init:
7994 a) init calls cxl_adapter_alloc, which creates a struct cxl,
7995 conventionally called adapter. This struct contains a
7996 device entry, adapter->dev.
7997
7998 b) init calls cxl_configure_adapter, where we set
7999 adapter->dev.parent = &dev->dev (here dev is the pci dev)
8000
8001 So at this point, the cxl adapter's device's parent is the PCI
8002 device that I want to be refcounted properly.
8003
8004 c) init calls cxl_register_adapter
8005 *) cxl_register_adapter calls device_register(&adapter->dev)
8006
8007 So now we're in device_register, where dev is the adapter device, and
8008 we want to know if the PCI device is safe after we return.
8009
8010 device_register(&adapter->dev) calls device_initialize() and then
8011 device_add().
8012
8013 device_add() does a get_device(). device_add() also explicitly grabs
8014 the device's parent, and calls get_device() on it:
8015
8016 parent = get_device(dev->parent);
8017
8018 So therefore, device_register() takes a lock on the parent PCI dev,
8019 which is what pci_dev_get() was guarding. pci_dev_get() can therefore
8020 be safely removed.
8021
8022 Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for userspace access")
8023 Cc: stable@vger.kernel.org
8024 Signed-off-by: Daniel Axtens <dja@axtens.net>
8025 Acked-by: Ian Munsie <imunsie@au1.ibm.com>
8026 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
8027 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8028
8029commit 788e0546bd53f9a9da38b671bc4fb644f14f1efc
8030Author: Shota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
8031Date: Wed Jul 1 09:25:52 2015 +0900
8032
8033 igb: Fix oops caused by missing queue pairing
8034
8035 [ Upstream commit 72ddef0506da852dc82f078f37ced8ef4d74a2bf ]
8036
8037 When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
8038 set if adapter->rss_queues exceeds half of max_rss_queues in
8039 igb_init_queue_configuration().
8040 On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
8041 queues exceeds half of max_combined in igb_set_channels() when changing
8042 the number of queues by "ethtool -L".
8043 In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
8044 of adapter->msix_entries[], an overflow can occur in
8045 igb_set_interrupt_capability(), which in turn leads to an oops.
8046
8047 Fix this problem as follows:
8048 - When changing the number of queues by "ethtool -L", set
8049 IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
8050 - When increasing the size of q_vector, reallocate it appropriately.
8051 (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)
8052
8053 Another possible way to fix this problem is to cap the queues at its
8054 initial number, which is the number of the initial online cpus. But this
8055 is not the optimal way because we cannot increase queues when another
8056 cpu becomes online.
8057
8058 Note that before commit cd14ef54d25b ("igb: Change to use statically
8059 allocated array for MSIx entries"), this problem did not cause oops
8060 but just made the number of queues become 1 because of entering msi_only
8061 mode in igb_set_interrupt_capability().
8062
8063 Fixes: 907b7835799f ("igb: Add ethtool support to configure number of channels")
8064 CC: stable <stable@vger.kernel.org>
8065 Signed-off-by: Shota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
8066 Tested-by: Aaron Brown <aaron.f.brown@intel.com>
8067 Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
8068 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8069
8070commit d098c085d0ae8dfa8a52f541fd7ba6c2dc69102d
8071Author: Larry Finger <Larry.Finger@lwfinger.net>
8072Date: Wed Jul 8 10:18:50 2015 -0500
8073
8074 rtlwifi: rtl8821ae: Fix an expression that is always false
8075
8076 [ Upstream commit 251086f588720277a6f5782020a648ce32c4e00b ]
8077
8078 In routine _rtl8821ae_set_media_status(), an incorrect mask results in a test
8079 for AP status to always be false. Similar bugs were fixed in rtl8192cu and
8080 rtl8192de, but this instance was missed at that time.
8081
8082 Reported-by: David Binderman <dcb314@hotmail.com>
8083 Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
8084 Cc: Stable <stable@vger.kernel.org> [3.18+]
8085 Cc: David Binderman <dcb314@hotmail.com>
8086 Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
8087 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8088
8089commit 5cadbe921f575c8cc69907a3ed62541cef571b98
8090Author: Andy Lutomirski <luto@kernel.org>
8091Date: Wed Jul 15 10:29:38 2015 -0700
8092
8093 x86/nmi/64: Use DF to avoid userspace RSP confusing nested NMI detection
8094
8095 [ Upstream commit 810bc075f78ff2c221536eb3008eac6a492dba2d ]
8096
8097 We have a tricky bug in the nested NMI code: if we see RSP
8098 pointing to the NMI stack on NMI entry from kernel mode, we
8099 assume that we are executing a nested NMI.
8100
8101 This isn't quite true. A malicious userspace program can point
8102 RSP at the NMI stack, issue SYSCALL, and arrange for an NMI to
8103 happen while RSP is still pointing at the NMI stack.
8104
8105 Fix it with a sneaky trick. Set DF in the region of code that
8106 the RSP check is intended to detect. IRET will clear DF
8107 atomically.
8108
8109 ( Note: other than paravirt, there's little need for all this
8110 complexity. We could check RIP instead of RSP. )
8111
8112 Signed-off-by: Andy Lutomirski <luto@kernel.org>
8113 Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
8114 Cc: Borislav Petkov <bp@suse.de>
8115 Cc: Linus Torvalds <torvalds@linux-foundation.org>
8116 Cc: Peter Zijlstra <peterz@infradead.org>
8117 Cc: Thomas Gleixner <tglx@linutronix.de>
8118 Cc: stable@vger.kernel.org
8119 Signed-off-by: Ingo Molnar <mingo@kernel.org>
8120 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8121
8122commit 6acb4e24f7101f011d1ab85ddd2f63fc0f26b2b4
8123Author: Andy Lutomirski <luto@kernel.org>
8124Date: Wed Jul 15 10:29:37 2015 -0700
8125
8126 x86/nmi/64: Reorder nested NMI checks
8127
8128 [ Upstream commit a27507ca2d796cfa8d907de31ad730359c8a6d06 ]
8129
8130 Check the repeat_nmi .. end_repeat_nmi special case first. The
8131 next patch will rework the RSP check and, as a side effect, the
8132 RSP check will no longer detect repeat_nmi .. end_repeat_nmi, so
8133 we'll need this ordering of the checks.
8134
8135 Note: this is more subtle than it appears. The check for
8136 repeat_nmi .. end_repeat_nmi jumps straight out of the NMI code
8137 instead of adjusting the "iret" frame to force a repeat. This
8138 is necessary, because the code between repeat_nmi and
8139 end_repeat_nmi sets "NMI executing" and then writes to the
8140 "iret" frame itself. If a nested NMI comes in and modifies the
8141 "iret" frame while repeat_nmi is also modifying it, we'll end up
8142 with garbage. The old code got this right, as does the new
8143 code, but the new code is a bit more explicit.
8144
8145 If we were to move the check right after the "NMI executing"
8146 check, then we'd get it wrong and have random crashes.
8147
8148 ( Because the "NMI executing" check would jump to the code that would
8149 modify the "iret" frame without checking if the interrupted NMI was
8150 currently modifying it. )
8151
8152 Signed-off-by: Andy Lutomirski <luto@kernel.org>
8153 Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
8154 Cc: Borislav Petkov <bp@suse.de>
8155 Cc: Linus Torvalds <torvalds@linux-foundation.org>
8156 Cc: Peter Zijlstra <peterz@infradead.org>
8157 Cc: Thomas Gleixner <tglx@linutronix.de>
8158 Cc: stable@vger.kernel.org
8159 Signed-off-by: Ingo Molnar <mingo@kernel.org>
8160 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8161
8162commit aac26b9c16d68f5b13a606f7100fea119083aa52
8163Author: Andy Lutomirski <luto@kernel.org>
8164Date: Wed Jul 15 10:29:36 2015 -0700
8165
8166 x86/nmi/64: Improve nested NMI comments
8167
8168 [ Upstream commit 0b22930ebad563ae97ff3f8d7b9f12060b4c6e6b ]
8169
8170 I found the nested NMI documentation to be difficult to follow.
8171 Improve the comments.
8172
8173 Signed-off-by: Andy Lutomirski <luto@kernel.org>
8174 Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
8175 Cc: Borislav Petkov <bp@suse.de>
8176 Cc: Linus Torvalds <torvalds@linux-foundation.org>
8177 Cc: Peter Zijlstra <peterz@infradead.org>
8178 Cc: Thomas Gleixner <tglx@linutronix.de>
8179 Cc: stable@vger.kernel.org
8180 Signed-off-by: Ingo Molnar <mingo@kernel.org>
8181 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8182
8183commit 838d2bbdb0468307fad3d1d5f396f99bc87d0a65
8184Author: Ivan Vecera <ivecera@redhat.com>
8185Date: Thu Aug 6 22:48:23 2015 +0200
8186
8187 bna: fix interrupts storm caused by erroneous packets
8188
8189 [ Upstream commit ade4dc3e616e33c80d7e62855fe1b6f9895bc7c3 ]
8190
8191 The commit "e29aa33 bna: Enable Multi Buffer RX" moved packets counter
8192 increment from the beginning of the NAPI processing loop after the check
8193 for erroneous packets so they are never accounted. This counter is used
8194 to inform firmware about number of processed completions (packets).
8195 As these packets are never acked the firmware fires IRQs for them again
8196 and again.
8197
8198 Fixes: e29aa33 ("bna: Enable Multi Buffer RX")
8199 Signed-off-by: Ivan Vecera <ivecera@redhat.com>
8200 Acked-by: Rasesh Mody <rasesh.mody@qlogic.com>
8201 Signed-off-by: David S. Miller <davem@davemloft.net>
8202 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8203
8204commit 3a2c446444593647bdc13d6da6fcabfc99ac7470
8205Author: Eric Dumazet <edumazet@google.com>
8206Date: Sat Aug 1 12:14:33 2015 +0200
8207
8208 udp: fix dst races with multicast early demux
8209
8210 [ Upstream commit 10e2eb878f3ca07ac2f05fa5ca5e6c4c9174a27a ]
8211
8212 Multicast dst are not cached. They carry DST_NOCACHE.
8213
8214 As mentioned in commit f8864972126899 ("ipv4: fix dst race in
8215 sk_dst_get()"), these dst need special care before caching them
8216 into a socket.
8217
8218 Caching them is allowed only if their refcnt was not 0, ie we
8219 must use atomic_inc_not_zero()
8220
8221 Also, we must use READ_ONCE() to fetch sk->sk_rx_dst, as mentioned
8222 in commit d0c294c53a771 ("tcp: prevent fetching dst twice in early demux
8223 code")
8224
8225 Fixes: 421b3885bf6d ("udp: ipv4: Add udp early demux")
8226 Tested-by: Gregory Hoggarth <Gregory.Hoggarth@alliedtelesis.co.nz>
8227 Signed-off-by: Eric Dumazet <edumazet@google.com>
8228 Reported-by: Gregory Hoggarth <Gregory.Hoggarth@alliedtelesis.co.nz>
8229 Reported-by: Alex Gartrell <agartrell@fb.com>
8230 Cc: Michal Kubeček <mkubecek@suse.cz>
8231 Signed-off-by: David S. Miller <davem@davemloft.net>
8232 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8233
8234commit 4320f02c4667d3106fe0c9e308694490a3b51913
8235Author: Lars Westerhoff <lars.westerhoff@newtec.eu>
8236Date: Tue Jul 28 01:32:21 2015 +0300
8237
8238 packet: missing dev_put() in packet_do_bind()
8239
8240 [ Upstream commit 158cd4af8dedbda0d612d448c724c715d0dda649 ]
8241
8242 When binding a PF_PACKET socket, the use count of the bound interface is
8243 always increased with dev_hold in dev_get_by_{index,name}. However,
8244 when rebound with the same protocol and device as in the previous bind
8245 the use count of the interface was not decreased. Ultimately, this
8246 caused the deletion of the interface to fail with the following message:
8247
8248 unregister_netdevice: waiting for dummy0 to become free. Usage count = 1
8249
8250 This patch moves the dev_put out of the conditional part that was only
8251 executed when either the protocol or device changed on a bind.
8252
8253 Fixes: 902fefb82ef7 ('packet: improve socket create/bind latency in some cases')
8254 Signed-off-by: Lars Westerhoff <lars.westerhoff@newtec.eu>
8255 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
8256 Reviewed-by: Daniel Borkmann <dborkman@redhat.com>
8257 Signed-off-by: David S. Miller <davem@davemloft.net>
8258 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8259
8260commit e6551e40ada2272f7388c7e2d157ef3474ba2c34
8261Author: Wilson Kok <wkok@cumulusnetworks.com>
8262Date: Tue Sep 22 21:40:22 2015 -0700
8263
8264 fib_rules: fix fib rule dumps across multiple skbs
8265
8266 [ Upstream commit 41fc014332d91ee90c32840bf161f9685b7fbf2b ]
8267
8268 dump_rules returns skb length and not error.
8269 But when family == AF_UNSPEC, the caller of dump_rules
8270 assumes that it returns an error. Hence, when family == AF_UNSPEC,
8271 we continue trying to dump on -EMSGSIZE errors resulting in
8272 incorrect dump idx carried between skbs belonging to the same dump.
8273 This results in fib rule dump always only dumping rules that fit
8274 into the first skb.
8275
8276 This patch fixes dump_rules to return error so that we exit correctly
8277 and idx is correctly maintained between skbs that are part of the
8278 same dump.
8279
8280 Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
8281 Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
8282 Signed-off-by: David S. Miller <davem@davemloft.net>
8283 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8284
8285commit 8f1cdabcc6ccd7dea59fffc692e122c0b5eaf9f2
8286Author: Jesse Gross <jesse@nicira.com>
8287Date: Mon Sep 21 20:21:20 2015 -0700
8288
8289 openvswitch: Zero flows on allocation.
8290
8291 [ Upstream commit ae5f2fb1d51fa128a460bcfbe3c56d7ab8bf6a43 ]
8292
8293 When support for megaflows was introduced, OVS needed to start
8294 installing flows with a mask applied to them. Since masking is an
8295 expensive operation, OVS also had an optimization that would only
8296 take the parts of the flow keys that were covered by a non-zero
8297 mask. The values stored in the remaining pieces should not matter
8298 because they are masked out.
8299
8300 While this works fine for the purposes of matching (which must always
8301 look at the mask), serialization to netlink can be problematic. Since
8302 the flow and the mask are serialized separately, the uninitialized
8303 portions of the flow can be encoded with whatever values happen to be
8304 present.
8305
8306 In terms of functionality, this has little effect since these fields
8307 will be masked out by definition. However, it leaks kernel memory to
8308 userspace, which is a potential security vulnerability. It is also
8309 possible that other code paths could look at the masked key and get
8310 uninitialized data, although this does not currently appear to be an
8311 issue in practice.
8312
8313 This removes the mask optimization for flows that are being installed.
8314 This was always intended to be the case as the mask optimizations were
8315 really targetting per-packet flow operations.
8316
8317 Fixes: 03f0d916 ("openvswitch: Mega flow implementation")
8318 Signed-off-by: Jesse Gross <jesse@nicira.com>
8319 Acked-by: Pravin B Shelar <pshelar@nicira.com>
8320 Signed-off-by: David S. Miller <davem@davemloft.net>
8321 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8322
8323commit 738a811a9ee144f98717ae29441825615b551c0d
8324Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
8325Date: Thu Sep 10 17:31:15 2015 -0300
8326
8327 sctp: fix race on protocol/netns initialization
8328
8329 [ Upstream commit 8e2d61e0aed2b7c4ecb35844fe07e0b2b762dee4 ]
8330
8331 Consider sctp module is unloaded and is being requested because an user
8332 is creating a sctp socket.
8333
8334 During initialization, sctp will add the new protocol type and then
8335 initialize pernet subsys:
8336
8337 status = sctp_v4_protosw_init();
8338 if (status)
8339 goto err_protosw_init;
8340
8341 status = sctp_v6_protosw_init();
8342 if (status)
8343 goto err_v6_protosw_init;
8344
8345 status = register_pernet_subsys(&sctp_net_ops);
8346
8347 The problem is that after those calls to sctp_v{4,6}_protosw_init(), it
8348 is possible for userspace to create SCTP sockets like if the module is
8349 already fully loaded. If that happens, one of the possible effects is
8350 that we will have readers for net->sctp.local_addr_list list earlier
8351 than expected and sctp_net_init() does not take precautions while
8352 dealing with that list, leading to a potential panic but not limited to
8353 that, as sctp_sock_init() will copy a bunch of blank/partially
8354 initialized values from net->sctp.
8355
8356 The race happens like this:
8357
8358 CPU 0 | CPU 1
8359 socket() |
8360 __sock_create | socket()
8361 inet_create | __sock_create
8362 list_for_each_entry_rcu( |
8363 answer, &inetsw[sock->type], |
8364 list) { | inet_create
8365 /* no hits */ |
8366 if (unlikely(err)) { |
8367 ... |
8368 request_module() |
8369 /* socket creation is blocked |
8370 * the module is fully loaded |
8371 */ |
8372 sctp_init |
8373 sctp_v4_protosw_init |
8374 inet_register_protosw |
8375 list_add_rcu(&p->list, |
8376 last_perm); |
8377 | list_for_each_entry_rcu(
8378 | answer, &inetsw[sock->type],
8379 sctp_v6_protosw_init | list) {
8380 | /* hit, so assumes protocol
8381 | * is already loaded
8382 | */
8383 | /* socket creation continues
8384 | * before netns is initialized
8385 | */
8386 register_pernet_subsys |
8387
8388 Simply inverting the initialization order between
8389 register_pernet_subsys() and sctp_v4_protosw_init() is not possible
8390 because register_pernet_subsys() will create a control sctp socket, so
8391 the protocol must be already visible by then. Deferring the socket
8392 creation to a work-queue is not good specially because we loose the
8393 ability to handle its errors.
8394
8395 So, as suggested by Vlad, the fix is to split netns initialization in
8396 two moments: defaults and control socket, so that the defaults are
8397 already loaded by when we register the protocol, while control socket
8398 initialization is kept at the same moment it is today.
8399
8400 Fixes: 4db67e808640 ("sctp: Make the address lists per network namespace")
8401 Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
8402 Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
8403 Signed-off-by: David S. Miller <davem@davemloft.net>
8404 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8405
8406commit 821cb36fe391803e70c61bab8321abc1108ddcce
8407Author: Daniel Borkmann <daniel@iogearbox.net>
8408Date: Thu Sep 10 20:05:46 2015 +0200
8409
8410 netlink, mmap: transform mmap skb into full skb on taps
8411
8412 [ Upstream commit 1853c949646005b5959c483becde86608f548f24 ]
8413
8414 Ken-ichirou reported that running netlink in mmap mode for receive in
8415 combination with nlmon will throw a NULL pointer dereference in
8416 __kfree_skb() on nlmon_xmit(), in my case I can also trigger an "unable
8417 to handle kernel paging request". The problem is the skb_clone() in
8418 __netlink_deliver_tap_skb() for skbs that are mmaped.
8419
8420 I.e. the cloned skb doesn't have a destructor, whereas the mmap netlink
8421 skb has it pointed to netlink_skb_destructor(), set in the handler
8422 netlink_ring_setup_skb(). There, skb->head is being set to NULL, so
8423 that in such cases, __kfree_skb() doesn't perform a skb_release_data()
8424 via skb_release_all(), where skb->head is possibly being freed through
8425 kfree(head) into slab allocator, although netlink mmap skb->head points
8426 to the mmap buffer. Similarly, the same has to be done also for large
8427 netlink skbs where the data area is vmalloced. Therefore, as discussed,
8428 make a copy for these rather rare cases for now. This fixes the issue
8429 on my and Ken-ichirou's test-cases.
8430
8431 Reference: http://thread.gmane.org/gmane.linux.network/371129
8432 Fixes: bcbde0d449ed ("net: netlink: virtual tap device management")
8433 Reported-by: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
8434 Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
8435 Tested-by: Ken-ichirou MATSUZAWA <chamaken@gmail.com>
8436 Signed-off-by: David S. Miller <davem@davemloft.net>
8437 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8438
8439commit 371a4bbb343053875e2165958b98a54514a9c186
8440Author: Richard Laing <richard.laing@alliedtelesis.co.nz>
8441Date: Thu Sep 3 13:52:31 2015 +1200
8442
8443 net/ipv6: Correct PIM6 mrt_lock handling
8444
8445 [ Upstream commit 25b4a44c19c83d98e8c0807a7ede07c1f28eab8b ]
8446
8447 In the IPv6 multicast routing code the mrt_lock was not being released
8448 correctly in the MFC iterator, as a result adding or deleting a MIF would
8449 cause a hang because the mrt_lock could not be acquired.
8450
8451 This fix is a copy of the code for the IPv4 case and ensures that the lock
8452 is released correctly.
8453
8454 Signed-off-by: Richard Laing <richard.laing@alliedtelesis.co.nz>
8455 Acked-by: Cong Wang <cwang@twopensource.com>
8456 Signed-off-by: David S. Miller <davem@davemloft.net>
8457 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8458
8459commit 232baded6d6fd8814de60534d30ced820552c015
8460Author: Daniel Borkmann <daniel@iogearbox.net>
8461Date: Thu Sep 3 00:29:07 2015 +0200
8462
8463 ipv6: fix exthdrs offload registration in out_rt path
8464
8465 [ Upstream commit e41b0bedba0293b9e1e8d1e8ed553104b9693656 ]
8466
8467 We previously register IPPROTO_ROUTING offload under inet6_add_offload(),
8468 but in error path, we try to unregister it with inet_del_offload(). This
8469 doesn't seem correct, it should actually be inet6_del_offload(), also
8470 ipv6_exthdrs_offload_exit() from that commit seems rather incorrect (it
8471 also uses rthdr_offload twice), but it got removed entirely later on.
8472
8473 Fixes: 3336288a9fea ("ipv6: Switch to using new offload infrastructure.")
8474 Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
8475 Signed-off-by: David S. Miller <davem@davemloft.net>
8476 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8477
8478commit f9e86ab009f39ff2d25379f3fed3a5d8f2ad25e7
8479Author: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
8480Date: Mon Aug 24 23:13:42 2015 +0300
8481
8482 usbnet: Get EVENT_NO_RUNTIME_PM bit before it is cleared
8483
8484 [ Upstream commit f50791ac1aca1ac1b0370d62397b43e9f831421a ]
8485
8486 It is needed to check EVENT_NO_RUNTIME_PM bit of dev->flags in
8487 usbnet_stop(), but its value should be read before it is cleared
8488 when dev->flags is set to 0.
8489
8490 The problem was spotted and the fix was provided by
8491 Oliver Neukum <oneukum@suse.de>.
8492
8493 Signed-off-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
8494 Acked-by: Oliver Neukum <oneukum@suse.com>
8495 Signed-off-by: David S. Miller <davem@davemloft.net>
8496 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8497
8498commit 78aa277b5c1ad0b2091b94bf1d57db9b557e186e
8499Author: huaibin Wang <huaibin.wang@6wind.com>
8500Date: Tue Aug 25 16:20:34 2015 +0200
8501
8502 ip6_gre: release cached dst on tunnel removal
8503
8504 [ Upstream commit d4257295ba1b389c693b79de857a96e4b7cd8ac0 ]
8505
8506 When a tunnel is deleted, the cached dst entry should be released.
8507
8508 This problem may prevent the removal of a netns (seen with a x-netns IPv6
8509 gre tunnel):
8510 unregister_netdevice: waiting for lo to become free. Usage count = 3
8511
8512 CC: Dmitry Kozlov <xeb@mail.ru>
8513 Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
8514 Signed-off-by: huaibin Wang <huaibin.wang@6wind.com>
8515 Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
8516 Signed-off-by: David S. Miller <davem@davemloft.net>
8517 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8518
8519commit fa89e04f61900d6888517ac0c42907c569fc7c44
8520Author: Daniel Borkmann <daniel@iogearbox.net>
8521Date: Tue Jul 7 00:07:52 2015 +0200
8522
8523 rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver
8524
8525 [ Upstream commit 4f7d2cdfdde71ffe962399b7020c674050329423 ]
8526
8527 Jason Gunthorpe reported that since commit c02db8c6290b ("rtnetlink: make
8528 SR-IOV VF interface symmetric"), we don't verify IFLA_VF_INFO attributes
8529 anymore with respect to their policy, that is, ifla_vfinfo_policy[].
8530
8531 Before, they were part of ifla_policy[], but they have been nested since
8532 placed under IFLA_VFINFO_LIST, that contains the attribute IFLA_VF_INFO,
8533 which is another nested attribute for the actual VF attributes such as
8534 IFLA_VF_MAC, IFLA_VF_VLAN, etc.
8535
8536 Despite the policy being split out from ifla_policy[] in this commit,
8537 it's never applied anywhere. nla_for_each_nested() only does basic nla_ok()
8538 testing for struct nlattr, but it doesn't know about the data context and
8539 their requirements.
8540
8541 Fix, on top of Jason's initial work, does 1) parsing of the attributes
8542 with the right policy, and 2) using the resulting parsed attribute table
8543 from 1) instead of the nla_for_each_nested() loop (just like we used to
8544 do when still part of ifla_policy[]).
8545
8546 Reference: http://thread.gmane.org/gmane.linux.network/368913
8547 Fixes: c02db8c6290b ("rtnetlink: make SR-IOV VF interface symmetric")
8548 Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
8549 Cc: Chris Wright <chrisw@sous-sol.org>
8550 Cc: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
8551 Cc: Greg Rose <gregory.v.rose@intel.com>
8552 Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
8553 Cc: Rony Efraim <ronye@mellanox.com>
8554 Cc: Vlad Zolotarov <vladz@cloudius-systems.com>
8555 Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
8556 Cc: Thomas Graf <tgraf@suug.ch>
8557 Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
8558 Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
8559 Acked-by: Vlad Zolotarov <vladz@cloudius-systems.com>
8560 Signed-off-by: David S. Miller <davem@davemloft.net>
8561 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8562
8563commit 7acebc24194b31d4e5b98f9e436ae960c0948dd6
8564Author: Vlad Zolotarov <vladz@cloudius-systems.com>
8565Date: Mon Mar 30 21:35:23 2015 +0300
8566
8567 if_link: Add an additional parameter to ifla_vf_info for RSS querying
8568
8569 [ Upstream commit 01a3d796813d6302af9f828f34b73d21a4b96c9a ]
8570
8571 Add configuration setting for drivers to allow/block an RSS Redirection
8572 Table and a Hash Key querying for discrete VFs.
8573
8574 On some devices VF share the mentioned above information with PF and
8575 querying it may adduce a theoretical security risk. We want to let a
8576 system administrator to decide if he/she wants to take this risk or not.
8577
8578 Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
8579 Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
8580 Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
8581 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8582
8583commit 2117c584b5952c240d194486a9aeba34265736bc
8584Author: Hin-Tak Leung <htl10@users.sourceforge.net>
8585Date: Wed Sep 9 15:38:04 2015 -0700
8586
8587 hfs,hfsplus: cache pages correctly between bnode_create and bnode_free
8588
8589 [ Upstream commit 7cb74be6fd827e314f81df3c5889b87e4c87c569 ]
8590
8591 Pages looked up by __hfs_bnode_create() (called by hfs_bnode_create() and
8592 hfs_bnode_find() for finding or creating pages corresponding to an inode)
8593 are immediately kmap()'ed and used (both read and write) and kunmap()'ed,
8594 and should not be page_cache_release()'ed until hfs_bnode_free().
8595
8596 This patch fixes a problem I first saw in July 2012: merely running "du"
8597 on a large hfsplus-mounted directory a few times on a reasonably loaded
8598 system would get the hfsplus driver all confused and complaining about
8599 B-tree inconsistencies, and generates a "BUG: Bad page state". Most
8600 recently, I can generate this problem on up-to-date Fedora 22 with shipped
8601 kernel 4.0.5, by running "du /" (="/" + "/home" + "/mnt" + other smaller
8602 mounts) and "du /mnt" simultaneously on two windows, where /mnt is a
8603 lightly-used QEMU VM image of the full Mac OS X 10.9:
8604
8605 $ df -i / /home /mnt
8606 Filesystem Inodes IUsed IFree IUse% Mounted on
8607 /dev/mapper/fedora-root 3276800 551665 2725135 17% /
8608 /dev/mapper/fedora-home 52879360 716221 52163139 2% /home
8609 /dev/nbd0p2 4294967295 1387818 4293579477 1% /mnt
8610
8611 After applying the patch, I was able to run "du /" (60+ times) and "du
8612 /mnt" (150+ times) continuously and simultaneously for 6+ hours.
8613
8614 There are many reports of the hfsplus driver getting confused under load
8615 and generating "BUG: Bad page state" or other similar issues over the
8616 years. [1]
8617
8618 The unpatched code [2] has always been wrong since it entered the kernel
8619 tree. The only reason why it gets away with it is that the
8620 kmap/memcpy/kunmap follow very quickly after the page_cache_release() so
8621 the kernel has not had a chance to reuse the memory for something else,
8622 most of the time.
8623
8624 The current RW driver appears to have followed the design and development
8625 of the earlier read-only hfsplus driver [3], where-by version 0.1 (Dec
8626 2001) had a B-tree node-centric approach to
8627 read_cache_page()/page_cache_release() per bnode_get()/bnode_put(),
8628 migrating towards version 0.2 (June 2002) of caching and releasing pages
8629 per inode extents. When the current RW code first entered the kernel [2]
8630 in 2005, there was an REF_PAGES conditional (and "//" commented out code)
8631 to switch between B-node centric paging to inode-centric paging. There
8632 was a mistake with the direction of one of the REF_PAGES conditionals in
8633 __hfs_bnode_create(). In a subsequent "remove debug code" commit [4], the
8634 read_cache_page()/page_cache_release() per bnode_get()/bnode_put() were
8635 removed, but a page_cache_release() was mistakenly left in (propagating
8636 the "REF_PAGES <-> !REF_PAGE" mistake), and the commented-out
8637 page_cache_release() in bnode_release() (which should be spanned by
8638 !REF_PAGES) was never enabled.
8639
8640 References:
8641 [1]:
8642 Michael Fox, Apr 2013
8643 http://www.spinics.net/lists/linux-fsdevel/msg63807.html
8644 ("hfsplus volume suddenly inaccessable after 'hfs: recoff %d too large'")
8645
8646 Sasha Levin, Feb 2015
8647 http://lkml.org/lkml/2015/2/20/85 ("use after free")
8648
8649 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/740814
8650 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1027887
8651 https://bugzilla.kernel.org/show_bug.cgi?id=42342
8652 https://bugzilla.kernel.org/show_bug.cgi?id=63841
8653 https://bugzilla.kernel.org/show_bug.cgi?id=78761
8654
8655 [2]:
8656 http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/\
8657 fs/hfs/bnode.c?id=d1081202f1d0ee35ab0beb490da4b65d4bc763db
8658 commit d1081202f1d0ee35ab0beb490da4b65d4bc763db
8659 Author: Andrew Morton <akpm@osdl.org>
8660 Date: Wed Feb 25 16:17:36 2004 -0800
8661
8662 [PATCH] HFS rewrite
8663
8664 http://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/\
8665 fs/hfsplus/bnode.c?id=91556682e0bf004d98a529bf829d339abb98bbbd
8666
8667 commit 91556682e0bf004d98a529bf829d339abb98bbbd
8668 Author: Andrew Morton <akpm@osdl.org>
8669 Date: Wed Feb 25 16:17:48 2004 -0800
8670
8671 [PATCH] HFS+ support
8672
8673 [3]:
8674 http://sourceforge.net/projects/linux-hfsplus/
8675
8676 http://sourceforge.net/projects/linux-hfsplus/files/Linux%202.4.x%20patch/hfsplus%200.1/
8677 http://sourceforge.net/projects/linux-hfsplus/files/Linux%202.4.x%20patch/hfsplus%200.2/
8678
8679 http://linux-hfsplus.cvs.sourceforge.net/viewvc/linux-hfsplus/linux/\
8680 fs/hfsplus/bnode.c?r1=1.4&r2=1.5
8681
8682 Date: Thu Jun 6 09:45:14 2002 +0000
8683 Use buffer cache instead of page cache in bnode.c. Cache inode extents.
8684
8685 [4]:
8686 http://git.kernel.org/cgit/linux/kernel/git/\
8687 stable/linux-stable.git/commit/?id=a5e3985fa014029eb6795664c704953720cc7f7d
8688
8689 commit a5e3985fa014029eb6795664c704953720cc7f7d
8690 Author: Roman Zippel <zippel@linux-m68k.org>
8691 Date: Tue Sep 6 15:18:47 2005 -0700
8692
8693 [PATCH] hfs: remove debug code
8694
8695 Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
8696 Signed-off-by: Sergei Antonov <saproj@gmail.com>
8697 Reviewed-by: Anton Altaparmakov <anton@tuxera.com>
8698 Reported-by: Sasha Levin <sasha.levin@oracle.com>
8699 Cc: Al Viro <viro@zeniv.linux.org.uk>
8700 Cc: Christoph Hellwig <hch@infradead.org>
8701 Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
8702 Cc: Sougata Santra <sougata@tuxera.com>
8703 Cc: <stable@vger.kernel.org>
8704 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
8705 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
8706 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8707
8708commit 13f3dc548b25086fb4e66636f6a1c8ba79b8353c
8709Author: Noa Osherovich <noaos@mellanox.com>
8710Date: Thu Jul 30 17:34:24 2015 +0300
8711
8712 IB/mlx4: Use correct SL on AH query under RoCE
8713
8714 [ Upstream commit 5e99b139f1b68acd65e36515ca347b03856dfb5a ]
8715
8716 The mlx4 IB driver implementation for ib_query_ah used a wrong offset
8717 (28 instead of 29) when link type is Ethernet. Fixed to use the correct one.
8718
8719 Fixes: fa417f7b520e ('IB/mlx4: Add support for IBoE')
8720 Signed-off-by: Shani Michaeli <shanim@mellanox.com>
8721 Signed-off-by: Noa Osherovich <noaos@mellanox.com>
8722 Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
8723 Signed-off-by: Doug Ledford <dledford@redhat.com>
8724 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8725
8726commit 40968908297a4416894af5a203b43632d331435c
8727Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
8728Date: Thu Jul 30 17:34:23 2015 +0300
8729
8730 IB/mlx4: Forbid using sysfs to change RoCE pkeys
8731
8732 [ Upstream commit 2b135db3e81301d0452e6aa107349abe67b097d6 ]
8733
8734 The pkey mapping for RoCE must remain the default mapping:
8735 VFs:
8736 virtual index 0 = mapped to real index 0 (0xFFFF)
8737 All others indices: mapped to a real pkey index containing an
8738 invalid pkey.
8739 PF:
8740 virtual index i = real index i.
8741
8742 Don't allow users to change these mappings using files found in
8743 sysfs.
8744
8745 Fixes: c1e7e466120b ('IB/mlx4: Add iov directory in sysfs under the ib device')
8746 Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
8747 Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
8748 Signed-off-by: Doug Ledford <dledford@redhat.com>
8749 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8750
8751commit 15b3aadf15f0bb696184235163ff42ab0cb7e26c
8752Author: Yishai Hadas <yishaih@mellanox.com>
8753Date: Thu Aug 13 18:32:03 2015 +0300
8754
8755 IB/uverbs: Fix race between ib_uverbs_open and remove_one
8756
8757 [ Upstream commit 35d4a0b63dc0c6d1177d4f532a9deae958f0662c ]
8758
8759 Fixes: 2a72f212263701b927559f6850446421d5906c41 ("IB/uverbs: Remove dev_table")
8760
8761 Before this commit there was a device look-up table that was protected
8762 by a spin_lock used by ib_uverbs_open and by ib_uverbs_remove_one. When
8763 it was dropped and container_of was used instead, it enabled the race
8764 with remove_one as dev might be freed just after:
8765 dev = container_of(inode->i_cdev, struct ib_uverbs_device, cdev) but
8766 before the kref_get.
8767
8768 In addition, this buggy patch added some dead code as
8769 container_of(x,y,z) can never be NULL and so dev can never be NULL.
8770 As a result the comment above ib_uverbs_open saying "the open method
8771 will either immediately run -ENXIO" is wrong as it can never happen.
8772
8773 The solution follows Jason Gunthorpe suggestion from below URL:
8774 https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg25692.html
8775
8776 cdev will hold a kref on the parent (the containing structure,
8777 ib_uverbs_device) and only when that kref is released it is
8778 guaranteed that open will never be called again.
8779
8780 In addition, fixes the active count scheme to use an atomic
8781 not a kref to prevent WARN_ON as pointed by above comment
8782 from Jason.
8783
8784 Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
8785 Signed-off-by: Shachar Raindel <raindel@mellanox.com>
8786 Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
8787 Signed-off-by: Doug Ledford <dledford@redhat.com>
8788 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8789
8790commit 7c1d757a1fe62ec2983751441724acd0e2f8cd3c
8791Author: Christoph Hellwig <hch@lst.de>
8792Date: Wed Aug 26 11:00:37 2015 +0200
8793
8794 IB/uverbs: reject invalid or unknown opcodes
8795
8796 [ Upstream commit b632ffa7cee439ba5dce3b3bc4a5cbe2b3e20133 ]
8797
8798 We have many WR opcodes that are only supported in kernel space
8799 and/or require optional information to be copied into the WR
8800 structure. Reject all those not explicitly handled so that we
8801 can't pass invalid information to drivers.
8802
8803 Cc: stable@vger.kernel.org
8804 Signed-off-by: Christoph Hellwig <hch@lst.de>
8805 Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
8806 Reviewed-by: Sagi Grimberg <sagig@mellanox.com>
8807 Signed-off-by: Doug Ledford <dledford@redhat.com>
8808 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8809
8810commit f3990e99b398e64af5f75eea3e4acc09260b667a
8811Author: Mike Marciniszyn <mike.marciniszyn@intel.com>
8812Date: Tue Jul 21 08:36:07 2015 -0400
8813
8814 IB/qib: Change lkey table allocation to support more MRs
8815
8816 [ Upstream commit d6f1c17e162b2a11e708f28fa93f2f79c164b442 ]
8817
8818 The lkey table is allocated with with a get_user_pages() with an
8819 order based on a number of index bits from a module parameter.
8820
8821 The underlying kernel code cannot allocate that many contiguous pages.
8822
8823 There is no reason the underlying memory needs to be physically
8824 contiguous.
8825
8826 This patch:
8827 - switches the allocation/deallocation to vmalloc/vfree
8828 - caps the number of bits to 23 to insure at least 1 generation bit
8829 o this matches the module parameter description
8830
8831 Cc: stable@vger.kernel.org
8832 Reviewed-by: Vinit Agnihotri <vinit.abhay.agnihotri@intel.com>
8833 Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
8834 Signed-off-by: Doug Ledford <dledford@redhat.com>
8835 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8836
8837commit 15c8f5c3e07d2059e02b686fc8f1abfd7201d4ca
8838Author: Hin-Tak Leung <htl10@users.sourceforge.net>
8839Date: Wed Sep 9 15:38:07 2015 -0700
8840
8841 hfs: fix B-tree corruption after insertion at position 0
8842
8843 [ Upstream commit b4cc0efea4f0bfa2477c56af406cfcf3d3e58680 ]
8844
8845 Fix B-tree corruption when a new record is inserted at position 0 in the
8846 node in hfs_brec_insert().
8847
8848 This is an identical change to the corresponding hfs b-tree code to Sergei
8849 Antonov's "hfsplus: fix B-tree corruption after insertion at position 0",
8850 to keep similar code paths in the hfs and hfsplus drivers in sync, where
8851 appropriate.
8852
8853 Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
8854 Cc: Sergei Antonov <saproj@gmail.com>
8855 Cc: Joe Perches <joe@perches.com>
8856 Reviewed-by: Vyacheslav Dubeyko <slava@dubeyko.com>
8857 Cc: Anton Altaparmakov <anton@tuxera.com>
8858 Cc: Al Viro <viro@zeniv.linux.org.uk>
8859 Cc: Christoph Hellwig <hch@infradead.org>
8860 Cc: <stable@vger.kernel.org>
8861 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
8862 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
8863 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8864
8865commit 3a2915dad9da74c13fd6a83c7d0465ce89fd4403
8866Author: NeilBrown <neilb@suse.com>
8867Date: Mon Jul 6 17:37:49 2015 +1000
8868
8869 md/raid10: always set reshape_safe when initializing reshape_position.
8870
8871 [ Upstream commit 299b0685e31c9f3dcc2d58ee3beca761a40b44b3 ]
8872
8873 'reshape_position' tracks where in the reshape we have reached.
8874 'reshape_safe' tracks where in the reshape we have safely recorded
8875 in the metadata.
8876
8877 These are compared to determine when to update the metadata.
8878 So it is important that reshape_safe is initialised properly.
8879 Currently it isn't. When starting a reshape from the beginning
8880 it usually has the correct value by luck. But when reducing the
8881 number of devices in a RAID10, it has the wrong value and this leads
8882 to the metadata not being updated correctly.
8883 This can lead to corruption if the reshape is not allowed to complete.
8884
8885 This patch is suitable for any -stable kernel which supports RAID10
8886 reshape, which is 3.5 and later.
8887
8888 Fixes: 3ea7daa5d7fd ("md/raid10: add reshape support")
8889 Cc: stable@vger.kernel.org (v3.5+ please wait for -final to be out for 2 weeks)
8890 Signed-off-by: NeilBrown <neilb@suse.com>
8891 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8892
8893commit c1802263482f6ce2501830c8aca14f582b7130cf
8894Author: Jialing Fu <jlfu@marvell.com>
8895Date: Fri Aug 28 11:13:09 2015 +0800
8896
8897 mmc: core: fix race condition in mmc_wait_data_done
8898
8899 [ Upstream commit 71f8a4b81d040b3d094424197ca2f1bf811b1245 ]
8900
8901 The following panic is captured in ker3.14, but the issue still exists
8902 in latest kernel.
8903 ---------------------------------------------------------------------
8904 [ 20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer dereference
8905 at virtual address 00000578
8906 ......
8907 [ 20.738499] c0 3136 (Compiler) PC is at _raw_spin_lock_irqsave+0x24/0x60
8908 [ 20.738527] c0 3136 (Compiler) LR is at _raw_spin_lock_irqsave+0x20/0x60
8909 [ 20.740134] c0 3136 (Compiler) Call trace:
8910 [ 20.740165] c0 3136 (Compiler) [<ffffffc0008ee900>] _raw_spin_lock_irqsave+0x24/0x60
8911 [ 20.740200] c0 3136 (Compiler) [<ffffffc0000dd024>] __wake_up+0x1c/0x54
8912 [ 20.740230] c0 3136 (Compiler) [<ffffffc000639414>] mmc_wait_data_done+0x28/0x34
8913 [ 20.740262] c0 3136 (Compiler) [<ffffffc0006391a0>] mmc_request_done+0xa4/0x220
8914 [ 20.740314] c0 3136 (Compiler) [<ffffffc000656894>] sdhci_tasklet_finish+0xac/0x264
8915 [ 20.740352] c0 3136 (Compiler) [<ffffffc0000a2b58>] tasklet_action+0xa0/0x158
8916 [ 20.740382] c0 3136 (Compiler) [<ffffffc0000a2078>] __do_softirq+0x10c/0x2e4
8917 [ 20.740411] c0 3136 (Compiler) [<ffffffc0000a24bc>] irq_exit+0x8c/0xc0
8918 [ 20.740439] c0 3136 (Compiler) [<ffffffc00008489c>] handle_IRQ+0x48/0xac
8919 [ 20.740469] c0 3136 (Compiler) [<ffffffc000081428>] gic_handle_irq+0x38/0x7c
8920 ----------------------------------------------------------------------
8921 Because in SMP, "mrq" has race condition between below two paths:
8922 path1: CPU0: <tasklet context>
8923 static void mmc_wait_data_done(struct mmc_request *mrq)
8924 {
8925 mrq->host->context_info.is_done_rcv = true;
8926 //
8927 // If CPU0 has just finished "is_done_rcv = true" in path1, and at
8928 // this moment, IRQ or ICache line missing happens in CPU0.
8929 // What happens in CPU1 (path2)?
8930 //
8931 // If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
8932 // path2 would have chance to break from wait_event_interruptible
8933 // in mmc_wait_for_data_req_done and continue to run for next
8934 // mmc_request (mmc_blk_rw_rq_prep).
8935 //
8936 // Within mmc_blk_rq_prep, mrq is cleared to 0.
8937 // If below line still gets host from "mrq" as the result of
8938 // compiler, the panic happens as we traced.
8939 wake_up_interruptible(&mrq->host->context_info.wait);
8940 }
8941
8942 path2: CPU1: <The mmcqd thread runs mmc_queue_thread>
8943 static int mmc_wait_for_data_req_done(...
8944 {
8945 ...
8946 while (1) {
8947 wait_event_interruptible(context_info->wait,
8948 (context_info->is_done_rcv ||
8949 context_info->is_new_req));
8950 static void mmc_blk_rw_rq_prep(...
8951 {
8952 ...
8953 memset(brq, 0, sizeof(struct mmc_blk_request));
8954
8955 This issue happens very coincidentally; however adding mdelay(1) in
8956 mmc_wait_data_done as below could duplicate it easily.
8957
8958 static void mmc_wait_data_done(struct mmc_request *mrq)
8959 {
8960 mrq->host->context_info.is_done_rcv = true;
8961 + mdelay(1);
8962 wake_up_interruptible(&mrq->host->context_info.wait);
8963 }
8964
8965 At runtime, IRQ or ICache line missing may just happen at the same place
8966 of the mdelay(1).
8967
8968 This patch gets the mmc_context_info at the beginning of function, it can
8969 avoid this race condition.
8970
8971 Signed-off-by: Jialing Fu <jlfu@marvell.com>
8972 Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
8973 Fixes: 2220eedfd7ae ("mmc: fix async request mechanism ....")
8974 Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
8975 Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
8976 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
8977
8978commit d8ef0bd7baadc1284b09b817ac61e7fe098b1c54
8979Author: Jann Horn <jann@thejh.net>
8980Date: Wed Sep 9 15:38:28 2015 -0700
8981
8982 fs: if a coredump already exists, unlink and recreate with O_EXCL
8983
8984 [ Upstream commit fbb1816942c04429e85dbf4c1a080accc534299e ]
8985
8986 It was possible for an attacking user to trick root (or another user) into
8987 writing his coredumps into an attacker-readable, pre-existing file using
8988 rename() or link(), causing the disclosure of secret data from the victim
8989 process' virtual memory. Depending on the configuration, it was also
8990 possible to trick root into overwriting system files with coredumps. Fix
8991 that issue by never writing coredumps into existing files.
8992
8993 Requirements for the attack:
8994 - The attack only applies if the victim's process has a nonzero
8995 RLIMIT_CORE and is dumpable.
8996 - The attacker can trick the victim into coredumping into an
8997 attacker-writable directory D, either because the core_pattern is
8998 relative and the victim's cwd is attacker-writable or because an
8999 absolute core_pattern pointing to a world-writable directory is used.
9000 - The attacker has one of these:
9001 A: on a system with protected_hardlinks=0:
9002 execute access to a folder containing a victim-owned,
9003 attacker-readable file on the same partition as D, and the
9004 victim-owned file will be deleted before the main part of the attack
9005 takes place. (In practice, there are lots of files that fulfill
9006 this condition, e.g. entries in Debian's /var/lib/dpkg/info/.)
9007 This does not apply to most Linux systems because most distros set
9008 protected_hardlinks=1.
9009 B: on a system with protected_hardlinks=1:
9010 execute access to a folder containing a victim-owned,
9011 attacker-readable and attacker-writable file on the same partition
9012 as D, and the victim-owned file will be deleted before the main part
9013 of the attack takes place.
9014 (This seems to be uncommon.)
9015 C: on any system, independent of protected_hardlinks:
9016 write access to a non-sticky folder containing a victim-owned,
9017 attacker-readable file on the same partition as D
9018 (This seems to be uncommon.)
9019
9020 The basic idea is that the attacker moves the victim-owned file to where
9021 he expects the victim process to dump its core. The victim process dumps
9022 its core into the existing file, and the attacker reads the coredump from
9023 it.
9024
9025 If the attacker can't move the file because he does not have write access
9026 to the containing directory, he can instead link the file to a directory
9027 he controls, then wait for the original link to the file to be deleted
9028 (because the kernel checks that the link count of the corefile is 1).
9029
9030 A less reliable variant that requires D to be non-sticky works with link()
9031 and does not require deletion of the original link: link() the file into
9032 D, but then unlink() it directly before the kernel performs the link count
9033 check.
9034
9035 On systems with protected_hardlinks=0, this variant allows an attacker to
9036 not only gain information from coredumps, but also clobber existing,
9037 victim-writable files with coredumps. (This could theoretically lead to a
9038 privilege escalation.)
9039
9040 Signed-off-by: Jann Horn <jann@thejh.net>
9041 Cc: Kees Cook <keescook@chromium.org>
9042 Cc: Al Viro <viro@zeniv.linux.org.uk>
9043 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
9044 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
9045 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9046
9047commit 19d585ab7bd36fb656008f8148049acde7643c91
9048Author: Jaewon Kim <jaewon31.kim@samsung.com>
9049Date: Tue Sep 8 15:02:21 2015 -0700
9050
9051 vmscan: fix increasing nr_isolated incurred by putback unevictable pages
9052
9053 [ Upstream commit c54839a722a02818677bcabe57e957f0ce4f841d ]
9054
9055 reclaim_clean_pages_from_list() assumes that shrink_page_list() returns
9056 number of pages removed from the candidate list. But shrink_page_list()
9057 puts back mlocked pages without passing it to caller and without
9058 counting as nr_reclaimed. This increases nr_isolated.
9059
9060 To fix this, this patch changes shrink_page_list() to pass unevictable
9061 pages back to caller. Caller will take care those pages.
9062
9063 Minchan said:
9064
9065 It fixes two issues.
9066
9067 1. With unevictable page, cma_alloc will be successful.
9068
9069 Exactly speaking, cma_alloc of current kernel will fail due to
9070 unevictable pages.
9071
9072 2. fix leaking of NR_ISOLATED counter of vmstat
9073
9074 With it, too_many_isolated works. Otherwise, it could make hang until
9075 the process get SIGKILL.
9076
9077 Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
9078 Acked-by: Minchan Kim <minchan@kernel.org>
9079 Cc: Mel Gorman <mgorman@techsingularity.net>
9080 Acked-by: Vlastimil Babka <vbabka@suse.cz>
9081 Cc: <stable@vger.kernel.org>
9082 Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
9083 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
9084 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9085
9086commit ee2cdeabb2b5bff780b1e61af5fc13967573e466
9087Author: Helge Deller <deller@gmx.de>
9088Date: Thu Sep 3 22:45:21 2015 +0200
9089
9090 parisc: Filter out spurious interrupts in PA-RISC irq handler
9091
9092 [ Upstream commit b1b4e435e4ef7de77f07bf2a42c8380b960c2d44 ]
9093
9094 When detecting a serial port on newer PA-RISC machines (with iosapic) we have a
9095 long way to go to find the right IRQ line, registering it, then registering the
9096 serial port and the irq handler for the serial port. During this phase spurious
9097 interrupts for the serial port may happen which then crashes the kernel because
9098 the action handler might not have been set up yet.
9099
9100 So, basically it's a race condition between the serial port hardware and the
9101 CPU which sets up the necessary fields in the irq sructs. The main reason for
9102 this race is, that we unmask the serial port irqs too early without having set
9103 up everything properly before (which isn't easily possible because we need the
9104 IRQ number to register the serial ports).
9105
9106 This patch is a work-around for this problem. It adds checks to the CPU irq
9107 handler to verify if the IRQ action field has been initialized already. If not,
9108 we just skip this interrupt (which isn't critical for a serial port at bootup).
9109 The real fix would probably involve rewriting all PA-RISC specific IRQ code
9110 (for CPU, IOSAPIC, GSC and EISA) to use IRQ domains with proper parenting of
9111 the irq chips and proper irq enabling along this line.
9112
9113 This bug has been in the PA-RISC port since the beginning, but the crashes
9114 happened very rarely with currently used hardware. But on the latest machine
9115 which I bought (a C8000 workstation), which uses the fastest CPUs (4 x PA8900,
9116 1GHz) and which has the largest possible L1 cache size (64MB each), the kernel
9117 crashed at every boot because of this race. So, without this patch the machine
9118 would currently be unuseable.
9119
9120 For the record, here is the flow logic:
9121 1. serial_init_chip() in 8250_gsc.c calls iosapic_serial_irq().
9122 2. iosapic_serial_irq() calls txn_alloc_irq() to find the irq.
9123 3. iosapic_serial_irq() calls cpu_claim_irq() to register the CPU irq
9124 4. cpu_claim_irq() unmasks the CPU irq (which it shouldn't!)
9125 5. serial_init_chip() then registers the 8250 port.
9126 Problems:
9127 - In step 4 the CPU irq shouldn't have been registered yet, but after step 5
9128 - If serial irq happens between 4 and 5 have finished, the kernel will crash
9129
9130 Signed-off-by: Helge Deller <deller@gmx.de>
9131 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9132
9133commit e158509bb2c10c88079043b2acdac71c34b0f666
9134Author: John David Anglin <dave.anglin@bell.net>
9135Date: Mon Sep 7 20:13:28 2015 -0400
9136
9137 parisc: Use double word condition in 64bit CAS operation
9138
9139 [ Upstream commit 1b59ddfcf1678de38a1f8ca9fb8ea5eebeff1843 ]
9140
9141 The attached change fixes the condition used in the "sub" instruction.
9142 A double word comparison is needed. This fixes the 64-bit LWS CAS
9143 operation on 64-bit kernels.
9144
9145 I can now enable 64-bit atomic support in GCC.
9146
9147 Cc: <stable@vger.kernel.org>
9148 Signed-off-by: John David Anglin <dave.anglin>
9149 Signed-off-by: Helge Deller <deller@gmx.de>
9150 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9151
9152commit 5d9b942696a6bcf8f1e498991f5eba35329ab1e6
9153Author: Trond Myklebust <trond.myklebust@primarydata.com>
9154Date: Mon Aug 17 12:57:07 2015 -0500
9155
9156 NFS: nfs_set_pgio_error sometimes misses errors
9157
9158 [ Upstream commit e9ae58aeee8842a50f7e199d602a5ccb2e41a95f ]
9159
9160 We should ensure that we always set the pgio_header's error field
9161 if a READ or WRITE RPC call returns an error. The current code depends
9162 on 'hdr->good_bytes' always being initialised to a large value, which
9163 is not always done correctly by callers.
9164 When this happens, applications may end up missing important errors.
9165
9166 Cc: stable@vger.kernel.org
9167 Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
9168 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9169
9170commit 2e81b26ee568c88b68c7b4e58a71bbdfe83fb338
9171Author: Kinglong Mee <kinglongmee@gmail.com>
9172Date: Sat Aug 15 21:52:10 2015 +0800
9173
9174 NFS: Fix a NULL pointer dereference of migration recovery ops for v4.2 client
9175
9176 [ Upstream commit 18e3b739fdc826481c6a1335ce0c5b19b3d415da ]
9177
9178 ---Steps to Reproduce--
9179 <nfs-server>
9180 # cat /etc/exports
9181 /nfs/referal *(rw,insecure,no_subtree_check,no_root_squash,crossmnt)
9182 /nfs/old *(ro,insecure,subtree_check,root_squash,crossmnt)
9183
9184 <nfs-client>
9185 # mount -t nfs nfs-server:/nfs/ /mnt/
9186 # ll /mnt/*/
9187
9188 <nfs-server>
9189 # cat /etc/exports
9190 /nfs/referal *(rw,insecure,no_subtree_check,no_root_squash,crossmnt,refer=/nfs/old/@nfs-server)
9191 /nfs/old *(ro,insecure,subtree_check,root_squash,crossmnt)
9192 # service nfs restart
9193
9194 <nfs-client>
9195 # ll /mnt/*/ --->>>>> oops here
9196
9197 [ 5123.102925] BUG: unable to handle kernel NULL pointer dereference at (null)
9198 [ 5123.103363] IP: [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
9199 [ 5123.103752] PGD 587b9067 PUD 3cbf5067 PMD 0
9200 [ 5123.104131] Oops: 0000 [#1]
9201 [ 5123.104529] Modules linked in: nfsv4(OE) nfs(OE) fscache(E) nfsd(OE) xfs libcrc32c iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev vmw_balloon parport_pc parport i2c_piix4 shpchp auth_rpcgss nfs_acl vmw_vmci lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi serio_raw scsi_transport_spi e1000 mptscsih mptbase ata_generic pata_acpi [last unloaded: nfsd]
9202 [ 5123.105887] CPU: 0 PID: 15853 Comm: ::1-manager Tainted: G OE 4.2.0-rc6+ #214
9203 [ 5123.106358] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
9204 [ 5123.106860] task: ffff88007620f300 ti: ffff88005877c000 task.ti: ffff88005877c000
9205 [ 5123.107363] RIP: 0010:[<ffffffffa03ed38b>] [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
9206 [ 5123.107909] RSP: 0018:ffff88005877fdb8 EFLAGS: 00010246
9207 [ 5123.108435] RAX: ffff880053f3bc00 RBX: ffff88006ce6c908 RCX: ffff880053a0d240
9208 [ 5123.108968] RDX: ffffea0000e6d940 RSI: ffff8800399a0000 RDI: ffff88006ce6c908
9209 [ 5123.109503] RBP: ffff88005877fe28 R08: ffffffff81c708a0 R09: 0000000000000000
9210 [ 5123.110045] R10: 00000000000001a2 R11: ffff88003ba7f5c8 R12: ffff880054c55800
9211 [ 5123.110618] R13: 0000000000000000 R14: ffff880053a0d240 R15: ffff880053a0d240
9212 [ 5123.111169] FS: 0000000000000000(0000) GS:ffffffff81c27000(0000) knlGS:0000000000000000
9213 [ 5123.111726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
9214 [ 5123.112286] CR2: 0000000000000000 CR3: 0000000054cac000 CR4: 00000000001406f0
9215 [ 5123.112888] Stack:
9216 [ 5123.113458] ffffea0000e6d940 ffff8800399a0000 00000000000167d0 0000000000000000
9217 [ 5123.114049] 0000000000000000 0000000000000000 0000000000000000 00000000a7ec82c6
9218 [ 5123.114662] ffff88005877fe18 ffffea0000e6d940 ffff8800399a0000 ffff880054c55800
9219 [ 5123.115264] Call Trace:
9220 [ 5123.115868] [<ffffffffa03fb44b>] nfs4_try_migration+0xbb/0x220 [nfsv4]
9221 [ 5123.116487] [<ffffffffa03fcb3b>] nfs4_run_state_manager+0x4ab/0x7b0 [nfsv4]
9222 [ 5123.117104] [<ffffffffa03fc690>] ? nfs4_do_reclaim+0x510/0x510 [nfsv4]
9223 [ 5123.117813] [<ffffffff810a4527>] kthread+0xd7/0xf0
9224 [ 5123.118456] [<ffffffff810a4450>] ? kthread_worker_fn+0x160/0x160
9225 [ 5123.119108] [<ffffffff816d9cdf>] ret_from_fork+0x3f/0x70
9226 [ 5123.119723] [<ffffffff810a4450>] ? kthread_worker_fn+0x160/0x160
9227 [ 5123.120329] Code: 4c 8b 6a 58 74 17 eb 52 48 8d 55 a8 89 c6 4c 89 e7 e8 4a b5 ff ff 8b 45 b0 85 c0 74 1c 4c 89 f9 48 8b 55 90 48 8b 75 98 48 89 df <41> ff 55 00 3d e8 d8 ff ff 41 89 c6 74 cf 48 8b 4d c8 65 48 33
9228 [ 5123.121643] RIP [<ffffffffa03ed38b>] nfs4_proc_get_locations+0x9b/0x120 [nfsv4]
9229 [ 5123.122308] RSP <ffff88005877fdb8>
9230 [ 5123.122942] CR2: 0000000000000000
9231
9232 Fixes: ec011fe847 ("NFS: Introduce a vector of migration recovery ops")
9233 Cc: stable@vger.kernel.org # v3.13+
9234 Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
9235 Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
9236 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9237
9238commit 9c4acd614315606108151ba7f2b13987368ea13c
9239Author: NeilBrown <neilb@suse.com>
9240Date: Thu Jul 30 13:00:56 2015 +1000
9241
9242 NFSv4: don't set SETATTR for O_RDONLY|O_EXCL
9243
9244 [ Upstream commit efcbc04e16dfa95fef76309f89710dd1d99a5453 ]
9245
9246 It is unusual to combine the open flags O_RDONLY and O_EXCL, but
9247 it appears that libre-office does just that.
9248
9249 [pid 3250] stat("/home/USER/.config", {st_mode=S_IFDIR|0700, st_size=8192, ...}) = 0
9250 [pid 3250] open("/home/USER/.config/libreoffice/4-suse/user/extensions/buildid", O_RDONLY|O_EXCL <unfinished ...>
9251
9252 NFSv4 takes O_EXCL as a sign that a setattr command should be sent,
9253 probably to reset the timestamps.
9254
9255 When it was an O_RDONLY open, the SETATTR command does not
9256 identify any actual attributes to change.
9257 If no delegation was provided to the open, the SETATTR uses the
9258 all-zeros stateid and the request is accepted (at least by the
9259 Linux NFS server - no harm, no foul).
9260
9261 If a read-delegation was provided, this is used in the SETATTR
9262 request, and a Netapp filer will justifiably claim
9263 NFS4ERR_BAD_STATEID, which the Linux client takes as a sign
9264 to retry - indefinitely.
9265
9266 So only treat O_EXCL specially if O_CREAT was also given.
9267
9268 Signed-off-by: NeilBrown <neilb@suse.com>
9269 Cc: stable@vger.kernel.org
9270 Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
9271 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9272
9273commit fe3882a4751d2b4fd004b4ce6f0e3ddebd093b52
9274Author: Filipe Manana <fdmanana@suse.com>
9275Date: Wed Aug 12 11:54:35 2015 +0100
9276
9277 Btrfs: check if previous transaction aborted to avoid fs corruption
9278
9279 [ Upstream commit 1f9b8c8fbc9a4d029760b16f477b9d15500e3a34 ]
9280
9281 While we are committing a transaction, it's possible the previous one is
9282 still finishing its commit and therefore we wait for it to finish first.
9283 However we were not checking if that previous transaction ended up getting
9284 aborted after we waited for it to commit, so we ended up committing the
9285 current transaction which can lead to fs corruption because the new
9286 superblock can point to trees that have had one or more nodes/leafs that
9287 were never durably persisted.
9288 The following sequence diagram exemplifies how this is possible:
9289
9290 CPU 0 CPU 1
9291
9292 transaction N starts
9293
9294 (...)
9295
9296 btrfs_commit_transaction(N)
9297
9298 cur_trans->state = TRANS_STATE_COMMIT_START;
9299 (...)
9300 cur_trans->state = TRANS_STATE_COMMIT_DOING;
9301 (...)
9302
9303 cur_trans->state = TRANS_STATE_UNBLOCKED;
9304 root->fs_info->running_transaction = NULL;
9305
9306 btrfs_start_transaction()
9307 --> starts transaction N + 1
9308
9309 btrfs_write_and_wait_transaction(trans, root);
9310 --> starts writing all new or COWed ebs created
9311 at transaction N
9312
9313 creates some new ebs, COWs some
9314 existing ebs but doesn't COW or
9315 deletes eb X
9316
9317 btrfs_commit_transaction(N + 1)
9318 (...)
9319 cur_trans->state = TRANS_STATE_COMMIT_START;
9320 (...)
9321 wait_for_commit(root, prev_trans);
9322 --> prev_trans == transaction N
9323
9324 btrfs_write_and_wait_transaction() continues
9325 writing ebs
9326 --> fails writing eb X, we abort transaction N
9327 and set bit BTRFS_FS_STATE_ERROR on
9328 fs_info->fs_state, so no new transactions
9329 can start after setting that bit
9330
9331 cleanup_transaction()
9332 btrfs_cleanup_one_transaction()
9333 wakes up task at CPU 1
9334
9335 continues, doesn't abort because
9336 cur_trans->aborted (transaction N + 1)
9337 is zero, and no checks for bit
9338 BTRFS_FS_STATE_ERROR in fs_info->fs_state
9339 are made
9340
9341 btrfs_write_and_wait_transaction(trans, root);
9342 --> succeeds, no errors during writeback
9343
9344 write_ctree_super(trans, root, 0);
9345 --> succeeds
9346 --> we have now a superblock that points us
9347 to some root that uses eb X, which was
9348 never written to disk
9349
9350 In this scenario future attempts to read eb X from disk results in an
9351 error message like "parent transid verify failed on X wanted Y found Z".
9352
9353 So fix this by aborting the current transaction if after waiting for the
9354 previous transaction we verify that it was aborted.
9355
9356 Cc: stable@vger.kernel.org
9357 Signed-off-by: Filipe Manana <fdmanana@suse.com>
9358 Reviewed-by: Josef Bacik <jbacik@fb.com>
9359 Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
9360 Signed-off-by: Chris Mason <clm@fb.com>
9361 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9362
9363commit e5ce14705d3199531b646c9e03724eaec77c6471
9364Author: Sakari Ailus <sakari.ailus@iki.fi>
9365Date: Fri Jun 12 20:06:23 2015 -0300
9366
9367 [media] v4l: omap3isp: Fix sub-device power management code
9368
9369 [ Upstream commit 9d39f05490115bf145e5ea03c0b7ec9d3d015b01 ]
9370
9371 Commit 813f5c0ac5cc ("media: Change media device link_notify behaviour")
9372 modified the media controller link setup notification API and updated the
9373 OMAP3 ISP driver accordingly. As a side effect it introduced a bug by
9374 turning power on after setting the link instead of before. This results in
9375 sub-devices not being powered down in some cases when they should be. Fix
9376 it.
9377
9378 Fixes: 813f5c0ac5cc [media] media: Change media device link_notify behaviour
9379
9380 Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
9381 Cc: stable@vger.kernel.org # since v3.10
9382 Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
9383 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
9384 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9385
9386commit 51d0384968780c9532bb63f9842e82c336fa7ab8
9387Author: David Härdeman <david@hardeman.nu>
9388Date: Tue May 19 19:03:12 2015 -0300
9389
9390 [media] rc-core: fix remove uevent generation
9391
9392 [ Upstream commit a66b0c41ad277ae62a3ae6ac430a71882f899557 ]
9393
9394 The input_dev is already gone when the rc device is being unregistered
9395 so checking for its presence only means that no remove uevent will be
9396 generated.
9397
9398 Cc: stable@kernel.org
9399 Signed-off-by: David Härdeman <david@hardeman.nu>
9400 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
9401 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9402
9403commit 8da2e87b95215ef4acd944ed1d552d5082ba98f8
9404Author: Minfei Huang <mnfhuang@gmail.com>
9405Date: Sun Jul 12 20:18:42 2015 +0800
9406
9407 x86/mm: Initialize pmd_idx in page_table_range_init_count()
9408
9409 [ Upstream commit 9962eea9e55f797f05f20ba6448929cab2a9f018 ]
9410
9411 The variable pmd_idx is not initialized for the first iteration of the
9412 for loop.
9413
9414 Assign the proper value which indexes the start address.
9415
9416 Fixes: 719272c45b82 'x86, mm: only call early_ioremap_page_table_range_init() once'
9417 Signed-off-by: Minfei Huang <mnfhuang@gmail.com>
9418 Cc: tony.luck@intel.com
9419 Cc: wangnan0@huawei.com
9420 Cc: david.vrabel@citrix.com
9421 Reviewed-by: yinghai@kernel.org
9422 Link: http://lkml.kernel.org/r/1436703522-29552-1-git-send-email-mhuang@redhat.com
9423 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
9424 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9425
9426commit 3cc3b3025f6259e23bfe2e1b95c4173001144cba
9427Author: Jeffery Miller <jmiller@neverware.com>
9428Date: Tue Sep 1 11:23:02 2015 -0400
9429
9430 Add radeon suspend/resume quirk for HP Compaq dc5750.
9431
9432 [ Upstream commit 09bfda10e6efd7b65bcc29237bee1765ed779657 ]
9433
9434 With the radeon driver loaded the HP Compaq dc5750
9435 Small Form Factor machine fails to resume from suspend.
9436 Adding a quirk similar to other devices avoids
9437 the problem and the system resumes properly.
9438
9439 Signed-off-by: Jeffery Miller <jmiller@neverware.com>
9440 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
9441 Cc: stable@vger.kernel.org
9442 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9443
9444commit 01104f30a6751e2b04cfc43a4b745a249d3ad04e
9445Author: Jann Horn <jann@thejh.net>
9446Date: Fri Sep 11 16:27:27 2015 +0200
9447
9448 CIFS: fix type confusion in copy offload ioctl
9449
9450 [ Upstream commit 4c17a6d56bb0cad3066a714e94f7185a24b40f49 ]
9451
9452 This might lead to local privilege escalation (code execution as
9453 kernel) for systems where the following conditions are met:
9454
9455 - CONFIG_CIFS_SMB2 and CONFIG_CIFS_POSIX are enabled
9456 - a cifs filesystem is mounted where:
9457 - the mount option "vers" was used and set to a value >=2.0
9458 - the attacker has write access to at least one file on the filesystem
9459
9460 To attack this, an attacker would have to guess the target_tcon
9461 pointer (but guessing wrong doesn't cause a crash, it just returns an
9462 error code) and win a narrow race.
9463
9464 CC: Stable <stable@vger.kernel.org>
9465 Signed-off-by: Jann Horn <jann@thejh.net>
9466 Signed-off-by: Steve French <smfrench@gmail.com>
9467 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9468
9469commit 435facb28b835f014b6a21ff887442d0e03cef03
9470Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
9471Date: Tue Sep 15 12:30:08 2015 +0530
9472
9473 powerpc/mm: Recompute hash value after a failed update
9474
9475 [ Upstream commit 36b35d5d807b7e57aff7d08e63de8b17731ee211 ]
9476
9477 If we had secondary hash flag set, we ended up modifying hash value in
9478 the updatepp code path. Hence with a failed updatepp we will be using
9479 a wrong hash value for the following hash insert. Fix this by
9480 recomputing hash before insert.
9481
9482 Without this patch we can end up with using wrong slot number in linux
9483 pte. That can result in us missing an hash pte update or invalidate
9484 which can cause memory corruption or even machine check.
9485
9486 Fixes: 6d492ecc6489 ("powerpc/THP: Add code to handle HPTE faults for hugepages")
9487 Cc: stable@vger.kernel.org # v3.11+
9488 Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
9489 Reviewed-by: Paul Mackerras <paulus@samba.org>
9490 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
9491 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9492
9493commit 3d108c1cfc2af67d14cb280fb118eee327fbb347
9494Author: Thomas Huth <thuth@redhat.com>
9495Date: Fri Jul 17 12:46:58 2015 +0200
9496
9497 powerpc/rtas: Introduce rtas_get_sensor_fast() for IRQ handlers
9498
9499 [ Upstream commit 1c2cb594441d02815d304cccec9742ff5c707495 ]
9500
9501 The EPOW interrupt handler uses rtas_get_sensor(), which in turn
9502 uses rtas_busy_delay() to wait for RTAS becoming ready in case it
9503 is necessary. But rtas_busy_delay() is annotated with might_sleep()
9504 and thus may not be used by interrupts handlers like the EPOW handler!
9505 This leads to the following BUG when CONFIG_DEBUG_ATOMIC_SLEEP is
9506 enabled:
9507
9508 BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:496
9509 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
9510 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.2.0-rc2-thuth #6
9511 Call Trace:
9512 [c00000007ffe7b90] [c000000000807670] dump_stack+0xa0/0xdc (unreliable)
9513 [c00000007ffe7bc0] [c0000000000e1f14] ___might_sleep+0x134/0x180
9514 [c00000007ffe7c20] [c00000000002aec0] rtas_busy_delay+0x30/0xd0
9515 [c00000007ffe7c50] [c00000000002bde4] rtas_get_sensor+0x74/0xe0
9516 [c00000007ffe7ce0] [c000000000083264] ras_epow_interrupt+0x44/0x450
9517 [c00000007ffe7d90] [c000000000120260] handle_irq_event_percpu+0xa0/0x300
9518 [c00000007ffe7e70] [c000000000120524] handle_irq_event+0x64/0xc0
9519 [c00000007ffe7eb0] [c000000000124dbc] handle_fasteoi_irq+0xec/0x260
9520 [c00000007ffe7ef0] [c00000000011f4f0] generic_handle_irq+0x50/0x80
9521 [c00000007ffe7f20] [c000000000010f3c] __do_irq+0x8c/0x200
9522 [c00000007ffe7f90] [c0000000000236cc] call_do_irq+0x14/0x24
9523 [c00000007e6f39e0] [c000000000011144] do_IRQ+0x94/0x110
9524 [c00000007e6f3a30] [c000000000002594] hardware_interrupt_common+0x114/0x180
9525
9526 Fix this issue by introducing a new rtas_get_sensor_fast() function
9527 that does not use rtas_busy_delay() - and thus can only be used for
9528 sensors that do not cause a BUSY condition - known as "fast" sensors.
9529
9530 The EPOW sensor is defined to be "fast" in sPAPR - mpe.
9531
9532 Fixes: 587f83e8dd50 ("powerpc/pseries: Use rtas_get_sensor in RAS code")
9533 Signed-off-by: Thomas Huth <thuth@redhat.com>
9534 Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
9535 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
9536 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9537
9538commit fb508c16d90ab7964fdbb38374954343159e1435
9539Author: Michael Ellerman <mpe@ellerman.id.au>
9540Date: Fri Aug 7 16:19:43 2015 +1000
9541
9542 powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash
9543
9544 [ Upstream commit 74b5037baa2011a2799e2c43adde7d171b072f9e ]
9545
9546 The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
9547 PAGE_SIZE.
9548
9549 However when built with a 4K PAGE_SIZE there is an additional config
9550 option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
9551 also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.
9552
9553 This is used in one obscure configuration, to support 64K pages for SPU
9554 local store on the Cell processor when the rest of the kernel is using
9555 4K pages.
9556
9557 In this configuration, pte_pagesize_index() is defined to just pass
9558 through its arguments to get_slice_psize(). However pte_pagesize_index()
9559 is called for both user and kernel addresses, whereas get_slice_psize()
9560 only knows how to handle user addresses.
9561
9562 This has been broken forever, however until recently it happened to
9563 work. That was because in get_slice_psize() the large kernel address
9564 would cause the right shift of the slice mask to return zero.
9565
9566 However in commit 7aa0727f3302 ("powerpc/mm: Increase the slice range to
9567 64TB"), the get_slice_psize() code was changed so that instead of a
9568 right shift we do an array lookup based on the address. When passed a
9569 kernel address this means we index way off the end of the slice array
9570 and return random junk.
9571
9572 That is only fatal if we happen to hit something non-zero, but when we
9573 do return a non-zero value we confuse the MMU code and eventually cause
9574 a check stop.
9575
9576 This fix is ugly, but simple. When we're called for a kernel address we
9577 return 4K, which is always correct in this configuration, otherwise we
9578 use the slice mask.
9579
9580 Fixes: 7aa0727f3302 ("powerpc/mm: Increase the slice range to 64TB")
9581 Reported-by: Cyril Bur <cyrilbur@gmail.com>
9582 Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
9583 Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
9584 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9585
9586commit 9d2debc73c13911b0969e34b0a2b4ca0c0d249d3
9587Author: Takashi Iwai <tiwai@suse.de>
9588Date: Thu Aug 13 18:05:06 2015 +0200
9589
9590 ALSA: hda - Use ALC880_FIXUP_FUJITSU for FSC Amilo M1437
9591
9592 [ Upstream commit a161574e200ae63a5042120e0d8c36830e81bde3 ]
9593
9594 It turned out that the machine has a bass speaker, so take a correct
9595 fixup entry.
9596
9597 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102501
9598 Cc: <stable@vger.kernel.org>
9599 Signed-off-by: Takashi Iwai <tiwai@suse.de>
9600 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9601
9602commit 60300afece1ee742fd4514654d87bd82441821e3
9603Author: Takashi Iwai <tiwai@suse.de>
9604Date: Thu Aug 13 18:02:39 2015 +0200
9605
9606 ALSA: hda - Enable headphone jack detect on old Fujitsu laptops
9607
9608 [ Upstream commit bb148bdeb0ab16fc0ae8009799471e4d7180073b ]
9609
9610 According to the bug report, FSC Amilo laptops with ALC880 can detect
9611 the headphone jack but currently the driver disables it. It's partly
9612 intentionally, as non-working jack detect was reported in the past.
9613 Let's enable now.
9614
9615 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=102501
9616 Cc: <stable@vger.kernel.org>
9617 Signed-off-by: Takashi Iwai <tiwai@suse.de>
9618 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9619
9620commit ae78a159fed6e17c22dfeb1c6c18ce442d2f8d89
9621Author: Takashi Iwai <tiwai@suse.de>
9622Date: Thu Sep 3 22:20:00 2015 -0700
9623
9624 Input: evdev - do not report errors form flush()
9625
9626 [ Upstream commit eb38f3a4f6e86f8bb10a3217ebd85ecc5d763aae ]
9627
9628 We've got bug reports showing the old systemd-logind (at least
9629 system-210) aborting unexpectedly, and this turned out to be because
9630 of an invalid error code from close() call to evdev devices. close()
9631 is supposed to return only either EINTR or EBADFD, while the device
9632 returned ENODEV. logind was overreacting to it and decided to kill
9633 itself when an unexpected error code was received. What a tragedy.
9634
9635 The bad error code comes from flush fops, and actually evdev_flush()
9636 returns ENODEV when device is disconnected or client's access to it is
9637 revoked. But in these cases the fact that flush did not actually happen is
9638 not an error, but rather normal behavior. For non-disconnected devices
9639 result of flush is also not that interesting as there is no potential of
9640 data loss and even if it fails application has no way of handling the
9641 error. Because of that we are better off always returning success from
9642 evdev_flush().
9643
9644 Also returning EINTR from flush()/close() is discouraged (as it is not
9645 clear how application should handle this error), so let's stop taking
9646 evdev->mutex interruptibly.
9647
9648 Bugzilla: http://bugzilla.suse.com/show_bug.cgi?id=939834
9649 Cc: <stable@vger.kernel.org>
9650 Signed-off-by: Takashi Iwai <tiwai@suse.de>
9651 Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
9652 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9653
9654commit 5fc83fad2a50c76695d7e56b48a1849b815229ae
9655Author: Marc Zyngier <marc.zyngier@arm.com>
9656Date: Wed Sep 16 16:18:59 2015 +0100
9657
9658 arm64: KVM: Disable virtual timer even if the guest is not using it
9659
9660 [ Upstream commit c4cbba9fa078f55d9f6d081dbb4aec7cf969e7c7 ]
9661
9662 When running a guest with the architected timer disabled (with QEMU and
9663 the kernel_irqchip=off option, for example), it is important to make
9664 sure the timer gets turned off. Otherwise, the guest may try to
9665 enable it anyway, leading to a screaming HW interrupt.
9666
9667 The fix is to unconditionally turn off the virtual timer on guest
9668 exit.
9669
9670 Cc: stable@vger.kernel.org
9671 Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
9672 Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
9673 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9674
9675commit 87b71fa85761e22cfb4ba62b6f54bbc57863a37d
9676Author: Will Deacon <will.deacon@arm.com>
9677Date: Tue Mar 17 12:15:02 2015 +0000
9678
9679 arm64: errata: add module build workaround for erratum #843419
9680
9681 [ Upstream commit df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00 ]
9682
9683 Cortex-A53 processors <= r0p4 are affected by erratum #843419 which can
9684 lead to a memory access using an incorrect address in certain sequences
9685 headed by an ADRP instruction.
9686
9687 There is a linker fix to generate veneers for ADRP instructions, but
9688 this doesn't work for kernel modules which are built as unlinked ELF
9689 objects.
9690
9691 This patch adds a new config option for the erratum which, when enabled,
9692 builds kernel modules with the mcmodel=large flag. This uses absolute
9693 addressing for all kernel symbols, thereby removing the use of ADRP as
9694 a PC-relative form of addressing. The ADRP relocs are removed from the
9695 module loader so that we fail to load any potentially affected modules.
9696
9697 Cc: <stable@vger.kernel.org>
9698 Acked-by: Catalin Marinas <catalin.marinas@arm.com>
9699 Signed-off-by: Will Deacon <will.deacon@arm.com>
9700 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9701
9702commit 0d4e0280e189269c26454584a83c2ab9a10a2c06
9703Author: Will Deacon <will.deacon@arm.com>
9704Date: Wed Sep 2 18:49:28 2015 +0100
9705
9706 arm64: head.S: initialise mdcr_el2 in el2_setup
9707
9708 [ Upstream commit d10bcd473301888f957ec4b6b12aa3621be78d59 ]
9709
9710 When entering the kernel at EL2, we fail to initialise the MDCR_EL2
9711 register which controls debug access and PMU capabilities at EL1.
9712
9713 This patch ensures that the register is initialised so that all traps
9714 are disabled and all the PMU counters are available to the host. When a
9715 guest is scheduled, KVM takes care to configure trapping appropriately.
9716
9717 Cc: <stable@vger.kernel.org>
9718 Acked-by: Marc Zyngier <marc.zyngier@arm.com>
9719 Signed-off-by: Will Deacon <will.deacon@arm.com>
9720 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9721
9722commit 38dc08cef862db3e36ca9834d64864c15a25b1dc
9723Author: Will Deacon <will.deacon@arm.com>
9724Date: Tue Sep 15 12:07:06 2015 +0100
9725
9726 arm64: compat: fix vfp save/restore across signal handlers in big-endian
9727
9728 [ Upstream commit bdec97a855ef1e239f130f7a11584721c9a1bf04 ]
9729
9730 When saving/restoring the VFP registers from a compat (AArch32)
9731 signal frame, we rely on the compat registers forming a prefix of the
9732 native register file and therefore make use of copy_{to,from}_user to
9733 transfer between the native fpsimd_state and the compat_vfp_sigframe.
9734
9735 Unfortunately, this doesn't work so well in a big-endian environment.
9736 Our fpsimd save/restore code operates directly on 128-bit quantities
9737 (Q registers) whereas the compat_vfp_sigframe represents the registers
9738 as an array of 64-bit (D) registers. The architecture packs the compat D
9739 registers into the Q registers, with the least significant bytes holding
9740 the lower register. Consequently, we need to swap the 64-bit halves when
9741 converting between these two representations on a big-endian machine.
9742
9743 This patch replaces the __copy_{to,from}_user invocations in our
9744 compat VFP signal handling code with explicit __put_user loops that
9745 operate on 64-bit values and swap them accordingly.
9746
9747 Cc: <stable@vger.kernel.org>
9748 Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
9749 Signed-off-by: Will Deacon <will.deacon@arm.com>
9750 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9751
9752commit 6faa56d421e277f8d08ab02de615b9080c629837
9753Author: Jeff Vander Stoep <jeffv@google.com>
9754Date: Tue Aug 18 20:50:10 2015 +0100
9755
9756 arm64: kconfig: Move LIST_POISON to a safe value
9757
9758 [ Upstream commit bf0c4e04732479f650ff59d1ee82de761c0071f0 ]
9759
9760 Move the poison pointer offset to 0xdead000000000000, a
9761 recognized value that is not mappable by user-space exploits.
9762
9763 Cc: <stable@vger.kernel.org>
9764 Acked-by: Catalin Marinas <catalin.marinas@arm.com>
9765 Signed-off-by: Thierry Strudel <tstrudel@google.com>
9766 Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
9767 Signed-off-by: Will Deacon <will.deacon@arm.com>
9768 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9769
9770commit dabbb4936dc232bffb5467c3aaf9d2ced053aa55
9771Author: Bob Copeland <me@bobcopeland.com>
9772Date: Sat Jun 13 10:16:31 2015 -0400
9773
9774 mac80211: enable assoc check for mesh interfaces
9775
9776 [ Upstream commit 3633ebebab2bbe88124388b7620442315c968e8f ]
9777
9778 We already set a station to be associated when peering completes, both
9779 in user space and in the kernel. Thus we should always have an
9780 associated sta before sending data frames to that station.
9781
9782 Failure to check assoc state can cause crashes in the lower-level driver
9783 due to transmitting unicast data frames before driver sta structures
9784 (e.g. ampdu state in ath9k) are initialized. This occurred when
9785 forwarding in the presence of fixed mesh paths: frames were transmitted
9786 to stations with whom we hadn't yet completed peering.
9787
9788 Cc: stable@vger.kernel.org
9789 Reported-by: Alexis Green <agreen@cococorp.com>
9790 Tested-by: Jesse Jones <jjones@cococorp.com>
9791 Signed-off-by: Bob Copeland <me@bobcopeland.com>
9792 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
9793 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9794
9795commit f37667746772aaf74372a661ac9be0e2f8bbf87a
9796Author: Jean Delvare <jdelvare@suse.de>
9797Date: Tue Sep 1 18:07:41 2015 +0200
9798
9799 tg3: Fix temperature reporting
9800
9801 [ Upstream commit d3d11fe08ccc9bff174fc958722b5661f0932486 ]
9802
9803 The temperature registers appear to report values in degrees Celsius
9804 while the hwmon API mandates values to be exposed in millidegrees
9805 Celsius. Do the conversion so that the values reported by "sensors"
9806 are correct.
9807
9808 Fixes: aed93e0bf493 ("tg3: Add hwmon support for temperature")
9809 Signed-off-by: Jean Delvare <jdelvare@suse.de>
9810 Cc: Prashant Sreedharan <prashant@broadcom.com>
9811 Cc: Michael Chan <mchan@broadcom.com>
9812 Cc: stable@vger.kernel.org [v3.6+]
9813 Signed-off-by: David S. Miller <davem@davemloft.net>
9814 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9815
9816commit 125f124f47bdc80702e69e1b912989bad1398a84
9817Author: Eric W. Biederman <ebiederm@xmission.com>
9818Date: Mon Aug 10 17:35:07 2015 -0500
9819
9820 unshare: Unsharing a thread does not require unsharing a vm
9821
9822 [ Upstream commit 12c641ab8270f787dfcce08b5f20ce8b65008096 ]
9823
9824 In the logic in the initial commit of unshare made creating a new
9825 thread group for a process, contingent upon creating a new memory
9826 address space for that process. That is wrong. Two separate
9827 processes in different thread groups can share a memory address space
9828 and clone allows creation of such proceses.
9829
9830 This is significant because it was observed that mm_users > 1 does not
9831 mean that a process is multi-threaded, as reading /proc/PID/maps
9832 temporarily increments mm_users, which allows other processes to
9833 (accidentally) interfere with unshare() calls.
9834
9835 Correct the check in check_unshare_flags() to test for
9836 !thread_group_empty() for CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM.
9837 For sighand->count > 1 for CLONE_SIGHAND and CLONE_VM.
9838 For !current_is_single_threaded instead of mm_users > 1 for CLONE_VM.
9839
9840 By using the correct checks in unshare this removes the possibility of
9841 an accidental denial of service attack.
9842
9843 Additionally using the correct checks in unshare ensures that only an
9844 explicit unshare(CLONE_VM) can possibly trigger the slow path of
9845 current_is_single_threaded(). As an explict unshare(CLONE_VM) is
9846 pointless it is not expected there are many applications that make
9847 that call.
9848
9849 Cc: stable@vger.kernel.org
9850 Fixes: b2e0d98705e60e45bbb3c0032c48824ad7ae0704 userns: Implement unshare of the user namespace
9851 Reported-by: Ricky Zhou <rickyz@chromium.org>
9852 Reported-by: Kees Cook <keescook@chromium.org>
9853 Reviewed-by: Kees Cook <keescook@chromium.org>
9854 Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
9855 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9856
9857commit 14982eddaefdb75c39bb5b1d3459ef21daea33ed
9858Author: Ming Lei <ming.lei@canonical.com>
9859Date: Sun Aug 9 03:41:50 2015 -0400
9860
9861 blk-mq: fix buffer overflow when reading sysfs file of 'pending'
9862
9863 [ Upstream commit 596f5aad2a704b72934e5abec1b1b4114c16f45b ]
9864
9865 There may be lots of pending requests so that the buffer of PAGE_SIZE
9866 can't hold them at all.
9867
9868 One typical example is scsi-mq, the queue depth(.can_queue) of
9869 scsi_host and blk-mq is quite big but scsi_device's queue_depth
9870 is a bit small(.cmd_per_lun), then it is quite easy to have lots
9871 of pending requests in hw queue.
9872
9873 This patch fixes the following warning and the related memory
9874 destruction.
9875
9876 [ 359.025101] fill_read_buffer: blk_mq_hw_sysfs_show+0x0/0x7d returned bad count^M
9877 [ 359.055595] irq event stamp: 15537^M
9878 [ 359.055606] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
9879 [ 359.055614] Dumping ftrace buffer:^M
9880 [ 359.055660] (ftrace buffer empty)^M
9881 [ 359.055672] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
9882 [ 359.055678] CPU: 4 PID: 21631 Comm: stress-ng-sysfs Not tainted 4.2.0-rc5-next-20150805 #434^M
9883 [ 359.055679] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011^M
9884 [ 359.055682] task: ffff8802161cc000 ti: ffff88021b4a8000 task.ti: ffff88021b4a8000^M
9885 [ 359.055693] RIP: 0010:[<ffffffff811541c5>] [<ffffffff811541c5>] __kmalloc+0xe8/0x152^M
9886
9887 Cc: <stable@vger.kernel.org>
9888 Signed-off-by: Ming Lei <ming.lei@canonical.com>
9889 Signed-off-by: Jens Axboe <axboe@fb.com>
9890 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
9891
9892commit 3c3b6c4338a98d671015c8cc895ef3319c342af5 (tag: 2.9.0_20180918-1544)
9893Author: Jenkins <jenkins@bqbot.bq.local>
9894Date: Wed Oct 17 14:28:58 2018 +0200
9895
9896 Version 2.9.0_20180918-1544 released
9897
9898commit 824af7f4a1fe77948c5e2e9ad297cd006dfc1ee1 (tag: 2.8.0_20180514-1614)
9899Author: Jenkins <jenkins@bqbot.bq.local>
9900Date: Tue May 29 14:05:49 2018 +0200
9901
9902 Version 2.8.0_20180514-1614 released
9903
9904commit da78d0f22f3a31008788071f0b0c7dc69893aa7f (tag: 2.7.0_20180301-0952)
9905Author: Jenkins <jenkins@bqbot.bq.local>
9906Date: Mon Mar 19 12:49:18 2018 +0100
9907
9908 Version 2.7.0_20180301-0952 released
9909
9910commit cae1942ba4d6ba74c3cfd9a9e8e6ebddddb0d542 (tag: 2.6.2_20180126-1035, tag: 2.6.0_20171221-1051)
9911Author: Jenkins <jenkins@bqbot.bq.local>
9912Date: Fri Dec 29 13:14:00 2017 +0100
9913
9914 Version 2.6.0_20171221-1051 released
9915
9916commit eba0fa2f0459fca1207334a8f0e532595bcef53c (tag: 2.5.0_20170911-1032)
9917Author: Jenkins <jenkins@bqbot.bq.local>
9918Date: Mon Sep 25 12:07:59 2017 +0200
9919
9920 Version 2.5.0_20170911-1032 released
9921
9922commit cfd722448994d16140d1ac6289de749f1b6f9c8a (tag: 2.4.0_20170619-0900)
9923Author: Jenkins <jenkins@bqbot.bq.local>
9924Date: Mon Jun 26 15:06:50 2017 +0200
9925
9926 Version 2.4.0_20170619-0900 released
9927
9928commit d53a412245c9ed05f0440270fc83b1db6d250b3b (tag: 2.3.0_20170405-1554)
9929Author: Jenkins <jenkins@bqbot.bq.local>
9930Date: Mon Apr 24 11:01:59 2017 +0200
9931
9932 Version 2.3.0_20170405-1554 released
9933
9934commit 1ebb8de13024abc8a424d8417f75c34daadeaa39 (tag: 2.1.1_20161020-1222)
9935Author: Jenkins <jenkins@bqbot.bq.local>
9936Date: Mon Oct 31 11:41:10 2016 +0100
9937
9938 Version 2.1.1_20161020-1222 released
9939
9940commit 49283b7994e37386c4cfbceaf9927391abfb541b (tag: 2.1.0_20160907-1500)
9941Author: Jenkins <jenkins@bqbot.bq.local>
9942Date: Mon Oct 31 11:37:24 2016 +0100
9943
9944 Version 2.1.0_20160907-1500 released
9945
9946commit ef70771e85978d94062f4d8f48038d3b4a1faec6 (tag: 2.0.0_20160817-1110)
9947Author: Jenkins <jenkins@bqbot.bq.local>
9948Date: Wed Oct 26 16:28:01 2016 +0200
9949
9950 Version 2.0.0_20160817-1110 released