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

Dmitry Torokhov
2026-04-05T03:28:03Z

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