FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 01-26-2012, 10:49 AM
"Karlsson, Jan"
 
Default Problem in command net -s

Hi Dave
*
I found a problem with the net -s command. It concerns line 1451 in net.c
*
*** struct_socket = inode - SIZE(socket);
*
As I understand it we have the type
* struct socket_alloc {
* ****struct socket socket;
*** **struct inode vfs_inode;
* }
and we have the address of the second field and want the address of the first. The calculation, using the size of the socket struct, used in net.c require that the second field is aligned directly after the first field. This is unfortunately not true in cases I have seen. By changing the line 1451 to:
*
*** struct_socket = inode - MEMBER_OFFSET("socket_alloc", "vfs_inode");
*
things work better.
*
Is this something you would like to change in Crash? I assume you will move the offset calculation to somewhere else so it is only performed once.
*
Jan
*
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-26-2012, 12:47 PM
Dave Anderson
 
Default Problem in command net -s

----- Original Message -----
>
>
>
>
> Hi Dave
>
> I found a problem with the net -s command. It concerns line 1451 in net.c
>
> struct_socket = inode - SIZE(socket);
>
> As I understand it we have the type
>
> struct socket_alloc {
> struct socket socket;
> struct inode vfs_inode;
> }
>
> and we have the address of the second field and want the address of
> the first. The calculation, using the size of the socket struct,
> used in net.c require that the second field is aligned directly
> after the first field. This is unfortunately not true in cases I
> have seen. By changing the line 1451 to:
>
> struct_socket = inode - MEMBER_OFFSET("socket_alloc", "vfs_inode");
>
> things work better.
>
> Is this something you would like to change in Crash? I assume you
> will move the offset calculation to somewhere else so it is only
> performed once.

Probably so...

Although I'm curious -- what kernel version do you see this on?
It works as expected on RHEL5, RHEL6 and a Fedora 16 3.1.7-based
kernel. What do you see when you do this:

crash> socket_alloc -o
struct socket_alloc {
[0] struct socket socket;
[48] struct inode vfs_inode;
}
SIZE: 616
crash> socket
struct socket {
socket_state state;
short int type;
long unsigned int flags;
struct socket_wq *wq;
struct file *file;
struct sock *sk;
const struct proto_ops *ops;
}
SIZE: 48
crash>

And just for the changelog description, what havoc does it wreak?

Thanks,
Dave


> Jan
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-26-2012, 03:35 PM
Dave Anderson
 
Default Problem in command net -s

----- Original Message -----
>
>
> ----- Original Message -----
> >
> > Hi Dave
> >
> > I found a problem with the net -s command. It concerns line 1451 in net.c
> >
> > struct_socket = inode - SIZE(socket);
> >
> > As I understand it we have the type
> >
> > struct socket_alloc {
> > struct socket socket;
> > struct inode vfs_inode;
> > }
> >
> > and we have the address of the second field and want the address of
> > the first. The calculation, using the size of the socket struct,
> > used in net.c require that the second field is aligned directly
> > after the first field. This is unfortunately not true in cases I
> > have seen. By changing the line 1451 to:
> >
> > struct_socket = inode - MEMBER_OFFSET("socket_alloc", "vfs_inode");
> >
> > things work better.
> >
> > Is this something you would like to change in Crash? I assume you
> > will move the offset calculation to somewhere else so it is only
> > performed once.
>
> Probably so...
>
> Although I'm curious -- what kernel version do you see this on?
> It works as expected on RHEL5, RHEL6 and a Fedora 16 3.1.7-based
> kernel. What do you see when you do this:
>
> crash> socket_alloc -o
> struct socket_alloc {
> [0] struct socket socket;
> [48] struct inode vfs_inode;
> }
> SIZE: 616
> crash> socket
> struct socket {
> socket_state state;
> short int type;
> long unsigned int flags;
> struct socket_wq *wq;
> struct file *file;
> struct sock *sk;
> const struct proto_ops *ops;
> }
> SIZE: 48
> crash>
>
> And just for the changelog description, what havoc does it wreak?
>
> Thanks,
> Dave

Interesing -- I see the problem with the 3 sample ARM dumpfiles I have
on hand. I would have thought the same issue would be seen with
a 32-bit x86, but it looks like it's an ARM compiler issue?

Check this comparison -- while the inode structure is different in
these two kernels, the socket structure is the same:

X86: ARM:

