From: Sowmini Varadhan
Date: Tue, 23 Feb 2016 18:59:46 -0500
> But then it's odd that the struct sizes (esp of things like
> request_sock, which are not config dependant) are not the same.
Every structure that has a lock, or something that contains a lock
(such as a timer or whatever), has a la
> > Since there are no config-dependent difference in the struct, maybe it's
> > a compiler version difference for padding/optimization instead?
>
> Changing the layout of a structure would break ABI, so unlikely.
>
> I've never used crash, so I have no idea where it gets it's
> information from
From: Sowmini Varadhan
Date: Tue, 23 Feb 2016 15:53:29 -0500
> On (02/23/16 22:51), mr...@linux.ee wrote:
>> Since there are no config-dependent difference in the struct, maybe it's
>> a compiler version difference for padding/optimization instead?
>
> possibly. The v440 is using a Debian 4.6.
From: mr...@linux.ee
Date: Tue, 23 Feb 2016 22:51:01 +0200 (EET)
>> > Indeed, the kernel is 64-bit in both cases.
>> > And the userland bit-arity has no relevance whatsoever for this bug.
>>
>> hang on; The sizeof (and offsetof) values I listed were obtained either
>> from /usr/bin/crash (on the
> > Indeed, the kernel is 64-bit in both cases.
> > And the userland bit-arity has no relevance whatsoever for this bug.
>
> hang on; The sizeof (and offsetof) values I listed were obtained either
> from /usr/bin/crash (on the T5) or from simple printk's of the structures
> in the case of the v440
On (02/23/16 22:51), mr...@linux.ee wrote:
> Since there are no config-dependent difference in the struct, maybe it's
> a compiler version difference for padding/optimization instead?
possibly. The v440 is using a Debian 4.6.3-14 gcc, while the
T5 is using "4.4.7 20120313 (Red Hat 4.4.7-4)"
But
> > However, I have not succeeded in reproducing the problem at will - git
> > checkout of another release + subsequent compile still does not trigger
> > it. But if it is the same problem, it seems to go int triple fault or
> > something similar for me to cause it reboot with no trace in the
>
> > Indeed, the kernel is 64-bit in both cases.
> > And the userland bit-arity has no relevance whatsoever for this bug.
>
> hang on; The sizeof (and offsetof) values I listed were obtained either
> from /usr/bin/crash (on the T5) or from simple printk's of the structures
> in the case of the v440
On (02/23/16 15:20), David Miller wrote:
> Indeed, the kernel is 64-bit in both cases.
> And the userland bit-arity has no relevance whatsoever for this bug.
hang on; The sizeof (and offsetof) values I listed were obtained either
from /usr/bin/crash (on the T5) or from simple printk's of the struc
From: Meelis Roos
Date: Tue, 23 Feb 2016 21:36:24 +0200 (EET)
> Sorry, I do not understand - what is 32-bit on V440? The kernel should
> be 64-bit since it's sun4u.
Indeed, the kernel is 64-bit in both cases.
And the userland bit-arity has no relevance whatsoever for this bug.
> I figured out what's the root-cause of my panics.
Great!
> sizeof 32-bit64-bit
> ---
> request_sock 256 312
> inet_request_sock 272 328
> sock 688 1216
>
> And offsetof sk_p
On (02/23/16 21:36), Meelis Roos wrote:
> Sorry, I do not understand - what is 32-bit on V440? The kernel should
> be 64-bit since it's sun4u.
v440# getconf LONG_BIT
32
v440# uname -a
Linux v440 4.4.0-rc3-roos-00790-g264a4ac-dirty #200 SMP Mon Feb 22 19:06:21 PST
2016 sparc64 GNU/Linux
> Howe
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 (a
13 matches
Mail list logo
