Re: [PATCH V1 03/10] arch/kmap: Remove redundant arch specific kmaps

2020-05-01 Thread Christoph Hellwig
Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V1 04/10] arch/kunmap: Remove duplicate kunmap implementations

2020-05-01 Thread Christoph Hellwig
p() on a number of > architectures to be an inline call rather than an actual function. > > Signed-off-by: Ira Weiny Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V1 05/10] arch/kmap_atomic: Consolidate duplicate code

2020-05-01 Thread Christoph Hellwig
lls the arch specific kmap_atomic_high() when the page is high memory. > > Signed-off-by: Ira Weiny Looks good: Reviewed-by: Christoph Hellwig

Re: [PATCH V1 06/10] arch/kunmap_atomic: Consolidate duplicate code

2020-05-01 Thread Christoph Hellwig
Lift this code into the > kunmap_atomic() macro. > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to > be consistent. > > Signed-off-by: Ira Weiny Looks good, Reviewed-by: Christoph Hellwig

sparc-related comment, to Re: [PATCH V1 07/10] arch/kmap: Ensure kmap_prot visibility

2020-05-01 Thread Christoph Hellwig
> --- a/arch/sparc/mm/highmem.c > +++ b/arch/sparc/mm/highmem.c > @@ -33,6 +33,7 @@ > #include > > pgprot_t kmap_prot; > +EXPORT_SYMBOL(kmap_prot); Btw, I don't see why sparc needs this as a variable, as there is just a single assignment to it. If sparc is sorted out we can always make it a

Re: [PATCH V1 08/10] arch/kmap: Don't hard code kmap_prot values

2020-05-01 Thread Christoph Hellwig
t; rather than a hard coded value which was equal. Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's

2020-05-01 Thread Christoph Hellwig
nge the name to > kmap_atomic_high_prot() to match. > > Then define kmap_atomic_prot() as a core function which calls > kmap_atomic_high_prot() when needed. > > Finally, redefine kmap_atomic() as a wrapper of kmap_atomic_prot() with > the default kmap_prot exported by the architectures.

Re: [PATCH V1 10/10] drm: Remove drm specific kmap_atomic code

2020-05-01 Thread Christoph Hellwig
Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V1 00/10] Remove duplicated kmap code

2020-05-01 Thread Christoph Hellwig
In addition to the work already it the series, it seems like LAST_PKMAP_MASK, PKMAP_ADDR and PKMAP_NR can also be consolidated to common code. Also kmap_atomic_high_prot / kmap_atomic_pfn could move into common code, maybe keyed off a symbol selected by the actual users that need it. It also seem

Re: [PATCH 1/2] powerpc/spufs: fix copy_to_user while atomic

2020-05-04 Thread Christoph Hellwig
er()) while holding a context's register_lock, > while accessing the context save area. > > This change uses a temporary buffer for the context save area data, > which we then pass to simple_read_from_buffer. > > Includes changes from Christoph Hellwig . > > Fixes: bf1ab9

Re: [PATCH 1/2] powerpc/spufs: fix copy_to_user while atomic

2020-05-05 Thread Christoph Hellwig
On Tue, May 05, 2020 at 05:20:54PM +1000, Michael Ellerman wrote: > Christoph Hellwig writes: > > powerpc mantainers, > > There's only one of me. > > > are you going to pick this up for the next -rc1? I'm waiting for it to > > hit upstream before resen

remove set_fs calls from the coredump code v6

2020-05-05 Thread Christoph Hellwig
Hi all, this series gets rid of playing with the address limit in the exec and coredump code. Most of this was fairly trivial, the biggest changes are those to the spufs coredump code. Changes since v5: - fix uaccess under spinlock in spufs (Jeremy) - remove use of access_ok in spufs Changes

[PATCH 1/7] powerpc/spufs: fix copy_to_user while atomic

2020-05-05 Thread Christoph Hellwig
uffer. Includes changes from Christoph Hellwig . Fixes: bf1ab978be23 ("[POWERPC] coredump: Add SPU elf notes to coredump.") Signed-off-by: Jeremy Kerr Reviewed-by: Arnd Bergmann [hch: renamed to function to avoid ___-prefixes] Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/ce

