1. 29 4月, 2017 6 次提交
  2. 14 4月, 2017 1 次提交
  3. 08 10月, 2016 1 次提交
  4. 04 8月, 2016 1 次提交
  5. 26 5月, 2016 1 次提交
  6. 25 5月, 2016 2 次提交
  7. 14 5月, 2016 2 次提交
  8. 22 3月, 2016 1 次提交
    • E
      IB/core: Support accessing SA in virtualized environment · a0c1b2a3
      Eli Cohen 提交于
      Per the ongoing standardisation process, when virtual HCAs are present
      in a network, traffic is routed based on a destination GID. In order to
      access the SA we use the well known SA GID.
      
      We also add a GRH required boolean field to the port attributes which is
      used to report to the verbs consumer whether this port is connected to a
      virtual network. We use this field to realize whether we need to create
      an address vector with GRH to access the subnet administrator. We clear
      the port attributes struct before calling the hardware driver to make
      sure the default remains that GRH is not required.
      Signed-off-by: NEli Cohen <eli@mellanox.com>
      Reviewed-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      a0c1b2a3
  9. 03 3月, 2016 3 次提交
  10. 22 1月, 2016 1 次提交
    • K
      IB/sa: Fix netlink local service GFP crash · 2deeb477
      Kaike Wan 提交于
      The rdma netlink local service registers a handler to handle RESOLVE
      response and another handler to handle SET_TIMEOUT request. The first
      thing these handlers do is to call netlink_capable() to check the
      access right of the received skb to make sure that the sender has root
      access. Under normal conditions, such responses and requests will be
      directly forwarded to the handlers without going through the netlink_dump
      pathway (see ibnl_rcv_msg() in drivers/infiniband/core/netlink.c).
      However, a user application could send a RESOLVE request (not response)
      to the local service, which will fall into the netlink_dump pathway,
      where a new skb will be created without initializing the control block.
      This new skb will be eventually forwarded to the local service RESOLVE
      response handler. Unfortunately, netlink_capable() will cause general
      protection fault if the skb's control block is not initialized. This
      patch will address the problem by checking the skb first.
      Signed-off-by: NKaike Wan <kaike.wan@intel.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      2deeb477
  11. 20 1月, 2016 1 次提交
  12. 23 12月, 2015 2 次提交
  13. 08 12月, 2015 1 次提交
  14. 07 11月, 2015 1 次提交
    • M
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman 提交于
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      reserves.
      
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      
      This patch then converts a number of sites
      
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: NMel Gorman <mgorman@techsingularity.net>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0164adc
  15. 22 10月, 2015 4 次提交
  16. 03 9月, 2015 1 次提交
  17. 31 8月, 2015 3 次提交
  18. 15 7月, 2015 1 次提交
  19. 13 6月, 2015 1 次提交
  20. 11 6月, 2015 1 次提交
  21. 19 5月, 2015 3 次提交
  22. 11 8月, 2014 1 次提交
  23. 04 6月, 2014 1 次提交
    • R
      IB/mad: Fix sparse warning about gfp_t use · 5343c00d
      Roland Dreier 提交于
      Properly convert gfp_t & result to bool to fix:
      
          drivers/infiniband/core/sa_query.c:621:33: warning: incorrect type in initializer (different base types)
          drivers/infiniband/core/sa_query.c:621:33:    expected bool [unsigned] [usertype] preload
          drivers/infiniband/core/sa_query.c:621:33:    got restricted gfp_t
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      5343c00d