* [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-07 20:45 ` Gary King 0 siblings, 0 replies; 12+ messages in thread From: Gary King @ 2010-09-07 20:45 UTC (permalink / raw) To: linux-arm-kernel I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache maintenance lazily), and the root cause appears to be that the mm bouncing code is calling flush_dcache_page before it copies the bounce buffer into the bio. The patch below reorders these two operations, and eliminates numerous arbitrary application crashes on my dev system. Gary -- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-07 20:45 ` Gary King 0 siblings, 0 replies; 12+ messages in thread From: Gary King @ 2010-09-07 20:45 UTC (permalink / raw) To: linux-mm; +Cc: linux-arm-kernel, tj, linux-kernel, Gary King I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache maintenance lazily), and the root cause appears to be that the mm bouncing code is calling flush_dcache_page before it copies the bounce buffer into the bio. The patch below reorders these two operations, and eliminates numerous arbitrary application crashes on my dev system. Gary -- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-07 20:45 ` Gary King 0 siblings, 0 replies; 12+ messages in thread From: Gary King @ 2010-09-07 20:45 UTC (permalink / raw) To: linux-mm; +Cc: linux-arm-kernel, tj, linux-kernel, Gary King I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform cache maintenance lazily), and the root cause appears to be that the mm bouncing code is calling flush_dcache_page before it copies the bounce buffer into the bio. The patch below reorders these two operations, and eliminates numerous arbitrary application crashes on my dev system. Gary -- >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 From: Gary King <gking@nvidia.com> Date: Mon, 6 Sep 2010 15:37:12 -0700 Subject: bounce: call flush_dcache_page after bounce_copy_vec the bounced page needs to be flushed after data is copied into it, to ensure that architecture implementations can synchronize instruction and data caches if necessary. Signed-off-by: Gary King <gking@nvidia.com> --- mm/bounce.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/bounce.c b/mm/bounce.c index 13b6dad..1481de6 100644 --- a/mm/bounce.c +++ b/mm/bounce.c @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) */ vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; - flush_dcache_page(tovec->bv_page); bounce_copy_vec(tovec, vfrom); + flush_dcache_page(tovec->bv_page); } } -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH] bounce: call flush_dcache_page after bounce_copy_vec 2010-09-07 20:45 ` Gary King (?) @ 2010-09-08 19:47 ` Andrew Morton -1 siblings, 0 replies; 12+ messages in thread From: Andrew Morton @ 2010-09-08 19:47 UTC (permalink / raw) To: linux-arm-kernel On Tue, 7 Sep 2010 13:45:34 -0700 Gary King <gking@nvidia.com> wrote: > I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM > enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform > cache maintenance lazily), and the root cause appears to be that the > mm bouncing code is calling flush_dcache_page before it copies the > bounce buffer into the bio. > > The patch below reorders these two operations, and eliminates numerous > arbitrary application crashes on my dev system. > > Gary > > -- > >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 > From: Gary King <gking@nvidia.com> > Date: Mon, 6 Sep 2010 15:37:12 -0700 > Subject: bounce: call flush_dcache_page after bounce_copy_vec > > the bounced page needs to be flushed after data is copied into it, > to ensure that architecture implementations can synchronize > instruction and data caches if necessary. > > Signed-off-by: Gary King <gking@nvidia.com> > --- > mm/bounce.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/bounce.c b/mm/bounce.c > index 13b6dad..1481de6 100644 > --- a/mm/bounce.c > +++ b/mm/bounce.c > @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) > */ > vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; > > - flush_dcache_page(tovec->bv_page); > bounce_copy_vec(tovec, vfrom); > + flush_dcache_page(tovec->bv_page); > } > } Oh my, that was bad. I queued your fix for 2.6.36 and tagged it for -stable backporting, thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-08 19:47 ` Andrew Morton 0 siblings, 0 replies; 12+ messages in thread From: Andrew Morton @ 2010-09-08 19:47 UTC (permalink / raw) To: Gary King Cc: linux-mm, linux-arm-kernel, tj, linux-kernel, stable, Jens Axboe On Tue, 7 Sep 2010 13:45:34 -0700 Gary King <gking@nvidia.com> wrote: > I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM > enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform > cache maintenance lazily), and the root cause appears to be that the > mm bouncing code is calling flush_dcache_page before it copies the > bounce buffer into the bio. > > The patch below reorders these two operations, and eliminates numerous > arbitrary application crashes on my dev system. > > Gary > > -- > >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 > From: Gary King <gking@nvidia.com> > Date: Mon, 6 Sep 2010 15:37:12 -0700 > Subject: bounce: call flush_dcache_page after bounce_copy_vec > > the bounced page needs to be flushed after data is copied into it, > to ensure that architecture implementations can synchronize > instruction and data caches if necessary. > > Signed-off-by: Gary King <gking@nvidia.com> > --- > mm/bounce.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/bounce.c b/mm/bounce.c > index 13b6dad..1481de6 100644 > --- a/mm/bounce.c > +++ b/mm/bounce.c > @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) > */ > vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; > > - flush_dcache_page(tovec->bv_page); > bounce_copy_vec(tovec, vfrom); > + flush_dcache_page(tovec->bv_page); > } > } Oh my, that was bad. I queued your fix for 2.6.36 and tagged it for -stable backporting, thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-08 19:47 ` Andrew Morton 0 siblings, 0 replies; 12+ messages in thread From: Andrew Morton @ 2010-09-08 19:47 UTC (permalink / raw) To: Gary King Cc: linux-mm, linux-arm-kernel, tj, linux-kernel, stable, Jens Axboe On Tue, 7 Sep 2010 13:45:34 -0700 Gary King <gking@nvidia.com> wrote: > I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM > enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform > cache maintenance lazily), and the root cause appears to be that the > mm bouncing code is calling flush_dcache_page before it copies the > bounce buffer into the bio. > > The patch below reorders these two operations, and eliminates numerous > arbitrary application crashes on my dev system. > > Gary > > -- > >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 > From: Gary King <gking@nvidia.com> > Date: Mon, 6 Sep 2010 15:37:12 -0700 > Subject: bounce: call flush_dcache_page after bounce_copy_vec > > the bounced page needs to be flushed after data is copied into it, > to ensure that architecture implementations can synchronize > instruction and data caches if necessary. > > Signed-off-by: Gary King <gking@nvidia.com> > --- > mm/bounce.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/bounce.c b/mm/bounce.c > index 13b6dad..1481de6 100644 > --- a/mm/bounce.c > +++ b/mm/bounce.c > @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) > */ > vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; > > - flush_dcache_page(tovec->bv_page); > bounce_copy_vec(tovec, vfrom); > + flush_dcache_page(tovec->bv_page); > } > } Oh my, that was bad. I queued your fix for 2.6.36 and tagged it for -stable backporting, thanks. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] bounce: call flush_dcache_page after bounce_copy_vec 2010-09-08 19:47 ` Andrew Morton (?) @ 2010-09-08 19:49 ` Jens Axboe -1 siblings, 0 replies; 12+ messages in thread From: Jens Axboe @ 2010-09-08 19:49 UTC (permalink / raw) To: linux-arm-kernel On 09/08/2010 09:47 PM, Andrew Morton wrote: > On Tue, 7 Sep 2010 13:45:34 -0700 > Gary King <gking@nvidia.com> wrote: > >> I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM >> enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform >> cache maintenance lazily), and the root cause appears to be that the >> mm bouncing code is calling flush_dcache_page before it copies the >> bounce buffer into the bio. >> >> The patch below reorders these two operations, and eliminates numerous >> arbitrary application crashes on my dev system. >> >> Gary >> >> -- >> >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 >> From: Gary King <gking@nvidia.com> >> Date: Mon, 6 Sep 2010 15:37:12 -0700 >> Subject: bounce: call flush_dcache_page after bounce_copy_vec >> >> the bounced page needs to be flushed after data is copied into it, >> to ensure that architecture implementations can synchronize >> instruction and data caches if necessary. >> >> Signed-off-by: Gary King <gking@nvidia.com> >> --- >> mm/bounce.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/mm/bounce.c b/mm/bounce.c >> index 13b6dad..1481de6 100644 >> --- a/mm/bounce.c >> +++ b/mm/bounce.c >> @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) >> */ >> vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; >> >> - flush_dcache_page(tovec->bv_page); >> bounce_copy_vec(tovec, vfrom); >> + flush_dcache_page(tovec->bv_page); >> } >> } > > Oh my, that was bad. Indeed, I wonder how that could have been wrong for so long. > I queued your fix for 2.6.36 and tagged it for -stable backporting, > thanks. Thanks, you can add my acked-by. -- Jens Axboe ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-08 19:49 ` Jens Axboe 0 siblings, 0 replies; 12+ messages in thread From: Jens Axboe @ 2010-09-08 19:49 UTC (permalink / raw) To: Andrew Morton Cc: Gary King, linux-mm, linux-arm-kernel, tj, linux-kernel, stable On 09/08/2010 09:47 PM, Andrew Morton wrote: > On Tue, 7 Sep 2010 13:45:34 -0700 > Gary King <gking@nvidia.com> wrote: > >> I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM >> enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform >> cache maintenance lazily), and the root cause appears to be that the >> mm bouncing code is calling flush_dcache_page before it copies the >> bounce buffer into the bio. >> >> The patch below reorders these two operations, and eliminates numerous >> arbitrary application crashes on my dev system. >> >> Gary >> >> -- >> >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 >> From: Gary King <gking@nvidia.com> >> Date: Mon, 6 Sep 2010 15:37:12 -0700 >> Subject: bounce: call flush_dcache_page after bounce_copy_vec >> >> the bounced page needs to be flushed after data is copied into it, >> to ensure that architecture implementations can synchronize >> instruction and data caches if necessary. >> >> Signed-off-by: Gary King <gking@nvidia.com> >> --- >> mm/bounce.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/mm/bounce.c b/mm/bounce.c >> index 13b6dad..1481de6 100644 >> --- a/mm/bounce.c >> +++ b/mm/bounce.c >> @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) >> */ >> vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; >> >> - flush_dcache_page(tovec->bv_page); >> bounce_copy_vec(tovec, vfrom); >> + flush_dcache_page(tovec->bv_page); >> } >> } > > Oh my, that was bad. Indeed, I wonder how that could have been wrong for so long. > I queued your fix for 2.6.36 and tagged it for -stable backporting, > thanks. Thanks, you can add my acked-by. -- Jens Axboe -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-08 19:49 ` Jens Axboe 0 siblings, 0 replies; 12+ messages in thread From: Jens Axboe @ 2010-09-08 19:49 UTC (permalink / raw) To: Andrew Morton Cc: Gary King, linux-mm, linux-arm-kernel, tj, linux-kernel, stable On 09/08/2010 09:47 PM, Andrew Morton wrote: > On Tue, 7 Sep 2010 13:45:34 -0700 > Gary King <gking@nvidia.com> wrote: > >> I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM >> enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform >> cache maintenance lazily), and the root cause appears to be that the >> mm bouncing code is calling flush_dcache_page before it copies the >> bounce buffer into the bio. >> >> The patch below reorders these two operations, and eliminates numerous >> arbitrary application crashes on my dev system. >> >> Gary >> >> -- >> >From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 >> From: Gary King <gking@nvidia.com> >> Date: Mon, 6 Sep 2010 15:37:12 -0700 >> Subject: bounce: call flush_dcache_page after bounce_copy_vec >> >> the bounced page needs to be flushed after data is copied into it, >> to ensure that architecture implementations can synchronize >> instruction and data caches if necessary. >> >> Signed-off-by: Gary King <gking@nvidia.com> >> --- >> mm/bounce.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/mm/bounce.c b/mm/bounce.c >> index 13b6dad..1481de6 100644 >> --- a/mm/bounce.c >> +++ b/mm/bounce.c >> @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) >> */ >> vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; >> >> - flush_dcache_page(tovec->bv_page); >> bounce_copy_vec(tovec, vfrom); >> + flush_dcache_page(tovec->bv_page); >> } >> } > > Oh my, that was bad. Indeed, I wonder how that could have been wrong for so long. > I queued your fix for 2.6.36 and tagged it for -stable backporting, > thanks. Thanks, you can add my acked-by. -- Jens Axboe ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] bounce: call flush_dcache_page after bounce_copy_vec 2010-09-07 20:45 ` Gary King (?) @ 2010-09-09 0:49 ` Bryan Wu -1 siblings, 0 replies; 12+ messages in thread From: Bryan Wu @ 2010-09-09 0:49 UTC (permalink / raw) To: linux-arm-kernel On Wed, Sep 8, 2010 at 4:45 AM, Gary King <gking@nvidia.com> wrote: > I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM > enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform > cache maintenance lazily), and the root cause appears to be that the > mm bouncing code is calling flush_dcache_page before it copies the > bounce buffer into the bio. > > The patch below reorders these two operations, and eliminates numerous > arbitrary application crashes on my dev system. > We also experience the package building failure on OMAP4 SMP system with HIGHMEM enabled on 2.6.35. Thanks a lot for this fixing, we will try it later soon. -Bryan > Gary > > -- > From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 > From: Gary King <gking@nvidia.com> > Date: Mon, 6 Sep 2010 15:37:12 -0700 > Subject: bounce: call flush_dcache_page after bounce_copy_vec > > the bounced page needs to be flushed after data is copied into it, > to ensure that architecture implementations can synchronize > instruction and data caches if necessary. > > Signed-off-by: Gary King <gking@nvidia.com> > --- > ?mm/bounce.c | ? ?2 +- > ?1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/bounce.c b/mm/bounce.c > index 13b6dad..1481de6 100644 > --- a/mm/bounce.c > +++ b/mm/bounce.c > @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) > ? ? ? ? ? ? ? ? */ > ? ? ? ? ? ? ? ?vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; > > - ? ? ? ? ? ? ? flush_dcache_page(tovec->bv_page); > ? ? ? ? ? ? ? ?bounce_copy_vec(tovec, vfrom); > + ? ? ? ? ? ? ? flush_dcache_page(tovec->bv_page); > ? ? ? ?} > ?} > > -- > 1.7.0.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-09 0:49 ` Bryan Wu 0 siblings, 0 replies; 12+ messages in thread From: Bryan Wu @ 2010-09-09 0:49 UTC (permalink / raw) To: Gary King; +Cc: linux-mm, tj, linux-kernel, linux-arm-kernel, Jan, Sebastien On Wed, Sep 8, 2010 at 4:45 AM, Gary King <gking@nvidia.com> wrote: > I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM > enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform > cache maintenance lazily), and the root cause appears to be that the > mm bouncing code is calling flush_dcache_page before it copies the > bounce buffer into the bio. > > The patch below reorders these two operations, and eliminates numerous > arbitrary application crashes on my dev system. > We also experience the package building failure on OMAP4 SMP system with HIGHMEM enabled on 2.6.35. Thanks a lot for this fixing, we will try it later soon. -Bryan > Gary > > -- > From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 > From: Gary King <gking@nvidia.com> > Date: Mon, 6 Sep 2010 15:37:12 -0700 > Subject: bounce: call flush_dcache_page after bounce_copy_vec > > the bounced page needs to be flushed after data is copied into it, > to ensure that architecture implementations can synchronize > instruction and data caches if necessary. > > Signed-off-by: Gary King <gking@nvidia.com> > --- > mm/bounce.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/bounce.c b/mm/bounce.c > index 13b6dad..1481de6 100644 > --- a/mm/bounce.c > +++ b/mm/bounce.c > @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) > */ > vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; > > - flush_dcache_page(tovec->bv_page); > bounce_copy_vec(tovec, vfrom); > + flush_dcache_page(tovec->bv_page); > } > } > > -- > 1.7.0.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] bounce: call flush_dcache_page after bounce_copy_vec @ 2010-09-09 0:49 ` Bryan Wu 0 siblings, 0 replies; 12+ messages in thread From: Bryan Wu @ 2010-09-09 0:49 UTC (permalink / raw) To: Gary King; +Cc: linux-mm, tj, linux-kernel, linux-arm-kernel, Jan, Sebastien On Wed, Sep 8, 2010 at 4:45 AM, Gary King <gking@nvidia.com> wrote: > I have been seeing problems on Tegra 2 (ARMv7 SMP) systems with HIGHMEM > enabled on 2.6.35 (plus some patches targetted at 2.6.36 to perform > cache maintenance lazily), and the root cause appears to be that the > mm bouncing code is calling flush_dcache_page before it copies the > bounce buffer into the bio. > > The patch below reorders these two operations, and eliminates numerous > arbitrary application crashes on my dev system. > We also experience the package building failure on OMAP4 SMP system with HIGHMEM enabled on 2.6.35. Thanks a lot for this fixing, we will try it later soon. -Bryan > Gary > > -- > From 678c9bca8d8a8f254f28af91e69fad3aa1be7593 Mon Sep 17 00:00:00 2001 > From: Gary King <gking@nvidia.com> > Date: Mon, 6 Sep 2010 15:37:12 -0700 > Subject: bounce: call flush_dcache_page after bounce_copy_vec > > the bounced page needs to be flushed after data is copied into it, > to ensure that architecture implementations can synchronize > instruction and data caches if necessary. > > Signed-off-by: Gary King <gking@nvidia.com> > --- > mm/bounce.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/bounce.c b/mm/bounce.c > index 13b6dad..1481de6 100644 > --- a/mm/bounce.c > +++ b/mm/bounce.c > @@ -116,8 +116,8 @@ static void copy_to_high_bio_irq(struct bio *to, struct bio *from) > */ > vfrom = page_address(fromvec->bv_page) + tovec->bv_offset; > > - flush_dcache_page(tovec->bv_page); > bounce_copy_vec(tovec, vfrom); > + flush_dcache_page(tovec->bv_page); > } > } > > -- > 1.7.0.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-09-09 0:50 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-07 20:45 [PATCH] bounce: call flush_dcache_page after bounce_copy_vec Gary King 2010-09-07 20:45 ` Gary King 2010-09-07 20:45 ` Gary King 2010-09-08 19:47 ` Andrew Morton 2010-09-08 19:47 ` Andrew Morton 2010-09-08 19:47 ` Andrew Morton 2010-09-08 19:49 ` Jens Axboe 2010-09-08 19:49 ` Jens Axboe 2010-09-08 19:49 ` Jens Axboe 2010-09-09 0:49 ` Bryan Wu 2010-09-09 0:49 ` Bryan Wu 2010-09-09 0:49 ` Bryan Wu
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.