From: Jakub Kicinski <kuba@kernel.org> To: Yunsheng Lin <linyunsheng@huawei.com> Cc: <davem@davemloft.net>, <pabeni@redhat.com>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Jesper Dangaard Brouer <hawk@kernel.org>, John Fastabend <john.fastabend@gmail.com>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, <bpf@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, Alexander Duyck <alexander.duyck@gmail.com> Subject: Re: [PATCH net-next v11 0/6] introduce page_pool_alloc() related API Date: Wed, 18 Oct 2023 08:35:16 -0700 [thread overview] Message-ID: <20231018083516.60f64c1a@kernel.org> (raw) In-Reply-To: <67f2af29-59b8-a9e2-1c31-c9a625e4c4b3@huawei.com> On Wed, 18 Oct 2023 19:47:16 +0800 Yunsheng Lin wrote: > > mention it in the documentation. Plus the kdoc of the function should > > say that this is just a thin wrapper around other page pool APIs, and > > it's safe to mix it with other page pool APIs? > > I am not sure I understand what do 'safe' and 'mix' mean here. > > For 'safe' part, I suppose you mean if there is a va accociated with > a 'struct page' without calling some API like kmap()? For that, I suppose > it is safe when the driver is calling page_pool API without the > __GFP_HIGHMEM flag. Maybe we should mention that in the kdoc and give a > warning if page_pool_*alloc_va() is called with the __GFP_HIGHMEM flag? Sounds good. Warning wrapped in #if CONFIG_DEBUG_NET perhaps? > For the 'mix', I suppose you mean the below: > 1. Allocate a page with the page_pool_*alloc_va() API and free a page with > page_pool_free() API. > 2. Allocate a page with the page_pool_*alloc() API and free a page with > page_pool_free_va() API. > > For 1, it seems it is ok as some virt_to_head_page() and page_address() call > between va and 'struct page' does not seem to change anything if we have > enforce page_pool_*alloc_va() to be called without the __GFP_HIGHMEM flag. > > For 2, If the va is returned from page_address() which the allocation API is > called without __GFP_HIGHMEM flag. If not, the va is from kmap*()? which means > we may be calling page_pool_free_va() before kunmap*()? Is that possible? Right, if someone passes kmap()'ed address they are trying quite hard to break their own driver. Technically possible but I wouldn't worry. I just mean that in the common case of non-HIGHMEM page, calling page_pool_free_va() with the address returned by page_address() is perfectly legal.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org> To: Yunsheng Lin <linyunsheng@huawei.com> Cc: <davem@davemloft.net>, <pabeni@redhat.com>, <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Jesper Dangaard Brouer <hawk@kernel.org>, John Fastabend <john.fastabend@gmail.com>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, <bpf@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, Alexander Duyck <alexander.duyck@gmail.com> Subject: Re: [PATCH net-next v11 0/6] introduce page_pool_alloc() related API Date: Wed, 18 Oct 2023 08:35:16 -0700 [thread overview] Message-ID: <20231018083516.60f64c1a@kernel.org> (raw) In-Reply-To: <67f2af29-59b8-a9e2-1c31-c9a625e4c4b3@huawei.com> On Wed, 18 Oct 2023 19:47:16 +0800 Yunsheng Lin wrote: > > mention it in the documentation. Plus the kdoc of the function should > > say that this is just a thin wrapper around other page pool APIs, and > > it's safe to mix it with other page pool APIs? > > I am not sure I understand what do 'safe' and 'mix' mean here. > > For 'safe' part, I suppose you mean if there is a va accociated with > a 'struct page' without calling some API like kmap()? For that, I suppose > it is safe when the driver is calling page_pool API without the > __GFP_HIGHMEM flag. Maybe we should mention that in the kdoc and give a > warning if page_pool_*alloc_va() is called with the __GFP_HIGHMEM flag? Sounds good. Warning wrapped in #if CONFIG_DEBUG_NET perhaps? > For the 'mix', I suppose you mean the below: > 1. Allocate a page with the page_pool_*alloc_va() API and free a page with > page_pool_free() API. > 2. Allocate a page with the page_pool_*alloc() API and free a page with > page_pool_free_va() API. > > For 1, it seems it is ok as some virt_to_head_page() and page_address() call > between va and 'struct page' does not seem to change anything if we have > enforce page_pool_*alloc_va() to be called without the __GFP_HIGHMEM flag. > > For 2, If the va is returned from page_address() which the allocation API is > called without __GFP_HIGHMEM flag. If not, the va is from kmap*()? which means > we may be calling page_pool_free_va() before kunmap*()? Is that possible? Right, if someone passes kmap()'ed address they are trying quite hard to break their own driver. Technically possible but I wouldn't worry. I just mean that in the common case of non-HIGHMEM page, calling page_pool_free_va() with the address returned by page_address() is perfectly legal. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-18 15:35 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-13 6:48 [PATCH net-next v11 0/6] introduce page_pool_alloc() related API Yunsheng Lin 2023-10-13 6:48 ` Yunsheng Lin 2023-10-13 6:48 ` [PATCH net-next v11 1/6] page_pool: fragment API support for 32-bit arch with 64-bit DMA Yunsheng Lin 2023-10-17 1:31 ` Jakub Kicinski 2023-10-17 12:05 ` Ilias Apalodimas 2023-10-17 12:17 ` Ilias Apalodimas 2023-10-17 12:53 ` Yunsheng Lin 2023-10-17 13:02 ` Ilias Apalodimas 2023-10-13 6:48 ` [PATCH net-next v11 2/6] page_pool: unify frag_count handling in page_pool_is_last_frag() Yunsheng Lin 2023-10-13 6:48 ` [PATCH net-next v11 3/6] page_pool: remove PP_FLAG_PAGE_FRAG Yunsheng Lin 2023-10-13 6:48 ` [Intel-wired-lan] " Yunsheng Lin 2023-10-13 6:48 ` Yunsheng Lin 2023-10-13 6:48 ` [PATCH net-next v11 4/6] page_pool: introduce page_pool[_cache]_alloc() API Yunsheng Lin 2023-10-13 6:48 ` [PATCH net-next v11 5/6] page_pool: update document about fragment API Yunsheng Lin 2023-10-13 6:48 ` [PATCH net-next v11 6/6] net: veth: use newly added page pool API for veth with xdp Yunsheng Lin 2023-10-17 1:27 ` [PATCH net-next v11 0/6] introduce page_pool_alloc() related API Jakub Kicinski 2023-10-17 1:27 ` Jakub Kicinski 2023-10-17 7:56 ` Yunsheng Lin 2023-10-17 7:56 ` Yunsheng Lin 2023-10-17 15:13 ` Jakub Kicinski 2023-10-17 15:13 ` Jakub Kicinski 2023-10-17 15:14 ` Jakub Kicinski 2023-10-17 15:14 ` Jakub Kicinski 2023-10-18 11:47 ` Yunsheng Lin 2023-10-18 11:47 ` Yunsheng Lin 2023-10-18 15:35 ` Jakub Kicinski [this message] 2023-10-18 15:35 ` Jakub Kicinski 2023-10-19 13:22 ` Yunsheng Lin 2023-10-19 13:22 ` Yunsheng Lin 2023-10-19 13:56 ` Jakub Kicinski 2023-10-19 13:56 ` Jakub Kicinski 2023-10-17 4:10 ` patchwork-bot+netdevbpf 2023-10-17 4:10 ` patchwork-bot+netdevbpf
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20231018083516.60f64c1a@kernel.org \ --to=kuba@kernel.org \ --cc=alexander.duyck@gmail.com \ --cc=angelogioacchino.delregno@collabora.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=davem@davemloft.net \ --cc=hawk@kernel.org \ --cc=john.fastabend@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linyunsheng@huawei.com \ --cc=matthias.bgg@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.