Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM

From: Michal Hocko
Date: Mon Apr 23 2018 - 11:15:59 EST


On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
>
>
> On Sat, 21 Apr 2018, Matthew Wilcox wrote:
>
> > On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > > > No way. This is just wrong! First of all, you will explode most likely
> > > > > > on many allocations of small sizes. Second, CONFIG_DEBUG_VM tends to be
> > > > > > enabled quite often.
> > > > >
> > > > > You're an evil person who doesn't want to fix bugs.
> > > >
> > > > Steady on. There's no need for that. Michal isn't evil. Please
> > > > apologise.
> > >
> > > I see this attitude from Michal again and again.
> >
> > Fine; then *say that*. I also see Michal saying "No" a lot. Sometimes
> > I agree with him, sometimes I don't. I think he genuinely wants the best
> > code in the kernel, and saying "No" is part of it.
> >
> > > He didn't want to fix vmalloc(GFP_NOIO)
> >
> > I don't remember that conversation, so I don't know whether I agree with
> > his reasoning or not. But we are supposed to be moving away from GFP_NOIO
> > towards marking regions with memalloc_noio_save() / restore. If you do
> > that, you won't need vmalloc(GFP_NOIO).
>
> He said the same thing a year ago. And there was small progress. 6 out of
> 27 __vmalloc calls were converted to memalloc_noio_save in a year - 5 in
> infiniband and 1 in btrfs. (the whole discussion is here
> http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04681.html )

Well this is not that easy. It requires a cooperation from maintainers.
I can only do as much. I've posted patches in the past and actively
bringing up this topic at LSFMM last two years...

> He refuses 15-line patch to fix GFP_NOIO bug because he believes that in 4
> years, the kernel will be refactored and GFP_NOIO will be eliminated. Why
> does he have veto over this part of the code? I'd much rather argue with
> people who have constructive comments about fixing bugs than with him.

I didn't NACK the patch AFAIR. I've said it is not a good idea longterm.
I would be much more willing to change my mind if you would back your
patch by a real bug report. Hacks are acceptable when we have a real
issue in hands. But if we want to fix potential issue then better make
it properly.

[...]

> I sent the CONFIG_DEBUG_SG patch before (I wonder why he didn't repond to
> it). I'll send a third version of the patch that actually randomly chooses
> between kmalloc and vmalloc, because some abuses can only be detected with
> kmalloc and we should test both.
>
> For bisecting, it is better to always fallback to vmalloc, but for general
> testing, it is better to test both branches.

Agreed!

--
Michal Hocko
SUSE Labs