linux-kernel - Re: [PATCH net-next v17 03/14] netdev: support binding dma-buf to netdevice

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] [day] [month] [year] [list]

Message-ID: <20240809075615.GD3075665@kernel.org>
Date: Fri, 9 Aug 2024 08:56:15 +0100
From: Simon Horman <horms@...nel.org>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Markus Elfring <Markus.Elfring@....de>,
	Mina Almasry <almasrymina@...gle.com>, netdev@...r.kernel.org,
	linux-doc@...r.kernel.org, Daniel Vetter <daniel.vetter@...ll.ch>,
	Kaiyuan Zhang <kaiyuanz@...gle.com>,
	Pavel Begunkov <asml.silence@...il.com>,
	Willem de Bruijn <willemb@...gle.com>, linux-alpha@...r.kernel.org,
	linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
	sparclinux@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-kselftest@...r.kernel.org,
	bpf@...r.kernel.org, linux-media@...r.kernel.org,
	dri-devel@...ts.freedesktop.org,
	LKML <linux-kernel@...r.kernel.org>,
	Andreas Larsson <andreas@...sler.com>,
	Arnd Bergmann <arnd@...db.de>, Bagas Sanjaya <bagasdotme@...il.com>,
	Christian König <christian.koenig@....com>,
	Christoph Hellwig <hch@...radead.org>,
	David Ahern <dsahern@...nel.org>,
	"David S. Miller" <davem@...emloft.net>, David Wei <dw@...idwei.uk>,
	Donald Hunter <donald.hunter@...il.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Harshitha Ramamurthy <hramamurthy@...gle.com>,
	Helge Deller <deller@....de>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Ilias Apalodimas <ilias.apalodimas@...aro.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	Jakub Kicinski <kuba@...nel.org>,
	"James E. J. Bottomley" <James.Bottomley@...senpartnership.com>,
	Jason Gunthorpe <jgg@...pe.ca>,
	Jeroen de Borst <jeroendb@...gle.com>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	Jonathan Corbet <corbet@....net>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Matt Turner <mattst88@...il.com>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	Paolo Abeni <pabeni@...hat.com>,
	Praveen Kaligineedi <pkaligineedi@...gle.com>,
	Richard Henderson <richard.henderson@...aro.org>,
	Shailend Chand <shailend@...gle.com>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Shuah Khan <shuah@...nel.org>,
	Steffen Klassert <steffen.klassert@...unet.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sumit Semwal <sumit.semwal@...aro.org>,
	Taehee Yoo <ap420073@...il.com>,
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
	Yunsheng Lin <linyunsheng@...wei.com>
Subject: Re: [PATCH net-next v17 03/14] netdev: support binding dma-buf to
 netdevice

On Tue, Aug 06, 2024 at 08:39:34AM -0400, Willem de Bruijn wrote:
> Markus Elfring wrote:
> > >> …
> > >>> +++ b/include/net/devmem.h
> > >>> @@ -0,0 +1,115 @@
> > >> …
> > >>> +#ifndef _NET_DEVMEM_H
> > >>> +#define _NET_DEVMEM_H
> > >> …
> > >>
> > >> I suggest to omit leading underscores from such identifiers.
> > >> https://wiki.sei.cmu.edu/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier
> > >>
> > >
> > > I was gonna apply this change, but I ack'd existing files and I find
> > > that all of them include leading underscores, including some very
> > > recently added files like net/core/page_pool_priv.h.
> > >
> > > I would prefer to stick to existing conventions if that's OK, unless
> > > there is widespread agreement to the contrary.
> > 
> > Under which circumstances would you become interested to reduce development risks
> > also according to undefined behaviour?
> > https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior#CC.UndefinedBehavior-ub_106
> 
> This series is following established practice in kernel networking.
> 
> If that conflicts with a C standard, then perhaps that needs to be
> resolved project wide.
> 
> Forcing an individual feature to diverge just brings inconsistency.
> That said, this appears to be inconsistent already.
> 
> Main question is whether this is worth respinning a series already at
> v17 with no more fundamental feedback.

No, from my point of view, it is not.

This really is a trivial and somewhat subjective mater.
I don't think it should hold up a substantial piece of work.