Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Crash Utility (http://www.linux-archive.org/crash-utility/)
-   -   add a new command: ipcs (http://www.linux-archive.org/crash-utility/650603-add-new-command-ipcs.html)

qiaonuohan 03-30-2012 02:29 AM

add a new command: ipcs
 
Hello Dave,

I have been working on a new command to provide information of ipc
facilities. Recently, the function displaying shared memory segments has
been implemented.


The output is like below:

crash> ipcs
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES
NATTCH SHM_INODE
ffff8804683b0310 0x00000000 0 7 15 0 600 393216 2
ffff880470512d98
ffff880470987910 0x00000000 32769 6 16 0 600 393216 2
ffff880470512758
ffff880471621190 0x00000000 65538 46 0 0 600 393216 2
ffff880474202d98
ffff8804747f1a50 0x00000000 98307 12 12 0 600 393216 2
ffff880471264758
ffff8804704ad510 0x00000000 131076 96 0 0 600 393216 2
ffff880474094d98


To see more details, please refer to the help information and the patch.

--
--
Regards
Qiao Nuohan

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

Dave Anderson 03-30-2012 07:16 PM

add a new command: ipcs
 
----- Original Message -----
> Hello Dave,
>
> I have been working on a new command to provide information of ipc
> facilities. Recently, the function displaying shared memory segments has
> been implemented.
>
> The output is like below:
>
> crash> ipcs
> ------ Shared Memory Segments ------
> SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE
> ffff8804683b0310 0x00000000 0 7 15 0 600 393216 2 ffff880470512d98
> ffff880470987910 0x00000000 32769 6 16 0 600 393216 2 ffff880470512758
> ffff880471621190 0x00000000 65538 46 0 0 600 393216 2 ffff880474202d98
> ffff8804747f1a50 0x00000000 98307 12 12 0 600 393216 2 ffff880471264758
> ffff8804704ad510 0x00000000 131076 96 0 0 600 393216 2 ffff880474094d98
>
> To see more details, please refer to the help information and the patch.
>
> --
> --
> Regards
> Qiao Nuohan

Hello Qiao,

Interestingly enough, I remember looking into doing something
like this to dump the three IPCS facilities quite a while ago.
And although I cannot recall exactly what my reasons were,
I think I decided against it because there were too many changes
to kernel's IPC code over several kernel versions. So I certainly
appreciate the amount of work that you have done.

I built and tested your patch, and have the following comments.

First, when posting a patch, can you please use the current
upstream version of the crash utility? I think that your
patch must be against crash-6.0.4:

$ patch -p1 < ./0001-add-ipcs-command.patch
patching file Makefile
patching file defs.h
Hunk #1 FAILED at 1662.
Hunk #2 FAILED at 1820.
Hunk #3 succeeded at 3695 (offset 121 lines).
Hunk #4 succeeded at 4055 (offset 2 lines).
2 out of 4 hunks FAILED -- saving rejects to file defs.h.rej
patching file global_data.c
patching file help.c
Hunk #1 succeeded at 5566 (offset 75 lines).
patching file ipcs.c
$

As part of my automated testing process, I run the same command(s),
against ~150 saved dumpfiles consisting of various kernel versions.
And not surprisingly, when testing the "ipcs" command, it failed a
considerable number of times. These are samples of the errors:

ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 281 FUNCTION: ipc_search_array()

ipcs: invalid structure member offset: idr_layer_layer
FILE: ipcs.c LINE: 338 FUNCTION: idr_find()

ipcs: zero-size memory allocation! (called from 53ffb3)

ipcs: invalid kernel virtual address: 8 type: "ipc_id_ary.p"

ipcs: cannot resolve "hugetlbfs_file_operations"

and eventually, when running against a 2.6.24 kernel, the
"ipcs" command just quietly goes into an infinite loop.
(I didn't check where...)

And strangely enough, it worked OK on some RHEL5 dumpfiles, but
failed on other RHEL5 dumpfiles. For example, on a 2.6.18-157.el5
kernel it failed like this:

crash> ipcs
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE
ipcs: zero-size memory allocation! (called from 53ffb3)

which comes from the GETBUF() call ipc_search_array(). And it's not
because there's no IPC segments existing, because many of the dumpfiles
just show this:

crash> ipcs
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE

In that case, you should show something like "(none allocated)" after
the header.

Anyway, it would be preferable if the command worked on all 2.6-era kernels,
but it should at least work on all kernels from RHEL5 (2.6.18) and up.

The command output violates the 80-column rule. If the data displayed
by a command is fixed (i.e., without things like file pathnames) , then
it should be formatted so that it fits into 80-columns:

(1) So in this case, I would omit the SHM_INODE column
completely. If the user actually wants to see the inode, it
can be found easily enough by following the trail from the
shmid_kernel structure.
(2) Don't waste space in the output with the "0x" prepended to
the KEY value -- if you feel that a particular column's value
is not obviously decimal or hexadecimal, then indicate what
it is in the command's help page.
(3) Your SHMID column should probably be made larger:

12345678901234567890123456789012345678901234567890 123456789012345678901234567890

crash> ipcs
------ Shared Memory Segments ------
SHM_KERNEL KEY SHMID RSS SWAP UID PERMS BYTES NATTCH SHM_INODE
ffff81003c537390 0x00000000 32768 0 96 42 600 393216 2 ffff81003bc3a718
ffff8100230cf1d0 0x7800801c 65537 0 1 0 666 4096 0 ffff81003d4cd418
ffff8100101b35d0 0x6600800a 135036930 0 1 0 666 4096 0 ffff81003c861118
ffff81002428b790 0x7600801e 269975555 1 0 0 666 4096 0 ffff81003bc3a118
ffff810018f9a0d0 0x6a0081bd 393221 0 0 99 600 8192 0 ffff81003d919a18
ffff81003c429d90 0x71008105 135364615 0 0 99 600 8192 0 ffff81002103a418
ffff8100300256d0 0x7000801c 270303241 0 0 99 600 8192 0 ffff810031304118
crash>

Also, when creating new functions, can you please put the
function name on its own line? It helps when using "grep"
or "vi" to quickly find the actual function if the function
name is the first thing on the line. In other words,
change all instances like this:

static void ipc_search_array(ulong ipc_ids_p, int id, int (*fn)(ulong, int))
{

to this:

static void
ipc_search_array(ulong ipc_ids_p, int id, int (*fn)(ulong, int))
{

Also, whenever you add new entries to the offset_table[] or size_table[]
arrays, please dump their values in dump_offset_table() so that their
values can be seen by "help -o". It makes it much easier to debug
offset-related bugs and/or kernel changes over time.

And if the command is going to be "ipcs", then it should deal
with all 3 SYSV IPCS facilities. I wouldn't consider taking
a half-baked command with just the shared memory stats.

A few other minor nits:

+ /*
+ * global data
+ */
+ static int idr_bits;
+ static ulong init_flags;
+ static ulong hugetlbfs_f_op_addr;
+ static ulong shm_f_op_addr;
+ static ulong shm_f_op_huge_addr;
+ static int use_shm_f_op;
+ static struct total_shm_info total_shm_info;
+ static unsigned int page_size;
+ static unsigned int page_shift;

Can you put these items into one global data structure,
and make them available for dumping during runtime with
a "help" command? For now, you can add a "hidden" option
letter to cmd_ipcs() to dump them.

And page_size and page_shift are redundant -- you can just
use the existing PAGESIZE() and PAGESHIFT() macros.

Here's my suggestion. Work on this command as a standalone
extension module. It will be very easy to transform what you
have in place now into an extension module -- the most work
will be involved with creating your own "MYOFFSET()" and
MYSIZE() macros, and storing your offsets and sizes locally.
And if/when it eventually is worthy of making it a new crash
command or option, then it will be mostly a matter of doing a
global search-and-replace of your MYOFFSET()/MYSIZE() callers
with OFFSET() and SIZE(), and putting the members/sizes into
the global offset_table[] and size_table[] arrays. And in the
meantime, you won't have to constantly update the patch for each
subsequent crash release.

Thanks,
Dave


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

qiaonuohan 04-06-2012 10:10 AM

add a new command: ipcs
 
Hello Dave,

I did some effort to change the patch. Now it can support all of the
three facilitis. I also check the kernel from 2.6.18 and up to find the
bugs and fix it. So please refer to the attachment.


--
--
Regards
Qiao Nuohan
--------------------------------------------------
Qiao Nuohan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China
TEL: +86+25-86630566-8526 FUJITSU
INTERNAL: 7998-8526 FAX: +86+25-83317685
EMail: qiaonuohan@cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended
recipient(s) only and may contain information that
is privileged, confidential and exempt from
disclosure under applicable law. If you are not an
intended recipient of this communication, you are
hereby notified that any dissemination,
distribution or copying hereof is strictly
prohibited. If you have received this communication
in error, please notify me by reply e-mail,
permanently delete this communication from your
system, and destroy any hard copies you may have
printed


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

Dave Anderson 04-10-2012 07:20 PM

add a new command: ipcs
 
----- Original Message -----
> Hello Dave,
>
> I did some effort to change the patch. Now it can support all of the
> three facilitis. I also check the kernel from 2.6.18 and up to find the
> bugs and fix it. So please refer to the attachment.
>
> --
> --
> Regards
> Qiao Nuohan

Hello Qiao,

First, I don't understand why you dropped the shmid_kernel address
display from the shared memory output? I only requested that you drop
the *inode* address -- because it could be ascertained from the shmid_kernel
structure.

In most crash commands, the relevant "head" data structure address
is displayed, along with a few other key values. The data structure
addresses are important for kernel debugging -- with your output,
statistics are dumped, but if the user actually needed to debug the
IPC facility, there would be no "starting point" kernel virtual address
to work from.

That being the case, the shared memory output should show the
"shmid_kernel" address, the semaphore output should show the
"sem_array" address, and the message queue output should show the
"msg_queue" address. They should be shown in the first column of
each display (similar to the SHMID_KERNEL you showed in your first
patch) and the output restricted to 80 columns.

Secondly, with respect to testing it against my sample set of kernels,
these are the errors that I still see:

(a) On these kernel versions:

2.6.9-89.ELxenU
2.6.15-1.2054_FC5
2.6.16.33-xen
2.6.18-1.2714.el5xen
2.6.18-36.el5xen
2.6.18-58.el5xen
2.6.18-152.el5xen
2.6.31 uniprocessor kernel

the command fails immediatedly with this error:

ipcs: cannot resolve "hugetlbfs_file_operations"


(b) On *all* RHEL5 2.6.18-era kernels, the message queue display
always fails like this:

------ Message Queues --------
KEY MSQID UID PERMS USED-BYTES MESSAGES
ipcs: invalid structure member offset: kern_ipc_perm_id
FILE: ipcs.c LINE: 899 FUNCTION: get_msg_info()


(c) On this 2.6.36-0.16.rc3.git0.fc15 Fedora kernel, it shows:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH STATUS
ipcs: invalid kernel virtual address: 10 type: "nsproxy.ipc_ns"


(d) On *all* RHEL4 2.6.9-era and SLES9 2.6.5-era kernels, the command fail like this:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH STATUS
ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()

or this:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH STATUS
(none allocated)------ Semaphore Arrays --------
KEY SEMID UID PERMS NSEMS
ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()


It would be preferable if you could support all 2.6-era kernels, but if not,
the command should handle them more gracefully by pre-verifying the offsets
before using them, and if they are invalid, then use the option_not_supported()
routine.

Thanks,
Dave

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

Dave Anderson 04-10-2012 08:00 PM

add a new command: ipcs
 
----- Original Message -----
...
>
> It would be preferable if you could support all 2.6-era kernels, but if not,
> the command should handle them more gracefully by pre-verifying the offsets
> before using them, and if they are invalid, then use the option_not_supported()
> routine.

I should note that I *only* tested the "ipcs" command entered alone.

Anyway, I now see that you separated the shared memory display into two
options, -m and -M. I don't believe that is necessary -- the first patch that
you posted gave enough basic information. If you want to expand it, perhaps the
extra data that is shown by "-M" option could be included in the "-i id" output?
And for that matter, the -u data could also be contained in the "-i id" output?
That way the basic shared memory data could be shown by "ipcs [-m]" option, and
a fully-exploded display could be done by the "-i id" qualifier because it
wouldn't have to be restricted to one line.

I also wish you had followed my original suggestion and made this into an extension
module first. If you do that, you could just post a single "ipcs.c" command that
could be dropped into the "extensions" subdirectory, and built with "make extensions".
There has not been a new command added to the crash utility in many years, and
it's going to be difficult to accept this as a built-in command until it first
goes through a lot of testing, usage, improvement, etc. If it were an extension
module, it could be stored on the extensions web page immediately for people
to use and test.

Also, if you are not going to support the earlier 2.6-era kernels, then
the command_not_supported() function would be preferable to option_not_supported().

Thanks,
Dave

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

qiaonuohan 04-11-2012 09:06 AM

add a new command: ipcs
 
Hello Dave,

I cannot get all kernels at hand. So I have to ask you about the code.
Please show me.




(a) On these kernel versions:

2.6.9-89.ELxenU
2.6.15-1.2054_FC5
2.6.16.33-xen
2.6.18-1.2714.el5xen
2.6.18-36.el5xen
2.6.18-58.el5xen
2.6.18-152.el5xen
2.6.31 uniprocessor kernel

the command fails immediatedly with this error:

ipcs: cannot resolve "hugetlbfs_file_operations"


(b) On *all* RHEL5 2.6.18-era kernels, the message queue display
always fails like this:

------ Message Queues --------
KEY MSQID UID PERMS USED-BYTES MESSAGES
ipcs: invalid structure member offset: kern_ipc_perm_id
FILE: ipcs.c LINE: 899 FUNCTION: get_msg_info()


I want to see the struct msg_queue and struct struct kern_ipc_perm.




(c) On this 2.6.36-0.16.rc3.git0.fc15 Fedora kernel, it shows:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH STATUS
ipcs: invalid kernel virtual address: 10 type: "nsproxy.ipc_ns"


what is struct nsproxy? Or is there any symbol referring to ipc_ns?




(d) On *all* RHEL4 2.6.9-era and SLES9 2.6.5-era kernels, the command fail like this:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH STATUS
ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()

or this:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH STATUS
(none allocated)------ Semaphore Arrays --------
KEY SEMID UID PERMS NSEMS
ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()



what is struct ipc_id? And what is entries in struct ipc_id or something
similar to it?




It would be preferable if you could support all 2.6-era kernels, but if not,
the command should handle them more gracefully by pre-verifying the offsets
before using them, and if they are invalid, then use the option_not_supported()
routine.



--
--
Regards
Qiao Nuohan

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

qiaonuohan 04-11-2012 09:39 AM

add a new command: ipcs
 
Sorry, I made some mistake.

At 2012-4-11 17:06, qiaonuohan wrote:


what is struct nsproxy? Or is there any symbol referring to ipc_ns?


I want to know how does the kernel get struct ipc_ids. the previous and
the hind kernel uses current->nsproxy->ipc_ns to get the pointer to
struct ipc_namespace and then use a macro shm_ids to get struct ipc_ids.
What about this kernel?







(d) On *all* RHEL4 2.6.9-era and SLES9 2.6.5-era kernels, the command
fail like this:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH
STATUS
ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()

or this:

------ Shared Memory Segments ------
KEY SHMID UID PERMS BYTES NATTCH
STATUS
(none allocated)------ Semaphore Arrays --------
KEY SEMID UID PERMS NSEMS
ipcs: invalid structure member offset: ipc_id_ary_p
FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()



what is struct ipc_id? And what is entries in struct ipc_id or something
similar to it?


I mean struct ipc_ids, not ipc_id.


--
--
Regards
Qiao Nuohan
--------------------------------------------------
Qiao Nuohan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China
TEL: +86+25-86630566-8526 FUJITSU
INTERNAL: 7998-8526 FAX: +86+25-83317685
EMail: qiaonuohan@cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended
recipient(s) only and may contain information that
is privileged, confidential and exempt from
disclosure under applicable law. If you are not an
intended recipient of this communication, you are
hereby notified that any dissemination,
distribution or copying hereof is strictly
prohibited. If you have received this communication
in error, please notify me by reply e-mail,
permanently delete this communication from your
system, and destroy any hard copies you may have
printed


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

qiaonuohan 04-11-2012 09:47 AM

add a new command: ipcs
 
Hello Dave,

I am going to fix the bug on some kernels. And I also need to confirm
the style with you.


At 2012-4-11 4:00, Dave Anderson wrote:

I should note that I*only* tested the "ipcs" command entered alone.

Anyway, I now see that you separated the shared memory display into two
options, -m and -M. I don't believe that is necessary -- the first patch that
you posted gave enough basic information. If you want to expand it, perhaps the
extra data that is shown by "-M" option could be included in the "-i id" output?
And for that matter, the -u data could also be contained in the "-i id" output?
That way the basic shared memory data could be shown by "ipcs [-m]" option, and
a fully-exploded display could be done by the "-i id" qualifier because it
wouldn't have to be restricted to one line.


I separate the display in two places beacuse displaying all items
violates the 80-column rule. And the "-m" shows like the command
system's build-in command. Actually, the reason why I change it like
this is because the inode is important to my proposer. He wants to use
it to identify memory area from such inode information. As you said, the
information displayed by "-M" can be contained in the "-i id" output.
But we have to get the address of inode one by one. I think debugger
will prefer getting data at one time.




I also wish you had followed my original suggestion and made this into an extension
module first. If you do that, you could just post a single "ipcs.c" command that
could be dropped into the "extensions" subdirectory, and built with "make extensions".
There has not been a new command added to the crash utility in many years, and
it's going to be difficult to accept this as a built-in command until it first
goes through a lot of testing, usage, improvement, etc. If it were an extension
module, it could be stored on the extensions web page immediately for people
to use and test.


From the aspect of myself, I would agree with it. But my proposer wants
to use it as soon as possible as a build-in command. I am not sure how
long it will take to convert an extension command to a build-in command.
So I insisted sending it as a build-in command.




Also, if you are not going to support the earlier 2.6-era kernels, then
the command_not_supported() function would be preferable to option_not_supported().



--
--
Regards
Qiao Nuohan
--------------------------------------------------
Qiao Nuohan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China
TEL: +86+25-86630566-8526 FUJITSU
INTERNAL: 7998-8526 FAX: +86+25-83317685
EMail: qiaonuohan@cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended
recipient(s) only and may contain information that
is privileged, confidential and exempt from
disclosure under applicable law. If you are not an
intended recipient of this communication, you are
hereby notified that any dissemination,
distribution or copying hereof is strictly
prohibited. If you have received this communication
in error, please notify me by reply e-mail,
permanently delete this communication from your
system, and destroy any hard copies you may have
printed


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

Dave Anderson 04-11-2012 01:58 PM

add a new command: ipcs
 
----- Original Message -----
> Hello Dave,
>
> I am going to fix the bug on some kernels. And I also need to confirm
> the style with you.
>
> At 2012-4-11 4:00, Dave Anderson wrote:
> > I should note that I *only* tested the "ipcs" command entered alone.
> >
> > Anyway, I now see that you separated the shared memory display into two
> > options, -m and -M. I don't believe that is necessary -- the first patch that
> > you posted gave enough basic information. If you want to expand it, perhaps the
> > extra data that is shown by "-M" option could be included in the "-i id" output?
> > And for that matter, the -u data could also be contained in the "-i id" output?
> > That way the basic shared memory data could be shown by "ipcs [-m]" option, and
> > a fully-exploded display could be done by the "-i id" qualifier because it
> > wouldn't have to be restricted to one line.
>
> I separate the display in two places beacuse displaying all items
> violates the 80-column rule. And the "-m" shows like the command
> system's build-in command. Actually, the reason why I change it like
> this is because the inode is important to my proposer. He wants to use
> it to identify memory area from such inode information. As you said, the
> information displayed by "-M" can be contained in the "-i id" output.
> But we have to get the address of inode one by one. I think debugger
> will prefer getting data at one time.

OK, then re-design it similarly to the way "kmem -s" and "kmem -S" work.
The "kmem -s" option shows a one-line summary, whereas the "kmem -S" option
shows the same one-line summary, followed by the full breakdown. The same
concept is used with "kmem -f" and "kmem -F", with "vm" and "vm -p", etc.

But the shmid_kernel, sem_array and msg_queue structure addresses should
always be shown in the one-liner.

> >
> > I also wish you had followed my original suggestion and made this into an extension
> > module first. If you do that, you could just post a single "ipcs.c" command that
> > could be dropped into the "extensions" subdirectory, and built with "make extensions".
> > There has not been a new command added to the crash utility in many years, and
> > it's going to be difficult to accept this as a built-in command until it first
> > goes through a lot of testing, usage, improvement, etc. If it were an extension
> > module, it could be stored on the extensions web page immediately for people
> > to use and test.
>
> From the aspect of myself, I would agree with it. But my proposer wants
> to use it as soon as possible as a build-in command. I am not sure how
> long it will take to convert an extension command to a build-in command.
> So I insisted sending it as a build-in command.

First -- let's be clear here -- your "proposer" does not determine whether this
command is going to be accepted as a built-in command. So when you state
that your "proposer wants to use it as soon as possible as a build-in", well,
I'm sorry, but that's just not the way things work here. I'm not in the business
of just throwing in anything that gets posted on this list into the upstream
version of the crash utility because somebody wants it as soon as possible.
And certainly your proposer can build his own version of the crash utility with
the command built-in.

To make it an extension module, the prime consideration is your usage of
MEMBER_OFFSET_INIT(), STRUCT_SIZE_INIT(), OFFSET() and SIZE(). And adapting
that should be doable by creating your own offset_table and size_table structures
containing your new entries, by doing something like this at the top of ipcs.c:

struct ipcs_offset_table {
... [ your entries ] ...
};
struct ipcs_size_table {
... [ your entries ] ...
};

#undef MEMBER_OFFSET_INIT()
#undef STRUCT_SIZE_INIT()
#define MEMBER_OFFSET_INIT() ... assign value to ipcs_offset_table.x ...
#define STRUCT_SIZE_INIT() ... assign value to ipcs_size_table.x ...

#define _OFFSET_() ... verify based upon ipcs_offset_table.x value ...
#define _SIZE_() ... verify based upon ipcs_size_table.x value ...

And then do a global search-and-replace of all of your OFFSET() and
SIZE() callers, and change them to _OFFSET_() and _SIZE_(). If you
are using any pre-existing offset_table or size_table values, then
those would obviously still need to use OFFSET() and SIZE().

Aside from that, just use "extensions/echo.c" as a template. That
way it will only consist of a single "ipcs.c" file that can be
placed into the extensions sub-directory, where "make extensions"
from the top-level crash directory will build it automatically.

Then, if the command is eventually accepted as a built-in, it will
be a simple matter of removing the stuff shown above, changing
all the _OFFSET_() and _SIZE_() callers to OFFSET() and SIZE(), and
adding the members to the offset_table and size_table structures.

Dave

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

Dave Anderson 04-11-2012 02:50 PM

add a new command: ipcs
 
----- Original Message -----
> Hello Dave,
>
> I cannot get all kernels at hand. So I have to ask you about the code.
> Please show me.

Why not? Just download the upstream kernels from here:

http://www.kernel.org/pub/linux/kernel/v2.6/

> >
> > (a) On these kernel versions:
> >
> > 2.6.9-89.ELxenU
> > 2.6.15-1.2054_FC5
> > 2.6.16.33-xen
> > 2.6.18-1.2714.el5xen
> > 2.6.18-36.el5xen
> > 2.6.18-58.el5xen
> > 2.6.18-152.el5xen
> > 2.6.31 uniprocessor kernel
> >
> > the command fails immediatedly with this error:
> >
> > ipcs: cannot resolve "hugetlbfs_file_operations"
> >
> >
> > (b) On *all* RHEL5 2.6.18-era kernels, the message queue display
> > always fails like this:
> >
> > ------ Message Queues --------
> > KEY MSQID UID PERMS USED-BYTES
> > MESSAGES
> > ipcs: invalid structure member offset: kern_ipc_perm_id
> > FILE: ipcs.c LINE: 899 FUNCTION: get_msg_info()
>
> I want to see the struct msg_queue and struct struct kern_ipc_perm.

Here is the output from a RHEL5 kernel:

crash> msg_queue
struct msg_queue {
struct kern_ipc_perm q_perm;
int q_id;
time_t q_stime;
time_t q_rtime;
time_t q_ctime;
long unsigned int q_cbytes;
long unsigned int q_qnum;
long unsigned int q_qbytes;
pid_t q_lspid;
pid_t q_lrpid;
struct list_head q_messages;
struct list_head q_receivers;
struct list_head q_senders;
}
SIZE: 160
crash> kern_ipc_perm
struct kern_ipc_perm {
spinlock_t lock;
int deleted;
key_t key;
uid_t uid;
gid_t gid;
uid_t cuid;
gid_t cgid;
mode_t mode;
long unsigned int seq;
void *security;
}
SIZE: 48
crash>

which is the same as the upstream 2.6.18 kernel.

> >
> > (c) On this 2.6.36-0.16.rc3.git0.fc15 Fedora kernel, it shows:
> >
> > ------ Shared Memory Segments ------
> > KEY SHMID UID PERMS BYTES NATTCH
> > STATUS
> > ipcs: invalid kernel virtual address: 10 type: "nsproxy.ipc_ns"
>
> what is struct nsproxy? Or is there any symbol referring to ipc_ns?

crash> nsproxy
struct nsproxy {
atomic_t count;
struct uts_namespace *uts_ns;
struct ipc_namespace *ipc_ns;
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns;
struct net *net_ns;
}
SIZE: 48
crash>

It's the same as upstream 2.6.36, but it's not the offset that's invalid,
it's the NULL "nsproxy" address.

>
> >
> >
> > (d) On *all* RHEL4 2.6.9-era and SLES9 2.6.5-era kernels, the
> > command fail like this:
> >
> > ------ Shared Memory Segments ------
> > KEY SHMID UID PERMS BYTES NATTCH
> > STATUS
> > ipcs: invalid structure member offset: ipc_id_ary_p
> > FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()
> >
> > or this:
> >
> > ------ Shared Memory Segments ------
> > KEY SHMID UID PERMS BYTES NATTCH
> > STATUS
> > (none allocated)------ Semaphore Arrays --------
> > KEY SEMID UID PERMS NSEMS
> > ipcs: invalid structure member offset: ipc_id_ary_p
> > FILE: ipcs.c LINE: 540 FUNCTION: ipc_search_array()
> >
>
> what is struct ipc_id? And what is entries in struct ipc_id or something
> similar to it?

This is from a RHEL4 kernel -- and the upstream 2.6.9 kernel is the same:

crash> ipc_id
struct ipc_id {
struct kern_ipc_perm *p;
}
SIZE: 8
crash> kern_ipc_perm
struct kern_ipc_perm {
spinlock_t lock;
int deleted;
key_t key;
uid_t uid;
gid_t gid;
uid_t cuid;
gid_t cgid;
mode_t mode;
long unsigned int seq;
void *security;
}
SIZE: 56
crash>

Dave




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


All times are GMT. The time now is 05:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.