RE: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
> From: Neil Brown [mailto:[EMAIL PROTECTED] > On Friday September 21, [EMAIL PROTECTED] wrote: > > On Thu, 20 Sep 2007 18:27:35 -0700 > > Dan Williams <[EMAIL PROTECTED]> wrote: > > > > > Fix a couple bugs and provide documentation for the async_tx api. > > > > > > Neil, please 'ack' patch #3. > > > > > > git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus > > > > Well it looks like Neil is on vacation or is hiding from us or something. > > Neil is just not coping well with jet-lag > > Patch #3 looks good and necessary > Acked-By: NeilBrown <[EMAIL PROTECTED]> > > I know that should probably be a "reviewed-by" I was a bit I went ahead and added reviewed-by. > surprised that the "handle_completed_read_requests" call was so early > in handle_stripe5 - I don't think the code was originally that early. It is slightly earlier than 2.6.22 (outside the '/* now count some things */' loop) to make sure the R5_Wantfill flags from the last request have been cleared before starting a new one: /* maybe we can request a biofill operation * * new wantfill requests are only permitted while * STRIPE_OP_BIOFILL is clear */ if (test_bit(R5_UPTODATE, >flags) && dev->toread && !test_bit(STRIPE_OP_BIOFILL, >ops.pending)) set_bit(R5_Wantfill, >flags); > But it is probably right. Hopefully my brain will have cleared by > Monday and I'll review it again then. > Ok, the tree is updated with 'Reviewed-by' tags and the proposed documentation updates from Randy and Shannon. git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Dan Williams (3): async_tx: usage documentation and developer notes (v2) async_tx: fix dma_wait_for_async_tx raid5: fix ops_complete_biofill > NeilBrown -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
On Friday September 21, [EMAIL PROTECTED] wrote: > On Thu, 20 Sep 2007 18:27:35 -0700 > Dan Williams <[EMAIL PROTECTED]> wrote: > > > Fix a couple bugs and provide documentation for the async_tx api. > > > > Neil, please 'ack' patch #3. > > > > git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus > > Well it looks like Neil is on vacation or is hiding from us or something. Neil is just not coping well with jet-lag Patch #3 looks good and necessary Acked-By: NeilBrown <[EMAIL PROTECTED]> I know that should probably be a "reviewed-by" I was a bit surprised that the "handle_completed_read_requests" call was so early in handle_stripe5 - I don't think the code was originally that early. But it is probably right. Hopefully my brain will have cleared by Monday and I'll review it again then. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
> From: Andrew Morton [mailto:[EMAIL PROTECTED] > > Fix a couple bugs and provide documentation for the async_tx api. > > > > Neil, please 'ack' patch #3. > > > > git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus > > Well it looks like Neil is on vacation or is hiding from us or something. > > In which case our options would be to go ahead and merge your #3 with > our fingers crossed, or wait and do it in 2.6.23.1 or .2. > > How serious is this bug which you're fixing? Will it affect users > of "legacy" MD setups, or only those who have enabled fancy dma-engine > features? > The symptom is raid array that fails to complete a read request. It has only been triggered by Yuri when he tried a dma-engine configuration on his PPC platform with PAGE_SIZE=64K, this opens a large window for the bug to hit. The window is much smaller but not 100% closed in the !dma-engine case, although no one else has hit it. 2.6.22 returned reads from handle_stripe under the stripe lock so this patch can be seen as 'reverting a botched micro-optimization' versus 'introducing a new way to handle reads'. > Either way, we need to get #2 (at least) in to Linus. #2 is less critical and cannot hit with any of the current drivers in the kernel, so it is ok if this one misses 2.6.23. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
On Thu, 20 Sep 2007 18:27:35 -0700 Dan Williams <[EMAIL PROTECTED]> wrote: > Fix a couple bugs and provide documentation for the async_tx api. > > Neil, please 'ack' patch #3. > > git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Well it looks like Neil is on vacation or is hiding from us or something. In which case our options would be to go ahead and merge your #3 with our fingers crossed, or wait and do it in 2.6.23.1 or .2. How serious is this bug which you're fixing? Will it affect users of "legacy" MD setups, or only those who have enabled fancy dma-engine features? Either way, we need to get #2 (at least) in to Linus. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
On Thu, 20 Sep 2007 18:27:35 -0700 Dan Williams [EMAIL PROTECTED] wrote: Fix a couple bugs and provide documentation for the async_tx api. Neil, please 'ack' patch #3. git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Well it looks like Neil is on vacation or is hiding from us or something. In which case our options would be to go ahead and merge your #3 with our fingers crossed, or wait and do it in 2.6.23.1 or .2. How serious is this bug which you're fixing? Will it affect users of legacy MD setups, or only those who have enabled fancy dma-engine features? Either way, we need to get #2 (at least) in to Linus. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
From: Andrew Morton [mailto:[EMAIL PROTECTED] Fix a couple bugs and provide documentation for the async_tx api. Neil, please 'ack' patch #3. git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Well it looks like Neil is on vacation or is hiding from us or something. In which case our options would be to go ahead and merge your #3 with our fingers crossed, or wait and do it in 2.6.23.1 or .2. How serious is this bug which you're fixing? Will it affect users of legacy MD setups, or only those who have enabled fancy dma-engine features? The symptom is raid array that fails to complete a read request. It has only been triggered by Yuri when he tried a dma-engine configuration on his PPC platform with PAGE_SIZE=64K, this opens a large window for the bug to hit. The window is much smaller but not 100% closed in the !dma-engine case, although no one else has hit it. 2.6.22 returned reads from handle_stripe under the stripe lock so this patch can be seen as 'reverting a botched micro-optimization' versus 'introducing a new way to handle reads'. Either way, we need to get #2 (at least) in to Linus. #2 is less critical and cannot hit with any of the current drivers in the kernel, so it is ok if this one misses 2.6.23. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
On Friday September 21, [EMAIL PROTECTED] wrote: On Thu, 20 Sep 2007 18:27:35 -0700 Dan Williams [EMAIL PROTECTED] wrote: Fix a couple bugs and provide documentation for the async_tx api. Neil, please 'ack' patch #3. git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Well it looks like Neil is on vacation or is hiding from us or something. Neil is just not coping well with jet-lag Patch #3 looks good and necessary Acked-By: NeilBrown [EMAIL PROTECTED] I know that should probably be a reviewed-by I was a bit surprised that the handle_completed_read_requests call was so early in handle_stripe5 - I don't think the code was originally that early. But it is probably right. Hopefully my brain will have cleared by Monday and I'll review it again then. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2.6.23-rc7 0/3] async_tx and md-accel fixes for 2.6.23
From: Neil Brown [mailto:[EMAIL PROTECTED] On Friday September 21, [EMAIL PROTECTED] wrote: On Thu, 20 Sep 2007 18:27:35 -0700 Dan Williams [EMAIL PROTECTED] wrote: Fix a couple bugs and provide documentation for the async_tx api. Neil, please 'ack' patch #3. git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Well it looks like Neil is on vacation or is hiding from us or something. Neil is just not coping well with jet-lag Patch #3 looks good and necessary Acked-By: NeilBrown [EMAIL PROTECTED] I know that should probably be a reviewed-by I was a bit I went ahead and added reviewed-by. surprised that the handle_completed_read_requests call was so early in handle_stripe5 - I don't think the code was originally that early. It is slightly earlier than 2.6.22 (outside the '/* now count some things */' loop) to make sure the R5_Wantfill flags from the last request have been cleared before starting a new one: /* maybe we can request a biofill operation * * new wantfill requests are only permitted while * STRIPE_OP_BIOFILL is clear */ if (test_bit(R5_UPTODATE, dev-flags) dev-toread !test_bit(STRIPE_OP_BIOFILL, sh-ops.pending)) set_bit(R5_Wantfill, dev-flags); But it is probably right. Hopefully my brain will have cleared by Monday and I'll review it again then. Ok, the tree is updated with 'Reviewed-by' tags and the proposed documentation updates from Randy and Shannon. git://lost.foo-projects.org/~dwillia2/git/iop async-tx-fixes-for-linus Dan Williams (3): async_tx: usage documentation and developer notes (v2) async_tx: fix dma_wait_for_async_tx raid5: fix ops_complete_biofill NeilBrown -- Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
