netdev - Re: [PATCH net-next 00/15] afs, rxrpc: Clean up refcounting on afs_cell and afs

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: <3151401.1740661831@warthog.procyon.org.uk>
Date: Thu, 27 Feb 2025 13:10:31 +0000
From: David Howells <dhowells@...hat.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: dhowells@...hat.com, netdev@...r.kernel.org,
    Marc Dionne <marc.dionne@...istor.com>,
    Jakub Kicinski <kuba@...nel.org>,
    "David S. Miller" <davem@...emloft.net>,
    Eric Dumazet <edumazet@...gle.com>,
    Christian Brauner <brauner@...nel.org>,
    linux-afs@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 00/15] afs, rxrpc: Clean up refcounting on afs_cell and afs_server records

Paolo Abeni <pabeni@...hat.com> wrote:

> The remaining patches in this series touch only AFS, I'm unsure if net-next
> if the best target here???

Yeah.  It's tricky as the complete set of patches I would like to post spans
three subsystems.

> The rxrpc follow-up could just wait the upcoming net -> net-next merge.
> AFAICS crypto patches go trough their own tree.

Ah, no.  That doesn't work.  The rxrpc follow-up needs the crypto patches to
even compile and so needs to go through the same tree.

Further, the afs patches in this patchset are also something of a
pre-requisite for the afs part of the rxrpc follow-up.  The problem is that we
have to be able to map back from the address in a challenge packet back to the
managing socket and the server record in order that we can send find the info
to put in the response packet and the key required in order to encrypt it.

This is something that this patchset deals with, as part of fixing some a
couple of very low-probability bugs (hence why I proposed it for net-next
rather than pushing it Linuswards).

If you prefer, I can see about sending all the patches through the vfs tree or
the crypto tree rather than net-next.  Or I can see if I can push this set as
a bug fix through the VFS tree.

David