On Mon, 2015-12-14 at 11:28 -0500, dwil...@us.ibm.com wrote:
> Eric -
> With this patch applied the test ran clean for 2 days.
>
> Thanks for your help.
Excellent !
Thanks a lot David, I will submit it formally with your 'Reported-by'
and 'Tested-by'
I have no idea why this took so long to dis
Eric -
With this patch applied the test ran clean for 2 days.
Thanks for your help.
Quoting Eric Dumazet :
On Fri, 2015-12-11 at 07:48 -0800, Eric Dumazet wrote:
On Fri, 2015-12-11 at 06:23 -0800, Eric Dumazet wrote:
> On Sun, 2015-12-06 at 17:58 -0800, Eric Dumazet wrote:
> > On Sun, 2015-12
On Fri, 2015-12-11 at 07:48 -0800, Eric Dumazet wrote:
> On Fri, 2015-12-11 at 06:23 -0800, Eric Dumazet wrote:
> > On Sun, 2015-12-06 at 17:58 -0800, Eric Dumazet wrote:
> > > On Sun, 2015-12-06 at 13:03 -0800, Eric Dumazet wrote:
> > >
> > > > But then when later we promote a skb->dst to a refct
On Fri, 2015-12-11 at 06:23 -0800, Eric Dumazet wrote:
> On Sun, 2015-12-06 at 17:58 -0800, Eric Dumazet wrote:
> > On Sun, 2015-12-06 at 13:03 -0800, Eric Dumazet wrote:
> >
> > > But then when later we promote a skb->dst to a refctounted one
> > > (skb_dst_force(), we might make sure we abort th
On Sun, 2015-12-06 at 17:58 -0800, Eric Dumazet wrote:
> On Sun, 2015-12-06 at 13:03 -0800, Eric Dumazet wrote:
>
> > But then when later we promote a skb->dst to a refctounted one
> > (skb_dst_force(), we might make sure we abort the operation if __refcnt
> > == 0 ( and DST_NOCACHE is in dst->fla
On Sun, 2015-12-06 at 13:03 -0800, Eric Dumazet wrote:
> But then when later we promote a skb->dst to a refctounted one
> (skb_dst_force(), we might make sure we abort the operation if __refcnt
> == 0 ( and DST_NOCACHE is in dst->flags)
>
Minimum patch would be :
diff --git a/include/net/dst.h
On Sun, 2015-12-06 at 13:26 -0500, dwil...@us.ibm.com wrote:
> Hi-
>
> I am seeing a crash on a distro V4.2.3 kernel caused by a double
> release of a dst_entry. In ipv4_dst_destroy() the call to
> list_empty() finds a poisoned next pointer, indicating the dst_entry
> has already been remov
Hi-
I am seeing a crash on a distro V4.2.3 kernel caused by a double
release of a dst_entry. In ipv4_dst_destroy() the call to
list_empty() finds a poisoned next pointer, indicating the dst_entry
has already been removed from the list and freed. The crash occurs
18 to 24 hours into a r
