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

[Andy Shevchenko]

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