talos-obmc-linux/include, branch v5.0.1

Bluetooth: Fix locking in bt_accept_enqueue() for BH context

2019-03-10T06:09:01+00:00

commit c4f5627f7eeecde1bb6b646d8c0907b96dc2b2a6 upstream. With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically") lock_sock[_nested]() is used to acquire the socket lock before manipulating the socket. lock_sock[_nested]() may block, which is problematic since bt_accept_enqueue() can be called in bottom half context (e.g. from rfcomm_connect_ind()): [] __might_sleep+0x4c/0x80 [] lock_sock_nested+0x24/0x58 [] bt_accept_enqueue+0x48/0xd4 [bluetooth] [] rfcomm_connect_ind+0x190/0x218 [rfcomm] Add a parameter to bt_accept_enqueue() to indicate whether the function is called from BH context, and acquire the socket lock with bh_lock_sock_nested() if that's the case. Also adapt all callers of bt_accept_enqueue() to pass the new parameter: - l2cap_sock_new_connection_cb() - uses lock_sock() to lock the parent socket => process context - rfcomm_connect_ind() - acquires the parent socket lock with bh_lock_sock() => BH context - __sco_chan_add() - called from sco_chan_add(), which is called from sco_connect(). parent is NULL, hence bt_accept_enqueue() isn't called in this code path and we can ignore it - also called from sco_conn_ready(). uses bh_lock_sock() to acquire the parent lock => BH context Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically") Signed-off-by: Matthias Kaehlcke Reviewed-by: Douglas Anderson Signed-off-by: Marcel Holtmann Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

net: sched: put back q.qlen into a single location

2019-03-10T06:08:59+00:00

[ Upstream commit 46b1c18f9deb326a7e18348e668e4c7ab7c7458b ] In the series fc8b81a5981f ("Merge branch 'lockless-qdisc-series'") John made the assumption that the data path had no need to read the qdisc qlen (number of packets in the qdisc). It is true when pfifo_fast is used as the root qdisc, or as direct MQ/MQPRIO children. But pfifo_fast can be used as leaf in class full qdiscs, and existing logic needs to access the child qlen in an efficient way. HTB breaks badly, since it uses cl->leaf.q->q.qlen in : htb_activate() -> WARN_ON() htb_dequeue_tree() to decide if a class can be htb_deactivated when it has no more packets. HFSC, DRR, CBQ, QFQ have similar issues, and some calls to qdisc_tree_reduce_backlog() also read q.qlen directly. Using qdisc_qlen_sum() (which iterates over all possible cpus) in the data path is a non starter. It seems we have to put back qlen in a central location, at least for stable kernels. For all qdisc but pfifo_fast, qlen is guarded by the qdisc lock, so the existing q.qlen{++|--} are correct. For 'lockless' qdisc (pfifo_fast so far), we need to use atomic_{inc|dec}() because the spinlock might be not held (for example from pfifo_fast_enqueue() and pfifo_fast_dequeue()) This patch adds atomic_qlen (in the same location than qlen) and renames the following helpers, since we want to express they can be used without qdisc lock, and that qlen is no longer percpu. - qdisc_qstats_cpu_qlen_dec -> qdisc_qstats_atomic_qlen_dec() - qdisc_qstats_cpu_qlen_inc -> qdisc_qstats_atomic_qlen_inc() Later (net-next) we might revert this patch by tracking all these qlen uses and replace them by a more efficient method (not having to access a precise qlen, but an empty/non_empty status that might be less expensive to maintain/track). Another possibility is to have a legacy pfifo_fast version that would be used when used a a child qdisc, since the parent qdisc needs a spinlock anyway. But then, future lockless qdiscs would also have the same problem. Fixes: 7e66016f2c65 ("net: sched: helpers to sum qlen and qlen for per cpu logic") Signed-off-by: Eric Dumazet Cc: John Fastabend Cc: Jamal Hadi Salim Cc: Cong Wang Cc: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

binder: create node flag to request sender's security context

2019-03-10T06:08:57+00:00

commit ec74136ded792deed80780a2f8baf3521eeb72f9 upstream. To allow servers to verify client identity, allow a node flag to be set that causes the sender's security context to be delivered with the transaction. The BR_TRANSACTION command is extended in BR_TRANSACTION_SEC_CTX to contain a pointer to the security context string. Signed-off-by: Todd Kjos Reviewed-by: Joel Fernandes (Google) Signed-off-by: Greg Kroah-Hartman

cpufreq: Use struct kobj_attribute instead of struct global_attr

2019-03-10T06:08:57+00:00

commit 625c85a62cb7d3c79f6e16de3cfa972033658250 upstream. The cpufreq_global_kobject is created using kobject_create_and_add() helper, which assigns the kobj_type as dynamic_kobj_ktype and show/store routines are set to kobj_attr_show() and kobj_attr_store(). These routines pass struct kobj_attribute as an argument to the show/store callbacks. But all the cpufreq files created using the cpufreq_global_kobject expect the argument to be of type struct attribute. Things work fine currently as no one accesses the "attr" argument. We may not see issues even if the argument is used, as struct kobj_attribute has struct attribute as its first element and so they will both get same address. But this is logically incorrect and we should rather use struct kobj_attribute instead of struct global_attr in the cpufreq core and drivers and the show/store callbacks should take struct kobj_attribute as argument instead. This bug is caught using CFI CLANG builds in android kernel which catches mismatch in function prototypes for such callbacks. Reported-by: Donghee Han Reported-by: Sangkyu Kim Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2019-03-02T16:46:34+00:00

