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

Date:   Thu, 22 Aug 2019 12:04:21 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jan.dakinevich@...tuozzo.com
Cc:     linux-kernel@...r.kernel.org, den@...tuozzo.com,
        khorenko@...tuozzo.com, pabeni@...hat.com, viro@...iv.linux.org.uk,
        axboe@...nel.dk, hare@...e.com, kgraul@...ux.ibm.com,
        kyeongdon.kim@....com, tglx@...utronix.de, netdev@...r.kernel.org
Subject: Re: [PATCH] af_unix: utilize skb's fragment list for sending large
 datagrams

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.