On Tue, Aug 18, 2020 at 4:58 AM Miaohe Lin <linmia...@huawei.com> 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 <linmia...@huawei.com> > --- > 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.