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
| ||
|
Message-ID: <CAHS8izMGNLM18TF1RCDBfdOXXpqseePA4_27qmQt-FsrFzGfdQ@mail.gmail.com> Date: Sun, 12 Nov 2023 20:54:18 -0800 From: Mina Almasry <almasrymina@...gle.com> To: Jakub Kicinski <kuba@...nel.org> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, linux-kselftest@...r.kernel.org, linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Jesper Dangaard Brouer <hawk@...nel.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, Arnd Bergmann <arnd@...db.de>, David Ahern <dsahern@...nel.org>, Willem de Bruijn <willemdebruijn.kernel@...il.com>, Shuah Khan <shuah@...nel.org>, Sumit Semwal <sumit.semwal@...aro.org>, Christian König <christian.koenig@....com>, Shakeel Butt <shakeelb@...gle.com>, Jeroen de Borst <jeroendb@...gle.com>, Praveen Kaligineedi <pkaligineedi@...gle.com>, Willem de Bruijn <willemb@...gle.com>, Kaiyuan Zhang <kaiyuanz@...gle.com> Subject: Re: [RFC PATCH v3 06/12] memory-provider: dmabuf devmem memory provider On Fri, Nov 10, 2023 at 3:16 PM Jakub Kicinski <kuba@...nel.org> wrote: > > On Sun, 5 Nov 2023 18:44:05 -0800 Mina Almasry wrote: > > +static int mp_dmabuf_devmem_init(struct page_pool *pool) > > +{ > > + struct netdev_dmabuf_binding *binding = pool->mp_priv; > > + > > + if (!binding) > > + return -EINVAL; > > + > > + if (pool->p.flags & PP_FLAG_DMA_MAP || > > + pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > > + return -EOPNOTSUPP; > > This looks backwards, we should _force_ the driver to use the dma > mapping built into the page pool APIs, to isolate the driver from > how the DMA addr actually gets obtained. Right? > > Maybe seeing driver patches would illuminate. The full tree with driver patches is here: https://github.com/torvalds/linux/compare/master...mina:linux:tcpdevmem-v3 This is probably the most relevant patch, it implements POC page-pool support into GVE + devmem support: https://github.com/torvalds/linux/commit/3c27aa21eb3374f2f1677ece6258f046da234443 But, to answer your question, yes, this is a mistake. devmem doesn't need to be mapped, which is why I disabled the flag. Actually what should happen is like you said, we should enforce that PP_FLAG_DMA_MAP is on, and have it be a no-op, so the driver doesn't try to map the devmem on its own. -- Thanks, Mina
Powered by blists - more mailing lists