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: <20240830105901.27e2e139@kernel.org>
Date: Fri, 30 Aug 2024 10:59:01 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
 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,
 bpf@...r.kernel.org, linux-kselftest@...r.kernel.org,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo
 Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Jonathan Corbet <corbet@....net>, Richard Henderson
 <richard.henderson@...aro.org>, Ivan Kokshaysky <ink@...assic.park.msu.ru>,
 Matt Turner <mattst88@...il.com>, Thomas Bogendoerfer
 <tsbogend@...ha.franken.de>, "James E.J. Bottomley"
 <James.Bottomley@...senpartnership.com>, Helge Deller <deller@....de>,
 Andreas Larsson <andreas@...sler.com>, Jesper Dangaard Brouer
 <hawk@...nel.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>, Steven
 Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Arnd Bergmann
 <arnd@...db.de>, Steffen Klassert <steffen.klassert@...unet.com>, Herbert
 Xu <herbert@...dor.apana.org.au>, David Ahern <dsahern@...nel.org>, Willem
 de Bruijn <willemdebruijn.kernel@...il.com>, Björn Töpel <bjorn@...nel.org>, Magnus Karlsson
 <magnus.karlsson@...el.com>, Maciej Fijalkowski
 <maciej.fijalkowski@...el.com>, Jonathan Lemon <jonathan.lemon@...il.com>,
 Shuah Khan <shuah@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Daniel
 Borkmann <daniel@...earbox.net>, John Fastabend <john.fastabend@...il.com>,
 Sumit Semwal <sumit.semwal@...aro.org>, Christian König
 <christian.koenig@....com>, Pavel Begunkov <asml.silence@...il.com>, David
 Wei <dw@...idwei.uk>, Jason Gunthorpe <jgg@...pe.ca>, Yunsheng Lin
 <linyunsheng@...wei.com>, Shailend Chand <shailend@...gle.com>, Harshitha
 Ramamurthy <hramamurthy@...gle.com>, Shakeel Butt <shakeel.butt@...ux.dev>,
 Jeroen de Borst <jeroendb@...gle.com>, Praveen Kaligineedi
 <pkaligineedi@...gle.com>, Bagas Sanjaya <bagasdotme@...il.com>, Christoph
 Hellwig <hch@...radead.org>, Nikolay Aleksandrov <razor@...ckwall.org>,
 Taehee Yoo <ap420073@...il.com>, Willem de Bruijn <willemb@...gle.com>,
 Kaiyuan Zhang <kaiyuanz@...gle.com>, Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [PATCH net-next v23 03/13] netdev: support binding dma-buf to
 netdevice

On Thu, 29 Aug 2024 22:41:17 -0700 Mina Almasry wrote:
> Thank you, I think the right fix here is to reacquire rtnl_lock before
> the `goto err_unbind;`, since err_unbind expects rtnl to be locked at
> this point.

FWIW it's best to keep the error path a mirror image of the success
path, so I'd add a new label "err_relock" or something. But..

> This could introduce a weird edge case where we drop rtnl_lock, then
> find out genlmsg_reply failed, then reacquire rtnl_lock to do the
> cleanup. I can't think of anything that would horribly break if we do
> that, but I may be missing something. In theory we could race with a
> dmabuf unbind call happening in parallel.
> 
> If we can't reacquire rtnl_lock to do the cleanup, I think I need to
> revert back to doing genlmsg_reply inside of rtnl_lock, and dropping
> the lock before we return from the function.

..indeed, best to keep it atomic. So let's hold rtnl_lock longer.
genlmsg_reply() shouldn't block, AFAIU.

BTW CI is quite behind but Yunsheng ignored it and reposted his
"refactor" which is going to take us another 10 hours back, 
so whatever, just post v24 when you're ready...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