27 Feb, 2015
21 commits
-
commit a8f29e89f2b54fbf2c52be341f149bc195b63a8b upstream.
Userspace expects to see a long space before the first pulse is sent on
the lirc device. Currently, if a long time has passed and a new packet
is started, the lirc codec just returns and doesn't send anything. This
makes lircd ignore many perfectly valid signals unless they are sent in
quick sucession. When a reset event is delivered, we cannot know
anything about the duration of the space. But it should be safe to
assume it has been a long time and we just set the duration to maximum.Signed-off-by: Austin Lund
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 2d5b86e048780c5efa7f7d9708815555919e7b05 upstream.
As of v3.18, ext4 started rejecting a remount which changes the
journal_checksum option.Prior to that, it was simply ignored; the problem here is that
if someone has this in their fstab for the root fs, now the box
fails to boot properly, because remount of root with the new options
will fail, and the box proceeds with a readonly root.I think it is a little nicer behavior to accept the option, but
warn that it's being ignored, rather than failing the mount,
but that might be a subjective matter...Reported-by: Cónräd
Signed-off-by: Eric Sandeen
Signed-off-by: Theodore Ts'o
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 0d32ef8cef9aa8f375e128f78b77caceaa7e8da0 ]
Doing the following commands on a non idle network device
panics the box instantly, because cpu_bstats gets overwritten
by stats.tc qdisc add dev eth0 root
... some traffic (one packet is enough) ...
tc qdisc replace dev eth0 root est 1sec 4sec[ 325.355596] BUG: unable to handle kernel paging request at ffff8841dc5a074c
[ 325.362609] IP: [] __gnet_stats_copy_basic+0x3e/0x90
[ 325.369158] PGD 1fa7067 PUD 0
[ 325.372254] Oops: 0000 [#1] SMP
[ 325.375514] Modules linked in: ...
[ 325.398346] CPU: 13 PID: 14313 Comm: tc Not tainted 3.19.0-smp-DEV #1163
[ 325.412042] task: ffff8800793ab5d0 ti: ffff881ff2fa4000 task.ti: ffff881ff2fa4000
[ 325.419518] RIP: 0010:[] [] __gnet_stats_copy_basic+0x3e/0x90
[ 325.428506] RSP: 0018:ffff881ff2fa7928 EFLAGS: 00010286
[ 325.433824] RAX: 000000000000000c RBX: ffff881ff2fa796c RCX: 000000000000000c
[ 325.440988] RDX: ffff8841dc5a0744 RSI: 0000000000000060 RDI: 0000000000000060
[ 325.448120] RBP: ffff881ff2fa7948 R08: ffffffff81cd4f80 R09: 0000000000000000
[ 325.455268] R10: ffff883ff223e400 R11: 0000000000000000 R12: 000000015cba0744
[ 325.462405] R13: ffffffff81cd4f80 R14: ffff883ff223e460 R15: ffff883feea0722c
[ 325.469536] FS: 00007f2ee30fa700(0000) GS:ffff88407fa20000(0000) knlGS:0000000000000000
[ 325.477630] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 325.483380] CR2: ffff8841dc5a074c CR3: 0000003feeae9000 CR4: 00000000001407e0
[ 325.490510] Stack:
[ 325.492524] ffff883feea0722c ffff883fef719dc0 ffff883feea0722c ffff883ff223e4a0
[ 325.499990] ffff881ff2fa79a8 ffffffff815424ee ffff883ff223e49c 000000015cba0744
[ 325.507460] 00000000f2fa7978 0000000000000000 ffff881ff2fa79a8 ffff883ff223e4a0
[ 325.514956] Call Trace:
[ 325.517412] [] gen_new_estimator+0x8e/0x230
[ 325.523250] [] gen_replace_estimator+0x4a/0x60
[ 325.529349] [] tc_modify_qdisc+0x52b/0x590
[ 325.535117] [] rtnetlink_rcv_msg+0xa0/0x240
[ 325.540963] [] ? __rtnl_unlock+0x20/0x20
[ 325.546532] [] netlink_rcv_skb+0xb1/0xc0
[ 325.552145] [] rtnetlink_rcv+0x25/0x40
[ 325.557558] [] netlink_unicast+0x168/0x220
[ 325.563317] [] netlink_sendmsg+0x2ec/0x3e0Lets play safe and not use an union : percpu 'pointers' are mostly read
anyway, and we have typically few qdiscs per host.Signed-off-by: Eric Dumazet
Cc: John Fastabend
Fixes: 22e0f8b9322c ("net: sched: make bstats per cpu and estimator RCU safe")
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit d953ca4ddf71aa91a4596b2ff7ff1598f6ad4708 ]
The existing code frees the skb in EAGAIN case, in which the skb will be
retried from upper layer and used again.
Also, the existing code doesn't free send buffer slot in error case, because
there is no completion message for unsent packets.
This patch fixes these problems.(Please also include this patch for stable trees. Thanks!)
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit cfbf654efc6d78dc9812e030673b86f235bf677d ]
When making use of RFC5061, section 4.2.4. for setting the primary IP
address, we're passing a wrong parameter header to param_type2af(),
resulting always in NULL being returned.At this point, param.p points to a sctp_addip_param struct, containing
a sctp_paramhdr (type = 0xc004, length = var), and crr_id as a correlation
id. Followed by that, as also presented in RFC5061 section 4.2.4., comes
the actual sctp_addr_param, which also contains a sctp_paramhdr, but
this time with the correct type SCTP_PARAM_IPV{4,6}_ADDRESS that
param_type2af() can make use of. Since we already hold a pointer to
addr_param from previous line, just reuse it for param_type2af().Fixes: d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
Signed-off-by: Saran Maruti Ramanara
Signed-off-by: Daniel Borkmann
Acked-by: Vlad Yasevich
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit e2a4800e75780ccf4e6c2487f82b688ba736eb18 ]
When we've run out of space in the output buffer to store more data, we
will call zlib_deflate with a NULL output buffer until we've consumed
remaining input.When this happens, olen contains the size the output buffer would have
consumed iff we'd have had enough room.This can later cause skb_over_panic when ppp_generic skb_put()s
the returned length.Reported-by: Iain Douglas
Signed-off-by: Florian Westphal
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit bdbbb8527b6f6a358dbcb70dac247034d665b8e4 ]
In commit be9f4a44e7d41 ("ipv4: tcp: remove per net tcp_sock")
I tried to address contention on a socket lock, but the solution
I chose was horrible :commit 3a7c384ffd57e ("ipv4: tcp: unicast_sock should not land outside
of TCP stack") addressed a selinux regression.commit 0980e56e506b ("ipv4: tcp: set unicast_sock uc_ttl to -1")
took care of another regression.commit b5ec8eeac46 ("ipv4: fix ip_send_skb()") fixed another regression.
commit 811230cd85 ("tcp: ipv4: initialize unicast_sock sk_pacing_rate")
was another shot in the dark.Really, just use a proper socket per cpu, and remove the skb_orphan()
call, to re-enable flow control.This solves a serious problem with FQ packet scheduler when used in
hostile environments, as we do not want to allocate a flow structure
for every RST packet sent in response to a spoofed packet.Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 811230cd853d62f09ed0addd0ce9a1b9b0e13fb5 ]
When I added sk_pacing_rate field, I forgot to initialize its value
in the per cpu unicast_sock used in ip_send_unicast_reply()This means that for sch_fq users, RST packets, or ACK packets sent
on behalf of TIME_WAIT sockets might be sent to slowly or even dropped
once we reach the per flow limit.Signed-off-by: Eric Dumazet
Fixes: 95bd09eb2750 ("tcp: TSO packets automatic sizing")
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 59ccaaaa49b5b096cdc1f16706a9f931416b2332 ]
Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081
This patch avoids calling rtnl_notify if the device ndo_bridge_getlink
handler does not return any bytes in the skb.Alternately, the skb->len check can be moved inside rtnl_notify.
For the bridge vlan case described in 92081, there is also a fix needed
in bridge driver to generate a proper notification. Will fix that in
subsequent patch.v2: rebase patch on net tree
Signed-off-by: Roopa Prabhu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 06539d3071067ff146a9bffd1c801fa56d290909 ]
Signed-off-by: Christoph Hellwig
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 24e579c8898aa641ede3149234906982290934e5 ]
With the commit d75b1ade567ffab ("net: less interrupt masking in NAPI") napi
repoll is done only when work_done == budget. When in busy_poll is we return 0
in napi_poll. We should return budget.Signed-off-by: Govindarajulu Varadarajan
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6e9e16e6143b725662e47026a1d0f270721cdd24 ]
Lubomir Rintel reported that during replacing a route the interface
reference counter isn't correctly decremented.To quote bug :
| [root@rhel7-5 lkundrak]# sh -x lal
| + ip link add dev0 type dummy
| + ip link set dev0 up
| + ip link add dev1 type dummy
| + ip link set dev1 up
| + ip addr add 2001:db8:8086::2/64 dev dev0
| + ip route add 2001:db8:8086::/48 dev dev0 proto static metric 20
| + ip route add 2001:db8:8088::/48 dev dev1 proto static metric 10
| + ip route replace 2001:db8:8086::/48 dev dev1 proto static metric 20
| + ip link del dev0 type dummy
| Message from syslogd@rhel7-5 at Jan 23 10:54:41 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2
|
| Message from syslogd@rhel7-5 at Jan 23 10:54:51 ...
| kernel:unregister_netdevice: waiting for dev0 to become free. Usage count = 2During replacement of a rt6_info we must walk all parent nodes and check
if the to be replaced rt6_info got propagated. If so, replace it with
an alive one.Fixes: 4a287eba2de3957 ("IPv6 routing, NLM_F_* flag support: REPLACE and EXCL flags support, warn about missing CREATE flag")
Reported-by: Lubomir Rintel
Signed-off-by: Hannes Frederic Sowa
Tested-by: Lubomir Rintel
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit fc752f1f43c1c038a2c6ae58cc739ebb5953ccb0 ]
An exception is seen in ICMP ping receive path where the skb
destructor sock_rfree() tries to access a freed socket. This happens
because ping_rcv() releases socket reference with sock_put() and this
internally frees up the socket. Later icmp_rcv() will try to free the
skb and as part of this, skb destructor is called and which leads
to a kernel panic as the socket is freed already in ping_rcv().-->|exception
-007|sk_mem_uncharge
-007|sock_rfree
-008|skb_release_head_state
-009|skb_release_all
-009|__kfree_skb
-010|kfree_skb
-011|icmp_rcv
-012|ip_local_deliver_finishFix this incorrect free by cloning this skb and processing this cloned
skb instead.This patch was suggested by Eric Dumazet
Signed-off-by: Subash Abhinov Kasiviswanathan
Cc: Eric Dumazet
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 86f3cddbc3037882414c7308973530167906b7e9 ]
While working on rhashtable walking I noticed that the UDP diag
dumping code is buggy. In particular, the socket skipping within
a chain never happens, even though we record the number of sockets
that should be skipped.As this code was supposedly copied from TCP, this patch does what
TCP does and resets num before we walk a chain.Signed-off-by: Herbert Xu
Acked-by: Pavel Emelyanov
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit df4d92549f23e1c037e83323aff58a21b3de7fe0 ]
Not caching dst_entries which cause redirects could be exploited by hosts
on the same subnet, causing a severe DoS attack. This effect aggravated
since commit f88649721268999 ("ipv4: fix dst race in sk_dst_get()").Lookups causing redirects will be allocated with DST_NOCACHE set which
will force dst_release to free them via RCU. Unfortunately waiting for
RCU grace period just takes too long, we can end up with >1M dst_entries
waiting to be released and the system will run OOM. rcuos threads cannot
catch up under high softirq load.Attaching the flag to emit a redirect later on to the specific skb allows
us to cache those dst_entries thus reducing the pressure on allocation
and deallocation.This issue was discovered by Marcelo Leitner.
Cc: Julian Anastasov
Signed-off-by: Marcelo Leitner
Signed-off-by: Florian Westphal
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: Julian Anastasov
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 600ddd6825543962fb807884169e57b580dba208 ]
When hitting an INIT collision case during the 4WHS with AUTH enabled, as
already described in detail in commit 1be9a950c646 ("net: sctp: inherit
auth_capable on INIT collisions"), it can happen that we occasionally
still remotely trigger the following panic on server side which seems to
have been uncovered after the fix from commit 1be9a950c646 ...[ 533.876389] BUG: unable to handle kernel paging request at 00000000ffffffff
[ 533.913657] IP: [] __kmalloc+0x95/0x230
[ 533.940559] PGD 5030f2067 PUD 0
[ 533.957104] Oops: 0000 [#1] SMP
[ 533.974283] Modules linked in: sctp mlx4_en [...]
[ 534.939704] Call Trace:
[ 534.951833] [] ? crypto_init_shash_ops+0x60/0xf0
[ 534.984213] [] crypto_init_shash_ops+0x60/0xf0
[ 535.015025] [] __crypto_alloc_tfm+0x6d/0x170
[ 535.045661] [] crypto_alloc_base+0x4c/0xb0
[ 535.074593] [] ? _raw_spin_lock_bh+0x12/0x50
[ 535.105239] [] sctp_inet_listen+0x161/0x1e0 [sctp]
[ 535.138606] [] SyS_listen+0x9d/0xb0
[ 535.166848] [] system_call_fastpath+0x16/0x1b... or depending on the the application, for example this one:
[ 1370.026490] BUG: unable to handle kernel paging request at 00000000ffffffff
[ 1370.026506] IP: [] kmem_cache_alloc+0x75/0x1d0
[ 1370.054568] PGD 633c94067 PUD 0
[ 1370.070446] Oops: 0000 [#1] SMP
[ 1370.085010] Modules linked in: sctp kvm_amd kvm [...]
[ 1370.963431] Call Trace:
[ 1370.974632] [] ? SyS_epoll_ctl+0x53f/0x960
[ 1371.000863] [] SyS_epoll_ctl+0x53f/0x960
[ 1371.027154] [] ? anon_inode_getfile+0xd3/0x170
[ 1371.054679] [] ? __alloc_fd+0xa7/0x130
[ 1371.080183] [] system_call_fastpath+0x16/0x1bWith slab debugging enabled, we can see that the poison has been overwritten:
[ 669.826368] BUG kmalloc-128 (Tainted: G W ): Poison overwritten
[ 669.826385] INFO: 0xffff880228b32e50-0xffff880228b32e50. First byte 0x6a instead of 0x6b
[ 669.826414] INFO: Allocated in sctp_auth_create_key+0x23/0x50 [sctp] age=3 cpu=0 pid=18494
[ 669.826424] __slab_alloc+0x4bf/0x566
[ 669.826433] __kmalloc+0x280/0x310
[ 669.826453] sctp_auth_create_key+0x23/0x50 [sctp]
[ 669.826471] sctp_auth_asoc_create_secret+0xcb/0x1e0 [sctp]
[ 669.826488] sctp_auth_asoc_init_active_key+0x68/0xa0 [sctp]
[ 669.826505] sctp_do_sm+0x29d/0x17c0 [sctp] [...]
[ 669.826629] INFO: Freed in kzfree+0x31/0x40 age=1 cpu=0 pid=18494
[ 669.826635] __slab_free+0x39/0x2a8
[ 669.826643] kfree+0x1d6/0x230
[ 669.826650] kzfree+0x31/0x40
[ 669.826666] sctp_auth_key_put+0x19/0x20 [sctp]
[ 669.826681] sctp_assoc_update+0x1ee/0x2d0 [sctp]
[ 669.826695] sctp_do_sm+0x674/0x17c0 [sctp]Since this only triggers in some collision-cases with AUTH, the problem at
heart is that sctp_auth_key_put() on asoc->asoc_shared_key is called twice
when having refcnt 1, once directly in sctp_assoc_update() and yet again
from within sctp_auth_asoc_init_active_key() via sctp_assoc_update() on
the already kzfree'd memory, which is also consistent with the observation
of the poison decrease from 0x6b to 0x6a (note: the overwrite is detected
at a later point in time when poison is checked on new allocation).Reference counting of auth keys revisited:
Shared keys for AUTH chunks are being stored in endpoints and associations
in endpoint_shared_keys list. On endpoint creation, a null key is being
added; on association creation, all endpoint shared keys are being cached
and thus cloned over to the association. struct sctp_shared_key only holds
a pointer to the actual key bytes, that is, struct sctp_auth_bytes which
keeps track of users internally through refcounting. Naturally, on assoc
or enpoint destruction, sctp_shared_key are being destroyed directly and
the reference on sctp_auth_bytes dropped.User space can add keys to either list via setsockopt(2) through struct
sctp_authkey and by passing that to sctp_auth_set_key() which replaces or
adds a new auth key. There, sctp_auth_create_key() creates a new sctp_auth_bytes
with refcount 1 and in case of replacement drops the reference on the old
sctp_auth_bytes. A key can be set active from user space through setsockopt()
on the id via sctp_auth_set_active_key(), which iterates through either
endpoint_shared_keys and in case of an assoc, invokes (one of various places)
sctp_auth_asoc_init_active_key().sctp_auth_asoc_init_active_key() computes the actual secret from local's
and peer's random, hmac and shared key parameters and returns a new key
directly as sctp_auth_bytes, that is asoc->asoc_shared_key, plus drops
the reference if there was a previous one. The secret, which where we
eventually double drop the ref comes from sctp_auth_asoc_set_secret() with
intitial refcount of 1, which also stays unchanged eventually in
sctp_assoc_update(). This key is later being used for crypto layer to
set the key for the hash in crypto_hash_setkey() from sctp_auth_calculate_hmac().To close the loop: asoc->asoc_shared_key is freshly allocated secret
material and independant of the sctp_shared_key management keeping track
of only shared keys in endpoints and assocs. Hence, also commit 4184b2a79a76
("net: sctp: fix memory leak in auth key management") is independant of
this bug here since it concerns a different layer (though same structures
being used eventually). asoc->asoc_shared_key is reference dropped correctly
on assoc destruction in sctp_association_free() and when active keys are
being replaced in sctp_auth_asoc_init_active_key(), it always has a refcount
of 1. Hence, it's freed prematurely in sctp_assoc_update(). Simple fix is
to remove that sctp_auth_key_put() from there which fixes these panics.Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
Signed-off-by: Daniel Borkmann
Acked-by: Vlad Yasevich
Acked-by: Neil Horman
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6088beef3f7517717bd21d90b379714dd0837079 ]
NAPI poll logic now enforces that a poller returns exactly the budget
when it wants to be called again.If a driver limits TX completion, it has to return budget as well when
the limit is hit, not the number of received packets.Reported-and-tested-by: Mike Galbraith
Signed-off-by: Eric Dumazet
Fixes: d75b1ade567f ("net: less interrupt masking in NAPI")
Cc: Manish Chopra
Acked-by: Manish Chopra
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 9d289715eb5c252ae15bd547cb252ca547a3c4f2 ]
Reduce the attack vector and stop generating IPv6 Fragment Header for
paths with an MTU smaller than the minimum required IPv6 MTU
size (1280 byte) - called atomic fragments.See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1]
for more information and how this "feature" can be misused.[1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
Signed-off-by: Fernando Gont
Signed-off-by: Hagen Paul Pfeifer
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit ac64da0b83d82abe62f78b3d0e21cca31aea24fa ]
softnet_data.input_pkt_queue is protected by a spinlock that
we must hold when transferring packets from victim queue to an active
one. This is because other cpus could still be trying to enqueue packets
into victim queue.A second problem is that when we transfert the NAPI poll_list from
victim to current cpu, we absolutely need to special case the percpu
backlog, because we do not want to add complex locking to protect
process_queue : Only owner cpu is allowed to manipulate it, unless cpu
is offline.Based on initial patch from Prasad Sodagudi & Subash Abhinov
Kasiviswanathan.This version is better because we do not slow down packet processing,
only make migration safer.Reported-by: Prasad Sodagudi
Reported-by: Subash Abhinov Kasiviswanathan
Signed-off-by: Eric Dumazet
Cc: Tom Herbert
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f812116b174e59a350acc8e4856213a166a91222 ]
The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That
structure is defined and allocated on the stack asstruct {
struct sock_extended_err ee;
struct sockaddr_in(6) offender;
} errhdr;The second part is only initialized for certain SO_EE_ORIGIN values.
Always initialize it completely.An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that
would return uninitialized bytes.Signed-off-by: Willem de Bruijn
----
Also verified that there is no padding between errhdr.ee and
errhdr.offender that could leak additional kernel data.
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
11 Feb, 2015
19 commits
-
commit 7fb08eca45270d0ae86e1ad9d39c40b7a55d0190 upstream.
This replaces four copies in various stages of mm_fault_error() handling
with just a single one. It will also allow for more natural placement
of the unlocking after some further cleanup.Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 6c8465a82a605bc692304bab42703017dcfff013 upstream.
When taking a CPU down for suspend and resume, a tracepoint may be called
when the CPU has been designated offline. As tracepoints require RCU for
protection, they must not be called if the current CPU is offline.Unfortunately, trace_tlb_flush() is called in this scenario as was noted
by LOCKDEP:...
Disabling non-boot CPUs ...
intel_pstate CPU 1 exiting===============================
smpboot: CPU 1 didn't die...
[ INFO: suspicious RCU usage. ]
3.19.0-rc7-next-20150204.1-iniza-small #1 Not tainted
-------------------------------
include/trace/events/tlb.h:35 suspicious rcu_dereference_check() usage!other info that might help us debug this:
RCU used illegally from offline CPU!
rcu_scheduler_active = 1, debug_locks = 0
no locks held by swapper/1/0.stack backtrace:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150204.1-iniza-small #1
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
0000000000000001 ffff88011a44fe18 ffffffff817e370d 0000000000000011
ffff88011a448290 ffff88011a44fe48 ffffffff810d6847 ffff8800c66b9600
0000000000000001 ffff88011a44c000 ffffffff81cb3900 ffff88011a44fe78
Call Trace:
[] dump_stack+0x4c/0x65
[] lockdep_rcu_suspicious+0xe7/0x120
[] idle_task_exit+0x205/0x2c0
[] play_dead_common+0xe/0x50
[] native_play_dead+0x15/0x140
[] arch_cpu_idle_dead+0xf/0x20
[] cpu_startup_entry+0x37e/0x580
[] start_secondary+0x140/0x150
intel_pstate CPU 2 exiting...
By converting the tlb_flush tracepoint to a TRACE_EVENT_CONDITION where the
condition is cpu_online(smp_processor_id()), we can avoid calling RCU protected
code when the CPU is offline.Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com
Fixes: d17d8f9dedb9 "x86/mm: Add tracepoints for TLB flushes"
Reported-by: Sedat Dilek
Tested-by: Sedat Dilek
Suggested-by: Paul E. McKenney
Acked-by: Paul E. McKenney
Acked-by: Dave Hansen
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit a05d59a5673339ef6936d6940cdf68172ce75b9f upstream.
The trace_tlb_flush() tracepoint can be called when a CPU is going offline.
When a CPU is offline, RCU is no longer watching that CPU and since the
tracepoint is protected by RCU, it must not be called. To prevent the
tlb_flush tracepoint from being called when the CPU is offline, it was
converted to a TRACE_EVENT_CONDITION where the condition checks if the
CPU is online before calling the tracepoint.Unfortunately, this was not enough to stop lockdep from complaining about
it. Even though the RCU protected code of the tracepoint will never be
called, the condition is hidden within the tracepoint, and even though the
condition prevents RCU code from being called, the lockdep checks are
outside the tracepoint (this is to test tracepoints even when they are not
enabled).Even though tracepoints should be checked to be RCU safe when they are not
enabled, the condition should still be considered when checking RCU.Link: http://lkml.kernel.org/r/CA+icZUUGiGDoL5NU8RuxKzFjoLjEKRtUWx=JB8B9a0EQv-eGzQ@mail.gmail.com
Fixes: 3a630178fd5f "tracing: generate RCU warnings even when tracepoints are disabled"
Acked-by: Dave Hansen
Reported-by: Sedat Dilek
Tested-by: Sedat Dilek
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit 2d926c15d629a13914ce3e5f26354f6a0ac99e70 upstream.
I noticed some CLOCK_TAI timer test failures on one of my
less-frequently used configurations. And after digging in I
found in 76f4108892d9 (Cleanup hrtimer accessors to the
timekepeing state), the hrtimer_get_softirq_time tai offset
calucation was incorrectly rewritten, as the tai offset we
return shold be from CLOCK_MONOTONIC, and not CLOCK_REALTIME.This results in CLOCK_TAI timers expiring early on non-highres
capable machines.This patch fixes the issue, calculating the tai time properly
from the monotonic base.Signed-off-by: John Stultz
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1423097126-10236-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 4bee96860a65c3a62d332edac331b3cf936ba3ad upstream.
The following race exists in the smpboot percpu threads management:
CPU0 CPU1
cpu_up(2)
get_online_cpus();
smpboot_create_threads(2);
smpboot_register_percpu_thread();
for_each_online_cpu();
__smpboot_create_thread();
__cpu_up(2);This results in a missing per cpu thread for the newly onlined cpu2 and
in a NULL pointer dereference on a consecutive offline of that cpu.Proctect smpboot_register_percpu_thread() with get_online_cpus() to
prevent that.[ tglx: Massaged changelog and removed the change in
smpboot_unregister_percpu_thread() because that's an
optimization and therefor not stable material. ]Signed-off-by: Lai Jiangshan
Cc: Thomas Gleixner
Cc: Rusty Russell
Cc: Peter Zijlstra
Cc: Srivatsa S. Bhat
Cc: David Rientjes
Link: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit da63865a01c6384d459464e5165d95d4f04878d8 upstream.
Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and
a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
paravirt") allow microcode driver skip initialization when microcode
loading is not permitted.However, they don't prevent the driver from being loaded since the
init code returns 0. If at some point later the driver gets unloaded
this will result in an oops while trying to deregister the (never
registered) device.To avoid this, make init code return an error on paravirt or when
microcode loading is disabled. The driver will then never be loaded.Signed-off-by: Boris Ostrovsky
Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com
Reported-by: James Digwall
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman -
commit fddcd300732dad5b822d27de7aa78998dca43162 upstream.
I2S1, I2S2 on Exynos4 SoC series have limited functionality compared
to I2S0, "samsung,s3c6410-i2s" compatible should be used for them.Signed-off-by: Sylwester Nawrocki
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 4161b4505f1690358ac0a9ee59845a7887336b21 upstream.
When ak4114 work calls its callback and the callback invokes
ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding
this, control the reentrance by introducing a refcount. Also
flush_delayed_work() is replaced with cancel_delayed_work_sync().The exactly same bug is present in ak4113.c and fixed as well.
Reported-by: Pavel Hofman
Acked-by: Jaroslav Kysela
Tested-by: Pavel Hofman
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 58cc9c9a175885bbf6bae3acf18233d0a8229a84 upstream.
To quote from section 1.3.1 of the data sheet:
The SGTL5000 has an internal reset that is deasserted
8 SYS_MCLK cycles after all power rails have been brought
up. After this time, communication can start...
1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK.Signed-off-by: Eric Nelson
Reviewed-by: Fabio Estevam
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit a43bd7e125143b875caae6d4f9938855b440faaf upstream.
According to the I2S specification information as following:
- WS = 0, channel 1 (left)
- WS = 1, channel 2 (right)
So, the start event should be TF/RF falling edge.Reported-by: Songjun Wu
Signed-off-by: Bo Shen
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 9ce357795ef208faa0d59894d9d119a7434e37f3 upstream.
Fixed commit added from64to32 under _#ifndef do_csum_ but used it
under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's
robot reported TILEGX's). Move from64to32 under the latter.Fixes: 150ae0e94634 ("lib/checksum.c: fix carry in csum_tcpudp_nofold")
Reported-by: kbuild test robot
Signed-off-by: Karl Beldan
Cc: Eric Dumazet
Cc: David S. Miller
Signed-off-by: David S. Miller
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 44b82b7700d05a52cd983799d3ecde1a976b3bed upstream.
Commit d7a49086f263164a (arm64: cpuinfo: print info for all CPUs)
attempted to clean up /proc/cpuinfo, but due to concerns regarding
further changes was reverted in commit 5e39977edf6500fd (Revert "arm64:
cpuinfo: print info for all CPUs").There are two major issues with the arm64 /proc/cpuinfo format
currently:* The "Features" line describes (only) the 64-bit hwcaps, which is
problematic for some 32-bit applications which attempt to parse it. As
the same names are used for analogous ISA features (e.g. aes) despite
these generally being architecturally unrelated, it is not possible to
simply append the 64-bit and 32-bit hwcaps in a manner that might not
be misleading to some applications.Various potential solutions have appeared in vendor kernels. Typically
the format of the Features line varies depending on whether the task
is 32-bit.* Information is only printed regarding a single CPU. This does not
match the ARM format, and does not provide sufficient information in
big.LITTLE systems where CPUs are heterogeneous. The CPU information
printed is queried from the current CPU's registers, which is racy
w.r.t. cross-cpu migration.This patch attempts to solve these issues. The following changes are
made:* When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
the "Features" line contains the decoded 32-bit hwcaps, as with the
arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
the absense of compat support, the Features line is empty.The set of hwcaps injected into a task's auxval are unaffected.
* Properties are printed per-cpu, as with the ARM port. The per-cpu
information is queried from pre-recorded cpu information (as used by
the sanity checks).* As with the previous attempt at fixing up /proc/cpuinfo, the hardware
field is removed. The only users so far are 32-bit applications tied
to particular boards, so no portable applications should be affected,
and this should prevent future tying to particular boards.The following differences remain:
* No model_name is printed, as this cannot be queried from the hardware
and cannot be provided in a stable fashion. Use of the CPU
{implementor,variant,part,revision} fields is sufficient to identify a
CPU and is portable across arm and arm64.* The following system-wide properties are not provided, as they are not
possible to provide generally. Programs relying on these are already
tied to particular (32-bit only) boards:
- Hardware
- Revision
- SerialNo software has yet been identified for which these remaining
differences are problematic.Cc: Greg Hackmann
Cc: Ian Campbell
Cc: Serban Constantinescu
Cc: Will Deacon
Cc: cross-distro@lists.linaro.org
Cc: linux-api@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Catalin Marinas
Signed-off-by: Mark Rutland
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 2d560306096739e2251329ab5c16059311a151b0 upstream.
Warning:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
jump->offset = strlen(r->s);Simplifies the test logic because (head && local) means (jump != 0)
and makes GCC happy when checking if the jump pointer was initialized.Signed-off-by: Peter Kümmel
Signed-off-by: Michal Marek
Cc: Sedat Dilek
Signed-off-by: Greg Kroah-Hartman -
commit a124d068bf5be6be2ff4b9fab77b1b7509107e68 upstream.
Should be the same as cayman. We don't use VM by default
on NI parts so this isn't critical.Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 92b712b739811e4aa7c0e1af339d0098989ea024 upstream.
radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from vram BO.bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464Reviewed-by: Christian König
Signed-off-by: Ilija Hadzic
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 3f5e1b4f58b7b6480cccff4bf965436102db4346 upstream.
radeon_copy_dma and radeon_copy_blit must be called with
a valid reservation object. Otherwise a crash will be provoked.
We borrow the object from destination BO.bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88464Reviewed-by: Christian König
Signed-off-by: Ilija Hadzic
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 72edd83cc9e5819ed1ee771519143d7594e059f0 upstream.
This is a workaround for RS880 and older chips which seem to have
an additional limit on the minimum PLL input frequency.v2: fix signed/unsigned warning
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=91861
https://bugzilla.kernel.org/show_bug.cgi?id=83461Signed-off-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 544143f9e01a60a93eb00ab4bfcb9bf4702a2a7d upstream.
If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it. Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.v2: handle vm_fini as well
v3: handle bo_open/close as wellBug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
