All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.