crash> socket_alloc -o crash> socket_alloc -o
struct socket_alloc { struct socket_alloc {
[0] struct socket socket; [0] struct socket socket;
[28] struct inode vfs_inode; [32] struct inode vfs_inode;
} }
SIZE: 388 SIZE: 584
crash> socket -o crash> socket -o
struct socket { struct socket {
[0] socket_state state; [0] socket_state state;
[4] short int type; [4] short int type;
[8] long unsigned int flags; [8] long unsigned int flags;
[12] struct socket_wq *wq; [12] struct socket_wq *wq;
[16] struct file *file; [16] struct file *file;
[20] struct sock *sk; [20] struct sock *sk;
[24] const struct proto_ops *ops; [24] const struct proto_ops *ops;
} }
SIZE: 28 SIZE: 28
crash> crash>

But for whatever reason, the ARM kernel pushes the vfs_inode to
offset 32 even though the preceding socket structure is 28 bytes long.

Anyway, using the offset instead of the size is a better idea, so I'll
make that change.

Although -- my sample ARM dumpfiles don't have any tasks with open sockets,
so I still am interested in seeing what the failure looks like for the
changelog entry.

Thanks,
Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-27-2012, 06:27 AM
"Karlsson, Jan"
 
Default Problem in command net -s

This problem effects net -s and net -S, as the pointer to the socket is 4 bytes off, which of course means that all information about the socket is garbage. Example:

Before patch:
crash> net -s
PID: 377 TASK: cc4dc360 CPU: 0 COMMAND: "NetworkStats"
FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT DESTINATION-PORT
....
101 cf55b784 cc450a40 214324:23124
....

After patch:
crash> net -s
PID: 377 TASK: cc4dc360 CPU: 0 COMMAND: "NetworkStats"
FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT DESTINATION-PORT
....
101 cf55b780 cc450a40 INET6GRAM 0:0:0:0:0:0:0:0-50170 0:0:0:0:0:0:0:0-0
....

This problem was really found by Pavel Modilaynen (Pavel.Modilaynen@sonyericsson.com) working in the same group as I do. We saw the same kind of information using struct -o that you found yourself. The only reason I can think of for the 8-byte alignment is that the struct vfs_inode itself starts with an 8-byte struct.

That we might not have exactly the same alignment rules on ARM and x86 worries me. The whole idea to debug an ARM kernel using an x86 machine is based on the assumption that sizes of types, alignment rules, and so on are the same.

Jan


-----Original Message-----
From: crash-utility-bounces@redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: torsdag den 26 januari 2012 17:36
To: Discussion list for crash utility usage, maintenance and development
Cc: Fänge, Thomas
Subject: Re: [Crash-utility] Problem in command net -s



----- Original Message -----
>
>
> ----- Original Message -----
> >
> > Hi Dave
> >
> > I found a problem with the net -s command. It concerns line 1451 in net.c
> >
> > struct_socket = inode - SIZE(socket);
> >
> > As I understand it we have the type
> >
> > struct socket_alloc {
> > struct socket socket;
> > struct inode vfs_inode;
> > }
> >
> > and we have the address of the second field and want the address of
> > the first. The calculation, using the size of the socket struct,
> > used in net.c require that the second field is aligned directly
> > after the first field. This is unfortunately not true in cases I
> > have seen. By changing the line 1451 to:
> >
> > struct_socket = inode - MEMBER_OFFSET("socket_alloc", "vfs_inode");
> >
> > things work better.
> >
> > Is this something you would like to change in Crash? I assume you
> > will move the offset calculation to somewhere else so it is only
> > performed once.
>
> Probably so...
>
> Although I'm curious -- what kernel version do you see this on?
> It works as expected on RHEL5, RHEL6 and a Fedora 16 3.1.7-based
> kernel. What do you see when you do this:
>
> crash> socket_alloc -o
> struct socket_alloc {
> [0] struct socket socket;
> [48] struct inode vfs_inode;
> }
> SIZE: 616
> crash> socket
> struct socket {
> socket_state state;
> short int type;
> long unsigned int flags;
> struct socket_wq *wq;
> struct file *file;
> struct sock *sk;
> const struct proto_ops *ops;
> }
> SIZE: 48
> crash>
>
> And just for the changelog description, what havoc does it wreak?
>
> Thanks,
> Dave

Interesing -- I see the problem with the 3 sample ARM dumpfiles I have
on hand. I would have thought the same issue would be seen with
a 32-bit x86, but it looks like it's an ARM compiler issue?

Check this comparison -- while the inode structure is different in
these two kernels, the socket structure is the same:

X86: ARM:

