All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Akira Hayakawa <ruby.wktk@gmail.com>
Cc: Kumar Amit Mehta <gmate.amit@gmail.com>,
	device-mapper development <dm-devel@redhat.com>
Subject: dm-lc code/design [was: Re: dm-lc.c: fix for a potential NULL pointer dereference]
Date: Wed, 31 Jul 2013 11:57:17 -0400	[thread overview]
Message-ID: <20130731155717.GD17352@redhat.com> (raw)
In-Reply-To: <51F90B49.60708@gmail.com>

On Wed, Jul 31 2013 at  9:04am -0400,
Akira Hayakawa <ruby.wktk@gmail.com> wrote:

> Thanks, Kumar.
> Your patch is applied.
> 
> resume_cache,
> a routine to build in-memory data structures
> by reading metadata on cache device,
> is so complicated in the code and the logic
> to thoroughly implement the error checks.
> 
> I am wondering how I should face this problem.
> Only caring about lines
> that allocates large-sized memories
> and forget about anything else
> is what I am thinking now.
> But it is clear that
> it is not a way kernel module should be.
> 
> Do you guys have some thoughts on this problem?

I had a quick look at "resume_cache".  I was thinking you were referring
to the .resume method of the target.  The .resume method must not
allocate _any_ memory (DM convention requires all memory allocations to
be done in terms of preallocated memory or more commonly as part of the
DM table load, via .ctr)... anyway ignoring that for now.

I was very surprised to see that you're managing devices in terms of DM
messages like "resume_cache" (which I assume your dm-lc userspace tools
initiate).  This seems wrong -- I'm also not seeing proper locking in
the code either (which you get for free if with DM if you use the
traditional DM hooks via target_type ops).  But I haven't been able to
do a proper review.

DM device creation and deletion are done in terms of load (.ctr) and
remove (.dtr).

And all these sysfs files are excessive too.  You'll notice that DM devices
don't expose discrete sysfs files on a per device basis.  All per-device
info is exposed via .status

We _could_ take steps to establish a per-DM-device sysfs namespace; but
that would need to be something wired up to the DM core.  So I'd prefer
dm-lc use traditional .status (info and table).

All said, I'll try to make time for a more formal review in the coming
weeks.  Please feel free to ask more questions in the mean time.

Thanks,
Mike

  reply	other threads:[~2013-07-31 15:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-31 12:09 [PATCH] dm-lc.c: fix for a potential NULL pointer dereference Kumar Amit Mehta
2013-07-31 13:04 ` Akira Hayakawa
2013-07-31 15:57   ` Mike Snitzer [this message]
2013-08-01 12:45     ` dm-lc code/design [was: Re: dm-lc.c: fix for a potential NULL pointer dereference] Akira Hayakawa

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=20130731155717.GD17352@redhat.com \
    --to=snitzer@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=gmate.amit@gmail.com \
    --cc=ruby.wktk@gmail.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.