lkml.org 
[lkml]   [2018]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM
    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?

    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).

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