Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 1月, 2008 4 次提交
  3. 24 10月, 2007 1 次提交
  5. 11 10月, 2007 2 次提交
    • R
      [NET]: Nuke SET_MODULE_OWNER macro. · 10d024c1
      由 Ralf Baechle 提交于 
      It's been a useless no-op for long enough in 2.6 so I figured it's time to
remove it.  The number of people that could object because they're
maintaining unified 2.4 and 2.6 drivers is probably rather small.

[ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10d024c1
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      由 Eric W. Biederman 提交于 
      This patch makes most of the generic device layer network
namespace safe.  This patch makes dev_base_head a
network namespace variable, and then it picks up
a few associated variables.  The functions:
dev_getbyhwaddr
dev_getfirsthwbytype
dev_get_by_flags
dev_get_by_name
__dev_get_by_name
dev_get_by_index
__dev_get_by_index
dev_ioctl
dev_ethtool
dev_load
wireless_process_ioctl

were modified to take a network namespace argument, and
deal with it.

vlan_ioctl_set and brioctl_set were modified so their
hooks will receive a network namespace argument.

So basically anthing in the core of the network stack that was
affected to by the change of dev_base was modified to handle
multiple network namespaces.  The rest of the network stack was
simply modified to explicitly use &init_net the initial network
namespace.  This can be fixed when those components of the network
stack are modified to handle multiple network namespaces.

For now the ifindex generator is left global.

Fundametally ifindex numbers are per namespace, or else
we will have corner case problems with migration when
we get that far.

At the same time there are assumptions in the network stack
that the ifindex of a network device won't change.  Making
the ifindex number global seems a good compromise until
the network stack can cope with ifindex changes when
you change namespaces, and the like.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
  7. 27 7月, 2007 1 次提交
    • A
      ip6_tunnel - endianness annotations · 704eae1f
      由 Al Viro 提交于 
      Convert rel_info to host-endian before calling ip6_tnl_err().
The things become much more straightforward that way.
The key observation (and the reason why that code actually
worked) is that after ip6_tnl_err() we either immediately
bailed out or had rel_info set to 0 or had it set to host-endian
and guaranteed to hit
(rel_type == ICMP_DEST_UNREACH && rel_code == ICMP_FRAG_NEEDED)
case.  So inconsistent endianness didn't really lead to bugs,
but it had been subtle and prone to breakage.  New variant is
saner and obviously safe.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      704eae1f
  9. 22 7月, 2007 1 次提交
  11. 11 7月, 2007 1 次提交
  13. 26 4月, 2007 12 次提交
  15. 27 2月, 2007 1 次提交
  17. 14 2月, 2007 1 次提交
  19. 11 2月, 2007 1 次提交
  21. 09 2月, 2007 1 次提交
  23. 03 12月, 2006 9 次提交
  25. 22 11月, 2006 2 次提交
  27. 22 7月, 2006 1 次提交
  29. 01 7月, 2006 1 次提交
  31. 10 4月, 2006 1 次提交
    • H
      [INET]: Move no-tunnel ICMP error to tunnel4/tunnel6 · 50fba2aa
      由 Herbert Xu 提交于 
      This patch moves the sending of ICMP messages when there are no IPv4/IPv6
tunnels present to tunnel4/tunnel6 respectively.  Please note that for now
if xfrm4_tunnel/xfrm6_tunnel is loaded then no ICMP messages will ever be
sent.  This is similar to how we handle AH/ESP/IPCOMP.

This move fixes the bug where we always send an ICMP message when there is
no ip6_tunnel device present for a given packet even if it is later handled
by IPsec.  It also causes ICMP messages to be sent when no IPIP tunnel is
present.

I've decided to use the "port unreachable" ICMP message over the current
value of "address unreachable" (and "protocol unreachable" by GRE) because
it is not ambiguous unlike the other ones which can be triggered by other
conditions.  There seems to be no standard specifying what value must be
used so this change should be OK.  In fact we should change GRE to use
this value as well.

Incidentally, this patch also fixes a fairly serious bug in xfrm6_tunnel
where we don't check whether the embedded IPv6 header is present before
dereferencing it for the inside source address.

This patch is inspired by a previous patch by Hugo Santos <hsantos@av.it.pt>.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50fba2aa