1. 01 2月, 2011 15 次提交
  2. 31 1月, 2011 15 次提交
  3. 30 1月, 2011 8 次提交
    • S
      batman-adv: Make vis info stack traversal threadsafe · 1181e1da
      Sven Eckelmann 提交于
      The batman-adv vis server has to a stack which stores all information
      about packets which should be send later. This stack is protected
      with a spinlock that is used to prevent concurrent write access to it.
      
      The send_vis_packets function has to take all elements from the stack
      and send them to other hosts over the primary interface. The send will
      be initiated without the lock which protects the stack.
      
      The implementation using list_for_each_entry_safe has the problem that
      it stores the next element as "safe ptr" to allow the deletion of the
      current element in the list. The list may be modified during the
      unlock/lock pair in the loop body which may make the safe pointer
      not pointing to correct next element.
      
      It is safer to remove and use the first element from the stack until no
      elements are available. This does not need reduntant information which
      would have to be validated each time the lock was removed.
      Reported-by: NRussell Senior <russell@personaltelco.net>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      1181e1da
    • S
      batman-adv: Remove vis info element in free_info · dda9fc6b
      Sven Eckelmann 提交于
      The free_info function will be called when no reference to the info
      object exists anymore. It must be ensured that the allocated memory
      gets freed and not only the elements which are managed by the info
      object.
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      dda9fc6b
    • S
      batman-adv: Remove vis info on hashing errors · 2674c158
      Sven Eckelmann 提交于
      A newly created vis info object must be removed when it couldn't be
      added to the hash. The old_info which has to be replaced was already
      removed and isn't related to the hash anymore.
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      2674c158
    • E
      net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT · 709b46e8
      Eric W. Biederman 提交于
      SIOCGETSGCNT is not a unique ioctl value as it it maps tio SIOCPROTOPRIVATE +1,
      which unfortunately means the existing infrastructure for compat networking
      ioctls is insufficient.  A trivial compact ioctl implementation would conflict
      with:
      
      SIOCAX25ADDUID
      SIOCAIPXPRISLT
      SIOCGETSGCNT_IN6
      SIOCGETSGCNT
      SIOCRSSCAUSE
      SIOCX25SSUBSCRIP
      SIOCX25SDTEFACILITIES
      
      To make this work I have updated the compat_ioctl decode path to mirror the
      the normal ioctl decode path.  I have added an ipv4 inet_compat_ioctl function
      so that I can have ipv4 specific compat ioctls.   I have added a compat_ioctl
      function into struct proto so I can break out ioctls by which kind of ip socket
      I am using.  I have added a compat_raw_ioctl function because SIOCGETSGCNT only
      works on raw sockets.  I have added a ipmr_compat_ioctl that mirrors the normal
      ipmr_ioctl.
      
      This was necessary because unfortunately the struct layout for the SIOCGETSGCNT
      has unsigned longs in it so changes between 32bit and 64bit kernels.
      
      This change was sufficient to run a 32bit ip multicast routing daemon on a
      64bit kernel.
      Reported-by: NBill Fenner <fenner@aristanetworks.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      709b46e8
    • E
      net: Fix ip link add netns oops · 13ad1774
      Eric W. Biederman 提交于
      Ed Swierk <eswierk@bigswitch.com> writes:
      > On 2.6.35.7
      >  ip link add link eth0 netns 9999 type macvlan
      > where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
      > [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
      >  [10663.821917] IP: [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170
      >  [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
      >  [10663.821944] Oops: 0000 [#1] SMP
      >  [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
      >  [10663.821959] CPU 3
      >  [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class
      >  [10663.822155]
      >  [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
      >  [10663.822167] RIP: 0010:[<ffffffff8149c2fa>] [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170
      >  [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
      >  [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
      >  [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
      >  [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
      >  [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
      >  [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
      >  [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
      >  [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      >  [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
      >  [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      >  [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      >  [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
      >  [10663.822236] Stack:
      >  [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
      >  [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
      >  [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
      >  [10663.822281] Call Trace:
      >  [10663.822290] [<ffffffff814a2bb5>] ? dev_addr_init+0x75/0xb0
      >  [10663.822298] [<ffffffff8149c413>] dev_alloc_name+0x43/0x90
      >  [10663.822307] [<ffffffff814a85ee>] rtnl_create_link+0xbe/0x1b0
      >  [10663.822314] [<ffffffff814ab2aa>] rtnl_newlink+0x48a/0x570
      >  [10663.822321] [<ffffffff814aafcc>] ? rtnl_newlink+0x1ac/0x570
      >  [10663.822332] [<ffffffff81030064>] ? native_x2apic_icr_read+0x4/0x20
      >  [10663.822339] [<ffffffff814a8c17>] rtnetlink_rcv_msg+0x177/0x290
      >  [10663.822346] [<ffffffff814a8aa0>] ? rtnetlink_rcv_msg+0x0/0x290
      >  [10663.822354] [<ffffffff814c25d9>] netlink_rcv_skb+0xa9/0xd0
      >  [10663.822360] [<ffffffff814a8a85>] rtnetlink_rcv+0x25/0x40
      >  [10663.822367] [<ffffffff814c223e>] netlink_unicast+0x2de/0x2f0
      >  [10663.822374] [<ffffffff814c303e>] netlink_sendmsg+0x1fe/0x2e0
      >  [10663.822383] [<ffffffff81488533>] sock_sendmsg+0xf3/0x120
      >  [10663.822391] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20
      >  [10663.822400] [<ffffffff81168656>] ? __d_lookup+0x136/0x150
      >  [10663.822406] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20
      >  [10663.822414] [<ffffffff812b7a0d>] ? _atomic_dec_and_lock+0x4d/0x80
      >  [10663.822422] [<ffffffff8116ea90>] ? mntput_no_expire+0x30/0x110
      >  [10663.822429] [<ffffffff81486ff5>] ? move_addr_to_kernel+0x65/0x70
      >  [10663.822435] [<ffffffff81493308>] ? verify_iovec+0x88/0xe0
      >  [10663.822442] [<ffffffff81489020>] sys_sendmsg+0x240/0x3a0
      > [10663.822450] [<ffffffff8111e2a9>] ? __do_fault+0x479/0x560
      >  [10663.822457] [<ffffffff815899fe>] ? _raw_spin_lock+0xe/0x20
      >  [10663.822465] [<ffffffff8116cf4a>] ? alloc_fd+0x10a/0x150
      >  [10663.822473] [<ffffffff8158d76e>] ? do_page_fault+0x15e/0x350
      >  [10663.822482] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b
      >  [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
      >  [10663.822618] RIP [<ffffffff8149c2fa>] __dev_alloc_name+0x9a/0x170
      >  [10663.822627] RSP <ffff88014aebf7b8>
      >  [10663.822631] CR2: 000000000000006d
      >  [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---
      
      This bug was introduced in:
      commit 81adee47
      Author: Eric W. Biederman <ebiederm@aristanetworks.com>
      Date:   Sun Nov 8 00:53:51 2009 -0800
      
          net: Support specifying the network namespace upon device creation.
      
          There is no good reason to not support userspace specifying the
          network namespace during device creation, and it makes it easier
          to create a network device and pass it to a child network namespace
          with a well known name.
      
          We have to be careful to ensure that the target network namespace
          for the new device exists through the life of the call.  To keep
          that logic clear I have factored out the network namespace grabbing
          logic into rtnl_link_get_net.
      
          In addtion we need to continue to pass the source network namespace
          to the rtnl_link_ops.newlink method so that we can find the base
          device source network namespace.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      
      Where apparently I forgot to add error handling to the path where we create
      a new network device in a new network namespace, and pass in an invalid pid.
      
      Cc: stable@kernel.org
      Reported-by: NEd Swierk <eswierk@bigswitch.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13ad1774
    • S
      caif: bugfix - add caif headers for userspace usage. · 52fe7c9c
      sjur.brandeland@stericsson.com 提交于
      Add caif_socket.h and if_caif.h to the kernel header files
      exported for use by userspace.
      Signed-off-by: NSjur Braendeland <sjur.brandeland@stericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52fe7c9c
    • O
      slcan: fix referenced website in Kconfig help text · c128df73
      Oliver Hartkopp 提交于
      Fix the referenced project website to www.mictronics.de in the Kconfig
      help text for the slcan driver.
      Signed-off-by: NOliver Hartkopp <socketcan@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c128df73
    • H
      gro: Reset dev pointer on reuse · 66c46d74
      Herbert Xu 提交于
      On older kernels the VLAN code may zero skb->dev before dropping
      it and causing it to be reused by GRO.
      
      Unfortunately we didn't reset skb->dev in that case which causes
      the next GRO user to get a bogus skb->dev pointer.
      
      This particular problem no longer happens with the current upstream
      kernel due to changes in VLAN processing.
      
      However, for correctness we should still reset the skb->dev pointer
      in the GRO reuse function in case a future user does the same thing.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66c46d74
  4. 29 1月, 2011 2 次提交