From: Mike Snitzer <snitzer@redhat.com>
To: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
Cc: Steffen Maier <maier@linux.vnet.ibm.com>,
dm-devel@redhat.com, Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: Modern device mapper module makes problems for dump analysis
Date: Thu, 3 Dec 2015 14:31:30 -0500 [thread overview]
Message-ID: <20151203193129.GA5264@redhat.com> (raw)
In-Reply-To: <565DA1FD.3010804@linux.vnet.ibm.com>
On Tue, Dec 01 2015 at 8:34am -0500,
Alexey Ishchuk <aishchuk@linux.vnet.ibm.com> wrote:
> Hi,
>
> in the modern device mapper Linux kernel module the data structure
> struct dm_table is declared more than once. One of those
> declarations is the real structure definition and the other are
> dummy definitions. This coding manner makes serious problems for the
> Linux kernel dump analysis with crash utility using custom EPPIC
> language scripts and even the dminfo built-in crash extension does
> not work with the dumps. The problem occurs because the crash
> utility tries to expose to the EPPIC language scripts a dummy
> structure definition that contains no required fields.
>
> I would like to get to know, why do we need more than one struct
> dm_table declarations in the kernel module? Is it possible to
> improve the device mapper kernel module code to have the only one
> struct dm_table declaration to allow kernel dumps to be analyzed
> using custom scripts?
The dm.c definition is:
/*
* A dummy definition to make RCU happy.
* struct dm_table should never be dereferenced in this file.
*/
struct dm_table {
int undefined__;
};
As you can see in the block comment above this dummy definition is
purely to "make RCU happy"...
We'll need to research how/if we can avoid such hacks (and still have
RCU function as needed).
But short of eliminating the dummy definition, have you tried using the
crash utility's 'set scope <text_address>' capability to force the use
of the dm-table.c definition? e.g.:
crash> mod -s dm_mod
MODULE NAME SIZE OBJECT FILE
ffffffffa0013640 dm_mod 110592 /lib/modules/4.4.0-rc1.snitm+/kernel/drivers/md/dm-mod.ko
crash> struct dm_table
struct dm_table {
int undefined__;
}
SIZE: 4
crash> set scope dm_table_create
scope: ffffffffa0005b30 (dm_table_create)
crash> struct dm_table
struct dm_table {
struct mapped_device *md;
unsigned int type;
unsigned int depth;
unsigned int counts[16];
sector_t *index[16];
unsigned int num_targets;
unsigned int num_allocated;
sector_t *highs;
struct dm_target *targets;
struct target_type *immutable_target_type;
unsigned int integrity_supported : 1;
unsigned int singleton : 1;
fmode_t mode;
struct list_head devices;
void (*event_fn)(void *);
void *event_context;
struct dm_md_mempools *mempools;
struct list_head target_callbacks;
}
SIZE: 304
next prev parent reply other threads:[~2015-12-03 19:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 13:34 [RFC] Modern device mapper module makes problems for dump analysis Alexey Ishchuk
2015-12-03 19:31 ` Mike Snitzer [this message]
2015-12-04 1:36 ` Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151203193129.GA5264@redhat.com \
--to=snitzer@redhat.com \
--cc=aishchuk@linux.vnet.ibm.com \
--cc=dm-devel@redhat.com \
--cc=maier@linux.vnet.ibm.com \
--cc=mpatocka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox