From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2397C2A1AA for ; Tue, 7 Nov 2023 22:23:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="izoEPk39" Received: from mail-pg1-x54a.google.com (mail-pg1-x54a.google.com [IPv6:2607:f8b0:4864:20::54a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8010B11C for ; Tue, 7 Nov 2023 14:23:22 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-5b7fb057153so4975173a12.1 for ; Tue, 07 Nov 2023 14:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699395802; x=1700000602; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=0Pmozh0ybI7SbfNg64kEULMiwr3zKJkFxXH8jQ6gCVM=; b=izoEPk39tqUfOifZkL9mKfl1YAU7GCXRX/ZXJXZRdlk+1UH2+aWafH+4gnT8MnBwdC +ASbrpYY5N55torcG421dxWhTV7MlYXPxEh5e+e3Ws3IWrtjPKS3pC9wqWJudPuRD6Nx sl0ICx5rQ2VCQVdIuEQ6IUatHJE7zHCE14Sw0o3nSIqyHaGQSkhrm2zMd9edZUqxqPTc 23p/J4VlnYYqkYtx1bfuffQ9KG/gcdhsPsH1hsSA1e5f/FMDubp992lKv0HoI1ZivSJW QZNieQvsuMR9zN4pa/mES1gpDpL9xCyKp2xy6AXbpfHOtIwz57BYwQUGaxDsn2tBTCRz azow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699395802; x=1700000602; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=0Pmozh0ybI7SbfNg64kEULMiwr3zKJkFxXH8jQ6gCVM=; b=cAUBflQNDyIo9vMCFHhMM3hgE6bUGITpUp49Dp2OKNaWp2r8xIjllSDqkUXSot5Vzu Qv72rPUO+rSJimizPVZVgfuXUCboFvpAlN6Phh3Vot+vyKqQmPyL91lqZTmJ211/sWus 1F4vdjflb0Vzxw0XgB5y04mCjnIK4ZwBHA3Ji2kr5Rij63wYxloKxZZVWKV1DvB37Kll YvGxtuyROZMlKLOlKt1zuwz1FbltmKq/Xvcnt358zaqFe/igt4hiWY79qNb9EW9Y1yHj CLYMy9jC4cYYFsA0A3yKAjXq67kMi9UTFFn1oHTzQOPDNnXuZxWVdm5kFOl4vOW3ftYK ImHQ== X-Gm-Message-State: AOJu0Yxr91xWggex9xgBpfW+Uw5OUTmaV9blNAY7mzsx7dxn1ftwAuK3 bSkNTiW+JVPHImwIHtLI6Ku3OCU= X-Google-Smtp-Source: AGHT+IH1xKdg+nrZdYHc/L2SejfqkQOSdqRffH8LAz7J5HMiZt1d8BbpMO2b6yTqmZzIZmhgTiZbQUk= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:a17:903:3244:b0:1cc:bb7f:bd60 with SMTP id ji4-20020a170903324400b001ccbb7fbd60mr6825plb.6.1699395801930; Tue, 07 Nov 2023 14:23:21 -0800 (PST) Date: Tue, 7 Nov 2023 14:23:20 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-arch@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: Message-ID: Subject: Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags From: Stanislav Fomichev To: Eric Dumazet Cc: Mina Almasry , Willem de Bruijn , David Ahern , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, "David S. Miller" , Jakub Kicinski , Paolo Abeni , Jesper Dangaard Brouer , Ilias Apalodimas , Arnd Bergmann , Shuah Khan , Sumit Semwal , "Christian =?utf-8?B?S8O2bmln?=" , Shakeel Butt , Jeroen de Borst , Praveen Kaligineedi , Willem de Bruijn , Kaiyuan Zhang Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/07, Eric Dumazet wrote: > On Tue, Nov 7, 2023 at 10:05=E2=80=AFPM Stanislav Fomichev wrote: >=20 > > > > I don't understand. We require an elaborate setup to receive devmem cms= gs, > > why would some random application receive those? >=20 >=20 > A TCP socket can receive 'valid TCP packets' from many different sources, > especially with BPF hooks... >=20 > Think of a bonding setup, packets being mirrored by some switches or > even from tc. >=20 > Better double check than be sorry. >=20 > We have not added a 5th component in the 4-tuple lookups, being "is > this socket a devmem one". >=20 > A mix of regular/devmem skb is supported. Can we mark a socket as devmem-only? Do we have any use-case for those hybrid setups? Or, let me put it that way: do we expect API callers to handle both linear and non-linear cases correctly? As a consumer of the previous versions of these apis internally, I find all those corner cases confusing :-( Hence trying to understand whether we can make it a bit more rigid and properly defined upstream. But going back to that MSG_SOCK_DEVMEM flag. If the application is supposed to handle both linear and devmem chucks, why do we need this extra MSG_SOCK_DEVMEM opt-in to signal that it's able to process it? From Mina's reply, it seemed like MSG_SOCK_DEVMEM is there to protect random applications that get misrouted devmem skb. I don't see how returning EFAULT helps in that case. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1BF9EC04A92 for ; Tue, 7 Nov 2023 22:23:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 365BC10E0D8; Tue, 7 Nov 2023 22:23:25 +0000 (UTC) Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by gabe.freedesktop.org (Postfix) with ESMTPS id 63CC310E0B8 for ; Tue, 7 Nov 2023 22:23:22 +0000 (UTC) Received: by mail-pl1-x649.google.com with SMTP id d9443c01a7336-1cc2efd22ccso55040665ad.1 for ; Tue, 07 Nov 2023 14:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699395802; x=1700000602; darn=lists.freedesktop.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=0Pmozh0ybI7SbfNg64kEULMiwr3zKJkFxXH8jQ6gCVM=; b=DafWbwLUF9bAsfjFO1oXSx+PplfkYS3hXzcJo+JH/RQbhJCPFEwFnncXuVwHKkt4mO 3oOUnjTM3j+p0xnWTn1KGeuHFfAeN/XgP+Er0gK6avYhZaWt0xgVQMoR6C4g9DO5FoxZ DBnTvUl46HPRR/vRZ+fsY8XFByEUeXkimD19rjlalGxTxmzTDVzq/5vY0tHAS9x2F2Bj ZXXfSFccAUp9pu6AghRHsFf56wFanN1V6AhLBNJRzX8aozoClsaNdMLc8TJH6OKw80gE cuBx5Xg3cRu8su742Mm8iheJUuwURvYied3dbTitpOlcbImaWPhooufPIEyXrvi3AVDD rsAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699395802; x=1700000602; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=0Pmozh0ybI7SbfNg64kEULMiwr3zKJkFxXH8jQ6gCVM=; b=W27LwjQl0niiHIVxme0NZsi3jZK9fcx4T1J1f7Z2a1wlVEnxWna+fdFYp4omY5Vn3/ x1H6XvnBIQUGt0404C9JDxuLvgMuAzL3QQtuMJ9MHSSj4VuLvRZkXye8GcBSzAF0L7Od l5oLzeISPnxMQ6phyHNfKowVaVoy5ap1G7FnQMiSK32apigdB6tN3Z8eMAphuQ0MzNVi 8hjN7vEM/VDrswBfk2gREi+zvjkma9k/LHitRkiqrl7KI6I3FvWds1asoGYa6Vko+rMe ek78tE3K7KTfir8wMW84LZQBTUU4ENzIGOmOX+P+7xBshKqbTJ5w7xyNl53o7qutJ3+t 4J7g== X-Gm-Message-State: AOJu0YxSTFkObZDfqe6P8jc5KIsJO0q9zUqRvMY+RBPae6//IHWIu7Hh L9VglEomC4/35JO443OTb9jVcY0= X-Google-Smtp-Source: AGHT+IH1xKdg+nrZdYHc/L2SejfqkQOSdqRffH8LAz7J5HMiZt1d8BbpMO2b6yTqmZzIZmhgTiZbQUk= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:a17:903:3244:b0:1cc:bb7f:bd60 with SMTP id ji4-20020a170903324400b001ccbb7fbd60mr6825plb.6.1699395801930; Tue, 07 Nov 2023 14:23:21 -0800 (PST) Date: Tue, 7 Nov 2023 14:23:20 -0800 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags From: Stanislav Fomichev To: Eric Dumazet Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kaiyuan Zhang , dri-devel@lists.freedesktop.org, linux-kselftest@vger.kernel.org, Shuah Khan , Sumit Semwal , Mina Almasry , Willem de Bruijn , Jeroen de Borst , Jakub Kicinski , Paolo Abeni , linux-media@vger.kernel.org, linux-arch@vger.kernel.org, Jesper Dangaard Brouer , Arnd Bergmann , linaro-mm-sig@lists.linaro.org, Shakeel Butt , Willem de Bruijn , netdev@vger.kernel.org, David Ahern , Ilias Apalodimas , linux-kernel@vger.kernel.org, "David S. Miller" , Praveen Kaligineedi , Christian =?utf-8?B?S8O2bmln?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 11/07, Eric Dumazet wrote: > On Tue, Nov 7, 2023 at 10:05=E2=80=AFPM Stanislav Fomichev wrote: >=20 > > > > I don't understand. We require an elaborate setup to receive devmem cms= gs, > > why would some random application receive those? >=20 >=20 > A TCP socket can receive 'valid TCP packets' from many different sources, > especially with BPF hooks... >=20 > Think of a bonding setup, packets being mirrored by some switches or > even from tc. >=20 > Better double check than be sorry. >=20 > We have not added a 5th component in the 4-tuple lookups, being "is > this socket a devmem one". >=20 > A mix of regular/devmem skb is supported. Can we mark a socket as devmem-only? Do we have any use-case for those hybrid setups? Or, let me put it that way: do we expect API callers to handle both linear and non-linear cases correctly? As a consumer of the previous versions of these apis internally, I find all those corner cases confusing :-( Hence trying to understand whether we can make it a bit more rigid and properly defined upstream. But going back to that MSG_SOCK_DEVMEM flag. If the application is supposed to handle both linear and devmem chucks, why do we need this extra MSG_SOCK_DEVMEM opt-in to signal that it's able to process it? From Mina's reply, it seemed like MSG_SOCK_DEVMEM is there to protect random applications that get misrouted devmem skb. I don't see how returning EFAULT helps in that case.