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

Andy Shevchenko
2026-03-31T08:33:17Z

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

--
With Best Regards,
Andy Shevchenko