netdev - Re: [PATCH] af_unix: utilize skb's fragment list for sending large datagrams

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] [day] [month] [year] [list]

Date:   Sat, 24 Aug 2019 20:38:48 +0000
From:   Denis Lunev <den@...tuozzo.com>
To:     David Miller <davem@...emloft.net>,
        Jan Dakinevich <jan.dakinevich@...tuozzo.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Konstantin Khorenko <khorenko@...tuozzo.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "hare@...e.com" <hare@...e.com>,
        "kgraul@...ux.ibm.com" <kgraul@...ux.ibm.com>,
        "kyeongdon.kim@....com" <kyeongdon.kim@....com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] af_unix: utilize skb's fragment list for sending large
 datagrams

On 8/22/19 9:04 PM, David Miller wrote:
> From: Jan Dakinevich <jan.dakinevich@...tuozzo.com>
> Date: Thu, 22 Aug 2019 10:38:39 +0000
>
>> However, paged part can not exceed MAX_SKB_FRAGS * PAGE_SIZE, and large
>> datagram causes increasing skb's data buffer. Thus, if any user-space
>> program sets send buffer (by calling setsockopt(SO_SNDBUF, ...)) to
>> maximum allowed size (wmem_max) it becomes able to cause any amount
>> of uncontrolled high-order kernel allocations.
> So?  You want huge SKBs you get the high order allocations, seems
> rather reasonable to me.
>
> SKBs using fragment lists are the most difficult and cpu intensive
> geometry for an SKB to have and we should avoid using it where
> feasible.
>
> I don't want to apply this, sorry.
Under even mediocre memory pressure this will either takes seconds or fail,
which does not look good. We can try to allocate memory of big order
but not that hard and switch to fragments when possible.

Please also note that even ordinary user could trigger really big
allocations
and thus force the whole node to dance.

Den

Den