- 03 Mar, 2015 6 commits
-
-
Joe Perches authored
Use the built-in function instead of memset. Miscellanea: Add #include <linux/etherdevice.h> where appropriate Use ETH_ALEN instead of 6 Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Joe Perches authored
Use the built-in function instead of memset. Signed-off-by:
-
Joe Perches authored
Use the built-in function instead of memset. Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Greg Rose authored
Module dependencies are broken in the case where CONFIG_I40E=y and CONFIG_CONFIGFS_FS=m. This fixes the broken dependency. Signed-off-by:
Greg Rose <gregory.v.rose@intel.com> Signed-off-by:
-
Eric W. Biederman authored
Before the ax25 stack calls dev_queue_xmit it always calls ax25_type_trans which sets skb->protocol to ETH_P_AX25. Which means that by looking at the protocol type it is possible to detect IP packets that have not been munged by the ax25 stack in ndo_start_xmit and call a function to munge them. Rename ax25_neigh_xmit to ax25_ip_xmit and tweak the return type and value to be appropriate for an ndo_start_xmit function. Update all of the ax25 devices to test the protocol type for ETH_P_IP and return ax25_ip_xmit as the first thing they do. This preserves the existing semantics of IP packet processing, but the timing will be a little different as the IP packets now pass through the qdisc layer before reaching the ax25 ip packet processing. Remove the now unnecessary ax25 neighbour table operations. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Fabian Frederick authored
WAIT_FOR_DEMON code is directly undefined at the beginning of signaling.c since initial git version and thus never compiled. This also removes buggy current->state direct access. Suggested-by:
Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
- 02 Mar, 2015 34 commits
-
-
David S. Miller authored
Eric W. Biederman says: ==================== Neighbour table and ax25 cleanups While looking at the neighbour table to what it would take to allow using next hops in a different address family than the current packets I found a partial resolution for my issues and I stumbled upon some work that makes the neighbour table code easier to understand and maintain. Long ago in a much younger kernel ax25 found a hack to use dev_rebuild_header to transmit it's packets instead of going through what today is ndo_start_xmit. When the neighbour table was rewritten into it's current form the ax25 code was such a challenge that arp_broken_ops appeard in arp.c and neigh_compat_output appeared in neighbour.c to keep the ax25 hack alive. With a little bit of work I was able to remove some of the hack that is the ax25 transmit path for ip packets and to isolate what remains into a slightly more readable piece of code in ax25_ip.c. Removing the need for the generic code to worry about ax25 special cases. After cleaning up the old ax25 hacks I also performed a little bit of work on neigh_resolve_output to remove the need for a dst entry and to ensure cached headers get a deterministic protocol value in their cached header. This guarantees that a cached header will not be different depending on which protocol of packet is transmitted, and it allows packets to be transmitted that don't have a dst entry. There remains a small amount of code that takes advantage of when packets have a dst entry but that is something different. ==================== Signed-off-by: -
Eric W. Biederman authored
Having a dst helps a little bit for teql but is fundamentally unnecessary and there are code paths where a dst is not available that it would be nice to use the neighbour cache. Signed-off-by:
-
Eric W. Biederman authored
- Add protocol to neigh_tbl so that dst->ops->protocol is not needed - Acquire the device from neigh->dev This results in a neigh_hh_init that will cache the samve values regardless of the packets flowing through it. Signed-off-by:
-
Eric W. Biederman authored
There are no more callers so kill this function. Signed-off-by:
-
Eric W. Biederman authored
Now that there are no more users kill dev_rebuild_header and all of it's implementations. This is long overdue. Signed-off-by:
-
Eric W. Biederman authored
Have ax25_neigh_output perform ordinary arp resolution before calling ax25_neigh_xmit. Call dev_hard_header in ax25_neigh_output with a destination address so it will not fail, and the destination mac address will not need to be set in ax25_neigh_xmit. Remove arp_find from ax25_neigh_xmit (the ordinary arp resolution added to ax25_neigh_output removes the need for calling arp_find). Document how close ax25_neigh_output is to neigh_resolve_output. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
- Rename ax25_rebuild_header to ax25_neigh_xmit and call it from ax25_neigh_output directly. The rename is to make it clear that this is not a rebuild_header operation. - Remove ax25_rebuild_header from ax25_header_ops. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
The only caller is now is ax25_neigh_construct so move neigh_compat_output into ax25_ip.c make it static and rename it ax25_neigh_output. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
The special case has been pushed out into ax25_neigh_construct so there is no need to keep this code in arp.c Signed-off-by:
-
Eric W. Biederman authored
AX25 already has it's own private arp cache operations to isolate it's abuse of dev_rebuild_header to transmit packets. Add a function ax25_neigh_construct that will allow all of the ax25 devices to force using these operations, so that the generic arp code does not need to. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
The only user is in ax25_ip.c so stop exporting these functions. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
The two sets of header operations are functionally identical remove the duplicate definition. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
The two sets of header operations are functionally identical remove the duplicate definition. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
Patterned after the similar code in net/rom this turns out to be a trivial obviously correct transmformation. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
Not setting the destination address is a bug that I suspect causes no problems today, as only the arp code seems to call dev_hard_header and the description I have of rose is that it is expected to be used with a static neigbour table. I have derived the offset and the length of the rose destination address from rose_rebuild_header where arp_find calls neigh_ha_snapshot to set the destination address. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
In the unlikely (impossible?) event that we attempt to transmit an ax25 packet over a non-ax25 device free the skb so we don't leak it. Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-hams@vger.kernel.org Signed-off-by:
-
Daniel Borkmann authored
Masami noted that it would be better to hide the remaining CONFIG_BPF_SYSCALL-only function declarations within the BPF header ifdef, w/o else path dummy alternatives since these functions are not supposed to have a user outside of CONFIG_BPF_SYSCALL. Suggested-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Reference: http://article.gmane.org/gmane.linux.kernel.api/8658Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next A small batch with accumulated updates in nf-next, mostly IPVS updates, they are: 1) Add 64-bits stats counters to IPVS, from Julian Anastasov. 2) Move NETFILTER_XT_MATCH_ADDRTYPE out of NETFILTER_ADVANCED as docker seem to require this, from Anton Blanchard. 3) Use boolean instead of numeric value in set_match_v*(), from coccinelle via Fengguang Wu. 4) Allows rescheduling of new connections in IPVS when port reuse is detected, from Marcelo Ricardo Leitner. 5) Add missing bits to support arptables extensions from nft_compat, from Arturo Borrero. Patrick is preparing a large batch to enhance the set infrastructure, named expressions among other things, that should follow up soon after this batch. ==================== Signed-off-by: -
Daniel Borkmann authored
Both sk_attach_filter() and sk_attach_bpf() are setting up sk_filter, charging skmem and attaching it to the socket after we got the eBPF prog up and ready. Lets refactor that into a common helper. Signed-off-by:
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2015-03-02 Here's the first bluetooth-next pull request targeting the 4.1 kernel: - ieee802154/6lowpan cleanups - SCO routing to host interface support for the btmrvl driver - AMP code cleanups - Fixes to AMP HCI init sequence - Refactoring of the HCI callback mechanism - Added shutdown routine for Intel controllers in the btusb driver - New config option to enable/disable Bluetooth debugfs information - Fix for early data reception on L2CAP fixed channels Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
David S. Miller authored
Ying Xue says: ==================== net: Remove iocb argument from sendmsg and recvmsg Currently there is only one user - TIPC whose sendmsg() instances using iocb argument. Meanwhile, there is no user using iocb argument in its recvmsg() instance. Therefore, if we eliminate the werid usage of iobc argument from TIPC, the iocb argument can be removed from all sendmsg() and recvmsg() instances of the whole networking stack. Reference: https://patchwork.ozlabs.org/patch/433960/ Changes: v2: * Fix compile errors of DCCP module pointed by David ==================== Signed-off-by:
-
Ying Xue authored
After TIPC doesn't depend on iocb argument in its internal implementations of sendmsg() and recvmsg() hooks defined in proto structure, no any user is using iocb argument in them at all now. Then we can drop the redundant iocb argument completely from kinds of implementations of both sendmsg() and recvmsg() in the entire networking stack. Cc: Christoph Hellwig <hch@lst.de> Suggested-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Ying Xue authored
Currently the iocb argument is used to idenfiy whether or not socket lock is hold before tipc_sendmsg()/tipc_send_stream() is called. But this usage prevents iocb argument from being dropped through sendmsg() at socket common layer. Therefore, in the commit we introduce two new functions called __tipc_sendmsg() and __tipc_send_stream(). When they are invoked, it assumes that their callers have taken socket lock, thereby avoiding the weird usage of iocb argument. Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Reviewed-by:
Erik Hugne <erik.hugne@ericsson.com> Reviewed-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Arturo Borrero authored
This patch adds support to arptables extensions from nft_compat. Signed-off-by:
Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
David S. Miller authored
Eyal Birger says: ==================== net: move skb->dropcount to skb->cb[] Commit 97775007 ("af_packet: add interframe drop cmsg (v6)") unionized skb->mark and skb->dropcount in order to allow recording of the socket drop count while maintaining struct sk_buff size. skb->dropcount was introduced since there was no available room in skb->cb[] in packet sockets. However, its introduction led to the inability to export skb->mark to userspace. It was considered to alias skb->priority instead of skb->mark. However, that would lead to the inabilty to export skb->priority to userspace if desired. Such change may also lead to hard-to-find issues as skb->priority is assumed to be alias free, and, as noted by Shmulik Ladkani, is not 'naturally orthogonal' with other skb fields. This patch series follows the suggestions made by Eric Dumazet moving the dropcount metric to skb->cb[], eliminating this problem at the expense of 4 bytes less in skb->cb[] for protocol families using it. The patch series include compactization of bluetooth and packet use of skb->cb[] as well as the infrastructure for placing dropcount in skb->cb[]. ==================== Signed-off-by:
-
Eyal Birger authored
Commit 97775007 ("af_packet: add interframe drop cmsg (v6)") unionized skb->mark and skb->dropcount in order to allow recording of the socket drop count while maintaining struct sk_buff size. skb->dropcount was introduced since there was no available room in skb->cb[] in packet sockets. However, its introduction led to the inability to export skb->mark, or any other aliased field to userspace if so desired. Moving the dropcount metric to skb->cb[] eliminates this problem at the expense of 4 bytes less in skb->cb[] for protocol families using it. Signed-off-by:
Eyal Birger <eyal.birger@gmail.com> Signed-off-by:
-
Eyal Birger authored
As part of an effort to move skb->dropcount to skb->cb[], use a common function in order to set dropcount in struct sk_buff. Signed-off-by:
-
Eyal Birger authored
As part of an effort to move skb->dropcount to skb->cb[] use a common macro in protocol families using skb->cb[] for ancillary data to validate available room in skb->cb[]. Signed-off-by:
-
Eyal Birger authored
As part of an effort to move skb->dropcount to skb->cb[], 4 bytes of additional room are needed in skb->cb[] in packet sockets. Store the skb original length in the first two fields of sockaddr_ll (sll_family and sll_protocol) as they can be derived from the skb when needed. Signed-off-by:
-
Eyal Birger authored
Commit 3b885787 ("net: Generalize socket rx gap / receive queue overflow cmsg") allowed receiving packet dropcount information as a socket level option. RXRPC sockets recvmsg function was changed to support this by calling sock_recv_ts_and_drops() instead of sock_recv_timestamp(). However, protocol families wishing to receive dropcount should call sock_queue_rcv_skb() or set the dropcount specifically (as done in packet_rcv()). This was not done for rxrpc and thus this feature never worked on these sockets. Formalizing this by not calling sock_recv_ts_and_drops() in rxrpc as part of an effort to move skb->dropcount into skb->cb[] Signed-off-by:
-
Eyal Birger authored
Convert boolean fields incoming and req_start to bit fields and move force_active in order save space in bt_skb_cb in an effort to use a portion of skb->cb[] for storing skb->dropcount. Signed-off-by:
-
Eyal Birger authored
struct hci_req_ctrl is never used outside of struct bt_skb_cb; Inlining it frees 8 bytes on a 64 bit system in skb->cb[] allowing the addition of more ancillary data. Signed-off-by:
Shmulik Ladkani <shmulik.ladkani@gmail.com> Signed-off-by:
-
Simon Farnsworth authored
When a PADT frame is received, the socket may not be in a good state to close down the PPP interface. The current implementation handles this by simply blocking all further PPP traffic, and hoping that the lack of traffic will trigger the user to investigate. Use schedule_work to get to a process context from which we clear down the PPP interface, in a fashion analogous to hangup on a TTY-based PPP interface. This causes pppd to disconnect immediately, and allows tools to take immediate corrective action. Note that pppd's rp_pppoe.so plugin has code in it to disable the session when it disconnects; however, as a consequence of this patch, the session is already disabled before rp_pppoe.so is asked to disable the session. The result is a harmless error message: Failed to disconnect PPPoE socket: 114 Operation already in progress This message is safe to ignore, as long as the error is 114 Operation already in progress; in that specific case, it means that the PPPoE session has already been disabled before pppd tried to disable it. Signed-off-by:
Simon Farnsworth <simon@farnz.org.uk> Tested-by:
Dan Williams <dcbw@redhat.com> Tested-by:
Christoph Schulz <develop@kristov.de> Signed-off-by:
-
Ivan Vecera authored
The bnx2 driver uses .ndo_fix_features to force enable of Rx VLAN tag stripping when the card cannot disable it. The driver should remove NETIF_F_HW_VLAN_CTAG_RX flag from hw_features instead so it is fixed for the ethtool. Cc: Sony Chacko <sony.chacko@qlogic.com> Cc: Dept-HSGLinuxNICDev@qlogic.com Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Signed-off-by:
-
