Displaying 14 results from an estimated 14 matches for "flush_kernel_dcache_page".
2019 Apr 09
2
[PATCH net] vhost: flush dcache page when logging dirty pages
We set dirty bit through setting up kmaps and access them through
kernel virtual address, this may result alias in virtually tagged
caches that require a dcache flush afterwards.
Cc: Christoph Hellwig <hch at infradead.org>
Cc: James Bottomley <James.Bottomley at HansenPartnership.com>
Cc: Andrea Arcangeli <aarcange at redhat.com>
Fixes: 3a4d5c94e9593 ("vhost_net: a
2019 Apr 09
2
[PATCH net] vhost: flush dcache page when logging dirty pages
We set dirty bit through setting up kmaps and access them through
kernel virtual address, this may result alias in virtually tagged
caches that require a dcache flush afterwards.
Cc: Christoph Hellwig <hch at infradead.org>
Cc: James Bottomley <James.Bottomley at HansenPartnership.com>
Cc: Andrea Arcangeli <aarcange at redhat.com>
Fixes: 3a4d5c94e9593 ("vhost_net: a
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
...s hard to see how the above can work
safe, is "page" would have been an userland page mapped with aliased
CPU cache.
> the sequence dirties the kernel virtual address but doesn't flush
> before doing kunmap. There are hundreds of other examples which is why
> I think adding flush_kernel_dcache_page() is an already lost cause.
In lots of cases kmap is needed to just modify kernel memory not to
modify userland memory (where get/put_user is more commonly used
instead..), there's no cache aliasing in such case.
> Actually copy_user_page() is unused in the main kernel. The big
> probl...
2019 Apr 09
0
[PATCH net] vhost: flush dcache page when logging dirty pages
...age(page);
> set_page_dirty_lock(page);
> put_page(page);
> return 0;
Ignoring the question of whether this actually helps, I doubt
flush_dcache_page is appropriate here. Pls take a look at
Documentation/core-api/cachetlb.rst as well as the actual
implementation.
I think you meant flush_kernel_dcache_page, and IIUC it must happen
before kunmap, not after (which you still have the va locked).
> --
> 2.19.1
2020 Nov 03
0
[patch V3 22/37] highmem: High implementation details and document API
.../include/linux/highmem.h
@@ -11,199 +11,125 @@
#include <asm/cacheflush.h>
-#ifndef ARCH_HAS_FLUSH_ANON_PAGE
-static inline void flush_anon_page(struct vm_area_struct *vma, struct page *page, unsigned long vmaddr)
-{
-}
-#endif
+#include "highmem-internal.h"
-#ifndef ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
-static inline void flush_kernel_dcache_page(struct page *page)
-{
-}
-static inline void flush_kernel_vmap_range(void *vaddr, int size)
-{
-}
-static inline void invalidate_kernel_vmap_range(void *vaddr, int size)
-{
-}
-#endif
-
-/*
- * Outside of CONFIG_HIGHMEM to support X86 32bit iomap_atomic(...
2019 Mar 14
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
...n help with this if we agree
> it's the best way forward. It's really only architectures that
> implement flush_dcache_page that would need modifying.
>
> It may also improve performance because some kmap/use/flush/kunmap
> sequences have flush_dcache_page() instead of
> flush_kernel_dcache_page() and the former is hugely expensive and
> usually unnecessary because GUP already flushed all the user aliases.
>
> In the interests of full disclosure the reason we do it for parisc is
> because our later machines have problems even with clean aliases. So
> on most VIPT systems,...
2019 Mar 12
9
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote:
>
> On 2019/3/12 ??2:14, David Miller wrote:
> > From: "Michael S. Tsirkin" <mst at redhat.com>
> > Date: Mon, 11 Mar 2019 09:59:28 -0400
> >
> > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
> > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote:
> > >
2019 Mar 12
9
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote:
>
> On 2019/3/12 ??2:14, David Miller wrote:
> > From: "Michael S. Tsirkin" <mst at redhat.com>
> > Date: Mon, 11 Mar 2019 09:59:28 -0400
> >
> > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
> > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote:
> > >
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
...r.bi_sector);
- size = bvec->bv_len;
- buf = bvec_kmap_irq(bvec, &flags);
+ size = bvec.bv_len;
+ buf = bvec_kmap_irq(&bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bvec->bv_page);
+ flush_kernel_dcache_page(bvec.bv_page);
bvec_kunmap_irq(buf, &flags);
i++;
}
@@ -130,7 +130,7 @@ static int ps3disk_submit_request_sg(struct ps3_storage_device *dev,
#ifdef DEBUG
unsigned int n = 0;
- struct bio_vec *bv;
+ struct bio_vec bv;
struct req_itera...
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
...r.bi_sector);
- size = bvec->bv_len;
- buf = bvec_kmap_irq(bvec, &flags);
+ size = bvec.bv_len;
+ buf = bvec_kmap_irq(&bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bvec->bv_page);
+ flush_kernel_dcache_page(bvec.bv_page);
bvec_kunmap_irq(buf, &flags);
i++;
}
@@ -130,7 +130,7 @@ static int ps3disk_submit_request_sg(struct ps3_storage_device *dev,
#ifdef DEBUG
unsigned int n = 0;
- struct bio_vec *bv;
+ struct bio_vec bv;
struct req_itera...
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
...r.bi_sector);
- size = bvec->bv_len;
- buf = bvec_kmap_irq(bvec, &flags);
+ size = bvec.bv_len;
+ buf = bvec_kmap_irq(&bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bvec->bv_page);
+ flush_kernel_dcache_page(bvec.bv_page);
bvec_kunmap_irq(buf, &flags);
i++;
}
@@ -130,7 +130,7 @@ static int ps3disk_submit_request_sg(struct ps3_storage_device *dev,
#ifdef DEBUG
unsigned int n = 0;
- struct bio_vec *bv;
+ struct bio_vec bv;
struct req_itera...
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all