crash> socket_alloc -o crash> socket_alloc -o
struct socket_alloc { struct socket_alloc {
[0] struct socket socket; [0] struct socket socket;
[28] struct inode vfs_inode; [32] struct inode vfs_inode;
} }
SIZE: 388 SIZE: 584
crash> socket -o crash> socket -o
struct socket { struct socket {
[0] socket_state state; [0] socket_state state;
[4] short int type; [4] short int type;
[8] long unsigned int flags; [8] long unsigned int flags;
[12] struct socket_wq *wq; [12] struct socket_wq *wq;
[16] struct file *file; [16] struct file *file;
[20] struct sock *sk; [20] struct sock *sk;
[24] const struct proto_ops *ops; [24] const struct proto_ops *ops;
} }
SIZE: 28 SIZE: 28
crash> crash>

But for whatever reason, the ARM kernel pushes the vfs_inode to
offset 32 even though the preceding socket structure is 28 bytes long.

Anyway, using the offset instead of the size is a better idea, so I'll
make that change.

Although -- my sample ARM dumpfiles don't have any tasks with open sockets,
so I still am interested in seeing what the failure looks like for the
changelog entry.

Thanks,
Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-27-2012, 09:28 AM
Per Fransson
 
Default Problem in command net -s

Hi,

On Fri, Jan 27, 2012 at 8:27 AM, Karlsson, Jan
<Jan.Karlsson@sonyericsson.com> wrote:
> This problem was really found by Pavel Modilaynen (Pavel.Modilaynen@sonyericsson.com) working in the same group as I do. We saw the same kind of information using struct -o that you found yourself. The only reason I can think of for the 8-byte alignment is that the struct vfs_inode itself starts with an 8-byte struct.
>
> That we might not have exactly the same alignment rules on ARM and x86 worries me. The whole idea to debug an ARM kernel using an x86 machine is based on the assumption that sizes of types, alignment rules, and so on are the same.
>
> Jan
>
>

I guess this is the result of the requirements of the ARM ABI found here:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

Table 1 in section 4.1 says that double-words should be 8 byte
aligned. Table 3 in section 7.1.1 maps double words to C long longs.
Section 4.3.1 says that aggregates (of which I believe structs are an
example) shall have the alignment of its "most-aligned component",
which is natural. struct inode contains at least one u64 that I can
see.

Regards,
Per

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-27-2012, 10:07 AM
"Karlsson, Jan"
 
Default Problem in command net -s

Maybe we should then build crash with the gcc option -malign-double, as that seems to enforce the same alignment rule also in x86, 32-bit. At least a quick test indicated that for me.

Jan

-----Original Message-----
From: crash-utility-bounces@redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf Of Per Fransson
Sent: fredag den 27 januari 2012 11:29
To: Discussion list for crash utility usage, maintenance and development
Cc: Modilaynen, Pavel; Fänge, Thomas
Subject: Re: [Crash-utility] Problem in command net -s

Hi,

On Fri, Jan 27, 2012 at 8:27 AM, Karlsson, Jan
<Jan.Karlsson@sonyericsson.com> wrote:
> This problem was really found by Pavel Modilaynen (Pavel.Modilaynen@sonyericsson.com) working in the same group as I do. We saw the same kind of information using struct -o that you found yourself. The only reason I can think of for the 8-byte alignment is that the struct vfs_inode itself starts with an 8-byte struct.
>
> That we might not have exactly the same alignment rules on ARM and x86 worries me. The whole idea to debug an ARM kernel using an x86 machine is based on the assumption that sizes of types, alignment rules, and so on are the same.
>
> Jan
>
>

I guess this is the result of the requirements of the ARM ABI found here:

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

Table 1 in section 4.1 says that double-words should be 8 byte
aligned. Table 3 in section 7.1.1 maps double words to C long longs.
Section 4.3.1 says that aggregates (of which I believe structs are an
example) shall have the alignment of its "most-aligned component",
which is natural. struct inode contains at least one u64 that I can
see.

Regards,
Per

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-27-2012, 01:31 PM
Dave Anderson
 
Default Problem in command net -s

----- Original Message -----
> This problem effects net -s and net -S, as the pointer to the socket
> is 4 bytes off, which of course means that all information about the
> socket is garbage. Example:
>
> Before patch:
> crash> net -s
> PID: 377 TASK: cc4dc360 CPU: 0 COMMAND: "NetworkStats"
> FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT
> DESTINATION-PORT
> ....
> 101 cf55b784 cc450a40 214324:23124
> ....
>
> After patch:
> crash> net -s
> PID: 377 TASK: cc4dc360 CPU: 0 COMMAND: "NetworkStats"
> FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT
> DESTINATION-PORT
> ....
> 101 cf55b780 cc450a40 INET6GRAM 0:0:0:0:0:0:0:0-50170
> 0:0:0:0:0:0:0:0-0
> ....

