linux-kernel - Re: [PATCH v2] mm: terminate shrink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJuCfpEvzo1BAAj5AHLFqZnjbQg+s2njkzGBycEWJe1ZHuwO5w@mail.gmail.com>
Date:   Fri, 8 Dec 2017 19:16:28 -0800
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     David Rientjes <rientjes@...gle.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, mhocko@...e.com,
        Johannes Weiner <hannes@...xchg.org>, hillf.zj@...baba-inc.com,
        minchan@...nel.org, mgorman@...hsingularity.net,
        ying.huang@...el.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Tim Murray <timmurray@...gle.com>,
        Todd Kjos <tkjos@...gle.com>
Subject: Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending

On Fri, Dec 8, 2017 at 1:02 PM, David Rientjes <rientjes@...gle.com> wrote:
> On Thu, 7 Dec 2017, Suren Baghdasaryan wrote:
>
>> Slab shrinkers can be quite time consuming and when signal
>> is pending they can delay handling of the signal. If fatal
>> signal is pending there is no point in shrinking that process
>> since it will be killed anyway. This change checks for pending
>> fatal signals inside shrink_slab loop and if one is detected
>> terminates this loop early.
>>
>
> I've proposed a similar patch in the past, but for a check on TIF_MEMDIE,
> which would today be a tsk_is_oom_victim(current), since we had observed
> lengthy stalls in reclaim that would have been prevented if the oom victim
> had exited out, returned back to the page allocator, allocated with
> ALLOC_NO_WATERMARKS, and proceeded to quickly exit.
>
> I'm not sure that all fatal_signal_pending() tasks should get the same
> treatment, but I understand the point that the task is killed and should
> free memory when it fully exits.  How much memory is unknown.
>

Thanks for the input. For my particular use case TIF_MEMDIE check
would not help because I'm trying to kill a process before OOM kicks
in, however the approach is interesting and provides food for thought.

>  > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
>>
>> ---
>> V2:
>> Sergey Senozhatsky:
>>   - Fix missing parentheses
>> ---
>>  mm/vmscan.c | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index c02c850ea349..28e4bdc72c16 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -486,6 +486,13 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>>                       .memcg = memcg,
>>               };
>>
>> +             /*
>> +              * We are about to die and free our memory.
>> +              * Stop shrinking which might delay signal handling.
>> +              */
>> +             if (unlikely(fatal_signal_pending(current)))
>> +                     break;
>> +
>>               /*
>>                * If kernel memory accounting is disabled, we ignore
>>                * SHRINKER_MEMCG_AWARE flag and call all shrinkers