[PATCH 2/7] powerpc/spufs: stop using access_ok

2020-05-05 Thread Christoph Hellwig
Just use the proper non __-prefixed get/put_user variants where that is not done yet. Signed-off-by: Christoph Hellwig Signed-off-by: Jeremy Kerr Signed-off-by: Christoph Hellwig --- arch/powerpc/platforms/cell/spufs/file.c | 42 +--- 1 file changed, 8 insertions(+), 34

[PATCH 3/7] powerpc/spufs: simplify spufs core dumping

2020-05-05 Thread Christoph Hellwig
id memory allocations as well. Signed-off-by: Christoph Hellwig Reviewed-by: Arnd Bergmann Reviewed-by: Jeremy Kerr --- arch/powerpc/platforms/cell/spufs/coredump.c | 87 +++- arch/powerpc/platforms/cell/spufs/file.c | 203 --- arch/powerpc/platforms/cell/spufs/spufs.h|

[PATCH 4/7] signal: refactor copy_siginfo_to_user32

2020-05-05 Thread Christoph Hellwig
allows moving the x32 SIGCHLD purely to x86 architecture code. As a nice side effect copy_siginfo_to_external32 also comes in handy for avoiding a set_fs() call in the coredump code later on. Contains improvements from Eric W. Biederman and Arnd Bergmann . Signed-off-by: Christoph Hellwig

[PATCH 5/7] binfmt_elf: remove the set_fs in fill_siginfo_note

2020-05-05 Thread Christoph Hellwig
o use the previously added copy_siginfo_to_external32 to handle the compat case. Signed-off-by: "Eric W. Biederman" Signed-off-by: Christoph Hellwig --- fs/binfmt_elf.c| 5 + fs/compat_binfmt_elf.c | 2 +- include/linux/signal.h | 8 3 files changed, 10 insertions(+)

[PATCH 6/7] binfmt_elf: remove the set_fs(KERNEL_DS) in elf_core_dump

2020-05-05 Thread Christoph Hellwig
There is no logic in elf_core_dump itself or in the various arch helpers called from it which use uaccess routines on kernel pointers except for the file writes thate are nicely encapsulated by using __kernel_write in dump_emit. Signed-off-by: Christoph Hellwig --- fs/binfmt_elf.c | 16

[PATCH 7/7] binfmt_elf_fdpic: remove the set_fs(KERNEL_DS) in elf_fdpic_core_dump

2020-05-05 Thread Christoph Hellwig
There is no logic in elf_fdpic_core_dump itself or in the various arch helpers called from it which use uaccess routines on kernel pointers except for the file writes thate are nicely encapsulated by using __kernel_write in dump_emit. Signed-off-by: Christoph Hellwig --- fs/binfmt_elf_fdpic.c

Re: remove set_fs calls from the coredump code v6

2020-05-05 Thread Christoph Hellwig
On Tue, May 05, 2020 at 09:34:46PM +0100, Al Viro wrote: > Looks good. Want me to put it into vfs.git? #work.set_fs-exec, perhaps? Sounds good.

Re: [PATCH V2 05/11] {x86,powerpc,microblaze}/kmap: Move preempt disable

2020-05-05 Thread Christoph Hellwig
truct page *page, pgprot_t prot); > +extern void *kmap_atomic_high_prot(struct page *page, pgprot_t prot); > +void *kmap_atomic_prot(struct page *page, pgprot_t prot) Shouldn't this be marked inline? The rest looks fine: Reviewed-by: Christoph Hellwig

Re: [PATCH V2 06/11] arch/kmap_atomic: Consolidate duplicate code

2020-05-05 Thread Christoph Hellwig
Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V2 07/11] arch/kunmap_atomic: Consolidate duplicate code

2020-05-05 Thread Christoph Hellwig
Lift this code into the > kunmap_atomic() macro. > > While we are at it rename __kunmap_atomic() to kunmap_atomic_high() to > be consistent. > > Signed-off-by: Ira Weiny Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V2 08/11] arch/kmap: Ensure kmap_prot visibility

