linux-kernel - Re: [PATCH] dma-buf: add no-op stubs when CONFIG_DMA_SHARED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4o3meb52jvgjrtqswpmrgkgjhn4zbzkvmyen4zqrkzeypsthpt@nt4vm7jwqash>
Date: Thu, 27 Nov 2025 13:53:03 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Christian König <christian.koenig@....com>
Cc: Sumit Semwal <sumit.semwal@...aro.org>, linux-media@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dma-buf: add no-op stubs when CONFIG_DMA_SHARED_BUFFER
 is disabled

On 27-11-25, 09:07, Christian König wrote:
> On 11/27/25 08:40, Viresh Kumar wrote:
> > Move several dma-buf function declarations under
> > CONFIG_DMA_SHARED_BUFFER and provide static inline no-op implementations
> > for the disabled case to allow the callers to build when the feature is
> > not compiled in.
> 
> Good point, but which driver actually needs that?

This broke some WIP stuff [1] which isn't posted upstream yet. That's why I
didn't mention anything in the commit log, though I could have added a comment
about that in the non-commit-log part.

> In other words there should be a concrete example of what breaks in the commit message.

There is time for those changes to be posted and not sure if they will be
accepted or not. But either way, this change made sense in general and so I
thought there is nothing wrong to get this upstream right away.

> > +static inline struct dma_buf *dma_buf_get(int fd)
> > +{
> > +	return NULL;
> 
> And here ERR_PTR(-EINVAL).

I am not really sure if this should be EINVAL in this case. EOPNOTSUPP still
makes sense as the API isn't supported.

> > +static inline struct dma_buf *dma_buf_iter_begin(void)
> > +{
> > +	return NULL;
> > +}
> > +
> > +static inline struct dma_buf *dma_buf_iter_next(struct dma_buf *dmbuf)
> > +{
> > +	return NULL;
> > +}
> 
> Those two are only for BPF and not driver use.

Will drop them.

-- 
viresh

[1] https://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git/log/?h=virtio/msg