1. 25 Sep, 2009 36 commits
  2. 24 Sep, 2009 4 commits
    • Johannes Berg's avatar
      genetlink: fix netns vs. netlink table locking (2) · b8273570
      Johannes Berg authored
      Similar to commit d136f1bd,
      there's a bug when unregistering a generic netlink family,
      which is caught by the might_sleep() added in that commit:
      
          BUG: sleeping function called from invalid context at net/netlink/af_netlink.c:183
          in_atomic(): 1, irqs_disabled(): 0, pid: 1510, name: rmmod
          2 locks held by rmmod/1510:
           #0:  (genl_mutex){+.+.+.}, at: [<ffffffff8138283b>] genl_unregister_family+0x2b/0x130
           #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff8138270c>] __genl_unregister_mc_group+0x1c/0x120
          Pid: 1510, comm: rmmod Not tainted 2.6.31-wl #444
          Call Trace:
           [<ffffffff81044ff9>] __might_sleep+0x119/0x150
           [<ffffffff81380501>] netlink_table_grab+0x21/0x100
           [<ffffffff813813a3>] netlink_clear_multicast_users+0x23/0x60
           [<ffffffff81382761>] __genl_unregister_mc_group+0x71/0x120
           [<ffffffff81382866>] genl_unregister_family+0x56/0x130
           [<ffffffffa0007d85>] nl80211_exit+0x15/0x20 [cfg80211]
           [<ffffffffa000005a>] cfg80211_exit+0x1a/0x40 [cfg80211]
      
      Fix in the same way by grabbing the netlink table lock
      before doing rcu_read_lock().
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8273570
    • Anton Vorontsov's avatar
      3c59x: Get rid of "Trying to free already-free IRQ" · 704cc92e
      Anton Vorontsov authored
      Following trace pops up if we try to suspend with 3c59x ethernet NIC
      brought down:
      
        root@b1:~# ifconfig eth16 down
        root@b1:~# echo mem > /sys/power/state
        ...
        3c59x 0000:00:10.0: suspend
        3c59x 0000:00:10.0: PME# disabled
        Trying to free already-free IRQ 48
        ------------[ cut here ]------------
        Badness at c00554e4 [verbose debug info unavailable]
        NIP: c00554e4 LR: c00554e4 CTR: c019a098
        REGS: c7975c60 TRAP: 0700   Not tainted  (2.6.31-rc4)
        MSR: 00021032 <ME,CE,IR,DR>  CR: 28242422  XER: 20000000
        TASK = c79cb0c0[1746] 'bash' THREAD: c7974000
        ...
        NIP [c00554e4] __free_irq+0x108/0x1b0
        LR [c00554e4] __free_irq+0x108/0x1b0
        Call Trace:
        [c7975d10] [c00554e4] __free_irq+0x108/0x1b0 (unreliable)
        [c7975d30] [c005559c] free_irq+0x10/0x24
        [c7975d40] [c01e21ec] vortex_suspend+0x70/0xc4
        [c7975d60] [c017e584] pci_legacy_suspend+0x58/0x100
      
      This is because the driver manages interrupts without checking for
      netif_running().
      
      Though, there are few other issues with suspend/resume in this driver.
      The intention of calling free_irq() in suspend() was to avoid any
      possible spurious interrupts (see commit 5b039e68
      "3c59x PM fixes"). But,
      
      - On resume, the driver was requesting IRQ just after pci_set_master(),
        but before vortex_up() (which actually resets 3c59x chips).
      
      - Issuing free_irq() on a shared IRQ doesn't guarantee that a buggy
        HW won't trigger spurious interrupts in another driver that
        requested the same interrupt. So, if we want to protect from
        unexpected interrupts, then on suspend we should issue disable_irq(),
        not free_irq().
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      704cc92e
    • Eric Dumazet's avatar
      tunnel: eliminate recursion field · a43912ab
      Eric Dumazet authored
      It seems recursion field from "struct ip_tunnel" is not anymore needed.
      recursion prevention is done at the upper level (in dev_queue_xmit()),
      since we use HARD_TX_LOCK protection for tunnels.
      
      This avoids a cache line ping pong on "struct ip_tunnel" : This structure
      should be now mostly read on xmit and receive paths.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a43912ab
    • Sebastian Haas's avatar
      ems_pci: fix size of CAN controllers BAR mapping for CPC-PCI v2 · edf42a27
      Sebastian Haas authored
      The driver mapped only 128 bytes of the CAN controller address space when a
      CPC-PCI v2 was detected (incl. CPC-104P). This patch will fix it by always
      mapping the whole address space (4096 bytes on all boards) of the
      corresponding PCI BAR.
      Signed-off-by: default avatarSebastian Haas <haas@ems-wuensche.com>
      Signed-off-by: default avatarWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      edf42a27