2020-05-05 Thread Christoph Hellwig
On Sun, May 03, 2020 at 06:09:09PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > We want to support kmap_atomic_prot() on all architectures and it makes > sense to define kmap_atomic() to use the default kmap_prot. > > So we ensure all arch's have a globally available kmap_prot either

Re: [PATCH V2 10/11] arch/kmap: Define kmap_atomic_prot() for all arch's

2020-05-05 Thread Christoph Hellwig
gt; > Signed-off-by: Ira Weiny Looks good, Reviewed-by: Christoph Hellwig

Re: remove set_fs calls from the coredump code v6

2020-05-05 Thread Christoph Hellwig
On Tue, May 05, 2020 at 03:28:50PM -0500, Eric W. Biederman wrote: > We probably can. After introducing a kernel_compat_siginfo that is > the size that userspace actually would need. > > It isn't something I want to mess with until this code gets merged, as I > think the set_fs cleanups are more

Re: [PATCH V2 08/11] arch/kmap: Ensure kmap_prot visibility

2020-05-06 Thread Christoph Hellwig
ilable kmap_prot either as a > define or exported symbol. > > Signed-off-by: Ira Weiny Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH] powerpc/spufs: Add rcu_read_lock() around fcheck()

2020-05-06 Thread Christoph Hellwig
On Wed, Apr 29, 2020 at 09:42:39PM +1000, Michael Ellerman wrote: > Christoph Hellwig writes: > > On Tue, Apr 28, 2020 at 09:48:11PM +1000, Michael Ellerman wrote: > >> > >> This comes from fcheck_files() via fcheck(). > >> > >> It's pretty cle

[PATCH 02/15] simdisk: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- arch/xtensa/platforms/iss/simdisk.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/xtensa/platforms/iss/simdisk.c b/arch/xtensa/platforms/iss/simdisk.c index 49322b66cda93..31b5020077a05 100644 --- a/arch/xtensa/platforms/iss

[PATCH 06/15] rsxx: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/block/rsxx/dev.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c index 8ffa8260dcafe..6dde80b096c62 100644 --- a/drivers/block/rsxx/dev.c +++ b/drivers/block/rsxx/dev.c

[PATCH 08/15] zram: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/block/zram/zram_drv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index ebb234f36909c..e1a6c74c7a4ba 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block

[PATCH 05/15] ps3vram: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/block/ps3vram.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c index 821d4d8b1d763..5a1d1d137c724 100644 --- a/drivers/block/ps3vram.c +++ b/drivers/block/ps3vram.c @@ -587,7

[PATCH 03/15] drbd: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/block/drbd/drbd_main.c | 1 - drivers/block/drbd/drbd_req.c | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index c094c3c2c5d4d..be787b268f044 100644 --- a/drivers

remove a few uses of ->queuedata

2020-05-08 Thread Christoph Hellwig
Hi all, various bio based drivers use queue->queuedata despite already having set up disk->private_data, which can be used just as easily. This series cleans them up to only use a single private data pointer. blk-mq based drivers that have code pathes that can't easily get at the gendisk are una

[PATCH 07/15] umem: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/block/umem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/umem.c b/drivers/block/umem.c index d84e8a878df24..e59bff24e02cf 100644 --- a/drivers/block/umem.c +++ b/drivers/block/umem.c @@ -521,7 +521,8 @@ static

[PATCH 04/15] null_blk: stop using ->queuedata for bio mode

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/block/null_blk_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/null_blk_main.c b/drivers/block/null_blk_main.c index 8efd8778e2095..d14df79feca89 100644 --- a/drivers/block/null_blk_main.c +++ b/drivers/block

[PATCH 01/15] nfblock: use gendisk private_data

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- arch/m68k/emu/nfblock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/m68k/emu/nfblock.c b/arch/m68k/emu/nfblock.c index c3a630440512e..5c6f04b00e866 100644 --- a/arch/m68k/emu/nfblock.c +++ b/arch/m68k/emu/nfblock.c @@ -61,7

