From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ming Lei <ming.lei@canonical.com>, Jens Axboe <axboe@fb.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
"open list:DRBD DRIVER" <drbd-dev@lists.linbit.com>,
Jan Kara <jack@suse.cz>, Joe Thornber <ejt@redhat.com>,
Keith Busch <keith.busch@intel.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Michal Hocko <mhocko@suse.com>, NeilBrown <neilb@suse.com>,
Sagi Grimberg <sagig@mellanox.com>, Shaohua Li <shli@fb.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Tejun Heo <tj@kernel.org>,
"open list:XFS FILESYSTEM" <xfs@oss.sgi.com>
Subject: Re: [PATCH v6 0/8] block: prepare for multipage bvecs
Date: Wed, 1 Jun 2016 09:51:51 -0400 [thread overview]
Message-ID: <20160601135150.GA30759@redhat.com> (raw)
In-Reply-To: <20160601134427.GA15888@infradead.org>
On Wed, Jun 01 2016 at 9:44am -0400,
Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > > be dm-crypt.c. Maybe you've identified some indirect use of
> > > BIO_MAX_SIZE?
> >
> > I mean the recently introduced BIO_MAX_SIZE in -next tree:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/md/dm-crypt.c?id=4ed89c97b0706477b822ea2182827640c0cec486
>
> The crazy bcache bios striking back once again. I really think it's
> harmful having a _MAX value and then having a minor driver
> reinterpreting it and sending larger ones. Until we can lift the
> maximum limit in general nad have common code exercise it we really need
> to stop bcache from sending these instead of littering the tree with
> workarounds.
So should I not push this type of fix to Linus now? I was going to send
the above commit and this one to him this week:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.7&id=57b3001b240629ecc5266d28c845e23ca5f11719
Instead, should bcache be made to not do what it is doing?
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-block@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
Jan Kara <jack@suse.cz>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Ming Lei <ming.lei@canonical.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sagi Grimberg <sagig@mellanox.com>, NeilBrown <neilb@suse.com>,
Jens Axboe <axboe@fb.com>, Joe Thornber <ejt@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>, Shaohua Li <shli@fb.com>,
Tejun Heo <tj@kernel.org>, Keith Busch <keith.busch@intel.com>,
"open list:XFS FILESYSTEM" <xfs@oss.sgi.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"open list:DRBD DRIVER" <drbd-dev@lists.linbit.com>
Subject: Re: [PATCH v6 0/8] block: prepare for multipage bvecs
Date: Wed, 1 Jun 2016 09:51:51 -0400 [thread overview]
Message-ID: <20160601135150.GA30759@redhat.com> (raw)
In-Reply-To: <20160601134427.GA15888@infradead.org>
On Wed, Jun 01 2016 at 9:44am -0400,
Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > > be dm-crypt.c. Maybe you've identified some indirect use of
> > > BIO_MAX_SIZE?
> >
> > I mean the recently introduced BIO_MAX_SIZE in -next tree:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/md/dm-crypt.c?id=4ed89c97b0706477b822ea2182827640c0cec486
>
> The crazy bcache bios striking back once again. I really think it's
> harmful having a _MAX value and then having a minor driver
> reinterpreting it and sending larger ones. Until we can lift the
> maximum limit in general nad have common code exercise it we really need
> to stop bcache from sending these instead of littering the tree with
> workarounds.
So should I not push this type of fix to Linus now? I was going to send
the above commit and this one to him this week:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.7&id=57b3001b240629ecc5266d28c845e23ca5f11719
Instead, should bcache be made to not do what it is doing?
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-block@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
Jan Kara <jack@suse.cz>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Ming Lei <ming.lei@canonical.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sagi Grimberg <sagig@mellanox.com>, NeilBrown <neilb@suse.com>,
Jens Axboe <axboe@fb.com>, Joe Thornber <ejt@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>, Shaohua Li <shli@fb.com>,
Tejun Heo <tj@kernel.org>, Keith Busch <keith.busch@intel.com>,
"open list:XFS FILESYSTEM" <xfs@oss.sgi.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"open list:DRBD DRIVER" <drbd-dev@lists.linbit.com>
Subject: Re: [Drbd-dev] [PATCH v6 0/8] block: prepare for multipage bvecs
Date: Wed, 1 Jun 2016 09:51:51 -0400 [thread overview]
Message-ID: <20160601135150.GA30759@redhat.com> (raw)
In-Reply-To: <20160601134427.GA15888@infradead.org>
On Wed, Jun 01 2016 at 9:44am -0400,
Christoph Hellwig <hch@infradead.org> wrote:
> On Wed, Jun 01, 2016 at 08:38:41PM +0800, Ming Lei wrote:
> > > be dm-crypt.c. Maybe you've identified some indirect use of
> > > BIO_MAX_SIZE?
> >
> > I mean the recently introduced BIO_MAX_SIZE in -next tree:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/md/dm-crypt.c?id=4ed89c97b0706477b822ea2182827640c0cec486
>
> The crazy bcache bios striking back once again. I really think it's
> harmful having a _MAX value and then having a minor driver
> reinterpreting it and sending larger ones. Until we can lift the
> maximum limit in general nad have common code exercise it we really need
> to stop bcache from sending these instead of littering the tree with
> workarounds.
So should I not push this type of fix to Linus now? I was going to send
the above commit and this one to him this week:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.7&id=57b3001b240629ecc5266d28c845e23ca5f11719
Instead, should bcache be made to not do what it is doing?
next prev parent reply other threads:[~2016-06-01 13:51 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 13:34 [PATCH v6 0/8] block: prepare for multipage bvecs Ming Lei
2016-05-30 13:34 ` [Drbd-dev] " Ming Lei
2016-05-30 13:34 ` Ming Lei
2016-05-30 13:34 ` [PATCH v6 1/8] block: move bvec iterator into include/linux/bvec.h Ming Lei
2016-05-30 13:34 ` [PATCH v6 2/8] block: move two bvec structure into bvec.h Ming Lei
2016-05-30 13:34 ` [PATCH v6 3/8] block: mark 1st parameter of bvec_iter_advance as const Ming Lei
2016-05-30 13:34 ` [PATCH v6 4/8] iov_iter: use bvec iterator to implement iterate_bvec() Ming Lei
2016-05-30 13:34 ` [PATCH v6 5/8] fs: xfs: replace BIO_MAX_SECTORS with BIO_MAX_PAGES Ming Lei
2016-05-30 13:34 ` Ming Lei
2016-06-01 13:48 ` Christoph Hellwig
2016-06-01 13:48 ` Christoph Hellwig
2016-06-02 3:32 ` Ming Lei
2016-06-02 3:32 ` Ming Lei
2016-05-30 13:34 ` [PATCH v6 6/8] block: bio: remove BIO_MAX_SECTORS Ming Lei
2016-05-30 13:34 ` [PATCH v6 7/8] block: drbd: avoid to use BIO_MAX_SIZE Ming Lei
2016-05-30 13:34 ` [Drbd-dev] " Ming Lei
2016-05-30 13:34 ` [PATCH v6 8/8] block: mark BIO_MAX_SIZE as obsolete Ming Lei
2016-05-31 16:07 ` Jens Axboe
2016-05-31 15:53 ` [PATCH v6 0/8] block: prepare for multipage bvecs Mike Snitzer
2016-05-31 15:53 ` [Drbd-dev] " Mike Snitzer
2016-05-31 15:53 ` Mike Snitzer
2016-06-01 12:38 ` Ming Lei
2016-06-01 12:38 ` [Drbd-dev] " Ming Lei
2016-06-01 12:38 ` Ming Lei
2016-06-01 13:44 ` Christoph Hellwig
2016-06-01 13:44 ` [Drbd-dev] " Christoph Hellwig
2016-06-01 13:44 ` Christoph Hellwig
2016-06-01 13:51 ` Mike Snitzer [this message]
2016-06-01 13:51 ` [Drbd-dev] " Mike Snitzer
2016-06-01 13:51 ` Mike Snitzer
2016-06-01 14:05 ` Christoph Hellwig
2016-06-01 14:05 ` [Drbd-dev] " Christoph Hellwig
2016-06-01 14:05 ` Christoph Hellwig
2016-06-02 2:13 ` Ming Lei
2016-06-02 2:13 ` [Drbd-dev] " Ming Lei
2016-06-02 2:13 ` Ming Lei
2016-06-01 13:43 ` Christoph Hellwig
2016-06-01 13:43 ` [Drbd-dev] " Christoph Hellwig
2016-06-01 13:43 ` Christoph Hellwig
2016-06-01 13:53 ` Hannes Reinecke
2016-06-01 13:53 ` Hannes Reinecke
2016-06-01 13:53 ` [Drbd-dev] " Hannes Reinecke
2016-06-01 13:53 ` Hannes Reinecke
2016-06-01 13:57 ` Mike Snitzer
2016-06-01 13:57 ` [Drbd-dev] " Mike Snitzer
2016-06-01 13:57 ` Mike Snitzer
2016-06-09 16:06 ` Jens Axboe
2016-06-09 16:06 ` [Drbd-dev] " Jens Axboe
2016-06-09 16:06 ` Jens Axboe
2016-06-10 2:44 ` Ming Lei
2016-06-10 2:44 ` [Drbd-dev] " Ming Lei
2016-06-10 2:44 ` Ming Lei
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=20160601135150.GA30759@redhat.com \
--to=snitzer@redhat.com \
--cc=axboe@fb.com \
--cc=drbd-dev@lists.linbit.com \
--cc=ejt@redhat.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=keith.busch@intel.com \
--cc=kent.overstreet@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mhocko@suse.com \
--cc=ming.lei@canonical.com \
--cc=neilb@suse.com \
--cc=sagig@mellanox.com \
--cc=shli@fb.com \
--cc=swhiteho@redhat.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=xfs@oss.sgi.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.