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]

Date:   Sun, 10 Dec 2017 20:37:59 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     mhocko@...nel.org, surenb@...gle.com
Cc:     akpm@...ux-foundation.org, 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,
        timmurray@...gle.com, tkjos@...gle.com
Subject: Re: [PATCH v2] mm: terminate shrink_slab loop if signal is pending

Michal Hocko wrote:
> > > I agree that making waits/loops killable is generally good. But be sure to be
> > > prepared for the worst case. For example, start __GFP_KILLABLE from "best effort"
> > > basis (i.e. no guarantee that the allocating thread will leave the page allocator
> > > slowpath immediately) and check for fatal_signal_pending() only if
> > > __GFP_KILLABLE is set. That is,
> > >
> > > +               /*
> > > +                * We are about to die and free our memory.
> > > +                * Stop shrinking which might delay signal handling.
> > > +                */
> > > +               if (unlikely((gfp_mask & __GFP_KILLABLE) && fatal_signal_pending(current)))
> > > +                       break;
> > >
> > > at shrink_slab() etc. and
> > >
> > > +               if ((gfp_mask & __GFP_KILLABLE) && fatal_signal_pending(current))
> > > +                       goto nopage;
> > >
> > > at __alloc_pages_slowpath().
> > 
> > I was thinking about something similar and will experiment to see if
> > this solves the problem and if it has any side effects. Anyone sees
> > any obvious problems with this approach?
> 
> Tetsuo has been proposing this flag in the past and I've had objections
> why this is not a great idea. I do not have any link handy but the core
> objection was that the semantic would be too fuzzy. All the allocations
> in the same context would have to be killable for this flag to have any
> effect. Spreading it all over the kernel is simply not feasible.
> 

Refusing __GFP_KILLABLE based on "All the allocations in the same context
would have to be killable" does not make sense. Outside of MM, we update
code to use _killable version step by step based on best effort basis.
People don't call efforts to change like

  func1() {
    // As of this point it is easy to bail out.
    if (mutex_lock_killable(&lock1) == 0) {
      func2();
      mutex_unlock(&lock1);
    }
  }

  func2() {
    mutex_lock(&lock2);
    // Do something which is not possible to bail out for now.
    mutex_unlock(&lock2);
  }

pointless.

If you insist on "All the allocations in the same context would
have to be killable", then we will offload all activities to some
kernel thread.