I figured out what's the root-cause of my panics. In my case, for the stack shown in http://marc.info/?l=linux-sparc&m=145610295109214&w=2 (which also has all the details about the issue), tcp_make_synack has been called with attach_req set to true so it sets up the skb->sk via: if (attach_req) { skb_set_owner_w(skb, req_to_sk(req)); } else { /* .. */ Now, req is a struct inet_request_sock, and we are casting this as a struct sock, to later get the ->sk_policy[1] in the xfrm code. Consider the sizes of these structures between 32 and 64 bits: sizeof 32-bit 64-bit ------------------------------------------- request_sock 256 312 inet_request_sock 272 328 sock 688 1216 And offsetof sk_policy[1] is 256 on the 32-bit v440, whereas it is 520 on my 64-bit T5. Thus on the v440, the sk_policy[1] is pointing at somewhere in the middle of stuff set up by tcp_openreq_init() (the ireq flags initialization). Even on the 64-bit arch, trying to do req_to_sk(req) and accessing fields beyond the sock_common, e.g., between offset 312 and 328 may not give you the fields you are looking for? so how is this supposed to work? (Evidently it worked for Meelis before, but I dont know if that was before or after commit 9e17f8a475). --Sowmini -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
