linux-kernel - Re: Problem in pfmemalloc skb handling in net/core/dev.c

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: <CAJht_EN_N=H8xwVkTT7WiwmdRTeD-L+tM3Z6hu86ebbT_JpBDw@mail.gmail.com>
Date:   Fri, 9 Apr 2021 12:12:57 -0700
From:   Xie He <xie.he.0141@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Mel Gorman <mgorman@...e.de>, jslaby@...e.cz,
        Neil Brown <neilb@...e.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Mike Christie <michaelc@...wisc.edu>,
        Eric B Munson <emunson@...bm.net>,
        Sebastian Andrzej Siewior <sebastian@...akpoint.cc>,
        Christoph Lameter <cl@...ux.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Problem in pfmemalloc skb handling in net/core/dev.c

On Fri, Apr 9, 2021 at 4:50 AM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
> On 4/9/21 12:14 PM, Xie He wrote:
>
> Then simply copy the needed logic.

No, there's no such thing as "sockets" in some of the protocols. There
is simply no way to copy "the needed logic".

> > Also, I think this is a problem in net/core/dev.c, there are a lot of
> > old protocols that are not aware of pfmemalloc skbs. I don't think
> > it's a good idea to fix them one by one.
> >
>
> I think you are mistaken.
>
> There is no problem in net/core/dev.c really, it uses
> skb_pfmemalloc_protocol()

This is exactly what I'm talking about. "skb_pfmemalloc_protocol"
cannot guarantee pfmemalloc skbs are not delivered to unrelated
protocols, because "__netif_receive_skb" will sometimes treat
pfmemalloc skbs as normal skbs.

> pfmemalloc is best effort really.
>
> If a layer store packets in many long living queues, it has to drop pfmemalloc packets,
> unless these packets are used for swapping.

Yes, the code of "net/core/dev.c" has exactly this problem. It doesn't
drop pfmemalloc skbs in some situations, and instead deliver them to
unrelated protocols, which clearly have nothing to do with swapping.

I'm not sure if you understand what I'm saying. Please look at the
code of "__netif_receive_skb" and see what will happen when
"sk_memalloc_socks()" is false and "skb_pfmemalloc(skb)" is true.