- 10 Sep, 2014 19 commits
-
-
Eric Dumazet authored
Remove one sparse warning : net/ipv4/ip_sockglue.c:328:22: warning: incorrect type in assignment (different address spaces) net/ipv4/ip_sockglue.c:328:22: expected struct ip_ra_chain [noderef] <asn:4>*next net/ipv4/ip_sockglue.c:328:22: got struct ip_ra_chain *[assigned] ra And replace one rcu_assign_ptr() by RCU_INIT_POINTER() where applicable. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Daniel Borkmann authored
It's not used anywhere, so just remove these. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Andy Shevchenko authored
Instead of looping in the code let's use kernel extension to dump small buffers. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
hayeswang authored
Replace mdelay with usleep_range to avoid busy loop. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
Willem de Bruijn authored
Few packets have timestamping enabled. Exit sock_tx_timestamp quickly in this common case. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Florian Westphal authored
not used anymore since ddecf0f4 (net_sched: sfq: add optional RED on top of SFQ). Signed-off-by:
Florian Westphal <fw@strlen.de> Acked-by:
-
Rick Jones authored
Convert the normal transmit completion path from dev_kfree_skb_any() to dev_consume_skb_any() to help keep dropped packet profiling meaningful. Signed-off-by:
Rick Jones <rick.jones2@hp.com> Signed-off-by:
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== bonding: get rid of bond->lock This patch-set removes the last users of bond->lock and converts the places that needed it for sync to use curr_slave_lock or RCU as appropriate. I've run this with lockdep and have stress-tested it via loading/unloading and enslaving/releasing in parallel while outputting bond's proc, I didn't see any issues. Please pay special attention to the procfs change, I've done about an hour of stress-testing on it and have checked that the event that causes the bonding to delete its proc entry (NETDEV_UNREGISTER) is called before ndo_uninit() and the freeing of the dev so any readers will sync with that. Also ran sparse checks and there were no splats. v2: Add patch 0001/cxgb4 bond->lock removal, RTNL should be held in the notifier call, the other patches are the same. Also tested with allmodconfig to make sure there're no more users of bond->lock. Changes from the RFC: use RCU in procfs instead of RTNL since RTNL might lead to a deadlock with unloading and also is much slower. The bond destruction syncs with proc via the proc locks. There's one new patch that converts primary_slave to use RCU as it was necessary to fix a longstanding bugs in sysfs and procfs and to make it easy to migrate bond's procfs to RCU. And of course rebased on top of net-next current. This is the first patch-set in a series that should simplify the bond's locking requirements and will make it easier to define the locking conditions necessary for the various paths. The goal is to rely on RTNL and rcu alone, an extra lock would be needed in a few special cases that would be documented very well. ==================== Signed-off-by: -
Nikolay Aleksandrov authored
The usage of bond->lock in bond_main.c was completely unnecessary as it didn't help to sync with anything, most of the spots already had RTNL. Since there're no more users of bond->lock, remove it. Signed-off-by:
Nikolay Aleksandrov <nikolay@redhat.com> Signed-off-by:
-
Nikolay Aleksandrov authored
We're safe to remove the bond->lock use from the arp targets because arp_rcv_probe no longer acquires bond->lock, only rcu_read_lock. Also setting the primary slave is safe because noone uses the bond->lock as a syncing mechanism for that anymore. Signed-off-by:
-
Nikolay Aleksandrov authored
Use RCU to protect against slave release, the proc show function will sync with the bond destruction by the proc locks and the fact that the bond is released after NETDEV_UNREGISTER which causes the bonding to remove the proc entry. Signed-off-by:
-
Nikolay Aleksandrov authored
This is necessary mainly for two bonding call sites: procfs and sysfs as it was dereferenced without any real protection. Signed-off-by:
-
Nikolay Aleksandrov authored
We can remove the lock/unlock as it's no longer necessary since RTNL should be held while calling bond_alb_set_mac_address(). Signed-off-by:
-
Nikolay Aleksandrov authored
In 3ad mode the only syncing needed by bond->lock is for the wq and the recv handler, so change them to use curr_slave_lock. There're no locking dependencies here as 3ad doesn't use curr_slave_lock at all. Signed-off-by:
-
Nikolay Aleksandrov authored
RTNL should be already held in the notifier call so the slave list can be traversed without a problem, remove the unnecessary bond->lock. CC: Hariprasad S <hariprasad@chelsio.com> Signed-off-by:
-
Romain Perier authored
This enables EMAC Rockchip support on radxa rock boards. Signed-off-by:
Romain Perier <romain.perier@gmail.com> Signed-off-by:
-
Romain Perier authored
This adds support for EMAC Rockchip driver on RK3188 SoCs. Signed-off-by:
-
Romain Perier authored
This adds the necessary binding documentation for the EMAC Rockchip platform driver found in RK3066 and RK3188 SoCs. Signed-off-by:
-
Romain Perier authored
This patch defines a platform glue layer for Rockchip SoCs which support arc-emac driver. It ensures that regulator for the rmii is on before trying to connect to the ethernet controller. It applies right speed and mode changes to the grf when ethernet settings change. Signed-off-by:
-
- 09 Sep, 2014 19 commits
-
-
David S. Miller authored
Daniel Borkmann says: ==================== BPF updates [ Set applies on top of current net-next but also on top of Alexei's latest patches. Please see individual patches for more details. ] Changelog: v1->v2: - Removed paragraph in 1st commit message - Rest stays the same ==================== Signed-off-by: -
Daniel Borkmann authored
Reported by Mikulas Patocka, kmemcheck currently barks out a false positive since we don't have special kmemcheck annotation for bitfields used in bpf_prog structure. We currently have jited:1, len:31 and thus when accessing len while CONFIG_KMEMCHECK enabled, kmemcheck throws a warning that we're reading uninitialized memory. As we don't need the whole bit universe for pages member, we can just split it to u16 and use a bool flag for jited instead of a bitfield. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Signed-off-by:
-
Daniel Borkmann authored
This is the ARM variant for 314beb9b ("x86: bpf_jit_comp: secure bpf jit against spraying attacks"). It is now possible to implement it due to commits 75374ad4 ("ARM: mm: Define set_memory_* functions for ARM") and dca9aa92 ("ARM: add DEBUG_SET_MODULE_RONX option to Kconfig") which added infrastructure for this facility. Thus, this patch makes sure the BPF generated JIT code is marked RO, as other kernel text sections, and also lets the generated JIT code start at a pseudo random offset instead on a page boundary. The holes are filled with illegal instructions. JIT tested on armv7hl with BPF test suite. Reference: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.htmlSigned-off-by:
Mircea Gherzan <mgherzan@gmail.com> Signed-off-by:
-
Daniel Borkmann authored
Introduced in commit 314beb9b ("x86: bpf_jit_comp: secure bpf jit against spraying attacks") and later on replicated in aa2d2c73 ("s390/bpf,jit: address randomize and write protect jit code") for s390 architecture, write protection for BPF JIT images got added and a random start address of the JIT code, so that it's not on a page boundary anymore. Since both use a very similar allocator for the BPF binary header, we can consolidate this code into the BPF core as it's mostly JIT independant anyway. This will also allow for future archs that support DEBUG_SET_MODULE_RONX to just reuse instead of reimplementing it. JIT tested on x86_64 and s390x with BPF test suite. Signed-off-by:
-
Eric Dumazet authored
Alexander Duyck reported high false sharing on dst refcount in tcp stack when prequeue is used. prequeue is the mechanism used when a thread is blocked in recvmsg()/read() on a TCP socket, using a blocking model rather than select()/poll()/epoll() non blocking one. We already try to use RCU in input path as much as possible, but we were forced to take a refcount on the dst when skb escaped RCU protected region. When/if the user thread runs on different cpu, dst_release() will then touch dst refcount again. Commit 09316255 (tcp: force a dst refcount when prequeue packet) was an example of a race fix. It turns out the only remaining usage of skb->dst for a packet stored in a TCP socket prequeue is IP early demux. We can add a logic to detect when IP early demux is probably going to use skb->dst. Because we do an optimistic check rather than duplicate existing logic, we need to guard inet_sk_rx_dst_set() and inet6_sk_rx_dst_set() from using a NULL dst. Many thanks to Alexander for providing a nice bug report, git bisection, and reproducer. Tested using Alexander script on a 40Gb NIC, 8 RX queues. Hosts have 24 cores, 48 hyper threads. echo 0 >/proc/sys/net/ipv4/tcp_autocorking for i in `seq 0 47` do for j in `seq 0 2` do netperf -H $DEST -t TCP_STREAM -l 1000 \ -c -C -T $i,$i -P 0 -- \ -m 64 -s 64K -D & done done Before patch : ~6Mpps and ~95% cpu usage on receiver After patch : ~9Mpps and ~35% cpu usage on receiver. Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
-
Stephen Rothwell authored
After merging the wireless-next tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/net/wireless/ath/ath5k/debug.c: In function 'open_file_eeprom': drivers/net/wireless/ath/ath5k/debug.c:933:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration] buf = vmalloc(eesize); ^ drivers/net/wireless/ath/ath5k/debug.c:933:6: warning: assignment makes pointer from integer without a cast buf = vmalloc(eesize); ^ drivers/net/wireless/ath/ath5k/debug.c:960:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] vfree(buf); ^ Caused by commit db906eb2 ("ath5k: added debugfs file for dumping eeprom"). Also reported by Guenter Roeck. I have used Geert Uytterhoeven's suggested fix of including vmalloc.h and so added this patch for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 8 Sep 2014 18:39:23 +1000 Subject: [PATCH] ath5k: fix debugfs addition Reported-by:Guenter Roeck <linux@roeck-us.net> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Varka Bhadram authored
It removes the owner field updation of driver structure. It will be automatically updated by module_platform_driver() Signed-off-by:
Varka Bhadram <varkab@cdac.in> Signed-off-by:
-
Li RongQing authored
Change the date type of error status from u64 to atomic_long_t, and use atomic operation, then remove the lock which is used to protect the error status. The operation of atomic maybe faster than spin lock. Cc: Pravin Shelar <pshelar@nicira.com> Signed-off-by:
Li RongQing <roy.qing.li@gmail.com> Signed-off-by:
-
Rami Rosen authored
This patch removes an unncessary check in the br_afspec() method of br_netlink.c. Signed-off-by:
Rami Rosen <ramirose@gmail.com> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== bridge: implement rtnl_link options for getting and setting bridge options So far, only sysfs is complete interface for getting and setting bridge options. This patchset follows-up on the similar bonding code and allows userspace to get/set bridge master/port options using Netlink IFLA_INFO_DATA/IFLA_INFO_SLAVE_DATA attr. ==================== Signed-off-by: -
Jiri Pirko authored
Allow rtnetlink users to set bridge master info via IFLA_INFO_DATA attr This initial part implements forward_delay, hello_time, max_age options. Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Jiri Pirko authored
Allow rtnetlink users to get bridge master info in IFLA_INFO_DATA attr This initial part implements forward_delay, hello_time, max_age options. Signed-off-by:
-
Jiri Pirko authored
Allow rtnetlink users to set port info via IFLA_INFO_SLAVE_DATA attr Signed-off-by:
-
Jiri Pirko authored
Allow rtnetlink users to get port info in IFLA_INFO_SLAVE_DATA attr Signed-off-by:
-
Jiri Pirko authored
The thing is that netdev_master_upper_dev_link calls call_netdevice_notifiers(NETDEV_CHANGEUPPER, dev). That generates rtnl link message and during that, rtnl_link_ops->fill_slave_info is called. But with current ordering, rx_handler and IFF_BRIDGE_PORT are not set yet so there would have to be check for that in fill_slave_info callback. Resolve this by reordering to similar what bonding and team does to avoid the check. Also add removal of IFF_BRIDGE_PORT flag into error path. Signed-off-by:
-
Vincent Bernat authored
net.ipv4.ip_nonlocal_bind sysctl was global to all network namespaces. This patch allows to set a different value for each network namespace. Signed-off-by:
Vincent Bernat <vincent@bernat.im> Signed-off-by:
-
David S. Miller authored
Alexei Starovoitov says: ==================== load imm64 insn and uapi/linux/bpf.h V9->V10 - no changes, added Daniel's ack Note they're on top of Hannes's patch in the same area [1] V8 thread with 'why' reasoning and end goal [2] Original set [3] of ~28 patches I'm planning to present in 4 stages: I. this 2 patches to fork off llvm upstreaming II. bpf syscall with manpage and map implementation III. bpf program load/unload with verifier testsuite (1st user of instruction macros from bpf.h and 1st user of load imm64 insn) IV. tracing, etc [1] http://patchwork.ozlabs.org/patch/385266/ [2] https://lkml.org/lkml/2014/8/27/628 [3] https://lkml.org/lkml/2014/8/26/859 ==================== Signed-off-by: -
Alexei Starovoitov authored
allow user space to generate eBPF programs uapi/linux/bpf.h: eBPF instruction set definition linux/filter.h: the rest This patch only moves macro definitions, but practically it freezes existing eBPF instruction set, though new instructions can still be added in the future. These eBPF definitions cannot go into uapi/linux/filter.h, since the names may conflict with existing applications. Full eBPF ISA description is in Documentation/networking/filter.txt Signed-off-by:
-
Alexei Starovoitov authored
add BPF_LD_IMM64 instruction to load 64-bit immediate value into a register. All previous instructions were 8-byte. This is first 16-byte instruction. Two consecutive 'struct bpf_insn' blocks are interpreted as single instruction: insn[0].code = BPF_LD | BPF_DW | BPF_IMM insn[0].dst_reg = destination register insn[0].imm = lower 32-bit insn[1].code = 0 insn[1].imm = upper 32-bit All unused fields must be zero. Classic BPF has similar instruction: BPF_LD | BPF_W | BPF_IMM which loads 32-bit immediate value into a register. x64 JITs it as single 'movabsq %rax, imm64' arm64 may JIT as sequence of four 'movk x0, #imm16, lsl #shift' insn Note that old eBPF programs are binary compatible with new interpreter. It helps eBPF programs load 64-bit constant into a register with one instruction instead of using two registers and 4 instructions: BPF_MOV32_IMM(R1, imm32) BPF_ALU64_IMM(BPF_LSH, R1, 32) BPF_MOV32_IMM(R2, imm32) BPF_ALU64_REG(BPF_OR, R1, R2) User space generated programs will use this instruction to load constants only. To tell kernel that user space needs a pointer the _pseudo_ variant of this instruction may be added later, which will use extra bits of encoding to indicate what type of pointer user space is asking kernel to provide. For example 'off' or 'src_reg' fields can be used for such purpose. src_reg = 1 could mean that user space is asking kernel to validate and load in-kernel map pointer. src_reg = 2 could mean that user space needs readonly data section pointer src_reg = 3 could mean that user space needs a pointer to per-cpu local data All such future pseudo instructions will not be carrying the actual pointer as part of the instruction, but rather will be treated as a request to kernel to provide one. The kernel will verify the request_for_a_pointer, then will drop _pseudo_ marking and will store actual internal pointer inside the instruction, so the end result is the interpreter and JITs never see pseudo BPF_LD_IMM64 insns and only operate on generic BPF_LD_IMM64 that loads 64-bit immediate into a register. User space never operates on direct pointers and verifier can easily recognize request_for_pointer vs other instructions. Signed-off-by:
-
- 08 Sep, 2014 2 commits
-
-
David S. Miller authored
Merge tag 'master-2014-09-08' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next John W. Linville says: ==================== pull request: wireless-next 2014-09-08 Please pull this batch of updates intended for the 3.18 stream... For the mac80211 bits, Johannes says: "Not that much content this time. Some RCU cleanups, crypto performance improvements, and various patches all over, rather than listing them one might as well look into the git log instead." For the Bluetooth bits, Gustavo says: "The changes consists of: - Coding style fixes to HCI drivers - Corrupted ack value fix for the H5 HCI driver - A couple of Enhanced L2CAP fixes - Conversion of SMP code to use common L2CAP channel API - Page scan optimizations when using the kernel-side whitelist - Various mac802154 and and ieee802154 6lowpan cleanups - One new Atheros USB ID" For the iwlwifi bits, Emmanuel says: "We have a new big thing coming up which is called Dynamic Queue Allocation (or DQA). This is a completely new way to work with the Tx queues and it requires major refactoring. This is being done by Johannes and Avri. Besides this, Johannes disables U-APSD by default because of APs that would disable A-MPDU if the association supports U-ASPD. Luca contributed to the power area which he was cleaning up on the way while working on CSA. A few more random things here and there." For the Atheros bits, Kalle says: "For ath6kl we had two small fixes and a new SDIO device id. For ath10k the bigger changes are: * support for new firmware version 10.2 (Michal) * spectral scan support (Simon, Sven & Mathias) * export a firmware crash dump file (Ben & me) * cleaning up of pci.c (Michal) * print pci id in all messages, which causes most of the churn (Michal)" Beyond that, we have the usual collection of various updates to ath9k, b43, mwifiex, and wil6210, as well as a few other bits here and there. Please let me know if there are problems! ==================== Signed-off-by:
-
Willem de Bruijn authored
inetpeer sequence numbers are no longer incremented, so no need to check and flush the tree. The function that increments the sequence number was already dead code and removed in in "ipv4: remove unused function" (068a6e18). Remove the code that checks for a change, too. Verifying that v4_seq and v6_seq are never incremented and thus that flush_check compares bp->flush_seq to 0 is trivial. The second part of the change removes flush_check completely even though bp->flush_seq is exactly !0 once, at initialization. This change is correct because the time this branch is true is when bp->root == peer_avl_empty_rcu, in which the branch and inetpeer_invalidate_tree are a NOOP. Signed-off-by:
-
