2020-08-18 12:00:06

by Miaohe Lin

Subject: [PATCH] net: Relax the npages test against MAX_SKB_FRAGS

The npages test against MAX_SKB_FRAGS can be relaxed if we succeed to
allocate high order pages as the note in comment said.

Signed-off-by: Miaohe Lin <[email protected]>
---
net/core/skbuff.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 2f7dd689bccc..ca432bbfd90b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5758,13 +5758,6 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
struct page *page;
int i;

- *errcode = -EMSGSIZE;
- /* Note this test could be relaxed, if we succeed to allocate
- * high order pages...
- */
- if (npages > MAX_SKB_FRAGS)
- return NULL;
-
*errcode = -ENOBUFS;
skb = alloc_skb(header_len, gfp_mask);
if (!skb)
@@ -5775,6 +5768,10 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
for (i = 0; npages > 0; i++) {
int order = max_page_order;

+ if (unlikely(i >= MAX_SKB_FRAGS)) {
+ *errcode = -EMSGSIZE;
+ goto failure;
+ }
while (order) {
if (npages >= 1 << order) {
page = alloc_pages((gfp_mask & ~__GFP_DIRECT_RECLAIM) |
--
2.19.1

2020-08-18 14:19:49

by Eric Dumazet

Subject: Re: [PATCH] net: Relax the npages test against MAX_SKB_FRAGS

On Tue, Aug 18, 2020 at 4:58 AM Miaohe Lin <[email protected]> wrote:
>
> The npages test against MAX_SKB_FRAGS can be relaxed if we succeed to
> allocate high order pages as the note in comment said.
>
> Signed-off-by: Miaohe Lin <[email protected]>
> ---
> net/core/skbuff.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 2f7dd689bccc..ca432bbfd90b 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -5758,13 +5758,6 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
> struct page *page;
> int i;
>
> - *errcode = -EMSGSIZE;
> - /* Note this test could be relaxed, if we succeed to allocate
> - * high order pages...
> - */
> - if (npages > MAX_SKB_FRAGS)
> - return NULL;
> -
> *errcode = -ENOBUFS;
> skb = alloc_skb(header_len, gfp_mask);
> if (!skb)
> @@ -5775,6 +5768,10 @@ struct sk_buff *alloc_skb_with_frags(unsigned long header_len,
> for (i = 0; npages > 0; i++) {
> int order = max_page_order;
>
> + if (unlikely(i >= MAX_SKB_FRAGS)) {
> + *errcode = -EMSGSIZE;
> + goto failure;
> + }
> while (order) {
> if (npages >= 1 << order) {
> page = alloc_pages((gfp_mask & ~__GFP_DIRECT_RECLAIM) |
> --
> 2.19.1




We do not want this change.

This interface is used by datagram providers, we do not want to claim
they can safely use skb allocations over 64KB.

Returning -EMSGSIZE should not depend on availability of high-order pages.

The comment was a hint, but we need first a valid user before
considering expanding the interface.

2020-08-19 02:05:51

by Miaohe Lin

Subject: Re: [PATCH] net: Relax the npages test against MAX_SKB_FRAGS

Eric Dumazet <[email protected]> wrote:
>On Tue, Aug 18, 2020 at 4:58 AM Miaohe Lin <[email protected]> wrote:
>>
>> The npages test against MAX_SKB_FRAGS can be relaxed if we succeed to
>> allocate high order pages as the note in comment said.
>>
>
>
>We do not want this change.
>
>This interface is used by datagram providers, we do not want to claim they can safely use skb allocations over 64KB.
>
>Returning -EMSGSIZE should not depend on availability of high-order pages.
>
>The comment was a hint, but we need first a valid user before considering expanding the interface.

I see. Many thanks for reply and explaination. :)