Pull networking fixes from David Miller: 1) Fix refcount leak in act_ipt during replace, from Davide Caratti. 2) Set task state properly in tun during blocking reads, from Timur Celik. 3) Leaked reference in DSA, from Wen Yang. 4) NULL deref in act_tunnel_key, from Vlad Buslov. 5) cipso_v4_erro can reference the skb IPCB in inappropriate contexts thus referencing garbage, from Nazarov Sergey. 6) Don't accept RTA_VIA and RTA_GATEWAY in contexts where those attributes make no sense. 7) Fix hung sendto in tipc, from Tung Nguyen. 8) Out-of-bounds access in netlabel, from Paul Moore. 9) Grant reference leak in xen-netback, from Igor Druzhinin. 10) Fix tx stalls with lan743x, from Bryan Whitehead. 11) Fix interrupt storm with mv88e6xxx, from Hein Kallweit. 12) Memory leak in sit on device registry failure, from Mao Wenan. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (44 commits) net: sit: fix memory leak in sit_init_net() net: dsa: mv88e6xxx: Fix statistics on mv88e6161 geneve: correctly handle ipv6.disable module parameter net: dsa: mv88e6xxx: prevent interrupt storm caused by mv88e6390x_port_set_cmode bpf: fix sanitation rewrite in case of non-pointers ipv4: Add ICMPv6 support when parse route ipproto MIPS: eBPF: Fix icache flush end address lan743x: Fix TX Stall Issue net: phy: phylink: fix uninitialized variable in phylink_get_mac_state net: aquantia: regression on cpus with high cores: set mode with 8 queues selftests: fixes for UDP GRO bpf: drop refcount if bpf_map_new_fd() fails in map_create() net: dsa: mv88e6xxx: power serdes on/off for 10G interfaces on 6390X net: dsa: mv88e6xxx: Fix u64 statistics xen-netback: don't populate the hash cache on XenBus disconnect xen-netback: fix occasional leak of grant ref mappings under memory pressure sctp: chunk.c: correct format string for size_t in printk net: netem: fix skb length BUG_ON in __skb_to_sgvec netlabel: fix out-of-bounds memory accesses ipv4: Pass original device to ip_rcv_finish_core ...

ipv4: Add ICMPv6 support when parse route ipproto

2019-03-02T00:41:27+00:00

For ip rules, we need to use 'ipproto ipv6-icmp' to match ICMPv6 headers. But for ip -6 route, currently we only support tcp, udp and icmp. Add ICMPv6 support so we can match ipv6-icmp rules for route lookup. v2: As David Ahern and Sabrina Dubroca suggested, Add an argument to rtm_getroute_parse_ip_proto() to handle ICMP/ICMPv6 with different family. Reported-by: Jianlin Shi Fixes: eacb9384a3fe ("ipv6: support sport, dport and ip_proto in RTM_GETROUTE") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller

net: dev: Use unsigned integer as an argument to left-shift

2019-02-27T17:34:39+00:00

1 << 31 is Undefined Behaviour according to the C standard. Use U type modifier to avoid theoretical overflow. Signed-off-by: Andy Shevchenko Signed-off-by: David S. Miller

net: avoid use IPCB in cipso_v4_error

2019-02-25T22:32:35+00:00

Extract IP options in cipso_v4_error and use __icmp_send. Signed-off-by: Sergey Nazarov Acked-by: Paul Moore Signed-off-by: David S. Miller

net: Add __icmp_send helper.

2019-02-25T22:32:35+00:00

Add __icmp_send function having ip_options struct parameter Signed-off-by: Sergey Nazarov Reviewed-by: Paul Moore Signed-off-by: David S. Miller

Revert "x86/fault: BUG() when uaccess helpers fault on kernel addresses"

2019-02-25T17:10:51+00:00

This reverts commit 9da3f2b74054406f87dff7101a569217ffceb29b. It was well-intentioned, but wrong. Overriding the exception tables for instructions for random reasons is just wrong, and that is what the new code did. It caused problems for tracing, and it caused problems for strncpy_from_user(), because the new checks made perfectly valid use cases break, rather than catch things that did bad things. Unchecked user space accesses are a problem, but that's not a reason to add invalid checks that then people have to work around with silly flags (in this case, that 'kernel_uaccess_faults_ok' flag, which is just an odd way to say "this commit was wrong" and was sprinked into random places to hide the wrongness). The real fix to unchecked user space accesses is to get rid of the special "let's not check __get_user() and __put_user() at all" logic. Make __{get|put}_user() be just aliases to the regular {get|put}_user() functions, and make it impossible to access user space without having the proper checks in places. The raison d'être of the special double-underscore versions used to be that the range check was expensive, and if you did multiple user accesses, you'd do the range check up front (like the signal frame handling code, for example). But SMAP (on x86) and PAN (on ARM) have made that optimization pointless, because the _real_ expense is the "set CPU flag to allow user space access". Do let's not break the valid cases to catch invalid cases that shouldn't even exist. Cc: Thomas Gleixner Cc: Kees Cook Cc: Tobin C. Harding Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Andy Lutomirski Cc: Jann Horn Signed-off-by: Linus Torvalds