1. 16 Mar, 2010 16 commits
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      bridge br_multicast: Don't refer to BR_INPUT_SKB_CB(skb)->mrouters_only without IGMP snooping. · 32dec5dd
      YOSHIFUJI Hideaki / 吉藤英明 authored
      Without CONFIG_BRIDGE_IGMP_SNOOPING,
      BR_INPUT_SKB_CB(skb)->mrouters_only is not appropriately
      initialized, so we can see garbage.
      
      A clear option to fix this is to set it even without that
      config, but we cannot optimize out the branch.
      
      Let's introduce a macro that returns value of mrouters_only
      and let it return 0 without CONFIG_BRIDGE_IGMP_SNOOPING.
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32dec5dd
    • Vitaliy Gusev's avatar
      route: Fix caught BUG_ON during rt_secret_rebuild_oneshot() · 858a18a6
      Vitaliy Gusev authored
      route: Fix caught BUG_ON during rt_secret_rebuild_oneshot()
      
      Call rt_secret_rebuild can cause BUG_ON(timer_pending(&net->ipv4.rt_secret_timer)) in
      add_timer as there is not any synchronization for call rt_secret_rebuild_oneshot()
      for the same net namespace.
      
      Also this issue affects to rt_secret_reschedule().
      
      Thus use mod_timer enstead.
      Signed-off-by: default avatarVitaliy Gusev <vgusev@openvz.org>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      858a18a6
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • Jiri Slaby's avatar
      NET: netpoll, fix potential NULL ptr dereference · 21edbb22
      Jiri Slaby authored
      Stanse found that one error path in netpoll_setup dereferences npinfo
      even though it is NULL. Avoid that by adding new label and go to that
      instead.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Daniel Borkmann <danborkmann@googlemail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Acked-by: chavey@google.com
      Acked-by: default avatarMatt Mackall <mpm@selenic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21edbb22
    • Neil Horman's avatar
      tipc: fix lockdep warning on address assignment · a2f46ee1
      Neil Horman authored
      So in the forward porting of various tipc packages, I was constantly
      getting this lockdep warning everytime I used tipc-config to set a network
      address for the protocol:
      
      [ INFO: possible circular locking dependency detected ]
      2.6.33 #1
      tipc-config/1326 is trying to acquire lock:
      (ref_table_lock){+.-...}, at: [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
      
      but task is already holding lock:
      (&(&entry->lock)->rlock#2){+.-...}, at: [<ffffffffa03150d5>] tipc_ref_lock+0x43/0x63 [tipc]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&(&entry->lock)->rlock#2){+.-...}:
      [<ffffffff8107b508>] __lock_acquire+0xb67/0xd0f
      [<ffffffff8107b78c>] lock_acquire+0xdc/0x102
      [<ffffffff8145471e>] _raw_spin_lock_bh+0x3b/0x6e
      [<ffffffffa03152b1>] tipc_ref_acquire+0xe8/0x11b [tipc]
      [<ffffffffa031433f>] tipc_createport_raw+0x78/0x1b9 [tipc]
      [<ffffffffa031450b>] tipc_createport+0x8b/0x125 [tipc]
      [<ffffffffa030f221>] tipc_subscr_start+0xce/0x126 [tipc]
      [<ffffffffa0308fb2>] process_signal_queue+0x47/0x7d [tipc]
      [<ffffffff81053e0c>] tasklet_action+0x8c/0xf4
      [<ffffffff81054bd8>] __do_softirq+0xf8/0x1cd
      [<ffffffff8100aadc>] call_softirq+0x1c/0x30
      [<ffffffff810549f4>] _local_bh_enable_ip+0xb8/0xd7
      [<ffffffff81054a21>] local_bh_enable_ip+0xe/0x10
      [<ffffffff81454d31>] _raw_spin_unlock_bh+0x34/0x39
      [<ffffffffa0308eb8>] spin_unlock_bh.clone.0+0x15/0x17 [tipc]
      [<ffffffffa0308f47>] tipc_k_signal+0x8d/0xb1 [tipc]
      [<ffffffffa0308dd9>] tipc_core_start+0x8a/0xad [tipc]
      [<ffffffffa01b1087>] 0xffffffffa01b1087
      [<ffffffff8100207d>] do_one_initcall+0x72/0x18a
      [<ffffffff810872fb>] sys_init_module+0xd8/0x23a
      [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b
      
      -> #0 (ref_table_lock){+.-...}:
      [<ffffffff8107b3b2>] __lock_acquire+0xa11/0xd0f
      [<ffffffff8107b78c>] lock_acquire+0xdc/0x102
      [<ffffffff81454836>] _raw_write_lock_bh+0x3b/0x6e
      [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
      [<ffffffffa03141ee>] tipc_deleteport+0x40/0x119 [tipc]
      [<ffffffffa0316e35>] release+0xeb/0x137 [tipc]
      [<ffffffff8139dbf4>] sock_release+0x1f/0x6f
      [<ffffffff8139dc6b>] sock_close+0x27/0x2b
      [<ffffffff811116f6>] __fput+0x12a/0x1df
      [<ffffffff811117c5>] fput+0x1a/0x1c
      [<ffffffff8110e49b>] filp_close+0x68/0x72
      [<ffffffff8110e552>] sys_close+0xad/0xe7
      [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b
      
      Finally decided I should fix this.  Its a straightforward inversion,
      tipc_ref_acquire takes two locks in this order:
      ref_table_lock
      entry->lock
      
      while tipc_deleteport takes them in this order:
      entry->lock (via tipc_port_lock())
      ref_table_lock (via tipc_ref_discard())
      
      when the same entry is referenced, we get the above warning.  The fix is equally
      straightforward.  Theres no real relation between the entry->lock and the
      ref_table_lock (they just are needed at the same time), so move the entry->lock
      aquisition in tipc_ref_acquire down, after we unlock ref_table_lock (this is
      safe since the ref_table_lock guards changes to the reference table, and we've
      already claimed a slot there.  I've tested the below fix and confirmed that it
      clears up the lockdep issue
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Allan Stephens <allan.stephens@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2f46ee1
    • James Chapman's avatar
      l2tp: Fix UDP socket reference count bugs in the pppol2tp driver · c3259c8a
      James Chapman authored
      This patch fixes UDP socket refcnt bugs in the pppol2tp driver.
      
      A bug can cause a kernel stack trace when a tunnel socket is closed.
      
      A way to reproduce the issue is to prepare the UDP socket for L2TP (by
      opening a tunnel pppol2tp socket) and then close it before any L2TP
      sessions are added to it. The sequence is
      
      Create UDP socket
      Create tunnel pppol2tp socket to prepare UDP socket for L2TP
        pppol2tp_connect: session_id=0, peer_session_id=0
      L2TP SCCRP control frame received (tunnel_id==0)
        pppol2tp_recv_core: sock_hold()
        pppol2tp_recv_core: sock_put
      L2TP ZLB control frame received (tunnel_id=nnn)
        pppol2tp_recv_core: sock_hold()
        pppol2tp_recv_core: sock_put
      Close tunnel management socket
        pppol2tp_release: session_id=0, peer_session_id=0
      Close UDP socket
        udp_lib_close: BUG
      
      The addition of sock_hold() in pppol2tp_connect() solves the problem.
      
      For data frames, two sock_put() calls were added to plug a refcnt leak
      per received data frame. The ref that is grabbed at the top of
      pppol2tp_recv_core() must always be released, but this wasn't done for
      accepted data frames or data frames discarded because of bad UDP
      checksums. This leak meant that any UDP socket that had passed L2TP
      data traffic (i.e. L2TP data frames, not just L2TP control frames)
      using pppol2tp would not be released by the kernel.
      
      WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120()
      Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8
      Call Trace:
       [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
       [<c101b871>] ? warn_slowpath_common+0x71/0xd0
       [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
       [<c101b8e3>] ? warn_slowpath_null+0x13/0x20
       [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
       [<c11598a7>] ? sk_common_release+0x17/0x90
       [<c11a5e33>] ? inet_release+0x33/0x60
       [<c11577b0>] ? sock_release+0x10/0x60
       [<c115780f>] ? sock_close+0xf/0x30
       [<c106e542>] ? __fput+0x52/0x150
       [<c106b68e>] ? filp_close+0x3e/0x70
       [<c101d2e2>] ? put_files_struct+0x62/0xb0
       [<c101eaf7>] ? do_exit+0x5e7/0x650
       [<c1081623>] ? mntput_no_expire+0x13/0x70
       [<c106b68e>] ? filp_close+0x3e/0x70
       [<c101eb8a>] ? do_group_exit+0x2a/0x70
       [<c101ebe1>] ? sys_exit_group+0x11/0x20
       [<c10029b0>] ? sysenter_do_call+0x12/0x26
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c3259c8a
    • Steve Glendinning's avatar
      smsc95xx: wait for PHY to complete reset during init · db443c44
      Steve Glendinning authored
      This patch ensures the PHY correctly completes its reset before
      setting register values.
      Signed-off-by: default avatarSteve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db443c44
    • James Chapman's avatar
      l2tp: Fix oops in pppol2tp_xmit · 3feec909
      James Chapman authored
      When transmitting L2TP frames, we derive the outgoing interface's UDP
      checksum hardware assist capabilities from the tunnel dst dev. This
      can sometimes be NULL, especially when routing protocols are used and
      routing changes occur. This patch just checks for NULL dst or dev
      pointers when checking for netdev hardware assist features.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000c
      IP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp]
      *pde = 00000000
      Oops: 0000 [#1] SMP
      last sysfs file: /sys/class/net/lo/operstate
      Modules linked in: pppol2tp pppox ppp_generic slhc ipv6 dummy loop snd_hda_codec_atihdmi snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc evdev psmouse serio_raw processor button i2c_piix4 i2c_core ati_agp agpgart pcspkr ext3 jbd mbcache sd_mod ide_pci_generic atiixp ide_core ahci ata_generic floppy ehci_hcd ohci_hcd libata e1000e scsi_mod usbcore nls_base thermal fan thermal_sys [last unloaded: scsi_wait_scan]
      
      Pid: 0, comm: swapper Not tainted (2.6.32.8 #1)
      EIP: 0060:[<f89d074c>] EFLAGS: 00010297 CPU: 3
      EIP is at pppol2tp_xmit+0x341/0x4da [pppol2tp]
      EAX: 00000000 EBX: f64d1680 ECX: 000005b9 EDX: 00000000
      ESI: f6b91850 EDI: f64d16ac EBP: f6a0c4c0 ESP: f70a9cac
       DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      Process swapper (pid: 0, ti=f70a8000 task=f70a31c0 task.ti=f70a8000)
      Stack:
       000005a9 000005b9 f734c400 f66652c0 f7352e00 f67dc800 00000000 f6b91800
      <0> 000005a3 f70ef6c4 f67dcda9 000005a3 f89b192e 00000246 000005a3 f64d1680
      <0> f63633e0 f6363320 f64d1680 f65a7320 f65a7364 f65856c0 f64d1680 f679f02f
      Call Trace:
       [<f89b192e>] ? ppp_push+0x459/0x50e [ppp_generic]
       [<f89b217f>] ? ppp_xmit_process+0x3b6/0x430 [ppp_generic]
       [<f89b2306>] ? ppp_start_xmit+0x10d/0x120 [ppp_generic]
       [<c11c15cb>] ? dev_hard_start_xmit+0x21f/0x2b2
       [<c11d0947>] ? sch_direct_xmit+0x48/0x10e
       [<c11c19a0>] ? dev_queue_xmit+0x263/0x3a6
       [<c11e2a9f>] ? ip_finish_output+0x1f7/0x221
       [<c11df682>] ? ip_forward_finish+0x2e/0x30
       [<c11de645>] ? ip_rcv_finish+0x295/0x2a9
       [<c11c0b19>] ? netif_receive_skb+0x3e9/0x404
       [<f814b791>] ? e1000_clean_rx_irq+0x253/0x2fc [e1000e]
       [<f814cb7a>] ? e1000_clean+0x63/0x1fc [e1000e]
       [<c1047eff>] ? sched_clock_local+0x15/0x11b
       [<c11c1095>] ? net_rx_action+0x96/0x195
       [<c1035750>] ? __do_softirq+0xaa/0x151
       [<c1035828>] ? do_softirq+0x31/0x3c
       [<c10358fe>] ? irq_exit+0x26/0x58
       [<c1004b21>] ? do_IRQ+0x78/0x89
       [<c1003729>] ? common_interrupt+0x29/0x30
       [<c101ac28>] ? native_safe_halt+0x2/0x3
       [<c1008c54>] ? default_idle+0x55/0x75
       [<c1009045>] ? c1e_idle+0xd2/0xd5
       [<c100233c>] ? cpu_idle+0x46/0x62
      Code: 8d 45 08 f0 ff 45 08 89 6b 08 c7 43 68 7e fb 9c f8 8a 45 24 83 e0 0c 3c 04 75 09 80 63 64 f3 e9 b4 00 00 00 8b 43 18 8b 4c 24 04 <8b> 40 0c 8d 79 11 f6 40 44 0e 8a 43 64 75 51 6a 00 8b 4c 24 08
      EIP: [<f89d074c>] pppol2tp_xmit+0x341/0x4da [pppol2tp] SS:ESP 0068:f70a9cac
      CR2: 000000000000000c
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3feec909
    • Steve Glendinning's avatar
      smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver · d0cad871
      Steve Glendinning authored
      This patch adds a driver for SMSC's LAN7500 family of USB 2.0
      to gigabit ethernet adapters.  It's loosely based on the smsc95xx
      driver but the device registers for LAN7500 are completely different.
      Signed-off-by: default avatarSteve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0cad871
    • Atsushi Nemoto's avatar
      ne: Do not use slashes in irq name string · c5e49fb5
      Atsushi Nemoto authored
      This patch fixes following warning introduced by commit
      12bac0d9 ("proc: warn on non-existing
      proc entries"):
      
      WARNING: at /work/mips-linux/make/linux/fs/proc/generic.c:316 __xlate_proc_name+0xe0/0xe8()
      name 'RBHMA4X00/RTL8019'
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5e49fb5
    • Jiri Slaby's avatar
      NET: ksz884x, fix lock imbalance · edee3932
      Jiri Slaby authored
      Stanse found that one error path (when alloc_skb fails) in netdev_tx
      omits to unlock hw_priv->hwlock. Fix that.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Cc: Tristram Ha <Tristram.Ha@micrel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      edee3932
    • Tilman Schmidt's avatar
      gigaset: correct range checking off by one error · 6ad34145
      Tilman Schmidt authored
      Correct a potential array overrun due to an off by one error in the
      range check on the CAPI CONNECT_REQ CIPValue parameter.
      Found and reported by Dan Carpenter using smatch.
      
      Impact: bugfix
      Signed-off-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ad34145
    • Michael Braun's avatar
      bridge: Fix br_forward crash in promiscuous mode · 7f7708f0
      Michael Braun authored
      From: Michael Braun <michael-dev@fami-braun.de>
      
      bridge: Fix br_forward crash in promiscuous mode
      
      It's a linux-next kernel from 2010-03-12 on an x86 system and it
      OOPs in the bridge module in br_pass_frame_up (called by
      br_handle_frame_finish) because brdev cannot be dereferenced (its set to
      a non-null value).
      
      Adding some BUG_ON statements revealed that
       BR_INPUT_SKB_CB(skb)->brdev == br-dev
      (as set in br_handle_frame_finish first)
      only holds until br_forward is called.
      The next call to br_pass_frame_up then fails.
      
      Digging deeper it seems that br_forward either frees the skb or passes
      it to NF_HOOK which will in turn take care of freeing the skb. The
      same is holds for br_pass_frame_ip. So it seems as if two independent
      skb allocations are required. As far as I can see, commit
      b33084be ("bridge: Avoid unnecessary
      clone on forward path") removed skb duplication and so likely causes
      this crash. This crash does not happen on 2.6.33.
      
      I've therefore modified br_forward the same way br_flood has been
      modified so that the skb is not freed if skb0 is going to be used
      and I can confirm that the attached patch resolves the issue for me.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f7708f0
    • Herbert Xu's avatar
      bridge: Move NULL mdb check into br_mdb_ip_get · 0821ec55
      Herbert Xu authored
      Since all callers of br_mdb_ip_get need to check whether the
      hash table is NULL, this patch moves the check into the function.
      
      This fixes the two callers (query/leave handler) that didn't
      check it.
      Reported-by: default avatarMichael Braun <michael-dev@fami-braun.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0821ec55
    • Lars Ellenberg's avatar
      ISDN: Add PCI ID for HFC-2S/4S Beronet Card PCIe · d00561a2
      Lars Ellenberg authored
      A few subdevice IDs seem to have been dropped when hfc_multi was
      included upstream, just compare the list at
      http://www.openvox.cn/viewvc/misdn/trunk/hfc_multi.c?revision=75&view=annotate#l175
      with the IDs in drivers/isdn/hardware/mISDN/hfcmulti.c
      
      Added PCIe 2 Port card and LED settings (same as PCI)
      Do not use <linux/pci_ids.h> /KKe
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarKarsten Keil <keil@b1-systems.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d00561a2
  2. 15 Mar, 2010 24 commits