linux-kernel - Re: [PATCH] mm/vmscan: make do_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>] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2017 09:27:09 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     jiang.biao2@....com.cn
Cc:     minchan@...nel.org, akpm@...ux-foundation.org, hannes@...xchg.org,
        hillf.zj@...baba-inc.com, ying.huang@...el.com, linux-mm@...ck.org,
        mgorman@...hsingularity.net, linux-kernel@...r.kernel.org,
        zhong.weidong@....com.cn
Subject: Re: [PATCH] mm/vmscan: make do_shrink_slab more robust.

On Mon 27-11-17 15:26:54, jiang.biao2@....com.cn wrote:
> On Mon, Nov 27, 2017 at 02:27:20PM +0800, jiang.biao2@....com.cn wrote:> > I agree with your concern.  How about we take another way by
> > > adding some warning in such case? such as,
> > >         freeable = shrinker->count_objects(shrinker, shrinkctl);
> > > +       if (unlikely(freeable < 0)) {
> > > +               pr_err("shrink_slab: %pF negative objects returned. freeable=%ld\n",
> > > +                       shrinker->scan_objects, freeable);
> > > +               freeable = 0;  //maybe not needed?
> > > +       }
> > >         if (freeable == 0)
> > >                 return 0;
> > > In this way, we would not break the API, but could alert user exception
> > > with message, and make it more robust in such case.
> >
> > True but it would be a problem robust vs. effectivess tradeoff.
> > Think about that everyone want to make thier code robust.
> > It means they start to dump lots of defensive code so code start
> > to look like complicated as well as binary bloating.
> > So, whenever we add some more, we should think how effective
> > the code I am putting?
> > 
> > In this case, I'm skeptical, Sorry. But others might have different
> > opinions. :)
> 
> With all due respect. I still think the robustness is more important than 
> effectiveness in this case. :)

This is a slow path so I wouldn't worry about the performance much. On
the other hand I agree that the API is well documented so adding a
warning is too defensive. We simply assume that the kernel running in
the kernel is reasonable. So I would say, fix your code.

-- 
Michal Hocko
SUSE Labs