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 B9D3BC19F32 for ; Fri, 28 Feb 2025 02:23:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 055BB280002; Thu, 27 Feb 2025 21:23:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 005B8280001; Thu, 27 Feb 2025 21:23:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E36E2280002; Thu, 27 Feb 2025 21:23:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C7850280001 for ; Thu, 27 Feb 2025 21:23:37 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 54C6A82112 for ; Fri, 28 Feb 2025 02:23:37 +0000 (UTC) X-FDA: 83167757274.25.61A7147 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf02.hostedemail.com (Postfix) with ESMTP id 0A96780014 for ; Fri, 28 Feb 2025 02:23:33 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740709415; a=rsa-sha256; cv=none; b=a4KBdaJdI7EpQKMxPdRVSa0ggNHk3l9GJkRpqgd4/zGH1PTgWemcLCO+f0Yb7v5ZuAFsST 6sRFNT70CMchaUby/xG/fDc4JbI8ynWY5YJMbi2AHLwAVlLbuwJjtzB9cGzV1cn2hqPE0e KWTv44phoEUPn1SlwFFsV1HBkwDCkwA= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740709415; 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; bh=rQvCOjwqZFWgTM6Duk6m2nOX4IpVRZRvoIGWV5YANw4=; b=wq0oEYMULX+sNQO+6dl1jED6sRlsTcV//1ao0PcZBY6Gc/ECUo/Y5JQ7Wnpyr6crwg/wmo suRhXgXcKdx043ndWhsadxKzWlYWlQVtoPi1ETDNfHHSM959ENeRTS87aO+j6AR7rZp4ni 7XnRM1/Y4X66P/fcyUrME6dU4z5MEjk= Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Z3sRB30zpzVmVS; Fri, 28 Feb 2025 10:21:58 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id 1F94B1402C3; Fri, 28 Feb 2025 10:23:30 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 28 Feb 2025 10:23:28 +0800 Message-ID: Date: Fri, 28 Feb 2025 10:23:28 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [net-next PATCH v6 1/6] octeontx2-pf: use xdp_return_frame() to free xdp buffers To: Suman Ghosh , , , , , , , , , , , , , , , , , , , , , References: <20250213053141.2833254-1-sumang@marvell.com> <20250213053141.2833254-2-sumang@marvell.com> Content-Language: en-US From: Yunsheng Lin CC: Jesper Dangaard Brouer , linux-mm , Ilias Apalodimas In-Reply-To: <20250213053141.2833254-2-sumang@marvell.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 0A96780014 X-Stat-Signature: 7op5w1h4fu58cry4g5byo7fnwb6zouwb X-HE-Tag: 1740709413-336794 X-HE-Meta: U2FsdGVkX184TZsBwKlhFrUQeA1zWAGdRKQhU7AetZWBfq2KPZ7bcJ0dK9Na4jhLDO8EEJMZaHTrZfkUoaD2U0E+CW0yaxCD4XDKAGhEFH28KFn0byIZW0en/lqvr5Aldi3S7uwDCaJaehQY5iUO6lpfVYdw3kkUiT5JYyuH3Mb/HqJOUWu8qvuVblHyDr+W0X0dlDl+Ftyl0lAW7nO87l1CsZVugNqx+c/RSNVGAyCSExkrFeY0ag3PB0KRQOdbkgrm0bsLNLelN6ccBf6JjEG9ZrpnSq4XHODNMz2iRtE4vXUr0FVaibZTtGT71IvPnW7UXMlDuVtTZ+Jta5Q/6XmKCYZNRc0TA78r1LhKvhGET+wwaX9hxnCazsD48dedCSIQ5/dVIuX6RXt1/IHWGfhszPQUbPwJYWwJ1OacOesLHjtofbOdQfOOqQi4YwBiFv3E7eqjWQ4+35DASL5uDsM7I0uotBEY5JcB/AXYlPIXc+S/uytOozgYNWhA9HysQ0JC66m3NXmhntYu0f/kkcU1Pv5oKIYDcmeiqzNrZCgOqinkR+VyaVlOVIYV2gHgqHLXN9Jllk/DMj45CyPfkGdzjxndstJDdQsyEZLmwxcGxv5/q42HIDjEwP0+RVSRVfsHmG4FzbMnJ8ZRztL3/r8f9ZOZMY8Ke4Kz4okMdQ820FExwpnO/u6QGlQ927nTmXoOY82D2g++l0bj4tlYV5a1/zf1l4rWZUNAfyqR3TMrXEEN9FtmPFr7Xb4lGdlER5SXJPJckrO7LQgzo/iws5FZ6sAHoNdQY2hOflwDCk4W3mJgnEpkYSqIkQUd8ILnq9mBOUUNTIaZ6RAeskVhAKbmlOUKHumDFAU+VWcCmTlJEtdn9zhlFPEjNU8z2uPCMILe+2ap8oPO1e4blgqwUvUKqFmXjQ4YMyrpb6EYjmn3HAAVKWfTyir/MZ42s0wC8zYyc0jb+eEgVahORm4 RLZEcUye kDs6regiHJ8tfTwECOI1xd0j93EMeOQ1Ko3KU05J6rRhvUIrbu/MvXmUSRvxDsduDGJuORdAAKCJeVE210RxElKO1B0Aiz1aCuw4Q2BehqkUDAhhH2xDNrkbgNQ226PG9MNrcBhEY89IjUu3Tg3EiW/aTnpCKrwUHdHQIea3be7P6mRs4+I5jeCXO2WVv7Zj03FIfND3V+QqdUaxp8iozl/Z+WDpsCL7zaLP1EiqslvYoEW8805OtIZD2z6ZczYNrdSRL5H+BO28HjVlobbNOgEPyheaY30uOawSQSeBH/wKrrlQa2ovj3XEh+/Qa+yTQES7slXIQEk/Umfs6qgBcx/QGDsn9ONo0oRXz+KBlqTmqGFVGiXV9wzPJ1m4epyBcrNghmUKU6+ju0rngSjB8OJa7mR5GDGZXjFLnvBKRJTcO1Tc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 2025/2/13 13:31, Suman Ghosh wrote: > - put_page(page); > cq->pool_ptrs++; > + if (page->pp) { It seems the above changing caused the below error for the DMA API misuse patchset： https://lore.kernel.org/oe-kbuild-all/202502280250.Bp3jD6ZE-lkp@intel.com/ And it seems this patch uses 'page->pp' being NULL or not to decide if a page is page_pool owned or not, I am not sure if the buddy page allocator will always ensure that memory that 'page->pp' points to will always be zero, even if it is for now, It seems the driver should not use that to decide if a page is page_pool owned or not. The PP_SIGNATURE magic macro seems to be correct way to decide if the page is page_pool owned or not when driver doesn't have its own way to decide if a page is page_pool owned or not, see: https://elixir.bootlin.com/linux/v6.14-rc1/source/net/core/skbuff.c#L924 > + page_pool_recycle_direct(pool->page_pool, page); > + } else { > + otx2_dma_unmap_page(pfvf, iova, pfvf->rbsize, > + DMA_FROM_DEVICE); > + put_page(page); > + } > return true; > } > return false;