From: Christoph Hellwig <hch@infradead.org>
To: Ming Lei <ming.lei@canonical.com>
Cc: Mike Snitzer <snitzer@redhat.com>, Jens Axboe <axboe@fb.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-block@vger.kernel.org,
Christoph Hellwig <hch@infradead.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 06:44:27 -0700 [thread overview]
Message-ID: <20160601134427.GA15888@infradead.org> (raw)
In-Reply-To: <CACVXFVM9FqZFkMat_4ysJ8_vFd1FFnf6Bd9sHDDoCK=v93wViQ@mail.gmail.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Ming Lei <ming.lei@canonical.com>
Cc: linux-block@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
Jan Kara <jack@suse.cz>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Mike Snitzer <snitzer@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Steven Whitehouse <swhiteho@redhat.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 06:44:27 -0700 [thread overview]
Message-ID: <20160601134427.GA15888@infradead.org> (raw)
In-Reply-To: <CACVXFVM9FqZFkMat_4ysJ8_vFd1FFnf6Bd9sHDDoCK=v93wViQ@mail.gmail.com>
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.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-06-01 13:44 UTC|newest]
Thread overview: 39+ 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 ` 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 ` [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 ` Mike Snitzer
2016-06-01 12:38 ` Ming Lei
2016-06-01 12:38 ` Ming Lei
2016-06-01 13:44 ` Christoph Hellwig [this message]
2016-06-01 13:44 ` Christoph Hellwig
2016-06-01 13:51 ` Mike Snitzer
2016-06-01 13:51 ` Mike Snitzer
2016-06-01 14:05 ` Christoph Hellwig
2016-06-01 14:05 ` Christoph Hellwig
2016-06-02 2:13 ` Ming Lei
2016-06-02 2:13 ` Ming Lei
2016-06-01 13:43 ` 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 ` Hannes Reinecke
2016-06-01 13:57 ` Mike Snitzer
2016-06-01 13:57 ` Mike Snitzer
2016-06-09 16:06 ` Jens Axboe
2016-06-09 16:06 ` Jens Axboe
2016-06-10 2:44 ` 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=20160601134427.GA15888@infradead.org \
--to=hch@infradead.org \
--cc=axboe@fb.com \
--cc=drbd-dev@lists.linbit.com \
--cc=ejt@redhat.com \
--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=snitzer@redhat.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.