[PATCH 09/15] lightnvm: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/lightnvm/core.c | 1 - drivers/lightnvm/pblk-init.c | 2 +- drivers/lightnvm/pblk.h | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c index db38a68abb6c0..85c5490cdfd2e

[PATCH 10/15] bcache: stop setting ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/md/bcache/super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index d98354fa28e3e..a0fb5af2beeda 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -871,7 +871,6

[PATCH 11/15] dm: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/md/dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 0eb93da44ea2a..2aaae6c1ed312 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1783,7 +1783,7 @@ static blk_qc_t dm_process_bio

[PATCH 12/15] md: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/md/md.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index 271e8a5873549..c079ecf77c564 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -466,7 +466,7 @@ static blk_qc_t md_make_request

[PATCH 14/15] nvdimm/btt: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/nvdimm/btt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c index 3b09419218d6f..eca3e48fefda1 100644 --- a/drivers/nvdimm/btt.c +++ b/drivers/nvdimm/btt.c @@ -1442,7 +1442,7 @@ static

[PATCH 13/15] nvdimm/blk: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/nvdimm/blk.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm/blk.c index 43751fab9d36a..ffe4728bad8b1 100644 --- a/drivers/nvdimm/blk.c +++ b/drivers/nvdimm/blk.c @@ -165,7 +165,7

[PATCH 15/15] nvdimm/pmem: stop using ->queuedata

2020-05-08 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- drivers/nvdimm/pmem.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 2df6994acf836..f8dc5941215bf 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -196,7 +196,7

Re: [PATCH 1/4] dma-mapping: move the remaining DMA API calls out of line

2020-05-09 Thread Christoph Hellwig
On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote: > > > On 17/04/2020 17:58, Christoph Hellwig wrote: > > On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote: > >> And the fact they were exported leaves possibility that there is

Re: remove a few uses of ->queuedata

2020-05-09 Thread Christoph Hellwig
On Fri, May 08, 2020 at 11:04:45AM -0700, Dan Williams wrote: > On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote: > > > > Hi all, > > > > various bio based drivers use queue->queuedata despite already having > > set up disk->private_data, which can b

Re: remove a few uses of ->queuedata

2020-05-09 Thread Christoph Hellwig
On Sat, May 09, 2020 at 06:13:21AM +0800, Ming Lei wrote: > On Fri, May 08, 2020 at 06:15:02PM +0200, Christoph Hellwig wrote: > > Hi all, > > > > various bio based drivers use queue->queuedata despite already having > > set up disk->private_data, which

[PATCH 09/15, fіxed] lightnvm: stop using ->queuedata

2020-05-09 Thread Christoph Hellwig
Signed-off-by: Christoph Hellwig --- fixed the compilation in the print_ppa arguments drivers/lightnvm/core.c | 1 - drivers/lightnvm/pblk-init.c | 2 +- drivers/lightnvm/pblk.h | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/lightnvm/core.c b/drivers

sort out the flush_icache_range mess

2020-05-10 Thread Christoph Hellwig
Hi all, flush_icache_range is mostly used for kernel address, except for the following cases: - the nommu brk and mmap implementations, - the read_code helper that is only used for binfmt_flat, binfmt_elf_fdpic, and binfmt_aout including the broken ia32 compat version - binfmt_flat itself,

[PATCH 01/31] arm: fix the flush_icache_range arguments in set_fiq_handler

2020-05-10 Thread Christoph Hellwig
The arguments passed look bogus, try to fix them to something that seems to make sense. Signed-off-by: Christoph Hellwig --- arch/arm/kernel/fiq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c index cd1234c103fcd

[PATCH 02/31] arm64: fix the flush_icache_range arguments in machine_kexec

2020-05-10 Thread Christoph Hellwig
The second argument is the end "pointer", not the length. Signed-off-by: Christoph Hellwig --- arch/arm64/kernel/machine_kexec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c index 8e9c924423b4e..a0b144cfae

[PATCH 03/31] MIPS: unexport __flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
__flush_icache_user_range is not used in modular code, so unexport it. Signed-off-by: Christoph Hellwig --- arch/mips/mm/cache.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c index 33b409391ddb6..ad6df1cea866f 100644 --- a/arch/mips/mm/cache.c

