All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "hch@lst.de" <hch@lst.de>, "snitzer@redhat.com" <snitzer@redhat.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: small dm mpath cleanups
Date: Fri, 28 Apr 2017 20:42:36 +0000	[thread overview]
Message-ID: <1493412156.2767.21.camel@sandisk.com> (raw)
In-Reply-To: <20170428202358.GA28562@redhat.com>

On Fri, 2017-04-28 at 16:23 -0400, Mike Snitzer wrote:
> On Thu, Apr 27 2017 at  2:33am -0400, hch@lst.de <hch@lst.de> wrote:
> > On Wed, Apr 26, 2017 at 06:41:27PM +0000, Bart Van Assche wrote:
> > > On Wed, 2017-04-26 at 09:40 +0200, Christoph Hellwig wrote:
> > > > this series has some prep patches for my work to have proper, type
> > > > checked block errors codes.  One fallout of that is that we need to
> > > > get rid of how dm overloads a few return values with either internal
> > > > positive error codes or negative errno values.  This patches does
> > > > that, which happens to clean things up a bit, and also allows us
> > > > dm to propagate the actual error code in one case where it currently
> > > > is dropped on the floor.
> > > 
> > > Hello Christoph,
> > > 
> > > Some patches in this series conflict with patches I would like to end up in
> > > the stable kernel series. If I would rebase my patch series on top of your
> > > series then that would make it harder to apply my patches on the stable
> > > kernel trees. Mike and Christoph, please advise how to proceed.
> > 
> > Bugfixes always go before cleanups.  I'd be happy to delay and/or rebase
> > any of my patches as needed.
> 
> I rebased your patchset ontop of Bart's patchset that I've already
> staged in linux-dm.git's 'dm-4.12' branch.
> 
> When I try to apply this rebased patchset, it turns out 'dm-4.12' is
> missing linux-block.git commit 8fc779805 ("dm mpath: don't check for
> req->errors").  Because of this your first patch ("dm mpath: merge
> do_end_io into multipath_end_io") won't apply due to conflict.
> 
> Not sure how we skin this cat.  Unfortunately Jens cannot easily pick
> this rebased patchset up because he'll be missing all of Bart's changes
> that I've staged in linux-dm.git's 'dm-4.12'.
> 
> In hindsight, linux-block.git commit 8fc779805 likely should've been
> routed through linux-dm.git.  But not a big deal.
> 
> How should we skin this cat of getting your changes into 4.12?  I could
> send a 2nd pull request to Linus after both linux-block.git and
> linux-dm.git are merged... sound OK?
> 
> Until then, and/or for now, I've staged the fully merged result in
> linux-next via linux-dm.git's 'for-next', see:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/log/?h=for-next

Hello Mike,

A few days ago Linus wrote that he is OK with occasional cherry-picking of
patches to resolve scenarios like the one described above (see also
https://lkml.org/lkml/2017/4/14/484). How about cherry-picking the necessary
commit(s) from Jens' tree into the dm for-next branch?

Bart.

WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "hch@lst.de" <hch@lst.de>, "snitzer@redhat.com" <snitzer@redhat.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: small dm mpath cleanups
Date: Fri, 28 Apr 2017 20:42:36 +0000	[thread overview]
Message-ID: <1493412156.2767.21.camel@sandisk.com> (raw)
In-Reply-To: <20170428202358.GA28562@redhat.com>

On Fri, 2017-04-28 at 16:23 -0400, Mike Snitzer wrote:
> On Thu, Apr 27 2017 at  2:33am -0400, hch@lst.de <hch@lst.de> wrote:
> > On Wed, Apr 26, 2017 at 06:41:27PM +0000, Bart Van Assche wrote:
> > > On Wed, 2017-04-26 at 09:40 +0200, Christoph Hellwig wrote:
> > > > this series has some prep patches for my work to have proper, type
> > > > checked block errors codes.  One fallout of that is that we need to
> > > > get rid of how dm overloads a few return values with either interna=
l
> > > > positive error codes or negative errno values.  This patches does
> > > > that, which happens to clean things up a bit, and also allows us
> > > > dm to propagate the actual error code in one case where it currentl=
y
> > > > is dropped on the floor.
> > >=20
> > > Hello Christoph,
> > >=20
> > > Some patches in this series conflict with patches I would like to end=
 up in
> > > the stable kernel series. If I would rebase my patch series on top of=
 your
> > > series then that would make it harder to apply my patches on the stab=
le
> > > kernel trees. Mike and Christoph, please advise how to proceed.
> >=20
> > Bugfixes always go before cleanups.  I'd be happy to delay and/or rebas=
e
> > any of my patches as needed.
>=20
> I rebased your patchset ontop of Bart's patchset that I've already
> staged in linux-dm.git's 'dm-4.12' branch.
>=20
> When I try to apply this rebased patchset, it turns out 'dm-4.12' is
> missing linux-block.git commit 8fc779805 ("dm mpath: don't check for
> req->errors").  Because of this your first patch ("dm mpath: merge
> do_end_io into multipath_end_io") won't apply due to conflict.
>=20
> Not sure how we skin this cat.  Unfortunately Jens cannot easily pick
> this rebased patchset up because he'll be missing all of Bart's changes
> that I've staged in linux-dm.git's 'dm-4.12'.
>=20
> In hindsight, linux-block.git commit 8fc779805 likely should've been
> routed through linux-dm.git.  But not a big deal.
>=20
> How should we skin this cat of getting your changes into 4.12?  I could
> send a 2nd pull request to Linus after both linux-block.git and
> linux-dm.git are merged... sound OK?
>=20
> Until then, and/or for now, I've staged the fully merged result in
> linux-next via linux-dm.git's 'for-next', see:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.gi=
t/log/?h=3Dfor-next

Hello Mike,

A few days ago Linus wrote that he is OK with occasional cherry-picking of
patches to resolve scenarios like the one described above (see also
https://lkml.org/lkml/2017/4/14/484). How about cherry-picking the necessar=
y
commit(s) from Jens' tree into the dm for-next branch?

Bart.=

  reply	other threads:[~2017-04-28 20:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26  7:40 small dm mpath cleanups Christoph Hellwig
2017-04-26  7:40 ` [PATCH 1/4] dm mpath: merge do_end_io into multipath_end_io Christoph Hellwig
2017-04-26  7:40 ` [PATCH 2/4] dm rq: change ->rq_end_io calling conventions Christoph Hellwig
2017-04-26  7:40 ` [PATCH 3/4] dm mpath: simplify multipath_clone_and_map a little bit Christoph Hellwig
2017-04-26  7:40 ` [PATCH 4/4] dm: introduce a new DM_MAPIO_KILL return value Christoph Hellwig
2017-04-26 18:41 ` small dm mpath cleanups Bart Van Assche
2017-04-26 18:41   ` Bart Van Assche
2017-04-27  2:24   ` Mike Snitzer
2017-04-27  6:33   ` hch
2017-04-28 20:23     ` Mike Snitzer
2017-04-28 20:42       ` Bart Van Assche [this message]
2017-04-28 20:42         ` Bart Van Assche

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=1493412156.2767.21.camel@sandisk.com \
    --to=bart.vanassche@sandisk.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=snitzer@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.