Looks good,
Reviewed-by: 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
lls the arch specific kmap_atomic_high() when the page is high memory.
>
> Signed-off-by: Ira Weiny
Looks good:
Reviewed-by: 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
> --- 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
t; rather than a hard coded value which was equal.
Looks good,
Reviewed-by: 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.
Looks good,
Reviewed-by: 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
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
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
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
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
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
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|
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
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(+)
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
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
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.
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
Looks good,
Reviewed-by: 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
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
gt;
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: 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
ilable kmap_prot either as a
> define or exported symbol.
>
> Signed-off-by: Ira Weiny
Looks good,
Reviewed-by: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
__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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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(-)
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
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 +-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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'
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
> >
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
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
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
301 - 400 of 2738 matches
Mail list logo