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

[Dmitry Torokhov]

On Sat, Apr 04, 2026 at 08:27:58PM -0700, Dmitry Torokhov wrote:
> 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...

Grr... now for real...

-- 
Dmitry