linux-kernel - Re: [PATCH 1/4] net/skbuff: don't waste memory reserves

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]

Date:   Fri, 19 Apr 2019 06:41:37 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        "David S. Miller" <davem@...emloft.net>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Willem de Bruijn <willemb@...gle.com>,
        Florian Westphal <fw@...len.de>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH 1/4] net/skbuff: don't waste memory reserves



On 04/19/2019 06:17 AM, Andrey Ryabinin wrote:
> 

> I don't see why that would be a problem. If refill failed because we didn't have
> access to reserves, then there going to be an another refill attempt, right?
> And the next refill attempt will be with access to the reserves if memalloc socket was created.
> We can't predict the future, so until the memalloc socket appeared we must assume that those
> RX ring buffers won't be used to reclaim memory (and that is actually true in 99% of cases).
> 

I just said that the alloc might be attempted "in the past"

Yes, we can not predict the future, this is why we need to access the reserve _now_ and not
at the time the packet is received.

The 'being true in 99% of cases' argument is not really convincing.

You want the NIC to be ready to receive packets even before sk_memalloc_socks() becomes true.

If a NIC driver has a bug, please fix it.