[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190822.120421.71092037400077946.davem@davemloft.net>
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.
Powered by blists - more mailing lists