Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Jakub Kicinski <kuba@kernel.org>
CC:     "john.fastabend@gmail.com" <john.fastabend@gmail.com>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        "jakub@cloudflare.com" <jakub@cloudflare.com>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "ast@kernel.org" <ast@kernel.org>,
        "andrii@kernel.org" <andrii@kernel.org>,
        "kafai@fb.com" <kafai@fb.com>,
        "songliubraving@fb.com" <songliubraving@fb.com>,
        "yhs@fb.com" <yhs@fb.com>,
        "kpsingh@kernel.org" <kpsingh@kernel.org>,
        netdev <netdev@vger.kernel.org>,
        "bpf@vger.kernel.org" <bpf@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1] net: Add distinct sk_psock field
Thread-Topic: [PATCH v1] net: Add distinct sk_psock field
Thread-Index: AQHYlsSNzQGYXeKSYUuwAiRr7dGBLK19GvcAgADIx4A=
Date:   Thu, 14 Jul 2022 13:50:14 +0000
Message-ID: <B5485F5C-6E83-4186-9664-A8484848DE08@oracle.com>
References: <165772238175.1757.4978340330606055982.stgit@oracle-102.nfsv4.dev>
 <20220713185136.0e3c4fb2@kernel.org>
In-Reply-To: <20220713185136.0e3c4fb2@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?hqxELx4+AtXFFq02nZ582qLHA4+iav79rkAaNLwWnR3xXawvc9P/N0/bAPuB?=
 =?us-ascii?Q?SWl65otnLtN2iB2XAKkxIEhAdQn39alNI1KOC8OB37cOS7vM9e+Sjl2betSc?=
 =?us-ascii?Q?efUHWR28UWqSZkIk1HRACWmC8BO/NFf9CeWM0jE4raNn94NHIdjhVBotI5Zm?=
 =?us-ascii?Q?8dP9pPxXDDLDFXFur+q4aaRIdswgjGAoXWLRsezSAhm1ogdSaJx/yd7eSebq?=
 =?us-ascii?Q?smedoj+gjjv1qLWpf3ogmCPhsyg9i9QTmNOJ7Zzj+UbaLwC92wV6I0wxtHxw?=
 =?us-ascii?Q?tMBLovWLyqauahCjf4NMUe7uNq/2ORkQYcXd3V7nPVhhCmi084WSXTMzTP4J?=
 =?us-ascii?Q?VVkD0hpjo0AePRZ3i6lPDWCJSOP2+UMSlez66BS21+zyVKw8mv6VFJiu8mda?=
 =?us-ascii?Q?5/4apyHDZ4OgVeniQxANb9BkZN/LG4msUbnqorioQUQal2heK5J5SdxOlRYS?=
 =?us-ascii?Q?OOX/mNwBC7k6K8fMmF2ZQ2NUd66gcZOUfc03L7Yhh+yBDaN5NcSLnylw6K2m?=
 =?us-ascii?Q?P6sYul55Qg/INz/EQUSpE5HpzWt2VitrexUsY6wKYQqoCFemXwgQ9gg9rtxv?=
 =?us-ascii?Q?B1ZxIunNTiIUH6VpJPu119dC8w+5S+6DW18mzgsoxeZdJbnldQMQ7NYILOWW?=
 =?us-ascii?Q?HL7WZsKO0V1GKdaPLFNSy5yCbuRI7kX5ICPwvv20xEPEAmKFXBOESCVC785C?=
 =?us-ascii?Q?3xkJ+9vl8E4EFjF6OxhcmmkiAY/OJeG+rVkZPbEaxZrt/ytrbZDTfYw9THc9?=
 =?us-ascii?Q?u+c6OY90RKMrQjaf/Z1EoQC+lrE7uRoXdkmIFf/3nqRdn78Q6PEg8uRhFdAH?=
 =?us-ascii?Q?kzqdRStPvf7vdURTkPnV+bQNNFe5l/+/faqTcDPdPFjYS9X2Q0cQzbva5HNx?=
 =?us-ascii?Q?jmqT1dUJTI/Q0YTe93GsnFxie4VCQbQ1QyUxZTBECqArzNxQ9Qp1pH3BcdbZ?=
 =?us-ascii?Q?+r2NKcYK8JGmp++zzSj0Yb0ptgVozOfeKp0kv+aSSwM6PvSrxgGbQSmciF1l?=
 =?us-ascii?Q?TBwrZavdbtN8UTPM0SvOtzB6cNeuKgSEq9BtOaCi7TRgRsdjHenXbpc5aFeL?=
 =?us-ascii?Q?9SGm7NWsQMCPHyjJrSouZhavX3YHeJNSeSV8/DYRC6NzAnK4NxAg2+KDN9zY?=
 =?us-ascii?Q?eITL4JCAAF4H0Z3gUX2q4N7E/RoDTJykmyiQ+h5a5cH3mgq6Wp4c4J78OBkg?=
 =?us-ascii?Q?XPVeP0DdzQRMDQGbponwm9+DKF6hfcWl+jQ6lQNAhFhGP3NAvqnfkAfJeh9D?=
 =?us-ascii?Q?YK4oQJ+pYSc5JqGTZqvAr9+iDkJrJrmjnyTvSfeyDam5Ad4/7c2McDdhqBtZ?=
 =?us-ascii?Q?+ep2dRU1/0UqfFZQ51fmqChmOboKju0Zj9Pws4dQBMGV2JvQ7D8Mmf99GFMY?=
 =?us-ascii?Q?rTBBGNOnwRXhLYxvZRPcVFAEov0FIFRheGX9kSIwH02qzV/tfNioyR0TVEYH?=
 =?us-ascii?Q?ska1X52zQ88k2K5EAK5RTESVHflGkcls/sS3DPRamOxn+HETMQ4iM+gRObtN?=
 =?us-ascii?Q?YIoAYdRvMLllsv06PJccw7vckU3+0UlJi2fIlvYoYGsacABx23Vp09hAMoiG?=
 =?us-ascii?Q?//vZZkGK7Ty76HgBd83jv8xCfxccqdxSVD8gEy0T+jpycRpf4O2LRybLHERD?=
 =?us-ascii?Q?JA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5AC9529734A66C45AE07AB94E79A752C@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ba86cf83-ef8f-48ae-79ca-08da659fc770
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2022 13:50:14.4402
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: sI92Ch3+vID8/a9mUH7SlcTJiUV0mEQcC93qc/sB8GcEdui5OSSLZi71vTYRxY4pXhGrT2pLQy747clanxmR0w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR10MB2513
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883
 definitions=2022-07-14_10:2022-07-14,2022-07-14 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=999 mlxscore=0
 suspectscore=0 phishscore=0 spamscore=0 malwarescore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2207140058
