On Tue, 24 Apr 2018 12:33:01 -0400 (EDT) Mikulas Patocka <mpatocka@xxxxxxxxxx> 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).
