lkml.org 
[lkml]   [2018]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
    On Tue, May 01 2018 at  8:36pm -0400,
    Andrew Morton <akpm@linux-foundation.org> wrote:

    > On Tue, 24 Apr 2018 12:33:01 -0400 (EDT) Mikulas Patocka <mpatocka@redhat.com> wrote:
    >
    > >
    > >
    > > On Tue, 24 Apr 2018, Michal Hocko wrote:
    > >
    > > > On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
    > > > >
    > > > >
    > > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
    > > > >
    > > > > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
    > > > > >
    > > > > > > Fixing __vmalloc code
    > > > > > > is easy and it doesn't require cooperation with maintainers.
    > > > > >
    > > > > > But it is a hack against the intention of the scope api.
    > > > >
    > > > > It is not!
    > > >
    > > > This discussion simply doesn't make much sense it seems. The scope API
    > > > is to document the scope of the reclaim recursion critical section. That
    > > > certainly is not a utility function like vmalloc.
    > >
    > > That 15-line __vmalloc bugfix doesn't prevent you (or any other kernel
    > > developer) from converting the code to the scope API. You make nonsensical
    > > excuses.
    > >
    >
    > Fun thread!
    >
    > Winding back to the original problem, I'd state it as
    >
    > - Caller uses kvmalloc() but passes the address into vmalloc-naive
    > DMA API and
    >
    > - Caller uses kvmalloc() but passes the address into kfree()
    >
    > Yes?

    I think so.

    > If so, then...
    >
    > Is there a way in which, in the kvmalloc-called-kmalloc path, we can
    > tag the slab-allocated memory with a "this memory was allocated with
    > kvmalloc()" flag? I *think* there's extra per-object storage available
    > with suitable slab/slub debugging options? Perhaps we could steal one
    > bit from the redzone, dunno.
    >
    > If so then we can
    >
    > a) set that flag in kvmalloc() if the kmalloc() call succeeded
    >
    > b) check for that flag in the DMA code, WARN if it is set.
    >
    > c) in kvfree(), clear that flag before calling kfree()
    >
    > d) in kfree(), check for that flag and go WARN() if set.
    >
    > So both potential bugs are detected all the time, dependent upon
    > CONFIG_SLUB_DEBUG (and perhaps other slub config options).

    Thanks Andrew, definitely the most sane proposal I've seen to resolve
    this.

    \
     
     \ /
      Last update: 2018-05-02 15:34    [W:4.239 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site