OK, I was just wondering whether it caused a segmentation violation
or something else.

> This problem was really found by Pavel Modilaynen
> (Pavel.Modilaynen@sonyericsson.com) working in the same group as I
> do. We saw the same kind of information using struct -o that you
> found yourself. The only reason I can think of for the 8-byte
> alignment is that the struct vfs_inode itself starts with an 8-byte
> struct.
>
> That we might not have exactly the same alignment rules on ARM and
> x86 worries me. The whole idea to debug an ARM kernel using an x86
> machine is based on the assumption that sizes of types, alignment
> rules, and so on are the same.
>
> Jan

But the same thing would have happened if you were debugging an ARM kernel
using an ARM host, right?

Anyway, I don't think it's a problem. The crash code should have been
using the OFFSET() mechanism to begin with. The SIZE() macro is typically
used for reading the correct amount of data into a buffer, not for this
kind of situation.

Dave


> -----Original Message-----
> From: crash-utility-bounces@redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
> Sent: torsdag den 26 januari 2012 17:36
> To: Discussion list for crash utility usage, maintenance and development
> Cc: Fänge, Thomas
> Subject: Re: [Crash-utility] Problem in command net -s
>
>
>
> ----- Original Message -----
> >
> >
> > ----- Original Message -----
> > >
> > > Hi Dave
> > >
> > > I found a problem with the net -s command. It concerns line 1451 in net.c
> > >
> > > struct_socket = inode - SIZE(socket);
> > >
> > > As I understand it we have the type
> > >
> > > struct socket_alloc {
> > > struct socket socket;
> > > struct inode vfs_inode;
> > > }
> > >
> > > and we have the address of the second field and want the address of
> > > the first. The calculation, using the size of the socket struct,
> > > used in net.c require that the second field is aligned directly
> > > after the first field. This is unfortunately not true in cases I
> > > have seen. By changing the line 1451 to:
> > >
> > > struct_socket = inode - MEMBER_OFFSET("socket_alloc",
> > > "vfs_inode");
> > >
> > > things work better.
> > >
> > > Is this something you would like to change in Crash? I assume you
> > > will move the offset calculation to somewhere else so it is only
> > > performed once.
> >
> > Probably so...
> >
> > Although I'm curious -- what kernel version do you see this on?
> > It works as expected on RHEL5, RHEL6 and a Fedora 16 3.1.7-based
> > kernel. What do you see when you do this:
> >
> > crash> socket_alloc -o
> > struct socket_alloc {
> > [0] struct socket socket;
> > [48] struct inode vfs_inode;
> > }
> > SIZE: 616
> > crash> socket
> > struct socket {
> > socket_state state;
> > short int type;
> > long unsigned int flags;
> > struct socket_wq *wq;
> > struct file *file;
> > struct sock *sk;
> > const struct proto_ops *ops;
> > }
> > SIZE: 48
> > crash>
> >
> > And just for the changelog description, what havoc does it wreak?
> >
> > Thanks,
> > Dave
>
> Interesing -- I see the problem with the 3 sample ARM dumpfiles I have
> on hand. I would have thought the same issue would be seen with
> a 32-bit x86, but it looks like it's an ARM compiler issue?
>
> Check this comparison -- while the inode structure is different in
> these two kernels, the socket structure is the same:
>
> X86: ARM:
>
> crash> socket_alloc -o crash> socket_alloc -o
> struct socket_alloc { struct socket_alloc {
> [0] struct socket socket; [0] struct socket socket;
> [28] struct inode vfs_inode; [32] struct inode vfs_inode;
> } }
> SIZE: 388 SIZE: 584
> crash> socket -o crash> socket -o
> struct socket { struct socket {
> [0] socket_state state; [0] socket_state state;
> [4] short int type; [4] short int type;
> [8] long unsigned int flags; [8] long unsigned int
> flags;
> [12] struct socket_wq *wq; [12] struct socket_wq *wq;
> [16] struct file *file; [16] struct file *file;
> [20] struct sock *sk; [20] struct sock *sk;
> [24] const struct proto_ops *ops; [24] const struct proto_ops
> *ops;
> } }
> SIZE: 28 SIZE: 28
> crash> crash>
>
> But for whatever reason, the ARM kernel pushes the vfs_inode to
> offset 32 even though the preceding socket structure is 28 bytes long.
>
> Anyway, using the offset instead of the size is a better idea, so I'll
> make that change.
>
> Although -- my sample ARM dumpfiles don't have any tasks with open sockets,
> so I still am interested in seeing what the failure looks like for the
> changelog entry.
>
> Thanks,
> Dave

>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 06:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org