[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171211.162851.2062412815828426060.davem@davemloft.net>
Date: Mon, 11 Dec 2017 16:28:51 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: joseph.salisbury@...onical.com
Cc: edumazet@...gle.com, dvyukov@...gle.com, willemb@...gle.com,
daniel@...earbox.net, jakub.kicinski@...ronome.com,
linux@...musvillemoes.dk, john.fastabend@...il.com, me@...in.cc,
idosch@...lanox.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
stable@...r.kernel.org, 1715609@...s.launchpad.net
Subject: Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce
skb_warn_bad_offload() noise
From: Joseph Salisbury <joseph.salisbury@...onical.com>
Date: Mon, 11 Dec 2017 15:35:34 -0500
> A kernel bug report was opened against Ubuntu [0]. It was found that
> reverting the following commit resolved this bug:
>
> commit b2504a5dbef3305ef41988ad270b0e8ec289331c
> Author: Eric Dumazet <edumazet@...gle.com>
> Date: Tue Jan 31 10:20:32 2017 -0800
>
> net: reduce skb_warn_bad_offload() noise
>
>
> The regression was introduced as of v4.11-rc1 and still exists in
> current mainline.
>
> I was hoping to get your feedback, since you are the patch author. Do
> you think gathering any additional data will help diagnose this issue,
> or would it be best to submit a revert request?
>
> This commit did in fact resolve another bug[1], but in the process
> introduced this regression.
It helps if you can consolidate the information obtained in your bug
tracking here in the email so that people on this list can get an idea
of what the problem scope might be without having to go to your
special bug tracking site.
This is really not about us being snobs about this mailing list, it's
about you wanting to get a result. And you'll get a better result
faster if you post the details here on the lsit because most
developers are not going to go to your bug tracking site to read the
bug comments.
Also, this isn't a functional regression, it is just that we are
generating warnings that we didn't before. It doesn't mean that
Eric's patch is wrong, it could just be that his new check is
triggering for a bug that has always been there.
Scanning the bug myself it seems that the critical required component
is IPSEC, and IPSEC has it's own way of doing segmentation offload.
Thanks.
Powered by blists - more mailing lists