- 03 Mar, 2015 2 commits
-
-
Florian Westphal authored
bridge reject handling is not straightforward, there are many subtle differences depending on configuration. skb->dev is either the bridge port (PRE_ROUTING) or the bridge itself (INPUT), so we need to use indev instead. Also, checksum validation will only work reliably if we trim skb according to the l3 header size. While at it, add csum validation for ipv6 and skip existing tests if skb was already checked e.g. by GRO. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Florian Westphal authored
tcp resets are never emitted if the packet that triggers the reject/reset has an invalid checksum. For icmp error responses there was no such check. It allows to distinguish icmp response generated via iptables -I INPUT -p udp --dport 42 -j REJECT and those emitted by network stack (won't respond if csum is invalid, REJECT does). Arguably its possible to avoid this by using conntrack and only using REJECT with -m conntrack NEW/RELATED. However, this doesn't work when connection tracking is not in use or when using nf_conntrack_checksum=0. Furthermore, sending errors in response to invalid csums doesn't make much sense so just add similar test as in nf_send_reset. Validate csum if needed and only send the response if it is ok. Reference: http://bugzilla.redhat.com/show_bug.cgi?id=1169829Signed-off-by:
-
- 02 Mar, 2015 37 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:David S. Miller <davem@davemloft.net>
-
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" <ebiederm@xmission.com> 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:
-
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:
-
Arun Chandran authored
Add *_SIZE macros for the bits ENDIA_DESC and ENDIA_PKT Signed-off-by:
Arun Chandran <achandran@mvista.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Arun Chandran authored
Program management descriptor's access mode according to the dynamically detected CPU endianness. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Shrikrishna Khare authored
Allows for packet parsing to be done by the fast path. This performance optimization already exists for IPv4. Add similar logic for IPv6. Signed-off-by:
Amitabha Banerjee <banerjeea@vmware.com> Signed-off-by:
Shrikrishna Khare <skhare@vmware.com> Signed-off-by:
-
- 01 Mar, 2015 1 commit
-
-
David S. Miller authored
Daniel Borkmann says: ==================== eBPF support for cls_bpf This is the non-RFC version of my patchset posted before netdev01 [1] conference. It contains a couple of eBPF cleanups and preparation patches to get eBPF support into cls_bpf. The last patch adds the actual support. I'll post the iproute2 parts after the kernel bits are merged, an initial preview link to the code is mentioned in the last patch. Patch 4 and 5 were originally one patch, but I've split them into two parts upon request as patch 4 only is also needed for Alexei's tracing patches that go via tip tree. Tested with tc and all in-kernel available BPF test suites. I have configured and built LLVM with --enable-experimental-targets=BPF but as Alexei put it, the plan is to get rid of the experimental status in future [2]. Thanks a lot! v1 -> v2: - Removed arch patches from this series - x86 is already queued in tip tree, under x86/mm - arm64 just reposted directly to arm folks - Rest is unchanged [1] http://thread.gmane.org/gmane.linux.network/350191 [2] http://article.gmane.org/gmane.linux.kernel/1874969 ==================== Signed-off-by:
-
