Eric Lee / smarc-fsl-linux-kernel

01 Mar, 2016

1 commit

29 Jan, 2016

1 commit

  • 9b1a12d29   iommu/amd: Correct the wrong setting of alias DTE in do_attach ... Browse Code »

    In below commit alias DTE is set when its peripheral is
    setting DTE. However there's a code bug here to wrongly
    set the alias DTE, correct it in this patch.

    commit e25bfb56ea7f046b71414e02f80f620deb5c6362
    Author: Joerg Roedel
    Date: Tue Oct 20 17:33:38 2015 +0200

    iommu/amd: Set alias DTE in do_attach/do_detach

    Signed-off-by: Baoquan He
    Tested-by: Mark Hounschell
    Cc: stable@vger.kernel.org # v4.4
    Signed-off-by: Joerg Roedel

    Baoquan He
     

07 Jan, 2016

1 commit

29 Dec, 2015

23 commits

07 Nov, 2015

1 commit

  • d0164adc8   mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep an… ... Browse Code »

    …d 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: Mel Gorman <mgorman@techsingularity.net>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Johannes 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: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

    Mel Gorman
     

02 Nov, 2015

1 commit

22 Oct, 2015

1 commit

21 Oct, 2015

8 commits

09 Oct, 2015

1 commit

  • 5adad9915   iommu/amd: Fix NULL pointer deref on device detach ... Browse Code »

    When a device group is detached from its domain, the iommu
    core code calls into the iommu driver to detach each device
    individually.

    Before this functionality went into the iommu core code, it
    was implemented in the drivers, also in the AMD IOMMU
    driver as the device alias handling code.

    This code is still present, as there might be aliases that
    don't exist as real PCI devices (and are therefore invisible
    to the iommu core code).

    Unfortunatly it might happen now, that a device is unbound
    multiple times from its domain, first by the alias handling
    code and then by the iommu core code (or vice verca).

    This ends up in the do_detach function which dereferences
    the dev_data->domain pointer. When the device is already
    detached, this pointer is NULL and we get a kernel oops.

    Removing the alias code completly is not an option, as that
    would also remove the code which handles invisible aliases.
    The code could be simplified, but this is too big of a
    change outside the merge window.

    For now, just check the dev_data->domain pointer in
    do_detach and bail out if it is NULL.

    Reported-by: Andreas Hartmann
    Signed-off-by: Joerg Roedel

    Joerg Roedel
     

14 Aug, 2015

2 commits