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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 21 Apr 2022 09:35:05 +0200 From: Hannes Reinecke <hare@...e.de> To: Chuck Lever <chuck.lever@...cle.com>, netdev@...r.kernel.org, linux-nfs@...r.kernel.org, linux-nvme@...ts.infradead.org, linux-cifs@...r.kernel.org, linux-fsdevel@...r.kernel.org Cc: ak@...pesta-tech.com, borisp@...dia.com, simo@...hat.com Subject: Re: [PATCH RFC 1/5] net: Add distinct sk_psock field On 4/18/22 18:49, Chuck Lever wrote: > The sk_psock facility populates the sk_user_data field with the > address of an extra bit of metadata. User space sockets never > populate the sk_user_data field, so this has worked out fine. > > However, kernel consumers such as the RPC client and server do > populate the sk_user_data field. The sk_psock() function cannot tell > that the content of sk_user_data does not point to psock metadata, > so it will happily return a pointer to something else, cast to a > struct sk_psock. > > Thus kernel consumers and psock currently cannot co-exist. > > We could educate sk_psock() to return NULL if sk_user_data does > not point to a struct sk_psock. However, a more general solution > that enables full co-existence psock and other uses of sk_user_data > might be more interesting. > > Move the struct sk_psock address to its own pointer field so that > the contents of the sk_user_data field is preserved. > > Signed-off-by: Chuck Lever <chuck.lever@...cle.com> > --- > include/linux/skmsg.h | 2 +- > include/net/sock.h | 4 +++- > net/core/skmsg.c | 6 +++--- > 3 files changed, 7 insertions(+), 5 deletions(-) > Reviewed-by: Hannes Reinecke <hare@...e.de> Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@...e.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
Powered by blists - more mailing lists