[PATCH 04/31] nds32: unexport flush_icache_page

2020-05-10 Thread Christoph Hellwig
flush_icache_page is only used by mm/memory.c. Signed-off-by: Christoph Hellwig --- arch/nds32/mm/cacheflush.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c index 254703653b6f5..8f168b33065fa 100644 --- a/arch/nds32/mm/cacheflush.c

[PATCH 05/31] powerpc: unexport flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
flush_icache_user_range is only used by copy_to_user_page, which is only used by core VM code. Signed-off-by: Christoph Hellwig --- arch/powerpc/mm/mem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 041ed7cfd341a..f0d1bf0a8e14f 100644

[PATCH 06/31] unicore32: remove flush_cache_user_range

2020-05-10 Thread Christoph Hellwig
flush_cache_user_range is an ARMism not used by any generic or unicore32 specific code. Signed-off-by: Christoph Hellwig --- arch/unicore32/include/asm/cacheflush.h | 8 1 file changed, 8 deletions(-) diff --git a/arch/unicore32/include/asm/cacheflush.h b/arch/unicore32/include/asm

[PATCH 07/31] asm-generic: fix the inclusion guards for cacheflush.h

2020-05-10 Thread Christoph Hellwig
cacheflush.h uses a somewhat to generic include guard name that clashes with various arch files. Use a more specific one. Signed-off-by: Christoph Hellwig --- include/asm-generic/cacheflush.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/asm-generic

[PATCH 08/31] asm-generic: don't include in cacheflush.h

2020-05-10 Thread Christoph Hellwig
This seems to lead to some crazy include loops when using asm-generic/cacheflush.h on more architectures, so leave it to the arch header for now. Signed-off-by: Christoph Hellwig --- arch/um/include/asm/tlb.h | 2 ++ arch/x86/include/asm/cacheflush.h | 2 ++ include/asm-generic

[PATCH 09/31] asm-generic: improve the flush_dcache_page stub

2020-05-10 Thread Christoph Hellwig
There is a magic ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE cpp symbol that guards non-stub availability of flush_dcache_pagge. Use that to check if flush_dcache_pagg is implemented. Signed-off-by: Christoph Hellwig --- include/asm-generic/cacheflush.h | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH 10/31] alpha: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
Alpha needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/alpha/include/asm/cacheflush.h | 28 ++-- 1 file changed, 6 insertions(+), 22 deletions(-) diff --git a/arch/alpha

[PATCH 11/31] arm64: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
ARM64 needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/arm64/include/asm/cacheflush.h | 46 - 1 file changed, 5 insertions(+), 41 deletions(-) diff --git a/arch/arm64

[PATCH 12/31] c6x: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
C6x needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/c6x/include/asm/cacheflush.h | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/arch/c6x/include/asm

[PATCH 13/31] hexagon: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
Hexagon needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/hexagon/include/asm/cacheflush.h | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/arch/hexagon

[PATCH 14/31] ia64: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
IA64 needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/ia64/include/asm/cacheflush.h | 28 +++- 1 file changed, 3 insertions(+), 25 deletions(-) diff --git a/arch/ia64

[PATCH 15/31] microblaze: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
Microblaze needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/microblaze/include/asm/cacheflush.h | 29 ++-- 1 file changed, 2 insertions(+), 27 deletions(-) diff --git a/arch

[PATCH 16/31] m68knommu: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
m68knommu needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/m68k/include/asm/cacheflush_no.h | 19 ++- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/arch/m68k/include

[PATCH 17/31] openrisc: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
OpenRISC needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Signed-off-by: Christoph Hellwig --- arch/openrisc/include/asm/cacheflush.h | 31 +- 1 file changed, 6 insertions(+), 25 deletions(-) diff --git a/arch

[PATCH 18/31] powerpc: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
Power needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Also remove the pointless __KERNEL__ ifdef while we're at it. Signed-off-by: Christoph Hellwig --- arch/powerpc/include/asm/cacheflush.h | 42 +++ 1

