All of lore.kernel.org
 help / color / mirror / Atom feed
* Question on comment in dev_queue_xmit_nit
@ 2022-02-08 23:51 Ben Greear
  2022-02-09  0:13 ` Ben Greear
  0 siblings, 1 reply; 2+ messages in thread
From: Ben Greear @ 2022-02-08 23:51 UTC (permalink / raw)
  To: Salam Noureddine; +Cc: netdev

Hello Salam,

After an 8 day torture test on a hacked 5.15.7+ kernel doing wifi testing, our system crashed
in the dev_queue_xmit_nit method, evidently 'skb' is NULL.

gdb claims it is the 'skb2 = skb_clone ...' line below.  Now, this crash could
be fault of my local patches or other random things, but the comment caught
my attention.  It is cloning once per loop as far as I can see, so why the comment
about 'done only once' ?

		/* need to clone skb, done only once */
		skb2 = skb_clone(skb, GFP_ATOMIC);
		if (!skb2)
			goto out_unlock;

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Question on comment in dev_queue_xmit_nit
  2022-02-08 23:51 Question on comment in dev_queue_xmit_nit Ben Greear
@ 2022-02-09  0:13 ` Ben Greear
  0 siblings, 0 replies; 2+ messages in thread
From: Ben Greear @ 2022-02-09  0:13 UTC (permalink / raw)
  To: Salam Noureddine; +Cc: netdev

On 2/8/22 3:51 PM, Ben Greear wrote:
> Hello Salam,
> 
> After an 8 day torture test on a hacked 5.15.7+ kernel doing wifi testing, our system crashed
> in the dev_queue_xmit_nit method, evidently 'skb' is NULL.
> 
> gdb claims it is the 'skb2 = skb_clone ...' line below.  Now, this crash could
> be fault of my local patches or other random things, but the comment caught
> my attention.  It is cloning once per loop as far as I can see, so why the comment
> about 'done only once' ?
> 
>          /* need to clone skb, done only once */
>          skb2 = skb_clone(skb, GFP_ATOMIC);
>          if (!skb2)
>              goto out_unlock;
> 
> Thanks,
> Ben
> 

My question above stands, but I was looking at wrong stack frame for the actual
crash location.  It is actually dying down in slub.c, so I guess it is some nasty
memory corruption and this crash site is probably not actually related to the cause...

(gdb) l *(dev_queue_xmit_nit+0xf4)
0xffffffff819bf4d4 is in dev_queue_xmit_nit (/home2/greearb/git/linux-5.15.dev.y/net/core/dev.c:2305).
2300				pt_prev = ptype;
2301				continue;
2302			}
2303	
2304			/* need to clone skb, done only once */
2305			skb2 = skb_clone(skb, GFP_ATOMIC);
2306			if (!skb2)
2307				goto out_unlock;
2308	
2309			net_timestamp_set(skb2);
(gdb) l *(skb_clone+0x47)
0xffffffff819a9ff7 is in skb_clone (/home2/greearb/git/linux-5.15.dev.y/net/core/skbuff.c:1521).
1516			refcount_set(&fclones->fclone_ref, 2);
1517		} else {
1518			if (skb_pfmemalloc(skb))
1519				gfp_mask |= __GFP_MEMALLOC;
1520	
1521			n = kmem_cache_alloc(skbuff_head_cache, gfp_mask);
1522			if (!n)
1523				return NULL;
1524	
1525			n->fclone = SKB_FCLONE_UNAVAILABLE;
(gdb) l *(kmem_cache_alloc+0x71)
0xffffffff8133b821 is in kmem_cache_alloc (/home2/greearb/git/linux-5.15.dev.y/mm/slub.c:352).
347	}
348	
349	static inline void *get_freepointer(struct kmem_cache *s, void *object)
350	{
351		object = kasan_reset_tag(object);
352		return freelist_dereference(s, object + s->offset);
353	}
354	

Thanks,
Ben

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-02-09  0:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-08 23:51 Question on comment in dev_queue_xmit_nit Ben Greear
2022-02-09  0:13 ` Ben Greear

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.