Граф коммитов

13 Коммитов

Автор SHA1 Сообщение Дата
Arnaldo Carvalho de Melo 27a884dc3c [SK_BUFF]: Convert skb->tail to sk_buff_data_t
So that it is also an offset from skb->head, reduces its size from 8 to 4 bytes
on 64bit architectures, allowing us to combine the 4 bytes hole left by the
layer headers conversion, reducing struct sk_buff size to 256 bytes, i.e. 4
64byte cachelines, and since the sk_buff slab cache is SLAB_HWCACHE_ALIGN...
:-)

Many calculations that previously required that skb->{transport,network,
mac}_header be first converted to a pointer now can be done directly, being
meaningful as offsets or pointers.

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-25 22:26:28 -07:00
Arnaldo Carvalho de Melo eddc9ec53b [SK_BUFF]: Introduce ip_hdr(), remove skb->nh.iph
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-04-25 22:25:10 -07:00
YOSHIFUJI Hideaki e905a9edab [NET] IPV4: Fix whitespace errors.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-10 23:19:39 -08:00
Julian Anastasov bb831eb202 [IPVS]: More endianness fixed.
- make sure port in FTP data is in network order (in fact it was looking
buggy for big endian boxes before Viro's changes)
- htonl -> htons for port

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-11-10 14:57:37 -08:00
Al Viro 5e7ddac75d [PATCH] ptrdiff_t is %t, not %z
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-10 15:37:23 -07:00
Al Viro 96d2ca4ec0 [IPVS] bug: endianness breakage in ip_vs_ftp
(p[3]<<24) | (p[2]<<16) | (p[1]<<8) | p[0] is not a valid
way to spell get_unaligned((__be32 *)p

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-28 18:03:05 -07:00
Al Viro 014d730d56 [IPVS]: ipvs annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-28 18:03:04 -07:00
Simon Horman 28b06c380f [IPVS]: Make sure ip_vs_ftp ports are valid: module_param_array approach
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ensures that
the port values are unsigned short values, and thus always valid.

This is a second take at fixing this problem, it is simpler
and arguably more correct than the previous approach
that was committed as 3f5af5b353.
Prior to this patch a patch that reverses
3f5af5b353 was sent.

Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-28 18:02:56 -07:00
Simon Horman e44fd82caf [IPVS]: Reverse valid ip_vs_ftp ports fix: port check approach
This patch reverses 3f5af5b353 as
a better fix was suggested by Patrick McHardy.

Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-28 18:02:55 -07:00
Simon Horman b552216ff1 [IPVS]: remove the debug option go ip_vs_ftp
This patch makes the debuging behaviour of this code more consistent
with the rest of IPVS.

Signed-Off-By: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-17 23:21:06 -07:00
Simon Horman 3f5af5b353 [IPVS]: Make sure ip_vs_ftp ports are valid
I'm not entirely sure what happens in the case of a valid port,
at best it'll be silently ignored. This patch ignores them a little
more verbosely.

Signed-Off-By: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-17 23:21:05 -07:00
Simon Horman 70e76b768b [IPVS]: auto-help for ip_vs_ftp
Fill in a help message for the ports option to ip_vs_ftp

Signed-Off-By: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-17 23:21:04 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00