X-Proofpoint-GUID: OWjD6FKbYl_MEzaYUitI2HMJmSDmt-NJ
X-Proofpoint-ORIG-GUID: OWjD6FKbYl_MEzaYUitI2HMJmSDmt-NJ
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Jul 13, 2022, at 9:51 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>=20
> On Wed, 13 Jul 2022 10:26:21 -0400 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.
>>=20
>> However, kernel socket 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.
>>=20
>> Thus kernel socket consumers and psock currently cannot co-exist.
>>=20
>> 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.
>>=20
>> Move the struct sk_psock address to its own pointer field so that
>> the contents of the sk_user_data field is preserved.
>>=20
>> Reviewed-by: Hannes Reinecke <hare@suse.de>
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>=20
> Thanks for posting separately. We already have the (somewhat
> nondescript) SK_USER_DATA_BPF, can we use another bit for psock?
> Or add a u8 user_data type and have TCP ULP reject if the type is
> anything but psock. I'm not sure why psock is special to deserve=20
> its own pointer.

Hi Jakub, for an informed answer, you will need to ask the folks
who maintain psock. My guess is that kernel consumers might need
to populate both BPF/psock and sk_user_data concurrently for
separate purposes. If concurrent usage is never necessary, then
you can probably get away with a small enumerator that describes
the content of sk_user_data. But after some code auditing it didn't
look to me like that would be adequate.


--
Chuck Lever