On 08/01/2018 03:44 AM, Paolo Abeni wrote:

On Wed, 2018-08-01 at 10:35 +0000, Marcel Hellwig wrote:

quoted

quoted

quoted

[<c0228adc>] (udp_recvmsg+0x284/0x33c) from [<c02306e0>] (inet_recvmsg+0x38/0x4c): net/ipv4/udp.c:1234

             sin->sin_addr.s_addr = ip_hdr(skb)->saddr;

Unaligned access trap (virtual address c14fe63a), so either sin or ip_hdr(skb) are not on a 32bit alignment

Can you produce the disassembly of the trapping instruction ?

https://gist.github.com/hellow554/6b11c6c0827d5db80a7e66f71f5636ff#file-net_uipv4_udp-lst-L1892-L1895

		sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
c0228ad8:	e5943080 	ldr	r3, [r4, #128]	; 0x80
c0228adc:	e593300c 	ldr	r3, [r3, #12]
c0228ae0: 	e5823004	str	r3, [r2, #4]

I *think* pskb_trim_rcsum() in __udp4_lib_rcv() can copy the ipv4
header to an unaligned address, for cloned skbs. If I understood
correctly the relevant socket is a mcast one, so cloned skbs can land
there.

kmalloc() should return aligned pointer.

pskb_expand_head() should allocate aligned skb->head

So pskb_expand_head() should keep whatever offset was provided in the source skb 

( Driver called skb_reserve() or similar function)