All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: device-mapper development <dm-devel@redhat.com>,
	"Alasdair G. Kergon" <agk@redhat.com>
Subject: Re: [PATCH v2] dm: Fix alignment stacking on partitioned devices
Date: Tue, 5 Jan 2010 23:10:51 -0500	[thread overview]
Message-ID: <20100106041050.GA21438@redhat.com> (raw)
In-Reply-To: <yq11vi3ud84.fsf@sermon.lab.mkp.net>

On Tue, Jan 05 2010 at 10:24pm -0500,
Martin K. Petersen <martin.petersen@oracle.com> wrote:

> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
> 
> Mike,
> 
> Mike> After looking closer there seems to be various type
> Mike> inconsistencies in the alignment_offset and discard_alignment
> Mike> related routines (returning 'int' in places, etc).
> 
> Mike> The following patch is what I found; I have no problem with
> Mike> switching from 'unsigned long' to blk_off_t for LBD though.
> 
> I only use blk_off_t in the places where we're dealing with absolute
> offsets.
> 
> Blindly converting alignment_offset from int to unsigned long won't
> work.  We depend on being able to return -1 in case of
> misalignment. Hence int and not unsigned int.

Right, I realized/noticed that after I sent that patch.

But even with your blk_off_t patch (and prior to it with sector_t)
you're mixing int with blk_off_t in blk_stack_limits() by doing:

        alignment = queue_limit_alignment_offset(b, offset);

This helped motivate my "blind" conversion.

> Furthermore, the returned values are always modulo the granularity so
> int is plenty big.

OK.

  reply	other threads:[~2010-01-06  4:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-23 18:07 [PATCH v2] dm: Fix alignment stacking on partitioned devices Mike Snitzer
2009-12-23 19:21 ` Mike Snitzer
2010-01-05 18:04 ` Alasdair G Kergon
2010-01-05 18:27 ` Alasdair G Kergon
2010-01-06  2:23   ` Martin K. Petersen
2010-01-06  2:57     ` Mike Snitzer
2010-01-06  3:03       ` Mike Snitzer
2010-01-06  3:24       ` Martin K. Petersen
2010-01-06  4:10         ` Mike Snitzer [this message]
2010-01-06  4:16           ` Martin K. Petersen
2010-01-06  5:16             ` Mike Snitzer
2010-01-06  8:39               ` Martin K. Petersen
2010-01-06 13:25                 ` Mike Snitzer
2010-01-07 17:15                   ` Martin K. Petersen
2010-01-07 18:55                     ` Mike Snitzer
2010-01-08 18:41                       ` Martin K. Petersen
2010-01-08 20:28                         ` Mike Snitzer
2010-01-09  0:01                   ` [PATCH] block: bdev_stack_limits wrapper and DM topology fixes Mike Snitzer
2010-01-06 13:55                 ` [PATCH v2] dm: Fix alignment stacking on partitioned devices Alasdair G Kergon

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=20100106041050.GA21438@redhat.com \
    --to=snitzer@redhat.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=martin.petersen@oracle.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.