Re: [PATCH 1/9] block: Make generic_make_request handle arbitrary sized bios

we move the functionality into generic_make_request()? Thanks. Regards, Muthu On Sun, Mar 2, 2014 at 12:31 PM, Muthu Kumar wrote: > Kent, > The blk_queue_split(), splits a bio into at most two bios right? So, > if the original bio spans larger space than two bios can cover >

Re: [PATCH 1/9] block: Make generic_make_request handle arbitrary sized bios

Kent, The blk_queue_split(), splits a bio into at most two bios right? So, if the original bio spans larger space than two bios can cover (restriction by the lower driver in the stack), this might not work? Am I reading it incorrectly? Thanks! Regards, Muthu On Wed, Feb 26, 2014 at 3:39 PM,

Re: [PATCH 1/9] block: Make generic_make_request handle arbitrary sized bios

Kent, The blk_queue_split(), splits a bio into at most two bios right? So, if the original bio spans larger space than two bios can cover (restriction by the lower driver in the stack), this might not work? Am I reading it incorrectly? Thanks! Regards, Muthu On Wed, Feb 26, 2014 at 3:39 PM,

Re: [PATCH 1/9] block: Make generic_make_request handle arbitrary sized bios

we move the functionality into generic_make_request()? Thanks. Regards, Muthu On Sun, Mar 2, 2014 at 12:31 PM, Muthu Kumar muthu.l...@gmail.com wrote: Kent, The blk_queue_split(), splits a bio into at most two bios right? So, if the original bio spans larger space than two bios can cover

Re: [block:for-3.14/core] blk-mq: Compile fix for null_blk

Thanks Matias. Yes, Ming Lei's 4th patch does make the function internal. So, which branch has the laest patches... i am checking for-3.14/core... Regards, Muthu On Thu, Jan 9, 2014 at 12:58 PM, Matias Bjorling wrote: > On 01/09/2014 07:54 PM, Muthu Kumar wrote: >> >> Jens,

[block:for-3.14/core] blk-mq: Compile fix for null_blk

Jens, Compiling null_blk.ko failed with error that blk_mq_free_queue() was defined implicitly. So, moved the declaration from block/blk-mq.h to include/linux/blk-mq.h and exported it. Signed-off-by: Muthukumar Ratty -- block/blk-mq.c |1 + block/blk-mq.h

[block:for-3.14/core] blk-mq: Compile fix for null_blk

Jens, Compiling null_blk.ko failed with error that blk_mq_free_queue() was defined implicitly. So, moved the declaration from block/blk-mq.h to include/linux/blk-mq.h and exported it. Signed-off-by: Muthukumar Ratty mut...@gmail.com -- block/blk-mq.c |1 +

Re: [block:for-3.14/core] blk-mq: Compile fix for null_blk

