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 071DA2A1A4 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 8008F11B for ; Tue, 7 Nov 2023 14:23:22 -0800 (PST) Received: by mail-pg1-x54a.google.com with SMTP id 41be03b00d2f7-573fdb618eeso4967219a12.0 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=v0U4aVjotISb3x5mRhH4EsKfX0BpsSg3Art5+vfE3HsUYjc5eR3KSdp//3bz6sZmEC 6gq11bqwJGWMJMiEqD13hClQHChUaIQ6VjrW80f/l0X4Y5ypCmBtBSsF2Jsq9ZQH/G5Z wjDq7oEw0Hd2UnblCrUi62UmtctmKXu445++tWEFQ9I9bga03CLUkBwhMjJTsGBn3wLU xlbrsPJ7k+7tHXTjy4KL52lIOITbowxSmGfWxwNXdyD99foiM9CSxOX/tG8aLDxhQTxe xVFYZy7Ogq2kIVdIo+6ROOo8geHA8Gch1HFAeyks1e9PHCxHg36Q3RSMiVLe1+AkuoPF P0hQ== X-Gm-Message-State: AOJu0YzDKY80e6fQeT2AD9DxhafgUyMvZOhy3pJQkxQZlNWmXka8KGsZ 4DPOzXONdcQrkhYhNHfVjSAEUt0= 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: netdev@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.