All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
	netdev <netdev@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Miller <davem@davemloft.net>,
	Dmitry Vyukov <dvyukov@google.com>,
	Alexander Potapenko <glider@google.com>,
	Jann Horn <jannh@google.com>, Jakub Kicinski <kuba@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Willem de Bruijn <willemb@google.com>,
	syzbot <syzbot+7b99aafdcc2eedea6178@syzkaller.appspotmail.com>
Subject: Re: WARNING in sk_stream_kill_queues (5)
Date: Mon, 7 Dec 2020 17:28:31 +0100	[thread overview]
Message-ID: <X85YL2GZHXpgZYlm@elver.google.com> (raw)
In-Reply-To: <af884a0e-5d4d-f71b-4821-b430ac196240@gmail.com>

On Thu, Dec 03, 2020 at 07:01PM +0100, Eric Dumazet wrote:
> On 12/3/20 6:41 PM, Marco Elver wrote:
> 
> > One more experiment -- simply adding
> > 
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -207,7 +207,21 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> >  	 */
> >  	size = SKB_DATA_ALIGN(size);
> >  	size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
> > +	size = 1 << kmalloc_index(size); /* HACK */
> >  	data = kmalloc_reserve(size, gfp_mask, node, &pfmemalloc);
> > 
> > 
> > also got rid of the warnings. Something must be off with some value that
> > is computed in terms of ksize(). If not, I don't have any explanation
> > for why the above hides the problem.
> 
> Maybe the implementations of various macros (SKB_DATA_ALIGN and friends)
> hae some kind of assumptions, I will double check this.


Some more data; removing all uses of ksize() fixes the warnings:

| --- a/net/core/skbuff.c
| +++ b/net/core/skbuff.c
| @@ -214,7 +214,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
|  	 * Put skb_shared_info exactly at the end of allocated zone,
|  	 * to allow max possible filling before reallocation.
|  	 */
| -	size = SKB_WITH_OVERHEAD(ksize(data));
| +	size = SKB_WITH_OVERHEAD(size);
|  	prefetchw(data + size);
|  
|  	/*
| @@ -1628,7 +1628,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
|  			       gfp_mask, NUMA_NO_NODE, NULL);
|  	if (!data)
|  		goto nodata;
| -	size = SKB_WITH_OVERHEAD(ksize(data));
| +	size = SKB_WITH_OVERHEAD(size + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
^^ Reverting *only* this to 'ksize(data)' triggers the warning.
|  	/* Copy only real data... and, alas, header. This should be
|  	 * optimized for the cases when header is void.
| @@ -5901,7 +5901,7 @@ static int pskb_carve_inside_header(struct sk_buff *skb, const u32 off,
|  	if (!data)
|  		return -ENOMEM;
|  
| -	size = SKB_WITH_OVERHEAD(ksize(data));
| +	size = SKB_WITH_OVERHEAD(size + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
|  
|  	/* Copy real data, and all frags */
|  	skb_copy_from_linear_data_offset(skb, off, data, new_hlen);
| @@ -6025,7 +6025,7 @@ static int pskb_carve_inside_nonlinear(struct sk_buff *skb, const u32 off,
|  	if (!data)
|  		return -ENOMEM;
|  
| -	size = SKB_WITH_OVERHEAD(ksize(data));
| +	size = SKB_WITH_OVERHEAD(size + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
|  
|  	memcpy((struct skb_shared_info *)(data + size),
|  	       skb_shinfo(skb), offsetof(struct skb_shared_info, frags[0]));


Conversely, only doing this also fixes the warnings:

| --- a/net/core/skbuff.c
| +++ b/net/core/skbuff.c
| @@ -1628,7 +1628,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
|  			       gfp_mask, NUMA_NO_NODE, NULL);
|  	if (!data)
|  		goto nodata;
| -	size = SKB_WITH_OVERHEAD(ksize(data));
| +	size = SKB_WITH_OVERHEAD(size + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
|  
|  	/* Copy only real data... and, alas, header. This should be
|  	 * optimized for the cases when header is void.

But not sure if any of this is helpful, since in the end what we want is
to make a bunch of subtractions reach precisely 0, and any deviation
somewhere might, by chance, achieve that.

Thanks,
-- Marco

  parent reply	other threads:[~2020-12-07 16:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  8:40 WARNING in sk_stream_kill_queues (5) syzbot
2020-12-03 15:58 ` Marco Elver
2020-12-03 16:27   ` Eric Dumazet
2020-12-03 16:34     ` Marco Elver
2020-12-03 16:42       ` Eric Dumazet
2020-12-03 17:41         ` Marco Elver
2020-12-03 18:01           ` Eric Dumazet
2020-12-07 15:30             ` Marco Elver
2020-12-07 16:28             ` Marco Elver [this message]
2020-12-08 19:06             ` Marco Elver
2020-12-09 12:47               ` Marco Elver
2020-12-10 16:51                 ` Marco Elver
2020-12-10 17:14                   ` Eric Dumazet
2020-12-10 19:01                     ` Marco Elver
2020-12-14 10:09                       ` Marco Elver
2020-12-14 10:47                         ` Eric Dumazet
2021-01-11  8:55                           ` Marco Elver
2021-02-03 10:25                         ` Marco Elver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=X85YL2GZHXpgZYlm@elver.google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=glider@google.com \
    --cc=jannh@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=syzbot+7b99aafdcc2eedea6178@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.