- 12 Dec, 2013 12 commits
-
-
Olof Johansson authored
Commit c45f812f ('8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature') ended up moving the printout of version[] from something that will be compiled out due to defines, to something that is now evaluated at runtime. That means that what always used to be an access to an __initdata string from non-__init code started showing up as a section mismatch when it didn't before. All other 8390 versions skip __initdata on the version string, and starting to annotate the whole chain of callers with __init seems like more churn than it's worth on this driver, so remove it from etherh.c as well. Fixes: c45f812f ('8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature') Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jerry Chu authored
This patch modifies the GRO stack to avoid the use of "network_header" and associated macros like ip_hdr() and ipv6_hdr() in order to allow an arbitary number of IP hdrs (v4 or v6) to be used in the encapsulation chain. This lays the foundation for various IP tunneling support (IP-in-IP, GRE, VXLAN, SIT,...) to be added later. With this patch, the GRO stack traversing now is mostly based on skb_gro_offset rather than special hdr offsets saved in skb (e.g., skb->network_header). As a result all but the top layer (i.e., the the transport layer) must have hdrs of the same length in order for a pkt to be considered for aggregation. Therefore when adding a new encap layer (e.g., for tunneling), one must check and skip flows (e.g., by setting NAPI_GRO_CB(p)->same_flow to 0) that have a different hdr length. Note that unlike the network header, the transport header can and will continue to be set by the GRO code since there will be at most one "transport layer" in the encap chain. Signed-off-by:
H.K. Jerry Chu <hkchu@google.com> Suggested-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
-
David S. Miller authored
Vlad Yasevich says: ==================== Add packet capture support on macvtap device Change from RFC: - moved to the rx_handler approach. This series adds support for packet capturing on macvtap device. The initial approach was to simply export the capturing code as a function from the core network. While simple, it was not a very architecturally clean approach. The new appraoch is to provide macvtap with its rx_handler which can is attached to the macvtap device itself. Macvlan will simply requeue the packet with an updated skb->dev. BTW, macvlan layer already does this for macvlan devices. So, now macvtap and macvlan have almost the same exact input path. I've toyed with short-circuting the input path for macvtap by returning RX_HANDLER_ANOTHER, but that just made the code more complicated and didn't provide any kind of measurable gain (at least according to netperf and perf runs on the host). To see if there was a performance regression, I ran 1, 2 and 4 netperf STREAM and MAERTS tests agains the VM from both remote host and another guest on the same system. The command ran was netperf -H $host -t $test -l 20 -i 10 -I 95 -c -C The numbers I was getting with the new code were consistently very slightly (1-2%) better then the old code. I don't consider this an improvement, but it's not a regression! :) Running 'perf record' on the host didn't show any new hot spots and cpu utilization stayed about the same. This was better then I expected from simply looking at the code. ==================== Signed-off-by: -
Vlad Yasevich authored
Since now macvlan and macvtap use the same receive and forward handlers, we can remove them completely and use netif_rx and dev_forward_skb() directly. Signed-off-by:
Vlad Yasevich <vyasevic@redhat.com> Signed-off-by:
-
Vlad Yasevich authored
Macvtap device currently doesn not allow a user to capture traffic on due to the fact that it steals the packets from the network stack before the skb->dev is set correctly on the receive side, and that use uses macvlan transmit path directly on the send side. As a result, we never get a change to give traffic to the taps while the correct device is set in the skb. This patch makes macvtap device behave almost exaclty like macvlan. On the send side, we switch to using dev_queue_xmit(). On the receive side, to deliver packets to macvtap, we now use netif_rx and dev_forward_skb just like macvlan. The only differnce now is that macvtap has its own rx_handler which is attached to the macvtap netdev. It is here that we now steal the packet and provide it to the socket. As a result, we can now capture traffic on the macvtap device: tcpdump -i macvtap0 It also gives us the abilit to add tc actions to the macvtap device and actually utilize different bandwidth management queues on output. Signed-off-by:
-
David S. Miller authored
Daniel Borkmann says: ==================== bpf/filter updates This set adds just two minimal helper tools that complement the already available bpf_jit_disasm and complete BPF tooling; plus it adds and an extensive documentation update of filter.txt. Please see individual descriptions for details. ==================== Signed-off-by: -
Daniel Borkmann authored
This patch significantly updates the BPF documentation and describes its internal architecture, Linux extensions, and handling of the kernel's BPF and JIT engine, plus documents how development can be facilitated with the help of bpf_dbg, bpf_asm, bpf_jit_disasm. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
-
Daniel Borkmann authored
There are a couple of valid use cases for a minimal low-level bpf asm like tool, for example, using/linking to libpcap is not an option, the required BPF filters use Linux extensions that are not supported by libpcap's compiler, a filter might be more complex and not cleanly implementable with libpcap's compiler, particular filter codes should be optimized differently than libpcap's internal BPF compiler does, or for security audits of emitted BPF JIT code for prepared set of BPF instructions resp. BPF JIT compiler development in general. Then, in such cases writing such a filter in low-level syntax can be an good alternative, for example, xt_bpf and cls_bpf users might have requirements that could result in more complex filter code, or one that cannot be expressed with libpcap (e.g. different return codes in cls_bpf for flowids on various BPF code paths). Moreover, BPF JIT implementors may wish to manually write test cases in order to verify the resulting JIT image, and thus need low-level access to BPF code generation as well. Therefore, complete the available toolchain for BPF with this small bpf_asm helper tool for the tools/net/ directory. These 3 complementary minimal helper tools round up and facilitate BPF development. Signed-off-by:
-
Daniel Borkmann authored
This patch adds a minimal BPF debugger that "emulates" the kernel's BPF engine (w/o extensions) and allows for single stepping (forwards and backwards through BPF code) or running with >=1 breakpoints through selected or all packets from a pcap file with a provided user filter in order to facilitate verification of a BPF program. When a breakpoint is being hit, it dumps all register contents, decoded instructions and in case of branches both decoded branch targets as well as other useful information. Having this facility is in particular useful to verify BPF programs against given test traffic *before* attaching to a live system. With the general availability of cls_bpf, xt_bpf, socket filters, team driver and e.g. PTP code, all BPF users, quite often a single more complex BPF program is being used. Reasons for a more complex BPF program are primarily to optimize execution time for making a verdict when multiple simple BPF programs are combined into one in order to prevent parsing same headers multiple times. In particular, for cls_bpf that can have various return paths for encoding flowids, and xt_bpf to come to a fw verdict this can be the case. Therefore, as this can result in more complex and harder to debug code, it would be very useful to have this minimal tool for testing purposes. It can also be of help for BPF JIT developers as filters are "test attached" to the kernel on a temporary socket thus triggering a JIT image dump when enabled. The tool uses an interactive libreadline shell with auto-completion and history support. Signed-off-by:
-
Olof Johansson authored
Minor fix for printk format of a phys_addr_t, and the switch of two local functions to static since they're not used outside of the file. Signed-off-by:
-
Olof Johansson authored
Only used locally. Found by sparse. Signed-off-by:
-
Olof Johansson authored
Silences the below warnings when building with ARM_LPAE enabled, which gives longer dma_addr_t by default: drivers/net/ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create': drivers/net/ethernet/ti/davinci_cpdma.c:182:3: warning: passing argument 3 of 'dma_alloc_attrs' from incompatible pointer type [enabled by default] drivers/net/ethernet/ti/davinci_cpdma.c: In function 'desc_phys': drivers/net/ethernet/ti/davinci_cpdma.c:222:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] drivers/net/ethernet/ti/davinci_cpdma.c:223:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Signed-off-by:
-
- 11 Dec, 2013 28 commits
-
-
Matthew Whitehead authored
Removed the shared ei_debug variable. Replaced it by adding u32 msg_enable to the private struct ei_device. Now each 8390 ethernet instance has a per-device logging variable. Changed older style printk() calls to more canonical forms. Tested on: ne, ne2k-pci, smc-ultra, and wd hardware. V4.0 - Substituted pr_info() and pr_debug() for printk() KERN_INFO and KERN_DEBUG V3.0 - Checked for cases where pr_cont() was most appropriate choice. - Changed module parameter from 'debug' to 'msg_enable' because debug was no longer the best description. V2.0 - Changed netif_msg_(drv|probe|ifdown|rx_err|tx_err|tx_queued|intr|rx_status|hw) to netif_(dbg|info|warn|err) where possible. Signed-off-by:
Matthew Whitehead <tedheadster@gmail.com> Signed-off-by:
-
Jiri Benc authored
RFC 4191 states in 3.5: When a host avoids using any non-reachable router X and instead sends a data packet to another router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe each such router X's reachability by sending a single Neighbor Solicitation to that router's address. A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. In any case, these probes MUST be rate-limited to no more than one per minute per router. Currently, when the neighbour corresponding to a router falls into NUD_FAILED, it's never considered again. Introduce a new rt6_nud_state value, RT6_NUD_FAIL_PROBE, which suggests the route should not be used but should be probed with a single NS. The probe is ratelimited by the existing code. To better distinguish meanings of the failure values, rename RT6_NUD_FAIL_SOFT to RT6_NUD_FAIL_DO_RR. Signed-off-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
wangweidong authored
In sctp_err_lookup, goto out while the asoc is not NULL, so remove the check NULL. Also, in sctp_err_finish which called by sctp_v4_err and sctp_v6_err, they pass asoc to sctp_err_finish while the asoc is not NULL, so remove the check. Signed-off-by:
Wang Weidong <wangweidong1@huawei.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Yang Yingliang authored
It already has a NULL pointer judgment of rtab in qdisc_put_rtab(). Remove the judgment outside of qdisc_put_rtab(). Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Nicolas Dichtel authored
Help of this function says: "in_dev: only on this interface, 0=any interface", but since commit 39a6d063 ("[NETNS]: Process inet_confirm_addr in the correct namespace."), the code supposes that it will never be NULL. This function is never called with in_dev == NULL, but it's exported and may be used by an external module. Because this patch restore the ability to call inet_confirm_addr() with in_dev == NULL, I partially revert the above commit, as suggested by Julian. CC: Julian Anastasov <ja@ssi.bg> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
-
Gao feng authored
vxlan_group_used only allows device to leave multicast group when the remote_ip of this vxlan device is difference from other vxlan devices' remote_ip. this will cause device not leave multicast group untile the vn_sock of this vxlan deivce being released. The check in vxlan_group_used is not quite precise. since even the remote_ip is same, but these vxlan devices may use different lower devices, and they may use different vn_socks. Only when some vxlan devices use the same vn_sock,same lower device and same remote_ip, the mc_list of the vn_sock should not be changed. Signed-off-by:
Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by:
-
Gao feng authored
In vxlan_open, vxlan_group_used always returns true, because the state of the vxlan deivces which we want to open has alreay been running. and it has already in vxlan_list. Since ip_mc_join_group takes care of the reference of struct ip_mc_list. removing vxlan_group_used here is safe. Signed-off-by:
-
Rafał Miłecki authored
Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Rafał Miłecki authored
Without this bgmac_adjust_link didn't know it should re-initialize MAC state. This led to the MAC not working after if down & up routine. Signed-off-by:
-
Yang Yingliang authored
SKIP_NONLOCAL hides the control flow. The control flow should be inlined and expanded explicitly in code so that someone who reads it can tell the control flow can be changed by the statement. Signed-off-by:
-
Soren Brinkmann authored
When adjusting the link speed, the target frequency is determined by a 'swith (LINK_SPEED)' statement, that assigns the target rate only for valid and expected LINK_SPEED values. This incomplete switch statement leads to the following build warning: drivers/net/ethernet/cadence/macb.c: In function 'macb_handle_link_change': >> drivers/net/ethernet/cadence/macb.c:241:14: warning: 'rate' may be used uninitialized in this function [-Wmaybe-uninitialized] netdev_warn(dev, "unable to generate target frequency: %ld Hz\n", ^ drivers/net/ethernet/cadence/macb.c:215:13: note: 'rate' was declared here long ferr, rate, rate_rounded; Fixing this by bailing out of that function in the switch's default case before the rate variable is used. Reported-by:kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: cleanups in media and bearer layer This commit series performs a number cleanups in order to make the bearer and media part of the code more comprehensible and manageable. ==================== Signed-off-by: -
Ying Xue authored
In early versions of TIPC it was possible to administratively block individual links through the use of the member flag 'blocked'. This functionality was deemed redundant, and since commit 7368dd ("tipc: clean out all instances of #if 0'd unused code"), this flag has been unused. In the current code, a link only needs to be blocked for sending and reception if it is subject to an ongoing link failover. In that case, it is sufficient to check if the number of expected failover packets is non-zero, something which is done via the funtion 'link_blocked()'. This commit finally removes the redundant 'blocked' flag completely. Signed-off-by:Ying Xue <ying.xue@windriver.com> Reviewed-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Ying Xue authored
Currently TIPC supports two L2 media types, Ethernet and Infiniband. Because both these media are accessed through the common net_device API, several functions in the two media adaptation files turn out to be fully or almost identical, leading to unnecessary code duplication. In this commit we extract this common code from the two media files and move them to the generic bearer.c. Additionally, we change the function names to reflect their real role: to access L2 media, irrespective of type. Signed-off-by:
-
Ying Xue authored
Currently, registering a TIPC stack handler in the network device layer is done twice, once for Ethernet (eth_media) and Infiniband (ib_media) repectively. But, as this registration is not media specific, we can avoid some code duplication by moving the registering function to the generic bearer layer, to the file bearer.c, and call it only once. The same is true for the network device event notifier. As a side effect, the two workqueues we are using for for setting up/ cleaning up media can now be eliminated. Furthermore, the array for storing the specific media type structs, media_array[], can be entirely deleted. Note that the eth_started and ib_started flags were removed during the code relocation. There is now only one call to bearer_setup and bearer_cleanup, and these can logically not race against each other. Despite its size, this cleanup work incurs no functional changes in TIPC. In particular, it should be noted that the sequence ordering of received packets is unaffected by this change, since packet reception never was subject to any work queue handling in the first place. Signed-off-by:
-
Ying Xue authored
TIPC is currently using the field 'af_packet_priv' in struct net_device as a handle to find the bearer instance associated to the given network device. But, by doing so it is blocking other networking cleanups, such as the one discussed here: http://patchwork.ozlabs.org/patch/178044/ This commit removes this usage from TIPC. Instead, we introduce a new field, 'tipc_ptr', to the net_device structure, to serve this purpose. When TIPC bearer is enabled, the bearer object is associated to 'tipc_ptr'. When a TIPC packet arrives in the recv_msg() upcall from a networking device, the bearer object can now be obtained from 'tipc_ptr'. When a bearer is disabled, the bearer object is detached from its underlying network device by setting 'tipc_ptr' to NULL. Additionally, an RCU lock is used to protect the new pointer. Henceforth, the existing tipc_net_lock is used in write mode to serialize write accesses to this pointer, while the new RCU lock is applied on the read side to ensure that the pointer is 100% valid within its wrapped area for all readers. Signed-off-by:
-
Jon Paul Maloy authored
struct 'tipc_media' represents the specific info that the media layer adaptors (eth_media and ib_media) expose to the generic bearer layer. We clarify this by improved commenting, and by giving the 'media_list' array the more appropriate name 'media_info_array'. There are no functional changes in this commit. Signed-off-by:
-
Jon Paul Maloy authored
Communication media types are abstracted through the struct 'tipc_media', one per media type. These structs are allocated statically inside their respective media file. Furthermore, in order to be able to reach all instances from a central location, we keep a static array with pointers to these structs. This array is currently initialized at runtime, under protection of tipc_net_lock. However, since the contents of the array itself never changes after initialization, we can just as well initialize it at compile time and make it 'const', at the same time making it obvious that no lock protection is needed here. This commit makes the array constant and removes the redundant lock protection. Signed-off-by:
-
Ying Xue authored
sk_buff lists are currently relased by looping over the list and explicitly releasing each buffer. We replace all occurrences of this loop with a call to kfree_skb_list(). Signed-off-by:
-
David S. Miller authored
From: Soren Brinkmann <soren.brinkmann@xilinx.com> ==================== net: macb updates I'd really like to have Ethernet working for Zynq, so I want to at least revive this discussion regarding this patchset. And the first four patches should not even be too controversial. I didn't change anything compared to my original RFC submission, except for a typo in one of the commit messages. Handling the tx_clk as optional clock input seems a little bit weird, but it works on my Zynq platform and should be compatible with other users of macb and their DT descriptions. ==================== Signed-off-by: -
Soren Brinkmann authored
Adjust the ethernet clock according to the negotiated link speed. Signed-off-by:
-
Soren Brinkmann authored
Use the device managed interface to request the IRQ, simplifying error paths. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Soren Brinkmann authored
Use the device managed version of ioremap to remap IO memory, simplifying error paths. Signed-off-by:
-
Soren Brinkmann authored
Migrate to using the device managed interface for clocks and clean up the associated error paths. Signed-off-by:
-
Soren Brinkmann authored
Migrate the suspend/resume functions to use the dev_pm_ops PM interface. Signed-off-by:
-
Yang Yingliang authored
Macros with multiple statements should be enclosed in a do - while loop Signed-off-by:
-
Yang Yingliang authored
Spaces required around that '>' (ctx:VxV) and before the open parenthesis '('. Signed-off-by: -
Yang Yingliang authored
"foo* bar" or "foo * bar" should be "foo *bar". Signed-off-by:
-
