On Tue, 1 May 2018, Andrew Morton wrote:

On Tue, 24 Apr 2018 12:33:01 -0400 (EDT) Mikulas Patocka [off-list ref] wrote:

quoted

On Tue, 24 Apr 2018, Michal Hocko wrote:

quoted

On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:

quoted

On Tue, 24 Apr 2018, Michal Hocko wrote:

quoted

On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:

quoted

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

Yes, it would be good. You also need to check it in virt_to_phys(), 
virt_to_pfn(), __pa() and maybe some others.

Mikulas