[PATCH 19/31] riscv: use asm-generic/cacheflush.h

2020-05-10 Thread Christoph Hellwig
RISC-V needs almost no cache flushing routines of its own. Rely on asm-generic/cacheflush.h for the defaults. Also remove the pointless __KERNEL__ ifdef while we're at it. --- arch/riscv/include/asm/cacheflush.h | 62 ++--- 1 file changed, 3 insertions(+), 59 deletions(-)

[PATCH 20/31] arm,sparc,unicore32: remove flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
flush_icache_user_range is only used by , so remove it from the architectures that implement it, but don't use . Signed-off-by: Christoph Hellwig --- arch/arm/include/asm/cacheflush.h | 3 --- arch/sparc/include/asm/cacheflush_32.h | 2 -- arch/sparc/include/asm/cacheflush_64.h

[PATCH 21/31] mm: rename flush_icache_user_range to flush_icache_user_page

2020-05-10 Thread Christoph Hellwig
The function currently known as flush_icache_user_range only operates on a single page. Rename it to flush_icache_user_page as we'll need the name flush_icache_user_range for something else soon. Signed-off-by: Christoph Hellwig --- arch/alpha/include/asm/cacheflush.h| 10 +-

[PATCH 22/31] asm-generic: add a flush_icache_user_range stub

2020-05-10 Thread Christoph Hellwig
Define flush_icache_user_range to flush_icache_range unless the architecture provides its own implementation. Signed-off-by: Christoph Hellwig --- include/asm-generic/cacheflush.h | 4 1 file changed, 4 insertions(+) diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic

[PATCH 23/31] sh: implement flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
The SuperH implementation of flush_icache_range seems to be able to cope with user addresses. Just define flush_icache_user_range to flush_icache_range. Signed-off-by: Christoph Hellwig --- arch/sh/include/asm/cacheflush.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sh/include/asm

[PATCH 24/31] xtensa: implement flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
The Xtensa implementation of flush_icache_range seems to be able to cope with user addresses. Just define flush_icache_user_range to flush_icache_range. Signed-off-by: Christoph Hellwig --- arch/xtensa/include/asm/cacheflush.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/xtensa

[PATCH 25/31] arm: rename flush_cache_user_range to flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
flush_icache_user_range will be the name for a generic primitive. Move the arm name so that arm already has an implementation. Signed-off-by: Christoph Hellwig --- arch/arm/include/asm/cacheflush.h | 4 ++-- arch/arm/kernel/traps.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions

[PATCH 26/31] m68k: implement flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
Rename the current flush_icache_range to flush_icache_user_range as per commit ae92ef8a4424 ("PATCH] flush icache in correct context") there seems to be an assumption that it operates on user addresses. Add a flush_icache_range around it that for now is a no-op. Signed-off-by: Christo

[PATCH 27/31] exec: only build read_code when needed

2020-05-10 Thread Christoph Hellwig
Only build read_code when binary formats that use it are built into the kernel. Signed-off-by: Christoph Hellwig --- fs/exec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/exec.c b/fs/exec.c index 06b4c550af5d9..a4f766f296f8f 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1027,6

[PATCH 28/31] exec: use flush_icache_user_range in read_code

