1. 23 7月, 2005 2 次提交
  2. 20 7月, 2005 1 次提交
  3. 12 7月, 2005 1 次提交
    • S
      [NET]: move config options out to individual protocols · 6a2e9b73
      Sam Ravnborg 提交于
      Move the protocol specific config options out to the specific protocols.
      With this change net/Kconfig now starts to become readable and serve as a
      good basis for further re-structuring.
      
      The menu structure is left almost intact, except that indention is
      fixed in most cases. Most visible are the INET changes where several
      "depends on INET" are replaced with a single ifdef INET / endif pair.
      
      Several new files were created to accomplish this change - they are
      small but serve the purpose that config options are now distributed
      out where they belongs.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a2e9b73
  4. 09 7月, 2005 3 次提交
  5. 06 7月, 2005 3 次提交
  6. 29 6月, 2005 4 次提交
  7. 24 6月, 2005 3 次提交
  8. 22 6月, 2005 7 次提交
  9. 21 6月, 2005 1 次提交
  10. 19 6月, 2005 8 次提交
  11. 14 6月, 2005 2 次提交
    • R
      [IPv6] Don't generate temporary for TUN devices · 77bd9196
      Rémi Denis-Courmont 提交于
      Userland layer-2 tunneling devices allocated through the TUNTAP driver 
      (drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer 
      address. The kernel complains at regular interval when IPv6 Privacy 
      extension are enabled because it can't find an hardware address :
      
      Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00): 
      cannot get EUI64 identifier; use random bytes.
      
      IPv6 Privacy extensions should probably be disabled on that sort of 
      device. They won't work anyway. If userland wants a more usual 
      Ethernet-ish interface with usual IPv6 autoconfiguration, it will use a 
      TAP device with an emulated link-layer  and a random hardware address 
      rather than a TUN device.
      
      As far as I could fine, TUN virtual device from TUNTAP is the very only 
      sort of device using ARPHRD_NONE as kernel device type.
      Signed-off-by: NRmi Denis-Courmont <rdenis@simphalempin.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77bd9196
    • Y
      [IPV6]: Ensure to use icmpv6_socket in non-preemptive context. · 84427d53
      YOSHIFUJI Hideaki 提交于
      We saw following trace several times:
      
      |BUG: using smp_processor_id() in preemptible [00000001] code: httpd/30137
      |caller is icmpv6_send+0x23/0x540
      | [<c01ad63b>] smp_processor_id+0x9b/0xb8
      | [<c02993e7>] icmpv6_send+0x23/0x540
      
      This is because of icmpv6_socket, which is the only one user of
      smp_processor_id() in icmpv6_send(), AFAIK.
      
      Since it should be used in non-preemptive context,
      let's defer the dereference after disabling preemption
      (by icmpv6_xmit_lock()).
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84427d53
  12. 09 6月, 2005 1 次提交
  13. 03 6月, 2005 1 次提交
  14. 30 5月, 2005 1 次提交
  15. 27 5月, 2005 1 次提交
  16. 24 5月, 2005 1 次提交