Thanks Matias. Yes, Ming Lei's 4th patch does make the function internal. So, which branch has the laest patches... i am checking for-3.14/core... Regards, Muthu On Thu, Jan 9, 2014 at 12:58 PM, Matias Bjorling m...@bjorling.me wrote: On 01/09/2014 07:54 PM, Muthu Kumar wrote: Jens

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Wed, Jan 8, 2014 at 1:14 PM, Kent Overstreet wrote: > On Wed, Jan 08, 2014 at 09:11:49PM +, Chris Mason wrote: >> On Wed, 2014-01-08 at 13:01 -0800, Muthu Kumar wrote: >> > On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wrote: >> > > On Wed, 2014-01-08 at

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason wrote: > On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: >> On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: >> > On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: >> >> Chris, >> >> >> >

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason wrote: > On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: >> Chris, >> >> [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:1778 bio_endio+0xbe/0x100() >> [8.336062] bio_endio: bio for (unknown) without endio >

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

(which was freed before). Are you running the unmodified for-3.14/core or do you have local patches? Regards, Muthu On Wed, Jan 8, 2014 at 11:41 AM, Chris Mason wrote: > On Tue, 2014-01-07 at 13:23 -0800, Muthu Kumar wrote: >> Chris, >> This is based off of Jens block tree, for-3

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

(which was freed before). Are you running the unmodified for-3.14/core or do you have local patches? Regards, Muthu On Wed, Jan 8, 2014 at 11:41 AM, Chris Mason c...@fb.com wrote: On Tue, 2014-01-07 at 13:23 -0800, Muthu Kumar wrote: Chris, This is based off of Jens block tree, for-3.14/core

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason c...@fb.com wrote: On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: Chris, [8.336061] WARNING: CPU: 0 PID: 0 at fs/bio.c:1778 bio_endio+0xbe/0x100() [8.336062] bio_endio: bio for (unknown) without endio This is my recent change

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason c...@fb.com wrote: On Wed, 2014-01-08 at 12:40 -0800, Muthu Kumar wrote: On Wed, Jan 8, 2014 at 12:16 PM, Chris Mason c...@fb.com wrote: On Wed, 2014-01-08 at 11:54 -0800, Muthu Kumar wrote: Chris, [8.336061] WARNING: CPU: 0 PID: 0 at fs

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

On Wed, Jan 8, 2014 at 1:14 PM, Kent Overstreet k...@daterainc.com wrote: On Wed, Jan 08, 2014 at 09:11:49PM +, Chris Mason wrote: On Wed, 2014-01-08 at 13:01 -0800, Muthu Kumar wrote: On Wed, Jan 8, 2014 at 12:51 PM, Chris Mason c...@fb.com wrote: On Wed, 2014-01-08 at 12:40 -0800

[block:for-3.14/core]: bio_endio: Warn and free bio if bi_end_io is not set.

Jens, In bio_endio if bio doesn't have bi_end_io (should be an error case), we set bio to NULL and continue silently without freeing the bio. It would be good to have a WARN and free the bio to avoid memory leak. If you agree, here is the patch. - bio_endio: Warn and free bio if

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

Chris, This is based off of Jens block tree, for-3.14/core branch... Regards, Muthu On Tue, Jan 7, 2014 at 12:29 PM, Chris Mason wrote: > On Tue, 2014-01-07 at 12:15 -0800, Muthu Kumar wrote: >> Thanks Fengguang. Final patch with added comment. BTW, fengguang >> mentioned

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

Thanks Fengguang. Final patch with added comment. BTW, fengguang mentioned that git-am has trouble with the inline patch and "quilt import" worked fine for him... In btrfs_end_bio(), we increment bi_remaining if is_orig_bio. If not, we restore the orig_bio but failed to increment

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

Thanks Fengguang. Final patch with added comment. BTW, fengguang mentioned that git-am has trouble with the inline patch and quilt import worked fine for him... In btrfs_end_bio(), we increment bi_remaining if is_orig_bio. If not, we restore the orig_bio but failed to increment

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

Chris, This is based off of Jens block tree, for-3.14/core branch... Regards, Muthu On Tue, Jan 7, 2014 at 12:29 PM, Chris Mason c...@fb.com wrote: On Tue, 2014-01-07 at 12:15 -0800, Muthu Kumar wrote: Thanks Fengguang. Final patch with added comment. BTW, fengguang mentioned that git-am has

[block:for-3.14/core]: bio_endio: Warn and free bio if bi_end_io is not set.

Jens, In bio_endio if bio doesn't have bi_end_io (should be an error case), we set bio to NULL and continue silently without freeing the bio. It would be good to have a WARN and free the bio to avoid memory leak. If you agree, here is the patch. - bio_endio: Warn and free bio if

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

nt > Jens fixes for btrfs which I somehow lost when I rebased, do you remember how > this is supposed to work? Looking at the code I'm not quite sure what's going > on > here. > > On Fri, Jan 03, 2014 at 11:51:31AM -0800, Muthu Kumar wrote: >> Looks like Kent missed the bt

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

bi_remaining (probably) isn't getting decremented when it should be. You sent Jens fixes for btrfs which I somehow lost when I rebased, do you remember how this is supposed to work? Looking at the code I'm not quite sure what's going on here. On Fri, Jan 03, 2014 at 11:51:31AM -0800, Muthu Kumar

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

1:51:31AM -0800, Muthu Kumar wrote: >> Looks like Kent missed the btrfs endio in the original commit. How >> about this patch: >> >> - >> >> In btrfs_end_bio, call bio_endio_nodec on the restored bio so the >> bi_remaining is accounted for correctly. &g

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

, 2014 at 11:51:31AM -0800, Muthu Kumar wrote: Looks like Kent missed the btrfs endio in the original commit. How about this patch: - In btrfs_end_bio, call bio_endio_nodec on the restored bio so the bi_remaining is accounted for correctly. Reported-by: fengguang...@intel.com Cc: Kent

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

Looks like Kent missed the btrfs endio in the original commit. How about this patch: - In btrfs_end_bio, call bio_endio_nodec on the restored bio so the bi_remaining is accounted for correctly. Reported-by: fengguang...@intel.com Cc: Kent Overstreet CC: Jens Axboe Signed-off-by:

Re: [block:for-3.14/core] kernel BUG at fs/bio.c:1748

Looks like Kent missed the btrfs endio in the original commit. How about this patch: - In btrfs_end_bio, call bio_endio_nodec on the restored bio so the bi_remaining is accounted for correctly. Reported-by: fengguang...@intel.com Cc: Kent Overstreet k...@daterainc.com CC: Jens Axboe

Where can find block layer lockless queue work.

Hi All, I heard there is some work going on to support lockless queue in the block layer. Is there a git repo with current changes that I can follow? Any info on this work is appreciated. Thanks a lot. Regards, Muthu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Where can find block layer lockless queue work.

Hi All, I heard there is some work going on to support lockless queue in the block layer. Is there a git repo with current changes that I can follow? Any info on this work is appreciated. Thanks a lot. Regards, Muthu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the

Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

Kent, On Tue, Sep 11, 2012 at 12:31 PM, Kent Overstreet wrote: > On Tue, Sep 11, 2012 at 11:58:05AM -0700, Muthu Kumar wrote: >> On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo wrote: >> > Hello, >> > >> > On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wro

Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo wrote: > Hello, > > On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote: >> Does this preserve the CPU from which the bio was submitted >> originally. Not familiar with cmwq, may be Tejun can clarify. >> >> Tej

Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

Kent, On Mon, Sep 10, 2012 at 2:56 PM, Kent Overstreet wrote: .. .. > > +static void bio_alloc_rescue(struct work_struct *work) > +{ > + struct bio_set *bs = container_of(work, struct bio_set, rescue_work); > + struct bio *bio; > + > + while (1) { > +

Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

Kent, On Mon, Sep 10, 2012 at 2:56 PM, Kent Overstreet koverstr...@google.com wrote: .. snip .. +static void bio_alloc_rescue(struct work_struct *work) +{ + struct bio_set *bs = container_of(work, struct bio_set, rescue_work); + struct bio *bio; + + while (1) { +

Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo t...@kernel.org wrote: Hello, On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote: Does this preserve the CPU from which the bio was submitted originally. Not familiar with cmwq, may be Tejun can clarify. Tejun - the question is, do we

Re: [PATCH 2/2] block: Avoid deadlocks with bio allocation by stacking drivers

Kent, On Tue, Sep 11, 2012 at 12:31 PM, Kent Overstreet koverstr...@google.com wrote: On Tue, Sep 11, 2012 at 11:58:05AM -0700, Muthu Kumar wrote: On Tue, Sep 11, 2012 at 11:45 AM, Tejun Heo t...@kernel.org wrote: Hello, On Tue, Sep 11, 2012 at 11:36:28AM -0700, Muthu Kumar wrote: Does

Re: Re: [PATCH 0/8] Set bi_rw when alloc bio before call bio_add_page.

[ Resending in plain text... sorry for the duplicate ] Hi, On Mon, Jul 30, 2012 at 6:14 PM, Dave Chinner wrote: > > On Tue, Jul 31, 2012 at 08:55:59AM +0800, majianpeng wrote: > > On 2012-07-31 05:42 Dave Chinner Wrote: > > >On Mon, Jul 30, 2012 at 03:14:28PM +0800, majianpeng wrote: > > >>

Re: Re: [PATCH 0/8] Set bi_rw when alloc bio before call bio_add_page.

[ Resending in plain text... sorry for the duplicate ] Hi, On Mon, Jul 30, 2012 at 6:14 PM, Dave Chinner da...@fromorbit.com wrote: On Tue, Jul 31, 2012 at 08:55:59AM +0800, majianpeng wrote: On 2012-07-31 05:42 Dave Chinner da...@fromorbit.com Wrote: On Mon, Jul 30, 2012 at 03:14:28PM

Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use

Tejun, On Thu, Aug 9, 2012 at 12:01 AM, Tejun Heo wrote: > Hello, > > On Wed, Aug 08, 2012 at 04:47:46PM -0700, Muthu Kumar wrote: >> You are changing the meaning of __bio_clone() here. In old code, the >> number of io_vecs, bi_idx, bi_vcnt are preserved. But in this

Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use

Kent, >> -- >> You are changing the meaning of __bio_clone() here. In old code, the >> number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified >> code, you are mapping bio_src's bi_iovec[bi_idx] to bio_dests >> bi_iovec[0] and also restricting the number of allocated io_vecs of >>

Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use

Kent, -- You are changing the meaning of __bio_clone() here. In old code, the number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified code, you are mapping bio_src's bi_iovec[bi_idx] to bio_dests bi_iovec[0] and also restricting the number of allocated io_vecs of the clone.

Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use

Tejun, On Thu, Aug 9, 2012 at 12:01 AM, Tejun Heo t...@kernel.org wrote: Hello, On Wed, Aug 08, 2012 at 04:47:46PM -0700, Muthu Kumar wrote: You are changing the meaning of __bio_clone() here. In old code, the number of io_vecs, bi_idx, bi_vcnt are preserved. But in this modified code, you

Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use

Tejun, This is changing the semantics of the clone. Sorry, I missed this thread and replied separately. But anyway, replying it again here: On Wed, Aug 8, 2012 at 4:28 PM, Tejun Heo wrote: > On Mon, Aug 06, 2012 at 07:16:33PM -0400, Mikulas Patocka wrote: >> Hi Kent >> >> When you change the

Re: [dm-devel] [PATCH v5 12/12] block: Only clone bio vecs that are in use

Tejun, This is changing the semantics of the clone. Sorry, I missed this thread and replied separately. But anyway, replying it again here: On Wed, Aug 8, 2012 at 4:28 PM, Tejun Heo t...@kernel.org wrote: On Mon, Aug 06, 2012 at 07:16:33PM -0400, Mikulas Patocka wrote: Hi Kent When you

Re: [PATCH v4 12/12] block: Only clone bio vecs that are in use

Hi, On Tue, Jul 24, 2012 at 1:11 PM, Kent Overstreet wrote: > bcache creates large bios internally, and then splits them according to > the device requirements before it sends them down. If a lower level > device tries to clone the bio, and the original bio had more than > BIO_MAX_PAGES, the

Re: [PATCH v4 12/12] block: Only clone bio vecs that are in use

Hi, On Tue, Jul 24, 2012 at 1:11 PM, Kent Overstreet koverstr...@google.com wrote: bcache creates large bios internally, and then splits them according to the device requirements before it sends them down. If a lower level device tries to clone the bio, and the original bio had more than

Re: [PATCH v2 1/1] mmc: block: Add write packing control

> > I'd be willing to explore something like Venkat's idea if the block > layer maintainers insist, though. Yeah... I guess it's upto Jens. > > - Chris. > -- > Chris Ball > One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [PATCH v2 1/1] mmc: block: Add write packing control

I'd be willing to explore something like Venkat's idea if the block layer maintainers insist, though. Yeah... I guess it's upto Jens. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH v2 1/1] mmc: block: Add write packing control

On Sun, Jul 15, 2012 at 7:46 PM, Chris Ball wrote: > Hi, > > On Sun, Jul 15 2012, Muthu Kumar wrote: >>> I've already replied to a later version of the patch, but just to get >>> this comment in at the appropriate point of the discussion as well: >>> >>

Re: [PATCH v2 1/1] mmc: block: Add write packing control

On Sun, Jul 15, 2012 at 7:46 PM, Chris Ball c...@laptop.org wrote: Hi, On Sun, Jul 15 2012, Muthu Kumar wrote: I've already replied to a later version of the patch, but just to get this comment in at the appropriate point of the discussion as well: Even though it would result in a cleaner

Re: [PATCH v2 1/1] mmc: block: Add write packing control

Chris, On Sat, Jul 14, 2012 at 12:12 PM, Chris Ball wrote: > Hi, > > On Wed, Jun 13 2012, Muthu Kumar wrote: >> On Wed, Jun 13, 2012 at 12:52 PM, wrote: >>> >>> On Mon, June 11, 2012 5:28 pm, Muthu Kumar wrote: >>>> On Mon, Jun 11, 2012 at 2:19 PM,

Re: [PATCH v2 1/1] mmc: block: Add write packing control

Chris, On Sat, Jul 14, 2012 at 12:12 PM, Chris Ball c...@laptop.org wrote: Hi, On Wed, Jun 13 2012, Muthu Kumar wrote: On Wed, Jun 13, 2012 at 12:52 PM, me...@codeaurora.org wrote: On Mon, June 11, 2012 5:28 pm, Muthu Kumar wrote: On Mon, Jun 11, 2012 at 2:19 PM, Muthu Kumar muthu.l

[RFC] SCSI: drivers: Remove unnecessary assignment of scsi_done in driver queuecommand

[ CCing signed-off, acked-by of original patch - let me know if anyone else needs to be added ] Jeff, James, In the following commit: -- commit f281233d3eba15fb225d21ae2e228fd4553d824a Author: Jeff Garzik Date: Tue Nov 16 02:10:29 2010 -0500 SCSI host lock push-down -

[RFC] SCSI: drivers: Remove unnecessary assignment of scsi_done in driver queuecommand

[ CCing signed-off, acked-by of original patch - let me know if anyone else needs to be added ] Jeff, James, In the following commit: -- commit f281233d3eba15fb225d21ae2e228fd4553d824a Author: Jeff Garzik j...@garzik.org Date: Tue Nov 16 02:10:29 2010 -0500 SCSI host lock