2020-05-10 Thread Christoph Hellwig
read_code operates on user addresses. Signed-off-by: Christoph Hellwig --- fs/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index a4f766f296f8f..c541867316a63 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1033,7 +1033,7 @@ ssize_t read_code(struct

[PATCH 29/31] binfmt_flat: use flush_icache_user_range

2020-05-10 Thread Christoph Hellwig
load_flat_file works on user addresses. Signed-off-by: Christoph Hellwig --- fs/binfmt_flat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 831a2b25ba79f..6f0aca5379da2 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -854,7

[PATCH 30/31] nommu: use flush_icache_user_range in brk and mmap

2020-05-10 Thread Christoph Hellwig
These obviously operate on user addresses. Signed-off-by: Christoph Hellwig --- mm/nommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/nommu.c b/mm/nommu.c index 318df4e236c99..aed7acaed2383 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -443,7 +443,7

[PATCH 31/31] module: move the set_fs hack for flush_icache_range to m68k

2020-05-10 Thread Christoph Hellwig
flush_icache_range generally operates on kernel addresses, but for some reason m68k needed a set_fs override. Move that into the m68k code insted of keeping it in the module loader. Signed-off-by: Christoph Hellwig --- arch/m68k/mm/cache.c | 4 kernel/module.c | 8 2 files

Re: [PATCH 31/31] module: move the set_fs hack for flush_icache_range to m68k

2020-05-11 Thread Christoph Hellwig
On Mon, May 11, 2020 at 09:40:39AM +0200, Geert Uytterhoeven wrote: > On Sun, May 10, 2020 at 9:57 AM Christoph Hellwig wrote: > > > > flush_icache_range generally operates on kernel addresses, but for some > > reason m68k needed a set_fs override. Move that into the m6

Re: sort out the flush_icache_range mess

2020-05-11 Thread Christoph Hellwig
On Mon, May 11, 2020 at 09:46:17AM +0200, Geert Uytterhoeven wrote: > Hi Christoph, > > On Sun, May 10, 2020 at 9:55 AM Christoph Hellwig wrote: > > none of which really are used by a typical MMU enabled kernel, as a.out can > > only be build for alpha and m68k to start with

Re: [PATCH 02/31] arm64: fix the flush_icache_range arguments in machine_kexec

2020-05-11 Thread Christoph Hellwig
On Mon, May 11, 2020 at 12:00:14PM +0100, Catalin Marinas wrote: > Anyway, I think Christoph's patch needs to go in with a fixes tag: > > Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") > Cc: # 4.8.x- > > and we'll change these functions/helpers going forward for arm64. > > Happy to

Re: sort out the flush_icache_range mess

2020-05-11 Thread Christoph Hellwig
On Mon, May 11, 2020 at 05:25:45PM +0200, Geert Uytterhoeven wrote: > > Do you want to drop the: > > > > select HAVE_AOUT if MMU > > > > for m68k then? > > If that helps to reduce maintenance, it's fine for me. > That leaves alpha as the sole user? Yes. And for alpha it isn't classic Linux a

Re: [PATCH 31/31] module: move the set_fs hack for flush_icache_range to m68k

2020-05-11 Thread Christoph Hellwig
On Mon, May 11, 2020 at 05:24:30PM +0200, Geert Uytterhoeven wrote: > > Btw, do you know what part of flush_icache_range relied on set_fs? > > Do any of the m68k maintainers have an idea how to handle that in > > a nicer way when we can split the implementations? > > arch/m68k/mm/cache.c:virt_to_p

Re: remove a few uses of ->queuedata

2020-05-12 Thread Christoph Hellwig
On Sat, May 09, 2020 at 08:07:14AM -0700, Dan Williams wrote: > > which are all used in the I/O submission path (generic_make_request / > > generic_make_request_checks). This is mostly a prep cleanup patch to > > also remove the pointless queue argument from ->make_request - then > > ->queue is an

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-06 Thread Christoph Hellwig
On Tue, Aug 07, 2018 at 08:13:56AM +1000, Benjamin Herrenschmidt wrote: > It would be indeed ideal if all we had to do was setup some kind of > bus_dma_mask on all PCI devices and have virtio automagically insert > swiotlb when necessary. For 4.20 I plan to remove the swiotlb ops and instead do th

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-06 Thread Christoph Hellwig
On Tue, Aug 07, 2018 at 02:45:25AM +0300, Michael S. Tsirkin wrote: > > > I think that's where Christoph might have specific ideas about it. > > > > OK well, assuming Christoph can solve the direct case in a way that > > also work for the virtio !iommu case, we still want some bit of logic > > som

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-06 Thread Christoph Hellwig
On Mon, Aug 06, 2018 at 11:35:39PM +0300, Michael S. Tsirkin wrote: > > As I said replying to Christoph, we are "leaking" into the interface > > something here that is really what's the VM is doing to itself, which > > is to stash its memory away in an inaccessible place. > > > > Cheers, > > Ben.

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-07 Thread Christoph Hellwig
On Tue, Aug 07, 2018 at 04:42:44PM +1000, Benjamin Herrenschmidt wrote: > Note that I can make it so that the same DMA ops (basically standard > swiotlb ops without arch hacks) work for both "direct virtio" and > "normal PCI" devices. > > The trick is simply in the arch to setup the iommu to map t

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-07 Thread Christoph Hellwig
On Wed, Aug 08, 2018 at 06:32:45AM +1000, Benjamin Herrenschmidt wrote: > As for the flag itself, while we could set it from qemu when we get > notified that the guest is going secure, both Michael and I think it's > rather gross, it requires qemu to go iterate all virtio devices and > "poke" somet

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-08 Thread Christoph Hellwig
On Wed, Aug 08, 2018 at 08:07:49PM +1000, Benjamin Herrenschmidt wrote: > Qemu virtio bypasses that iommu when the VIRTIO_F_IOMMU_PLATFORM flag > is not set (default) but there's nothing in the device-tree to tell the > guest about this since it's a violation of our pseries architecture, so > we ju

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-08-08 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 08:13:32AM +1000, Benjamin Herrenschmidt wrote: > > > - if (xen_domain()) > > > + if (xen_domain() || pseries_secure_vm()) > > > return true; > > > > I don't think it's pseries specific actually. E.g. I suspect AMD SEV > > might benefit from the same kind of hack.

Re: [PATCH v6 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"

2018-08-13 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 06:27:43AM -0700, Srikar Dronamraju wrote: > * Gautham R. Shenoy [2018-08-09 11:02:07]: > > > > > int threads_per_core, threads_per_subcore, threads_shift; > > +bool has_big_cores; > > cpumask_t threads_core_mask; > > EXPORT_SYMBOL_GPL(threads_per_core); > > EXPORT_SY

Re: [RFC 00/15] PCI: turn some __weak functions into callbacks

2018-08-20 Thread Christoph Hellwig
On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > Hi Bjorn and others, > > Triggered by Christoph's patches, I had another go at converting > all of the remaining pci host bridge implementations to be based > on pci_alloc_host_bridge and a separate registration function. I really l

Re: [RFC 00/15] PCI: turn some __weak functions into callbacks

2018-08-21 Thread Christoph Hellwig
On Tue, Aug 21, 2018 at 12:30:50PM +0100, David Woodhouse wrote: > On Mon, 2018-08-20 at 23:14 -0700, Christoph Hellwig wrote: > > On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > > > Hi Bjorn and others, > > >  > > > Triggered by Christoph'

Re: [PATCH 08/20] powerpc/dma: remove the unused dma_nommu_ops export

2018-08-21 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 10:01:16AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2018-07-31 at 14:16 +0200, Christoph Hellwig wrote: > > It turns out cxl actually uses it. So for now skip this patch, > > although random code in drivers messing with dma ops will need to > >

Re: [PATCH 01/20] kernel/dma/direct: take DMA offset into account in dma_direct_supported

2018-08-21 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 09:44:18AM +1000, Benjamin Herrenschmidt wrote: > We do have the occasional device with things like 31-bit DMA > limitation. We know they happens to work because those systems > can't have enough memory to be a problem. This is why our current > DMA direct ops in powerpc jus

Re: [PATCH 02/20] kernel/dma/direct: refine dma_direct_alloc zone selection

2018-08-21 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 09:54:33AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote: > > We need to take the DMA offset and encryption bit into account when > > selecting > > a zone. Add a helper that takes those into account

Re: [PATCH 10/20] powerpc/dma-noncoherent: don't disable irqs over kmap_atomic

2018-08-22 Thread Christoph Hellwig
On Thu, Aug 09, 2018 at 10:27:46AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2018-07-30 at 18:38 +0200, Christoph Hellwig wrote: > > The requirement to disable local irqs over kmap_atomic is long gone, > > so remove those calls. > > Really ? I'm trying to verify

<    1   2   3   4   5   6   7   8   9   10   >