11 May, 2007
1 commit
-
__udp_lib_port_inuse() cannot make direct references to
inet_sk(sk)->rcv_saddr as that is ipv4 specific state and
this code is used by ipv6 too.Use an operations vector to solve this, and this also paves
the way for ipv6 support for non-wild saddr hashing in UDP.Signed-off-by: David S. Miller
26 Apr, 2007
3 commits
-
When a transmitted packet is looped back directly, CHECKSUM_PARTIAL
maps to the semantics of CHECKSUM_UNNECESSARY. Therefore we should
treat it as such in the stack.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller -
For the places where we need a pointer to the transport header, it is
still legal to touch skb->h.raw directly if just adding to,
subtracting from or setting it to another layer header.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller -
This patch eliminates some duplicate code for the verification of
receive checksums between UDP-Lite and UDP. It does this by
introducing __skb_checksum_complete_head which is identical to
__skb_checksum_complete_head apart from the fact that it takes
a length parameter rather than computing the first skb->len bytes.As a result UDP-Lite will be able to use hardware checksum offload
for packets which do not use partial coverage checksums. It also
means that UDP-Lite loopback no longer does unnecessary checksum
verification.If any NICs start support UDP-Lite this would also start working
automatically.This patch removes the assumption that msg_flags has MSG_TRUNC clear
upon entry in recvmsg.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller
04 Dec, 2006
1 commit
-
Signed-off-by: Al Viro
03 Dec, 2006
5 commits
-
This patch consolidates set/getsockopt code between UDP(-Lite) v4 and 6. The
justification is that UDP(-Lite) is a transport-layer protocol and therefore
the socket option code (at least in theory) should be AF-independent.Furthermore, there is the following code reduplication:
* do_udp{,v6}_getsockopt is 100% identical between v4 and v6
* do_udp{,v6}_setsockopt is identical up to the following differerence
--v4 in contrast to v4 additionally allows the experimental encapsulation
types UDP_ENCAP_ESPINUDP and UDP_ENCAP_ESPINUDP_NON_IKE
--the remainder is identical between v4 and v6
I believe that this difference is of little relevance.The advantages in not duplicating twice almost completely identical code.
The patch further simplifies the interface of udp{,v6}_push_pending_frames,
since for the second argument (struct udp_sock *up) it always holds that
up = udp_sk(sk); where sk is the first function argument.Signed-off-by: Gerrit Renker
Signed-off-by: David S. Miller -
Signed-off-by: Al Viro
Signed-off-by: David S. Miller -
Signed-off-by: Al Viro
Signed-off-by: David S. Miller -
Signed-off-by: Al Viro
Signed-off-by: David S. Miller -
This is a revision of the previously submitted patch, which alters
the way files are organized and compiled in the following manner:* UDP and UDP-Lite now use separate object files
* source file dependencies resolved via header files
net/ipv{4,6}/udp_impl.h
* order of inclusion files in udp.c/udplite.c adapted
accordingly[NET/IPv4]: Support for the UDP-Lite protocol (RFC 3828)
This patch adds support for UDP-Lite to the IPv4 stack, provided as an
extension to the existing UDPv4 code:
* generic routines are all located in net/ipv4/udp.c
* UDP-Lite specific routines are in net/ipv4/udplite.c
* MIB/statistics support in /proc/net/snmp and /proc/net/udplite
* shared API with extensions for partial checksum coverage[NET/IPv6]: Extension for UDP-Lite over IPv6
It extends the existing UDPv6 code base with support for UDP-Lite
in the same manner as per UDPv4. In particular,
* UDPv6 generic and shared code is in net/ipv6/udp.c
* UDP-Litev6 specific extensions are in net/ipv6/udplite.c
* MIB/statistics support in /proc/net/snmp6 and /proc/net/udplite6
* support for IPV6_ADDRFORM
* aligned the coding style of protocol initialisation with af_inet6.c
* made the error handling in udpv6_queue_rcv_skb consistent;
to return `-1' on error on all error cases
* consolidation of shared code[NET]: UDP-Lite Documentation and basic XFRM/Netfilter support
The UDP-Lite patch further provides
* API documentation for UDP-Lite
* basic xfrm support
* basic netfilter support for IPv4 and IPv6 (LOG target)Signed-off-by: Gerrit Renker
Signed-off-by: David S. Miller
23 Sep, 2006
2 commits
-
This also kills a warning while building ipv6:
net/ipv6/udp.c: In function ‘udp_v6_get_port’:
net/ipv6/udp.c:66: warning: passing argument 3 of ‘udp_get_port’ from incompatible pointer typeSigned-off-by: David S. Miller
-
This patch creates one common function which is called by
udp_v4_get_port() and udp_v6_get_port(). As a result,
* duplicated code is removed
* udp_port_rover and local port lookup can now be removed from udp.h
* further savings follow since the same function will be used by UDP-Litev4
and UDP-Litev6In contrast to the patch sent in response to Yoshifujis comments
(fixed by this variant), the code below also removes the
EXPORT_SYMBOL(udp_port_rover), since udp_port_rover can now remain
local to net/ipv4/udp.c.Signed-off-by: Gerrit Renker
Signed-off-by: David S. Miller
04 Jan, 2006
1 commit
-
To help in reducing the number of include dependencies, several files were
touched as they were getting needed headers indirectly for stuff they use.Thanks also to Alan Menegotto for pointing out that net/dccp/proto.c had
linux/dccp.h include twice.Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
30 Aug, 2005
1 commit
-
Of this type, mostly:
CHECK net/ipv6/netfilter.c
net/ipv6/netfilter.c:96:12: warning: symbol 'ipv6_netfilter_init' was not declared. Should it be static?
net/ipv6/netfilter.c:101:6: warning: symbol 'ipv6_netfilter_fini' was not declared. Should it be static?Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: David S. Miller
06 May, 2005
1 commit
-
Ross moved. Remove the bad email address so people will find the correct
one in ./CREDITS.Signed-off-by: Jesper Juhl
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
