[PATCH RFC 1/5] net: Add distinct sk_psock field

On 4/18/22 18:49, Chuck Lever wrote:

quoted

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 <redacted>
---
  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@suse.de>

Cheers,

Hannes

In Patchwork website, this patch fails the checks on
netdev/cc_maintainers.

So maybe you need CC folks pointed out by
scripts/get_maintainer.pl script, which is suggested
by Jakub Kicinski [off-list ref].

What's more, Syskaller reports
refcount bug in sk_psock_get (2).

In this bug, the problem is that smc and psock, 
both use sk_user_data field to save their 
private data. So they will treat field in their own way.

in smc_switch_to_fallback(), and set smc->clcsock->sk_user_data
to origin smc in smc_fback_replace_callbacks().

Later, sk_psock_get() will treat the smc->clcsock->sk_user_data
as sk_psock type, which triggers the refcnt warning.

I have tested this patch and the reproducer did not trigger any issue.
For more details, you can check the email
[PATCH] smc: fix refcount bug in sk_psock_get (2)