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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCF3BC28B2E for ; Tue, 11 Mar 2025 13:08:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D124D280005; Tue, 11 Mar 2025 09:08:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9B7D280001; Tue, 11 Mar 2025 09:08:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3E47280005; Tue, 11 Mar 2025 09:08:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 93B59280001 for ; Tue, 11 Mar 2025 09:08:56 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A52BD141F01 for ; Tue, 11 Mar 2025 13:08:57 +0000 (UTC) X-FDA: 83209300314.03.DBBAC75 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 017F640002 for ; Tue, 11 Mar 2025 13:08:54 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TIPETvRW; spf=pass (imf04.hostedemail.com: domain of pabeni@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pabeni@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741698535; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pSr0TDQLJaYD83EU6zHlB1nKsxywhTiBP95UqC0cvIM=; b=IspAj/fKWGwQijeVEa/ttHVPO4KwR/JEcL3lpLCNhnVZ5HJjD2n0zFUL5Mmnihr0pt8B7M KuW4K8NfY8mKN9eB+VLybcj1BCrS5waKfqmHFYnQ3pvNg/AxlAMOzkvEu3APCCK+d1cQKj U3phzYb+7Yzkz271zF2yVHe1Fr5yEjo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741698535; a=rsa-sha256; cv=none; b=IZ9UdCdZurzbBTMHrHUgoRo2zRgSRcZZZNwih8jq2lsmLoPWOAvZf/pqDLC2UJl/PPkqC9 0AbirWpI77mLqDRiVemN0OunChvyAJDJkWerMN8tQiyKg6ttvW3EeG/8RZFeUVmkICwIPJ oV2SRpPpQhfcvi9hYlFxrZG9IRVfJ/M= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TIPETvRW; spf=pass (imf04.hostedemail.com: domain of pabeni@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=pabeni@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741698534; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pSr0TDQLJaYD83EU6zHlB1nKsxywhTiBP95UqC0cvIM=; b=TIPETvRW+Oc8geWAq78CSeNMB2jgOySMG1HDsv4r42jV4FjDwY8CTm/IuyJJGXjfXZrFf9 +A48fWJ13JtBPVAuzwCYNECGWp+8m3Sg+Uj0PwDGjmQq1kX8kdvNQnUJSYB5HWIIMe9oT1 yZAwNQo1unUCO5GLvOqJhSBaEfdRARg= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-460-OAy-XijxMxKap_dk_iKH6g-1; Tue, 11 Mar 2025 09:08:50 -0400 X-MC-Unique: OAy-XijxMxKap_dk_iKH6g-1 X-Mimecast-MFC-AGG-ID: OAy-XijxMxKap_dk_iKH6g_1741698529 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-43ce8f82e66so15515445e9.3 for ; Tue, 11 Mar 2025 06:08:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741698529; x=1742303329; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pSr0TDQLJaYD83EU6zHlB1nKsxywhTiBP95UqC0cvIM=; b=ePmrj4UK2qt/EEwlbi7T6M06dYuMkepvmneyqYd2yYTxU1tx3lXfwODhuQhGSgO+co jJnxybffiho2RiSHnX4n14SBiXSkyvUPwlAaYwe+Z0vJFloIB8uzJIb2zkE2+U5xSsDm 3C/eKaUMeGH5K5gAXs4cYlkd8zhpqZpIzYJqJtB+MG80Abv2EAfKx2CrEbAnaf0m762K q8VkMtQHj5bnRDAWxxWw+TGN/ZhDdHOyA3j+eX0gwQjoeeje8sgSGPoLhLC5HrreGlPM ttoVgsuTjX5v5UcXZOarnyYc2b/8yekFfG8yaPCCMNRubDkPBowIJpsjqPadUct+O6Ks 5kOA== X-Forwarded-Encrypted: i=1; AJvYcCUQ6mjm4TUspuu5xUv7mgm7FkHyzDP5eLqgXrkuy1IXnhMqEcVGvBnI3UoM1jCvBaSIObisGTiVdw==@kvack.org X-Gm-Message-State: AOJu0YwEp9RpOozFdZ1+XEsPQ2Y9xqM7cNZBV9eK0WFxlaV1GzDV3FZD AUhUzRAA3kHLY+EmknK46wy19RnDhSt/+8I3GYPJG/oq55irI2iMdbKy/950oB8jdk53bokRdjL UFbHj5wXA9YuYbE6j5+F7whtFwF7TGZxX0C8h23pwzzeAQAw3 X-Gm-Gg: ASbGncvYjg8QCBPFih2NqYIDKF5kofZsGiAqwiAgEXM9SjINiZnsjdIezHD/SX0X1yc iSIKGTH77DiO+FUZCCgyW0IgQfH2PD7B+H7NmtcUO+GPs1gKoOrPClxf1w4DN2Vo5QaKN6om06g 3xL4OEMxxjv6vu38uT19FIQUyNiJu9mc02VGhowQWrGpF7+PpvRdyrXoOAWgrOcsEbAB04wnrDc GXK/oiUuzxsSVZ6hCflpDsPNGQtnrmBq9PZSodNcX9pmfHR/osmjVv/7IiKhAs25rJK98PccKYU dop2mlA8DTQTapjtkqXPAl3cvKmQxv+PvC7/2KWJDKKrSw== X-Received: by 2002:a05:600c:3b04:b0:43c:f44c:72b7 with SMTP id 5b1f17b1804b1-43cf44c7703mr98398925e9.14.1741698528854; Tue, 11 Mar 2025 06:08:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGHg2xJEtdcFy90P2VzdKFh3p/fCZJcgu7H/volTSsPrNEA8I4PMuG+4jYjYdTWL3xOUsvL7A== X-Received: by 2002:a05:600c:3b04:b0:43c:f44c:72b7 with SMTP id 5b1f17b1804b1-43cf44c7703mr98398315e9.14.1741698528418; Tue, 11 Mar 2025 06:08:48 -0700 (PDT) Received: from [192.168.88.253] (146-241-12-146.dyn.eolo.it. [146.241.12.146]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43cf3ca4f5asm82801875e9.12.2025.03.11.06.08.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Mar 2025 06:08:47 -0700 (PDT) Message-ID: <72cd7f5a-ab92-494c-b7f8-4696d23ed4b1@redhat.com> Date: Tue, 11 Mar 2025 14:08:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Intel-wired-lan] [PATCH net-next v11 0/4] fix the DMA API misuse problem for page_pool To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Yunsheng Lin , Yunsheng Lin , davem@davemloft.net, kuba@kernel.org Cc: zhangkun09@huawei.com, liuyonglong@huawei.com, fanghaiqing@huawei.com, Alexander Lobakin , Robin Murphy , Alexander Duyck , Andrew Morton , Gaurav Batra , Matthew Rosato , IOMMU , MM , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Matthias Brugger , AngeloGioacchino Del Regno , netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Eric Dumazet References: <20250307092356.638242-1-linyunsheng@huawei.com> <87v7slvsed.fsf@toke.dk> <40b33879-509a-4c4a-873b-b5d3573b6e14@gmail.com> <875xkj1t70.fsf@toke.dk> From: Paolo Abeni In-Reply-To: <875xkj1t70.fsf@toke.dk> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: W52lziTk0kBacT56PUlB67tnjI5X7OjajlBUq9rxhWA_1741698529 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam12 X-Rspam-User: X-Rspamd-Queue-Id: 017F640002 X-Stat-Signature: pywe1xfh9hum9fuhbyh7ms7xo614x65m X-HE-Tag: 1741698534-752417 X-HE-Meta: U2FsdGVkX1+TP6d8Gra2ccPEbo4qZRwZ+eVpSxlgrObVt/NT5YWJBcsYrqZ58Uww0Ey/rtL8GPT1iW1O5ASSnXAB4RH7JyYc1NaG4CH9miFiftAZgActjw++nAuFOldaE5kPqvieM+17swREIgvt1fn8zg/hy2Ya4tFkyM82brJ2c988gfbl4iGv/mbUY/lCmYDAye6M8aM/zScOIUtFXy389LxTTlc0nZgXvSVKi57u6FQ56aXbGgg+MZU0gsuBOZwm2V1vEXNAL2OV5ZpRk/ElQvgcUwTI7ner31EO2L7RMfnDaefC+cAZS9iG2oUBbCWDmumzNIpfM6nsr9iYKNEN8wHM7uQHWOq4CyVF233QhBrjnrZAZkYnkyZ6oSn6dTU3ENg0afMKZVjoDUrx5hNO7ZleHqS17lCS7TAj3FVmI3M7j5mk7IBfczFB5uTSvTFszeNm0qvXZPtuMgbePvPmGn5cSKA8zY1hBK9nbZCy9DE+KDUGLekjwZ5JAdbrEuTyadHgIUED/lA1hO/bxWz9sZk4egs8uZam6/vGhRF0JHm1PuQcxAmS5wYUx3+M1vsU5MXYXzHkux+YHZNvi3KBfA8ziqEQf37wUbiTf76KWI8XJR0bOBGKPq28tcl9LTZ5SOWrofacfZu0+Wk1KOvfhGcQgTY1hMUObbXi6nshMkNzT0Mdaa1Yh6IDqcOjaffc5vHq5+NC6pXoRacYsH/+J2JyoqI38zYL1ShhBQT1Nbe3usFrtWqlQMKTw7wAcranq4AEg8hiLH948/giD2VBhEVNHW9b3b7TuhsIItezJz1Qo7Mjh5FIXE8Dg763IhoLDHWkFjIfn5XBkk/fdzTtn7W/sE5i4V6z+1z6pHKzYoaqw7Y6B4HxG/ysIGyBB0qLvuL7nQemKNBWMERw28NuQg4gWcT+IDo/9gDZjTonBuYFhRjG5UjCL6jKliCg56GPZm/vwczSqEscsv2 8VDtTErp fm/tWlHvT3qCJapJuaE9TawQCWsdNN5Md9qxzdPW7MFNmnd/sxBgn64lSmF/clfNe/hLjqk3V8ZLXpxMUjm6cOG7v2w1VL9oPwz56ENzx2DLo3wBFawwo5R1TFRK+FAInoKNt5wYxl1YXzuLJhbD7ofc3gjftypWwIE27/+WIgvhtFW7WtCI5dij7z1Z71g7H0CVIeCVKwGRpxGikAeKjBpxgH0d0Ih1k5/Z5NlF7dQKXxunp+ugcw/1xiMppK2P/OI9qW0KtXkB5DjgvHEWQJ7NMvwNkAAIIRmnTM+7a5AeciY2e9t0ylqhf8OYRmiAjBKaGSuyECMYH6lp7YmJvV1NEZcAsnHsZfYZQNHMe2z+tOO9vwGD+9gxb8zkKejicTsQwhLxHiLcvZ5R41t+myFw49iyabg9AXn+5XJu8myMc858RxICJNULA0gDbLTWDZU4pQIgb2SCr2go91HR1Ho6Cga2m5gn4pO6WWqF1qqLcdHK14zMdCxwo4xzEtnYX4+3pr3BUgBS7dOvYhUkS4JPkZiCOzJEPtttfeCdERbrwYz7iAQGmbgiuij75feaokY9p+v5bJDb6OIdRQCh8G91mJ+efMPQCD2fYwqosToIm9BrjneNVGaSqaw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 3/8/25 3:40 PM, Toke Høiland-Jørgensen wrote: > Yunsheng Lin writes: >> I only took a glance at git code above, it seems reusing the >> _pp_mapping_pad for pp_dma_index seems like a wrong direction >> as mentioned in discussion with Ilias above as the field might >> be used when a page is mmap'ed to user space, and reusing that >> field in 'struct page' seems to disable the tcp_zerocopy feature, >> see the below commit from Eric: >> https://github.com/torvalds/linux/commit/577e4432f3ac810049cb7e6b71f4d96ec7c6e894 >> >> Also, I am not sure if a page_pool owned page can be spliced into the fs >> subsystem yet, but if it does, I am not sure how is reusing the >> page->mapping possible if that page is called in __filemap_add_folio()? >> >> https://elixir.bootlin.com/linux/v6.14-rc5/source/mm/filemap.c#L882 > > Hmm, so I did look at the mapping field, but concluded using it wouldn't > interfere with anything relevant as long as it's reset back to zero > before the page is returned to the page allocator. However, I definitely > missed the TCP zero-copy thing, and other things as well, it would seem > (cf the discussion you referred to above). > > However, I did consider alternatives: AFAICT there should be space in > the pp_magic field (used for the PP_SIGNATURE), so that with a bit of > care we can stick an ID into the upper bits and still avoid ending up > with a value that could look like a valid pointer. > > I didn't implement that initially because I wasn't sure it was > necessary, but seeing as it is, I will take another look at it. I have > one or two other ideas if this turns out not to pan out. Another dumb option would be storing directly the page address in the xarray, and avoid entirely going through an ID. I guess it will use more memory (the array will be more sparse) and will have more overhead, but could be possibly simpler? /P