Re: [PATCH v2 3/4] software node: verify that property data is not on stack

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Mar 31, 2026 at 11:33:10AM +0300, Andy Shevchenko wrote:
> On Tue, Mar 31, 2026 at 11:02:13AM +0300, Andy Shevchenko wrote:
> > On Mon, Mar 30, 2026 at 02:49:52PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 30, 2026 at 01:33:47PM +0300, Andy Shevchenko wrote:
> > > > On Sun, Mar 29, 2026 at 07:27:50PM -0700, Dmitry Torokhov wrote:
> 
> ...
> 
> > > > > +	for (prop = node->properties; prop && prop->name; prop++) {
> > > > > +		if (!prop->is_inline && object_is_on_stack(prop->pointer)) {
> > > > 
> > > > I read more about this... Any code that uses vmalloc() (or potentially may
> > > > switch to it from regular allocator with help of kvalloc() and similar) will
> > > > fail now. While it might be no issue right now, this may become a such. So
> > > > with this check in place you put a requirement that properties can only be
> > > > allocated from a kernel low memory heap and not vm.
> > > 
> > > Can you tell me more about this? As far as I can see it will actually
> > > have false negatives with CONFIG_VMAP_STACK, but should be OK not
> > > trigger with vmalloced memory... But I am genuinely interested to know
> > > more.
> > 
> > I dug into the history of this macro. It was added for the block and ide
> > subsystems to make sure that there is no buffer supplied that may not be DMAed.
> > As we know vmalloc():ed buffers may not be DMAed. In some commit messages
> > it was explicitly mentioned that this macro fails on vmalloc():ed memory.
> > 
> > Note, I haven't checked the actual behaviour by trying that on the HW.
> 
> OTOH, the check itself covers only 16kB of memory range. I don't understand
> how it can give true for anything outside that area...
> 

You probably mean b4a0f533e597 ("dma-api: Teach the "DMA-from-stack"
check about vmapped stacks") but it says that for vmapped stacks
object_is_on_stack() will produce false negative (which is tolerable
here).

I am not sure why object_is_on_stack() was not extended to also handle
this. From the cursory glance it looks like a lot of callsites do not
detect vmapped stacks... Let's add Andy Lutomirski...

Thanks.


-- 
Dmitry