netdev - Re: [PATCH net-next v6 2/2] page_pool: Track DMA-mapped pages and unmap them when destroying the pool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ecyamz6o.fsf@toke.dk>
Date: Wed, 02 Apr 2025 16:10:39 +0200
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Pavel Begunkov <asml.silence@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard
 Brouer <hawk@...nel.org>, Saeed Mahameed <saeedm@...dia.com>, Leon
 Romanovsky <leon@...nel.org>, Tariq Toukan <tariqt@...dia.com>, Andrew
 Lunn <andrew+netdev@...n.ch>, Eric Dumazet <edumazet@...gle.com>, Paolo
 Abeni <pabeni@...hat.com>, Ilias Apalodimas <ilias.apalodimas@...aro.org>,
 Simon Horman <horms@...nel.org>, Andrew Morton
 <akpm@...ux-foundation.org>, Mina Almasry <almasrymina@...gle.com>,
 Yonglong Liu <liuyonglong@...wei.com>, Yunsheng Lin
 <linyunsheng@...wei.com>, Matthew Wilcox <willy@...radead.org>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org, linux-rdma@...r.kernel.org,
 linux-mm@...ck.org, Qiuling Ren <qren@...hat.com>, Yuying Ma
 <yuma@...hat.com>
Subject: Re: [PATCH net-next v6 2/2] page_pool: Track DMA-mapped pages and
 unmap them when destroying the pool

Pavel Begunkov <asml.silence@...il.com> writes:

>>>> +	if (err) {
>>>> +		WARN_ONCE(1, "couldn't track DMA mapping, please report to netdev@");
>>>
>>> That can happen with enough memory pressure, I don't think
>>> it should be a warning. Maybe some pr_info?
>> 
>> So my reasoning here was that this code is only called in the alloc
>> path, so if we're under memory pressure, the page allocation itself
>> should fail before the xarray alloc does. And if it doesn't (i.e., if
>> the use of xarray itself causes allocation failures), we really want to
>> know about it so we can change things. Hence the loud warning.
>
> There is a gap between allocations, one doesn't guarantee
> another. I'd say the mental test here is whether we can reasonably
> cause it from user space (including by abusive users), because crash
> on warning setups exist, and it'll let you know about itself too
> loudly, when it could've been tolerated just fine. Not going to
> insist though.

Right, I do see what you mean - it's not guaranteed to be coupled.
However, my feeling is nonetheless that it's better for this to be loud
to weed out any new issues that may arise from this, so I'm inclined to
keep it as-is.

-Toke