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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D40D2C41535 for ; Tue, 7 Nov 2023 22:23:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234888AbjKGWX0 (ORCPT ); Tue, 7 Nov 2023 17:23:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56628 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232540AbjKGWXY (ORCPT ); Tue, 7 Nov 2023 17:23:24 -0500 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D657114 for ; Tue, 7 Nov 2023 14:23:22 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id d9443c01a7336-1cc56a9ece7so54966535ad.3 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=m8l7ZoOE6aRb7Zvj5rLdVysjiUKKsquFlZT1Vty9+wofYvZZdHLzX/ASp9fXq3J8z3 lCxctnKG2ori5xmILZzaX0/VAGoQAJFlsLVOdFm72PoDU8ZAgSZiaDtSf4t1qIef9U6s 5pZNx89Jfq38JzOxN1d0reLfi/qgtBGgp186rOjEiG2J0hn0sWIr9S63TaCuzJb/+kC3 r1+i6zaCaKd2x/0+yDhK+ksvghQ+CX0uH6YYyA6TdM3zUmc/Zn1dfkxwcXtGYkxFjN+s MN3UxY04maVnEZ+YeWM5MLx3+U6zok0ak4fU5Q/+XHA6aaPm5cAAKB8rzC/uEKozG2Dm wXZA== X-Gm-Message-State: AOJu0Ywy9snIT+1Wcn+rdbhTHTxBg2DRI1RlaZligR19VG2RZU8kKpLK 5ym4OXuEd3zG7zL4A0pyuEsrYnQ= 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 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.