1. 05 10月, 2015 1 次提交
  2. 29 9月, 2015 1 次提交
    • S
      igb: assume MSI-X interrupts during initialization · cbfe360a
      Stefan Assmann 提交于
      In igb_sw_init() the sequence of calls was changed from
      igb_init_queue_configuration()
      igb_init_interrupt_scheme()
      igb_probe_vfs()
      to
      igb_probe_vfs()
      igb_init_queue_configuration()
      igb_init_interrupt_scheme()
      
      This results in adapter->flags not having the IGB_FLAG_HAS_MSIX bit set
      during igb_probe_vfs()->igb_enable_sriov(). Therefore SR-IOV does not
      get enabled properly and we run into a NULL pointer if the max_vfs
      module parameter is specified (adapter->vf_data does not get allocated,
      crash on accessing the structure).
      
      [    7.419348] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
      [    7.419367] IP: [<ffffffffa02161c6>] igb_reset+0xe6/0x5d0 [igb]
      [    7.419370] PGD 0
      [    7.419373] Oops: 0002 [#1] SMP
      [    7.419381] Modules linked in: ahci(+) libahci igb(+) i40e(+) vxlan ip6_udp_tunnel udp_tunnel megaraid_sas(+) ixgbe(+) mdio
      [    7.419385] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.2.0+ #153
      [    7.419387] Hardware name: Dell Inc. PowerEdge R720/0C4Y3R, BIOS 1.6.0 03/07/2013
      [...]
      [    7.419431] Call Trace:
      [    7.419442]  [<ffffffffa0217236>] igb_probe+0x8b6/0x1340 [igb]
      [    7.419447]  [<ffffffff814c7f15>] local_pci_probe+0x45/0xa0
      
      Prevent this by setting the IGB_FLAG_HAS_MSIX bit before calling
      igb_probe_vfs(). The real interrupt capabilities will be checked during
      igb_init_interrupt_scheme() so this is safe to do.
      Signed-off-by: NStefan Assmann <sassmann@kpanic.de>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cbfe360a
  3. 22 8月, 2015 1 次提交
    • M
      mm: make page pfmemalloc check more robust · 2f064f34
      Michal Hocko 提交于
      Commit c48a11c7 ("netvm: propagate page->pfmemalloc to skb") added
      checks for page->pfmemalloc to __skb_fill_page_desc():
      
              if (page->pfmemalloc && !page->mapping)
                      skb->pfmemalloc = true;
      
      It assumes page->mapping == NULL implies that page->pfmemalloc can be
      trusted.  However, __delete_from_page_cache() can set set page->mapping
      to NULL and leave page->index value alone.  Due to being in union, a
      non-zero page->index will be interpreted as true page->pfmemalloc.
      
      So the assumption is invalid if the networking code can see such a page.
      And it seems it can.  We have encountered this with a NFS over loopback
      setup when such a page is attached to a new skbuf.  There is no copying
      going on in this case so the page confuses __skb_fill_page_desc which
      interprets the index as pfmemalloc flag and the network stack drops
      packets that have been allocated using the reserves unless they are to
      be queued on sockets handling the swapping which is the case here and
      that leads to hangs when the nfs client waits for a response from the
      server which has been dropped and thus never arrive.
      
      The struct page is already heavily packed so rather than finding another
      hole to put it in, let's do a trick instead.  We can reuse the index
      again but define it to an impossible value (-1UL).  This is the page
      index so it should never see the value that large.  Replace all direct
      users of page->pfmemalloc by page_is_pfmemalloc which will hide this
      nastiness from unspoiled eyes.
      
      The information will get lost if somebody wants to use page->index
      obviously but that was the case before and the original code expected
      that the information should be persisted somewhere else if that is
      really needed (e.g.  what SLAB and SLUB do).
      
      [akpm@linux-foundation.org: fix blooper in slub]
      Fixes: c48a11c7 ("netvm: propagate page->pfmemalloc to skb")
      Signed-off-by: NMichal Hocko <mhocko@suse.com>
      Debugged-by: NVlastimil Babka <vbabka@suse.com>
      Debugged-by: NJiri Bohac <jbohac@suse.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: <stable@vger.kernel.org>	[3.6+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f064f34
  4. 19 8月, 2015 7 次提交
  5. 23 7月, 2015 1 次提交
  6. 18 7月, 2015 1 次提交
  7. 26 6月, 2015 1 次提交
  8. 12 5月, 2015 1 次提交
  9. 07 5月, 2015 2 次提交
  10. 04 5月, 2015 1 次提交
  11. 30 3月, 2015 1 次提交
  12. 21 3月, 2015 1 次提交
  13. 23 1月, 2015 5 次提交
  14. 14 1月, 2015 1 次提交
  15. 12 12月, 2014 1 次提交
    • A
      fm10k/igb/ixgbe: Use dma_rmb on Rx descriptor reads · 124b74c1
      Alexander Duyck 提交于
      This change makes it so that dma_rmb is used when reading the Rx
      descriptor.  The advantage of dma_rmb is that it allows for a much
      lower cost barrier on x86, powerpc, arm, and arm64 architectures than a
      traditional memory barrier when dealing with reads that only have to
      synchronize to coherent memory.
      
      In addition I have updated the code so that it just checks to see if any
      bits have been set instead of just the DD bit since the DD bit will always
      be set as a part of a descriptor write-back so we just need to check for a
      non-zero value being present at that memory location rather than just
      checking for any specific bit.  This allows the code itself to appear much
      cleaner and allows the compiler more room to optimize.
      
      Cc: Matthew Vick <matthew.vick@intel.com>
      Cc: Don Skidmore <donald.c.skidmore@intel.com>
      Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      124b74c1
  16. 11 12月, 2014 1 次提交
  17. 09 12月, 2014 1 次提交
  18. 05 12月, 2014 1 次提交
  19. 24 11月, 2014 1 次提交
  20. 17 11月, 2014 1 次提交
  21. 12 11月, 2014 1 次提交
  22. 30 10月, 2014 1 次提交
    • R
      igb: don't reuse pages with pfmemalloc flag · bc16e47f
      Roman Gushchin 提交于
      Incoming packet is dropped silently by sk_filter(), if the skb was
      allocated from pfmemalloc reserves and the corresponding socket is
      not marked with the SOCK_MEMALLOC flag.
      
      Igb driver allocates pages for DMA with __skb_alloc_page(), which
      calls alloc_pages_node() with the __GFP_MEMALLOC flag. So, in case
      of OOM condition, igb can get pages with pfmemalloc flag set.
      
      If an incoming packet hits the pfmemalloc page and is large enough
      (small packets are copying into the memory, allocated with
      netdev_alloc_skb_ip_align(), so they are not affected), it will be
      dropped.
      
      This behavior is ok under high memory pressure, but the problem is
      that the igb driver reuses these mapped pages. So, packets are still
      dropping even if all memory issues are gone and there is a plenty
      of free memory.
      
      In my case, some TCP sessions hang on a small percentage (< 0.1%)
      of machines days after OOMs.
      
      Fix this by avoiding reuse of such pages.
      Signed-off-by: NRoman Gushchin <klamm@yandex-team.ru>
      Tested-by: Aaron Brown "aaron.f.brown@intel.com"
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      bc16e47f
  23. 11 10月, 2014 1 次提交
  24. 02 10月, 2014 3 次提交
  25. 06 9月, 2014 2 次提交
  26. 28 8月, 2014 1 次提交