1. 20 6月, 2011 3 次提交
  2. 19 6月, 2011 1 次提交
  3. 18 6月, 2011 7 次提交
  4. 17 6月, 2011 13 次提交
  5. 16 6月, 2011 6 次提交
  6. 15 6月, 2011 2 次提交
  7. 14 6月, 2011 3 次提交
  8. 13 6月, 2011 1 次提交
    • H
      IPVS netns exit causes crash in conntrack · 8f4e0a18
      Hans Schillstrom 提交于
      Quote from Patric Mc Hardy
      "This looks like nfnetlink.c excited and destroyed the nfnl socket, but
      ip_vs was still holding a reference to a conntrack. When the conntrack
      got destroyed it created a ctnetlink event, causing an oops in
      netlink_has_listeners when trying to use the destroyed nfnetlink
      socket."
      
      If nf_conntrack_netlink is loaded before ip_vs this is not a problem.
      
      This patch simply avoids calling ip_vs_conn_drop_conntrack()
      when netns is dying as suggested by Julian.
      Signed-off-by: NHans Schillstrom <hans.schillstrom@ericsson.com>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      8f4e0a18
  9. 12 6月, 2011 4 次提交
    • J
      ISDN, hfcsusb: Don't leak in hfcsusb_ph_info() · 84860c72
      Jesper Juhl 提交于
      We leak the memory allocated to 'phi' when the variable goes out of scope
      in hfcsusb_ph_info().
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84860c72
    • D
      netpoll: call dev_put() on error in netpoll_setup() · 83fe32de
      Dan Carpenter 提交于
      There is a dev_put(ndev) missing on an error path.  This was
      introduced in 0c1ad04a "netpoll: prevent netpoll setup on slave
      devices".
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83fe32de
    • M
      net: ep93xx_eth: fix DMA API violations · f1c089e3
      Mika Westerberg 提交于
      Russell King said:
      >
      > So, to summarize what its doing:
      >
      > 1. It allocates buffers for rx and tx.
      > 2. It maps them with dma_map_single().
      >       This transfers ownership of the buffer to the DMA device.
      > 3. In ep93xx_xmit,
      > 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
      >       This violates the DMA buffer ownership rules - the CPU should
      >       not be writing to this buffer while it is (in principle) owned
      >       by the DMA device.
      > 3b. It then calls dma_sync_single_for_cpu() for the buffer.
      >       This transfers ownership of the buffer to the CPU, which surely
      >       is the wrong direction.
      > 4. In ep93xx_rx,
      > 4a. It calls dma_sync_single_for_cpu() for the buffer.
      >       This at least transfers the DMA buffer ownership to the CPU
      >       before the CPU reads the buffer
      > 4b. It then uses skb_copy_to_linear_data() to copy the data out.
      >       At no point does it transfer ownership back to the DMA device.
      > 5. When the driver is removed, it dma_unmap_single()'s the buffer.
      >       This transfers ownership of the buffer to the CPU.
      > 6. It frees the buffer.
      >
      > While it may work on ep93xx, it's not respecting the DMA API rules,
      > and with DMA debugging enabled it will probably encounter quite a few
      > warnings.
      
      This patch fixes these violations.
      Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Tested-by: NPetr Stetiar <ynezz@true.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1c089e3
    • M
      net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent() · 1f758a43
      Mika Westerberg 提交于
      Commit a197b59a (mm: fail GFP_DMA allocations when ZONE_DMA is not
      configured) made page allocator to return NULL if GFP_DMA is set but
      CONFIG_ZONE_DMA is disabled.
      
      This causes ep93xx_eth to fail:
      
       WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
       Modules linked in:
       [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
       [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
       [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
       [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
       [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
       [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
       [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
       [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
       [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
       [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
       [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
       [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
       [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)
      
      Since there is no restrictions for DMA on ep93xx, we can fix this by just
      removing the GFP_DMA flag from the call.
      Signed-off-by: NMika Westerberg <mika.westerberg@iki.fi>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Tested-by: NPetr Stetiar <ynezz@true.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f758a43