* Re: [PATCH v2] kbuild: preprocess module linker script
From: Jessica Yu @ 2020-09-19 10:26 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-ia64, Paul Mackerras, linux-riscv, Will Deacon,
Anton Ivanov, linux-arch, Richard Weinberger, Russell King,
Geert Uytterhoeven, Catalin Marinas, Fenghua Yu, Albert Ou,
Arnd Bergmann, linux-kbuild, Jeff Dike, linux-um, linux-m68k,
Michal Marek, Paul Walmsley, linux-arm-kernel, Tony Luck,
linux-kernel, Palmer Dabbelt, linuxppc-dev
In-Reply-To: <20200908042708.2511528-1-masahiroy@kernel.org>
+++ Masahiro Yamada [08/09/20 13:27 +0900]:
>There was a request to preprocess the module linker script like we
>do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)
>
>The difference between vmlinux.lds and module.lds is that the latter
>is needed for external module builds, thus must be cleaned up by
>'make mrproper' instead of 'make clean'. Also, it must be created
>by 'make modules_prepare'.
>
>You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
>'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
>arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
>scripts/module.lds.S.
>
>scripts/module.lds is fine because 'make clean' keeps all the
>build artifacts under scripts/.
>
>You can add arch-specific sections in <asm/module.lds.h>.
>
>Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>Tested-by: Jessica Yu <jeyu@kernel.org>
>Acked-by: Will Deacon <will@kernel.org>
Acked-by: Jessica Yu <jeyu@kernel.org>
Thanks for working on this!
^ permalink raw reply
* Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
From: Daniel Vetter @ 2020-09-19 10:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Guo Ren, sparclinux, Vincent Chen, Will Deacon, Ard Biesheuvel,
open list:GENERIC INCLUDE/A..., Vincent Guittot, Herbert Xu,
X86 ML, Russell King, linux-csky, David Airlie, Mel Gorman, arcml,
linux-xtensa, Paul McKenney, intel-gfx, linuxppc-dev,
Steven Rostedt, Linus Torvalds, Jani Nikula, Rodrigo Vivi,
Dietmar Eggemann, Linux ARM, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Nick Hu, Linux-MM, Vineet Gupta, LKML,
Arnd Bergmann, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller, Greentime Hu
In-Reply-To: <20200919091751.011116649@linutronix.de>
On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> First of all, sorry for the horribly big Cc list!
>
> Following up to the discussion in:
>
> https://lore.kernel.org/r/20200914204209.256266093@linutronix.de
>
> this provides a preemptible variant of kmap_atomic & related
> interfaces. This is achieved by:
>
> - Consolidating all kmap atomic implementations in generic code
>
> - Switching from per CPU storage of the kmap index to a per task storage
>
> - Adding a pteval array to the per task storage which contains the ptevals
> of the currently active temporary kmaps
>
> - Adding context switch code which checks whether the outgoing or the
> incoming task has active temporary kmaps. If so, the outgoing task's
> kmaps are removed and the incoming task's kmaps are restored.
>
> - Adding new interfaces k[un]map_temporary*() which are not disabling
> preemption and can be called from any context (except NMI).
>
> Contrary to kmap() which provides preemptible and "persistant" mappings,
> these interfaces are meant to replace the temporary mappings provided by
> kmap_atomic*() today.
>
> This allows to get rid of conditional mapping choices and allows to have
> preemptible short term mappings on 64bit which are today enforced to be
> non-preemptible due to the highmem constraints. It clearly puts overhead on
> the highmem users, but highmem is slow anyway.
>
> This is not a wholesale conversion which makes kmap_atomic magically
> preemptible because there might be usage sites which rely on the implicit
> preempt disable. So this needs to be done on a case by case basis and the
> call sites converted to kmap_temporary.
>
> Note, that this is only lightly tested on X86 and completely untested on
> all other architectures.
>
> The lot is also available from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git highmem
I think it should be the case, but I want to double check: Will
copy_*_user be allowed within a kmap_temporary section? This would
allow us to ditch an absolute pile of slowpaths.
-Daniel
>
> Thanks,
>
> tglx
> ---
> a/arch/arm/mm/highmem.c | 121 ---------------------
> a/arch/microblaze/mm/highmem.c | 78 -------------
> a/arch/nds32/mm/highmem.c | 48 --------
> a/arch/powerpc/mm/highmem.c | 67 -----------
> a/arch/sparc/mm/highmem.c | 115 --------------------
> arch/arc/Kconfig | 1
> arch/arc/include/asm/highmem.h | 8 +
> arch/arc/mm/highmem.c | 44 -------
> arch/arm/Kconfig | 1
> arch/arm/include/asm/highmem.h | 30 +++--
> arch/arm/mm/Makefile | 1
> arch/csky/Kconfig | 1
> arch/csky/include/asm/highmem.h | 4
> arch/csky/mm/highmem.c | 75 -------------
> arch/microblaze/Kconfig | 1
> arch/microblaze/include/asm/highmem.h | 6 -
> arch/microblaze/mm/Makefile | 1
> arch/microblaze/mm/init.c | 6 -
> arch/mips/Kconfig | 1
> arch/mips/include/asm/highmem.h | 4
> arch/mips/mm/highmem.c | 77 -------------
> arch/mips/mm/init.c | 3
> arch/nds32/Kconfig.cpu | 1
> arch/nds32/include/asm/highmem.h | 21 ++-
> arch/nds32/mm/Makefile | 1
> arch/powerpc/Kconfig | 1
> arch/powerpc/include/asm/highmem.h | 6 -
> arch/powerpc/mm/Makefile | 1
> arch/powerpc/mm/mem.c | 7 -
> arch/sparc/Kconfig | 1
> arch/sparc/include/asm/highmem.h | 7 -
> arch/sparc/mm/Makefile | 3
> arch/sparc/mm/srmmu.c | 2
> arch/x86/include/asm/fixmap.h | 1
> arch/x86/include/asm/highmem.h | 12 +-
> arch/x86/include/asm/iomap.h | 29 +++--
> arch/x86/mm/highmem_32.c | 59 ----------
> arch/x86/mm/init_32.c | 15 --
> arch/x86/mm/iomap_32.c | 57 ----------
> arch/xtensa/Kconfig | 1
> arch/xtensa/include/asm/highmem.h | 9 +
> arch/xtensa/mm/highmem.c | 44 -------
> b/arch/x86/Kconfig | 3
> include/linux/highmem.h | 141 +++++++++++++++---------
> include/linux/io-mapping.h | 2
> include/linux/sched.h | 9 +
> kernel/sched/core.c | 10 +
> mm/Kconfig | 3
> mm/highmem.c | 192 ++++++++++++++++++++++++++++++++--
> 49 files changed, 422 insertions(+), 909 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
From: Daniel Vetter @ 2020-09-19 10:37 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Guo Ren, sparclinux, Vincent Chen, Will Deacon, Ard Biesheuvel,
open list:GENERIC INCLUDE/A..., Vincent Guittot, Herbert Xu,
X86 ML, Russell King, linux-csky, David Airlie, Mel Gorman, arcml,
linux-xtensa, Paul McKenney, intel-gfx, linuxppc-dev,
Steven Rostedt, Linus Torvalds, Jani Nikula, Rodrigo Vivi,
Dietmar Eggemann, Linux ARM, Chris Zankel, Michal Simek,
Thomas Bogendoerfer, Nick Hu, Linux-MM, Vineet Gupta, LKML,
Arnd Bergmann, Paul Mackerras, Andrew Morton,
Daniel Bristot de Oliveira, David S. Miller, Greentime Hu
In-Reply-To: <CAKMK7uHTVJL2jGtCg61zG=myiF1BSk+yDdRYikcm-Mq_1TQWMQ@mail.gmail.com>
On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Sat, Sep 19, 2020 at 11:50 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > First of all, sorry for the horribly big Cc list!
> >
> > Following up to the discussion in:
> >
> > https://lore.kernel.org/r/20200914204209.256266093@linutronix.de
> >
> > this provides a preemptible variant of kmap_atomic & related
> > interfaces. This is achieved by:
> >
> > - Consolidating all kmap atomic implementations in generic code
> >
> > - Switching from per CPU storage of the kmap index to a per task storage
> >
> > - Adding a pteval array to the per task storage which contains the ptevals
> > of the currently active temporary kmaps
> >
> > - Adding context switch code which checks whether the outgoing or the
> > incoming task has active temporary kmaps. If so, the outgoing task's
> > kmaps are removed and the incoming task's kmaps are restored.
> >
> > - Adding new interfaces k[un]map_temporary*() which are not disabling
> > preemption and can be called from any context (except NMI).
> >
> > Contrary to kmap() which provides preemptible and "persistant" mappings,
> > these interfaces are meant to replace the temporary mappings provided by
> > kmap_atomic*() today.
> >
> > This allows to get rid of conditional mapping choices and allows to have
> > preemptible short term mappings on 64bit which are today enforced to be
> > non-preemptible due to the highmem constraints. It clearly puts overhead on
> > the highmem users, but highmem is slow anyway.
> >
> > This is not a wholesale conversion which makes kmap_atomic magically
> > preemptible because there might be usage sites which rely on the implicit
> > preempt disable. So this needs to be done on a case by case basis and the
> > call sites converted to kmap_temporary.
> >
> > Note, that this is only lightly tested on X86 and completely untested on
> > all other architectures.
> >
> > The lot is also available from
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git highmem
>
> I think it should be the case, but I want to double check: Will
> copy_*_user be allowed within a kmap_temporary section? This would
> allow us to ditch an absolute pile of slowpaths.
(coffee just kicked in) copy_*_user is ofc allowed, but if you hit a
page fault you get a short read/write. This looks like it would remove
the need to handle these in a slowpath, since page faults can now be
served in this new kmap_temporary sections. But this sounds too good
to be true, so I'm wondering what I'm missing.
-Daniel
>
> >
> > Thanks,
> >
> > tglx
> > ---
> > a/arch/arm/mm/highmem.c | 121 ---------------------
> > a/arch/microblaze/mm/highmem.c | 78 -------------
> > a/arch/nds32/mm/highmem.c | 48 --------
> > a/arch/powerpc/mm/highmem.c | 67 -----------
> > a/arch/sparc/mm/highmem.c | 115 --------------------
> > arch/arc/Kconfig | 1
> > arch/arc/include/asm/highmem.h | 8 +
> > arch/arc/mm/highmem.c | 44 -------
> > arch/arm/Kconfig | 1
> > arch/arm/include/asm/highmem.h | 30 +++--
> > arch/arm/mm/Makefile | 1
> > arch/csky/Kconfig | 1
> > arch/csky/include/asm/highmem.h | 4
> > arch/csky/mm/highmem.c | 75 -------------
> > arch/microblaze/Kconfig | 1
> > arch/microblaze/include/asm/highmem.h | 6 -
> > arch/microblaze/mm/Makefile | 1
> > arch/microblaze/mm/init.c | 6 -
> > arch/mips/Kconfig | 1
> > arch/mips/include/asm/highmem.h | 4
> > arch/mips/mm/highmem.c | 77 -------------
> > arch/mips/mm/init.c | 3
> > arch/nds32/Kconfig.cpu | 1
> > arch/nds32/include/asm/highmem.h | 21 ++-
> > arch/nds32/mm/Makefile | 1
> > arch/powerpc/Kconfig | 1
> > arch/powerpc/include/asm/highmem.h | 6 -
> > arch/powerpc/mm/Makefile | 1
> > arch/powerpc/mm/mem.c | 7 -
> > arch/sparc/Kconfig | 1
> > arch/sparc/include/asm/highmem.h | 7 -
> > arch/sparc/mm/Makefile | 3
> > arch/sparc/mm/srmmu.c | 2
> > arch/x86/include/asm/fixmap.h | 1
> > arch/x86/include/asm/highmem.h | 12 +-
> > arch/x86/include/asm/iomap.h | 29 +++--
> > arch/x86/mm/highmem_32.c | 59 ----------
> > arch/x86/mm/init_32.c | 15 --
> > arch/x86/mm/iomap_32.c | 57 ----------
> > arch/xtensa/Kconfig | 1
> > arch/xtensa/include/asm/highmem.h | 9 +
> > arch/xtensa/mm/highmem.c | 44 -------
> > b/arch/x86/Kconfig | 3
> > include/linux/highmem.h | 141 +++++++++++++++---------
> > include/linux/io-mapping.h | 2
> > include/linux/sched.h | 9 +
> > kernel/sched/core.c | 10 +
> > mm/Kconfig | 3
> > mm/highmem.c | 192 ++++++++++++++++++++++++++++++++--
> > 49 files changed, 422 insertions(+), 909 deletions(-)
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* RE: [PATCH] powerpc: Select HAVE_FUTEX_CMPXCHG
From: David Laight @ 2020-09-19 13:50 UTC (permalink / raw)
To: 'Samuel Holland', Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20200919032009.8346-1-samuel@sholland.org>
From: Samuel Holland
> Sent: 19 September 2020 04:20
>
> On powerpc, access_ok() succeeds for the NULL pointer. This breaks the
> dynamic check in futex_detect_cmpxchg(), which expects -EFAULT. As a
> result, robust futex operations are not functional on powerpc.
access_ok(NULL, sane_count) will succeed on all (maybe most) architectures.
All access_ok() does is check that kernel addresses aren't referenced.
(access_ok(kernel_adress, 0) is also likely to succeed.)
It is the access to user-address 0 that is expected to fault.
If this isn't faulting something else is wrong.
Historically (at least pre-elf, if not before) user programs
were linked to address zero - so the page was mapped.
(Linux may be too new to actually require it.)
Not sure what 'wine' requires for win-32 execuatbles.
ISTR there are also some 'crazy' ARM? cpu that read the interrupt
vectors from address 0 in user-space.
So assuming:
static void __init futex_detect_cmpxchg(void)
{
#ifndef CONFIG_HAVE_FUTEX_CMPXCHG
u32 curval;
/*
* This will fail and we want it. Some arch implementations do
* runtime detection of the futex_atomic_cmpxchg_inatomic()
* functionality. We want to know that before we call in any
* of the complex code paths. Also we want to prevent
* registration of robust lists in that case. NULL is
* guaranteed to fault and we get -EFAULT on functional
* implementation, the non-functional ones will return
* -ENOSYS.
*/
if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT)
futex_cmpxchg_enabled = 1;
#endif
}
will fail -EFAULT because user address 0 is invalid seems hopeful.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* RE: let import_iovec deal with compat_iovecs as well
From: David Laight @ 2020-09-19 14:24 UTC (permalink / raw)
To: 'Christoph Hellwig', Alexander Viro
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, linux-arch@vger.kernel.org,
linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org,
x86@kernel.org, Arnd Bergmann, linux-block@vger.kernel.org,
io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Jens Axboe, linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200918124533.3487701-1-hch@lst.de>
From: Christoph Hellwig
> Sent: 18 September 2020 13:45
>
> this series changes import_iovec to transparently deal with comat iovec
> structures, and then cleanups up a lot of code dupliation. But to get
> there it first has to fix the pre-existing bug that io_uring compat
> contexts don't trigger the in_compat_syscall() check. This has so far
> been relatively harmless as very little code callable from io_uring used
> the check, and even that code that could be called usually wasn't.
I thought about that change while writing my import_iovec() => iovec_import()
patch - and thought that the io_uring code would (as usual) cause grief.
Christoph - did you see those patches?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* RE: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: David Laight @ 2020-09-19 14:53 UTC (permalink / raw)
To: 'Al Viro', Christoph Hellwig
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, linux-arch@vger.kernel.org,
linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org,
x86@kernel.org, Arnd Bergmann, linux-block@vger.kernel.org,
io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Jens Axboe, linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200918135822.GZ3421308@ZenIV.linux.org.uk>
From: Al Viro
> Sent: 18 September 2020 14:58
>
> On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote:
> > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
> > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
> > > > - return pt_regs_trap_type(current_pt_regs()) == 0x110;
> > > > + return pt_regs_trap_type(current_pt_regs()) == 0x110 ||
> > > > + (current->flags & PF_FORCE_COMPAT);
> > >
> > > Can't say I like that approach ;-/ Reasoning about the behaviour is much
> > > harder when it's controlled like that - witness set_fs() shite...
> >
> > I don't particularly like it either. But do you have a better idea
> > how to deal with io_uring vs compat tasks?
>
> <wry> git rm fs/io_uring.c would make a good starting point </wry>
> Yes, I know it's not going to happen, but one can dream...
Maybe the io_uring code needs some changes to make it vaguely safe.
- No support for 32-bit compat mixed working (or at all?).
Plausibly a special worker could do 32bit work.
- ring structure (I'm assuming mapped by mmap()) never mapped
in more than one process (not cloned by fork()).
- No implicit handover of files to another process.
Would need an munmap, handover, mmap sequence.
In any case the io_ring rather abuses the import_iovec() interface.
The canonical sequence is (types from memory):
struct iovec cache[8], *iov = cache;
struct iter iter;
...
rval = import_iovec(..., &iov, 8, &iter);
// Do read/write user using 'iter'
free(iov);
I don't think there is any strict requirement that iter.iov
is set to either 'cache' or 'iov' (it probably must point
into one of them.)
But the io_uring code will make that assumption because the
actual copies can be done much later and it doesn't save 'iter'.
It gets itself in a right mess because it doesn't separate
the 'address I need to free' from 'the iov[] for any transfers'.
io_uring is also the only code that relies on import_iovec()
returning the iter.count on success.
It would be much better to have:
iov = import_iovec(..., &cache, ...);
free(iov);
and use ERR_PTR() et al for error detectoion.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* [PATCH v2] powerpc/tm: Save and restore AMR on treclaim and trechkpt
From: Gustavo Romero @ 2020-09-19 15:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: aneesh.kumar, mikey, gromero
Althought AMR is stashed in the checkpoint area, currently we don't save
it to the per thread checkpoint struct after a treclaim and so we don't
restore it either from that struct when we trechkpt. As a consequence when
the transaction is later rolled back the kernel space AMR value when the
trechkpt was done appears in userspace.
That commit saves and restores AMR accordingly on treclaim and trechkpt.
Since AMR value is also used in kernel space in other functions, it also
takes care of stashing kernel live AMR into the stack before treclaim and
before trechkpt, restoring it later, just before returning from tm_reclaim
and __tm_recheckpoint.
Is also fixes two nonrelated comments about CR and MSR.
Signed-off-by: Gustavo Romero <gromero@linux.ibm.com>
---
arch/powerpc/include/asm/processor.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/tm.S | 35 ++++++++++++++++++++++++----
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..9f4f6cc033ac 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -220,6 +220,7 @@ struct thread_struct {
unsigned long tm_tar;
unsigned long tm_ppr;
unsigned long tm_dscr;
+ unsigned long tm_amr;
/*
* Checkpointed FP and VSX 0-31 register set.
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 8711c2164b45..c2722ff36e98 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -176,6 +176,7 @@ int main(void)
OFFSET(THREAD_TM_TAR, thread_struct, tm_tar);
OFFSET(THREAD_TM_PPR, thread_struct, tm_ppr);
OFFSET(THREAD_TM_DSCR, thread_struct, tm_dscr);
+ OFFSET(THREAD_TM_AMR, thread_struct, tm_amr);
OFFSET(PT_CKPT_REGS, thread_struct, ckpt_regs);
OFFSET(THREAD_CKVRSTATE, thread_struct, ckvr_state.vr);
OFFSET(THREAD_CKVRSAVE, thread_struct, ckvrsave);
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index 6ba0fdd1e7f8..2b91f233b05d 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -122,6 +122,13 @@ _GLOBAL(tm_reclaim)
std r3, STK_PARAM(R3)(r1)
SAVE_NVGPRS(r1)
+ /*
+ * Save kernel live AMR since it will be clobbered by treclaim
+ * but can be used elsewhere later in kernel space.
+ */
+ mfspr r3, SPRN_AMR
+ std r3, TM_FRAME_L1(r1)
+
/* We need to setup MSR for VSX register save instructions. */
mfmsr r14
mr r15, r14
@@ -245,7 +252,7 @@ _GLOBAL(tm_reclaim)
* but is used in signal return to 'wind back' to the abort handler.
*/
- /* ******************** CR,LR,CCR,MSR ********** */
+ /* ***************** CTR, LR, CR, XER ********** */
mfctr r3
mflr r4
mfcr r5
@@ -256,7 +263,6 @@ _GLOBAL(tm_reclaim)
std r5, _CCR(r7)
std r6, _XER(r7)
-
/* ******************** TAR, DSCR ********** */
mfspr r3, SPRN_TAR
mfspr r4, SPRN_DSCR
@@ -264,6 +270,10 @@ _GLOBAL(tm_reclaim)
std r3, THREAD_TM_TAR(r12)
std r4, THREAD_TM_DSCR(r12)
+ /* ******************** AMR **************** */
+ mfspr r3, SPRN_AMR
+ std r3, THREAD_TM_AMR(r12)
+
/*
* MSR and flags: We don't change CRs, and we don't need to alter MSR.
*/
@@ -308,7 +318,9 @@ _GLOBAL(tm_reclaim)
std r3, THREAD_TM_TFHAR(r12)
std r4, THREAD_TM_TFIAR(r12)
- /* AMR is checkpointed too, but is unsupported by Linux. */
+ /* Restore kernel live AMR */
+ ld r8, TM_FRAME_L1(r1)
+ mtspr SPRN_AMR, r8
/* Restore original MSR/IRQ state & clear TM mode */
ld r14, TM_FRAME_L0(r1) /* Orig MSR */
@@ -355,6 +367,13 @@ _GLOBAL(__tm_recheckpoint)
*/
SAVE_NVGPRS(r1)
+ /*
+ * Save kernel live AMR since it will be clobbered for trechkpt
+ * but can be used elsewhere later in kernel space.
+ */
+ mfspr r8, SPRN_AMR
+ std r8, TM_FRAME_L0(r1)
+
/* Load complete register state from ts_ckpt* registers */
addi r7, r3, PT_CKPT_REGS /* Thread's ckpt_regs */
@@ -404,7 +423,7 @@ _GLOBAL(__tm_recheckpoint)
restore_gprs:
- /* ******************** CR,LR,CCR,MSR ********** */
+ /* ****************** CTR, LR, XER ************* */
ld r4, _CTR(r7)
ld r5, _LINK(r7)
ld r8, _XER(r7)
@@ -417,6 +436,10 @@ restore_gprs:
ld r4, THREAD_TM_TAR(r3)
mtspr SPRN_TAR, r4
+ /* ******************** AMR ******************** */
+ ld r4, THREAD_TM_AMR(r3)
+ mtspr SPRN_AMR, r4
+
/* Load up the PPR and DSCR in GPRs only at this stage */
ld r5, THREAD_TM_DSCR(r3)
ld r6, THREAD_TM_PPR(r3)
@@ -509,6 +532,10 @@ restore_gprs:
li r4, MSR_RI
mtmsrd r4, 1
+ /* Restore kernel live AMR */
+ ld r8, TM_FRAME_L0(r1)
+ mtspr SPRN_AMR, r8
+
REST_NVGPRS(r1)
addi r1, r1, TM_FRAME_SIZE
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Andy Lutomirski @ 2020-09-19 16:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, linux-arch, linux-s390, Linux SCSI List, X86 ML,
Arnd Bergmann, linux-block, Al Viro, io-uring, linux-arm-kernel,
Jens Axboe, Parisc List, Network Development, LKML, LSM List,
Linux FS Devel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918151615.GA23432@lst.de>
On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there? And have the normal
> > one pass in_compat_syscall() to that...
>
> That would help to not introduce a regression with this series yes.
> But it wouldn't fix existing bugs when io_uring is used to access
> read or write methods that use in_compat_syscall(). One example that
> I recently ran into is drivers/scsi/sg.c.
Aside from the potentially nasty use of per-task variables, one thing
I don't like about PF_FORCE_COMPAT is that it's one-way. If we're
going to have a generic mechanism for this, shouldn't we allow a full
override of the syscall arch instead of just allowing forcing compat
so that a compat syscall can do a non-compat operation?
^ permalink raw reply
* Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
From: Linus Torvalds @ 2020-09-19 17:18 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Guo Ren, linux-sparc, Vincent Chen, Will Deacon, Ard Biesheuvel,
linux-arch, Vincent Guittot, Herbert Xu, the arch/x86 maintainers,
Russell King, linux-csky, David Airlie, Mel Gorman,
open list:SYNOPSYS ARC ARCHITECTURE, linux-xtensa, Paul McKenney,
intel-gfx, linuxppc-dev, Steven Rostedt, Jani Nikula,
Rodrigo Vivi, Dietmar Eggemann, Linux ARM, Chris Zankel,
Michal Simek, Thomas Bogendoerfer, Nick Hu, Linux-MM,
Vineet Gupta, LKML, Arnd Bergmann, Daniel Vetter, Paul Mackerras,
Andrew Morton, Daniel Bristot de Oliveira, David S. Miller,
Greentime Hu
In-Reply-To: <20200919091751.011116649@linutronix.de>
On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> this provides a preemptible variant of kmap_atomic & related
> interfaces. This is achieved by:
Ack. This looks really nice, even apart from the new capability.
The only thing I really reacted to is that the name doesn't make sense
to me: "kmap_temporary()" seems a bit odd.
Particularly for an interface that really is basically meant as a
better replacement of "kmap_atomic()" (but is perhaps also a better
replacement for "kmap()").
I think I understand how the name came about: I think the "temporary"
is there as a distinction from the "longterm" regular kmap(). So I
think it makes some sense from an internal implementation angle, but I
don't think it makes a lot of sense from an interface name.
I don't know what might be a better name, but if we want to emphasize
that it's thread-private and a one-off, maybe "local" would be a
better naming, and make it distinct from the "global" nature of the
old kmap() interface?
However, another solution might be to just use this new preemptible
"local" kmap(), and remove the old global one entirely. Yes, the old
global one caches the page table mapping and that sounds really
efficient and nice. But it's actually horribly horribly bad, because
it means that we need to use locking for them. Your new "temporary"
implementation seems to be fundamentally better locking-wise, and only
need preemption disabling as locking (and is equally fast for the
non-highmem case).
So I wonder if the single-page TLB flush isn't a better model, and
whether it wouldn't be a lot simpler to just get rid of the old
complex kmap() entirely, and replace it with this?
I agree we can't replace the kmap_atomic() version, because maybe
people depend on the preemption disabling it also implied. But what
about replacing the non-atomic kmap()?
Maybe I've missed something. Is it because the new interface still
does "pagefault_disable()" perhaps?
But does it even need the pagefault_disable() at all? Yes, the
*atomic* one obviously needed it. But why does this new one need to
disable page faults?
[ I'm just reading the patches, I didn't try to apply them and look at
the end result, so I might have missed something ]
The only other worry I would have is just test coverage of this
change. I suspect very few developers use HIGHMEM. And I know the
various test robots don't tend to test 32-bit either.
But apart from that question about naming (and perhaps replacing
kmap() entirely), I very much like it.
Linus
^ permalink raw reply
* [PATCH] PCI: Convert enum pci_bus_flags to bit fields in struct pci_bus
From: Krzysztof Wilczyński @ 2020-09-19 17:28 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linuxppc-dev, linux-pci, x86, linux-kernel, Kai-Heng Feng,
Borislav Petkov, Colin Ian King, Thomas Gleixner, Myron Stowe,
Ingo Molnar
All the flags defined in the enum pci_bus_flags are used to determine
whether a particular feature of a PCI bus is available or not - features
are also often disabled via architecture or device-specific quirk.
These flags are tightly coupled with a PCI buses and PCI bridges and
primarily used in simple binary on/off manner to check whether something
is enabled or disabled, and have almost no other users (with an
exception of the x86 architecture-specific quirk) outside of the PCI
device drivers space.
Therefore, convert enum pci_bus_flags into a set of bit fields in the
struct pci_bus, and then drop said enum and the typedef pci_bus_flags_t.
This will keep PCI device-specific features as part of the struct
pci_dev and make the code that used to use flags simpler.
Related:
https://patchwork.kernel.org/patch/11772809
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Krzysztof Wilczyński <kw@linux.com>
---
arch/x86/pci/fixup.c | 6 +++---
drivers/pci/msi.c | 8 ++++----
drivers/pci/pci-sysfs.c | 14 ++++++--------
drivers/pci/pci.c | 2 +-
drivers/pci/pcie/aer.c | 5 ++---
drivers/pci/probe.c | 13 +++++++++----
drivers/pci/quirks.c | 16 ++++++++--------
include/linux/pci.h | 20 ++++++++++----------
8 files changed, 43 insertions(+), 41 deletions(-)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index b8c9a5b87f37..50ff8aa542b8 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -641,14 +641,14 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_apple_mbp_poweroff);
* ID, the AER driver should traverse the child device tree, reading
* AER registers to find the faulting device.
*/
-static void quirk_no_aersid(struct pci_dev *pdev)
+static void quirk_no_aer_sid(struct pci_dev *pdev)
{
/* VMD Domain */
if (is_vmd(pdev->bus) && pci_is_root_bus(pdev->bus))
- pdev->bus->bus_flags |= PCI_BUS_FLAGS_NO_AERSID;
+ pdev->bus->no_aer_sid = 1;
}
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
- PCI_CLASS_BRIDGE_PCI, 8, quirk_no_aersid);
+ PCI_CLASS_BRIDGE_PCI, 8, quirk_no_aer_sid);
static void quirk_intel_th_dnv(struct pci_dev *dev)
{
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 30ae4ffda5c1..01e4bdbc830e 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -875,13 +875,13 @@ static int pci_msi_supported(struct pci_dev *dev, int nvec)
/*
* Any bridge which does NOT route MSI transactions from its
- * secondary bus to its primary bus must set NO_MSI flag on
- * the secondary pci_bus.
+ * secondary bus to its primary bus must enable "no_msi" on
+ * the secondary bus (pci_bus).
* We expect only arch-specific PCI host bus controller driver
- * or quirks for specific PCI bridges to be setting NO_MSI.
+ * or quirks for specific PCI bridges to enable "no_msi".
*/
for (bus = dev->bus; bus; bus = bus->parent)
- if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
+ if (bus->no_msi)
return 0;
return 1;
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 6d78df981d41..eca214e45418 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -357,9 +357,7 @@ static ssize_t msi_bus_show(struct device *dev, struct device_attribute *attr,
struct pci_dev *pdev = to_pci_dev(dev);
struct pci_bus *subordinate = pdev->subordinate;
- return sprintf(buf, "%u\n", subordinate ?
- !(subordinate->bus_flags & PCI_BUS_FLAGS_NO_MSI)
- : !pdev->no_msi);
+ return sprintf(buf, "%u\n", subordinate ? !subordinate->no_msi : !pdev->no_msi);
}
static ssize_t msi_bus_store(struct device *dev, struct device_attribute *attr,
@@ -376,9 +374,9 @@ static ssize_t msi_bus_store(struct device *dev, struct device_attribute *attr,
return -EPERM;
/*
- * "no_msi" and "bus_flags" only affect what happens when a driver
- * requests MSI or MSI-X. They don't affect any drivers that have
- * already requested MSI or MSI-X.
+ * "no_msi" enabled for device and bus only affect what happens
+ * when a driver requests MSI or MSI-X. They don't affect any
+ * drivers that have already requested MSI or MSI-X.
*/
if (!subordinate) {
pdev->no_msi = !val;
@@ -388,9 +386,9 @@ static ssize_t msi_bus_store(struct device *dev, struct device_attribute *attr,
}
if (val)
- subordinate->bus_flags &= ~PCI_BUS_FLAGS_NO_MSI;
+ subordinate->no_msi = 0;
else
- subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
+ subordinate->no_msi = 1;
dev_info(&subordinate->dev, "MSI/MSI-X %s for future drivers of devices on this bus\n",
val ? "allowed" : "disallowed");
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e39c5499770f..12d434eb1b97 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5657,7 +5657,7 @@ int pcix_set_mmrbc(struct pci_dev *dev, int mmrbc)
o = (cmd & PCI_X_CMD_MAX_READ) >> 2;
if (o != v) {
- if (v > o && (dev->bus->bus_flags & PCI_BUS_FLAGS_NO_MMRBC))
+ if (v > o && dev->bus->no_mmrbc)
return -EIO;
cmd &= ~PCI_X_CMD_MAX_READ;
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 65dff5f3457a..4272abab9695 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -827,8 +827,7 @@ static bool is_error_source(struct pci_dev *dev, struct aer_err_info *e_info)
* When bus id is equal to 0, it might be a bad id
* reported by root port.
*/
- if ((PCI_BUS_NUM(e_info->id) != 0) &&
- !(dev->bus->bus_flags & PCI_BUS_FLAGS_NO_AERSID)) {
+ if (PCI_BUS_NUM(e_info->id) != 0 && !dev->bus->no_aer_sid) {
/* Device ID match? */
if (e_info->id == ((dev->bus->number << 8) | dev->devfn))
return true;
@@ -842,7 +841,7 @@ static bool is_error_source(struct pci_dev *dev, struct aer_err_info *e_info)
* When either
* 1) bus id is equal to 0. Some ports might lose the bus
* id of error source id;
- * 2) bus flag PCI_BUS_FLAGS_NO_AERSID is set
+ * 2) bus has "no_aer_sid" enabled
* 3) There are multiple errors and prior ID comparing fails;
* We check AER status registers to find possible reporter.
*/
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 03d37128a24f..d3a92d60ae8f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1002,7 +1002,7 @@ static bool pci_bridge_child_ext_cfg_accessible(struct pci_dev *bridge)
* If extended config space isn't accessible on a bridge's primary
* bus, we certainly can't access it on the secondary bus.
*/
- if (bridge->bus->bus_flags & PCI_BUS_FLAGS_NO_EXTCFG)
+ if (bridge->bus->no_ext_cfg)
return false;
/*
@@ -1048,7 +1048,12 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
child->ops = parent->ops;
child->msi = parent->msi;
child->sysdata = parent->sysdata;
- child->bus_flags = parent->bus_flags;
+
+ /* PCI bus flags */
+ child->no_msi = parent->no_msi;
+ child->no_mmrbc = parent->no_mmrbc;
+ child->no_aer_sid = parent->no_aer_sid;
+ child->no_ext_cfg = parent->no_ext_cfg;
/*
* Initialize some portions of the bus device, but don't register
@@ -1079,7 +1084,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
* the root bus.
*/
if (!pci_bridge_child_ext_cfg_accessible(bridge)) {
- child->bus_flags |= PCI_BUS_FLAGS_NO_EXTCFG;
+ child->no_ext_cfg = 1;
pci_info(child, "extended config space not accessible\n");
}
@@ -1644,7 +1649,7 @@ int pci_cfg_space_size(struct pci_dev *dev)
return PCI_CFG_SPACE_EXP_SIZE;
#endif
- if (dev->bus->bus_flags & PCI_BUS_FLAGS_NO_EXTCFG)
+ if (dev->bus->no_ext_cfg)
return PCI_CFG_SPACE_SIZE;
class = dev->class >> 8;
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 2a589b6d6ed8..5fae54201b08 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1052,7 +1052,7 @@ static void quirk_amd_8131_mmrbc(struct pci_dev *dev)
if (dev->subordinate && dev->revision <= 0x12) {
pci_info(dev, "AMD8131 rev %x detected; disabling PCI-X MMRBC\n",
dev->revision);
- dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MMRBC;
+ dev->subordinate->no_mmrbc = 1;
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_amd_8131_mmrbc);
@@ -2503,10 +2503,10 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82875_HB,
#ifdef CONFIG_PCI_MSI
/*
- * Some chipsets do not support MSI. We cannot easily rely on setting
- * PCI_BUS_FLAGS_NO_MSI in its bus flags because there are actually some
- * other buses controlled by the chipset even if Linux is not aware of it.
- * Instead of setting the flag on all buses in the machine, simply disable
+ * Some chipsets do not support MSI. We cannot easily rely on enabling
+ * "no_msi" for its bus because there are actually some other buses
+ * controlled by the chipset even if Linux is not aware of it. Instead
+ * of enabling "no_msi" on all buses in the machine, simply disable
* MSI globally.
*/
static void quirk_disable_all_msi(struct pci_dev *dev)
@@ -2528,7 +2528,7 @@ static void quirk_disable_msi(struct pci_dev *dev)
{
if (dev->subordinate) {
pci_warn(dev, "MSI quirk detected; subordinate MSI disabled\n");
- dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
+ dev->subordinate->no_msi = 1;
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8131_BRIDGE, quirk_disable_msi);
@@ -2586,7 +2586,7 @@ static void quirk_msi_ht_cap(struct pci_dev *dev)
{
if (dev->subordinate && !msi_ht_cap_enabled(dev)) {
pci_warn(dev, "MSI quirk detected; subordinate MSI disabled\n");
- dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
+ dev->subordinate->no_msi = 1;
}
}
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_HT2000_PCIE,
@@ -2612,7 +2612,7 @@ static void quirk_nvidia_ck804_msi_ht_cap(struct pci_dev *dev)
return;
if (!msi_ht_cap_enabled(dev) && !msi_ht_cap_enabled(pdev)) {
pci_warn(dev, "MSI quirk detected; subordinate MSI disabled\n");
- dev->subordinate->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
+ dev->subordinate->no_msi = 1;
}
pci_dev_put(pdev);
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 835530605c0d..85204825d0a5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -234,14 +234,6 @@ enum pci_irq_reroute_variant {
MAX_IRQ_REROUTE_VARIANTS = 3
};
-typedef unsigned short __bitwise pci_bus_flags_t;
-enum pci_bus_flags {
- PCI_BUS_FLAGS_NO_MSI = (__force pci_bus_flags_t) 1,
- PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
- PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4,
- PCI_BUS_FLAGS_NO_EXTCFG = (__force pci_bus_flags_t) 8,
-};
-
/* Values from Link Status register, PCIe r3.1, sec 7.8.8 */
enum pcie_link_width {
PCIE_LNK_WIDTH_RESRV = 0x00,
@@ -627,12 +619,20 @@ struct pci_bus {
char name[48];
unsigned short bridge_ctl; /* Manage NO_ISA/FBB/et al behaviors */
- pci_bus_flags_t bus_flags; /* Inherited by child buses */
struct device *bridge;
struct device dev;
struct bin_attribute *legacy_io; /* Legacy I/O for this bus */
struct bin_attribute *legacy_mem; /* Legacy mem */
- unsigned int is_added:1;
+ unsigned int is_added:1; /* This bus has already been registered */
+
+ /* PCI bus flags are inherited by child buses */
+ unsigned int no_msi:1; /* Don't use MSI/MSI-X for devices behind a bridge that does not route
+ MSI transactions from its secondary bus to its primary bus */
+ unsigned int no_mmrbc:1; /* Disallow setting PCI-X Maximum Memory Read Byte Count on this bus */
+ unsigned int no_aer_sid:1; /* Allow Root Port buses to skip the AER source ID matching when finding
+ the faulting device */
+ unsigned int no_ext_cfg:1; /* Don't use PCIe/PCI-X Mode 2 Extended Configuration Space
+ when it isn't available on bridge's primary bus */
};
#define to_pci_bus(n) container_of(n, struct pci_bus, dev)
--
2.28.0
^ permalink raw reply related
* Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
From: Matthew Wilcox @ 2020-09-19 17:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Guo Ren, linux-sparc, Vincent Chen, Will Deacon, Ard Biesheuvel,
linux-arch, Vincent Guittot, Herbert Xu, the arch/x86 maintainers,
Russell King, linux-csky, David Airlie, Mel Gorman,
open list:SYNOPSYS ARC ARCHITECTURE, linux-xtensa, Paul McKenney,
intel-gfx, linuxppc-dev, Steven Rostedt, Jani Nikula,
Rodrigo Vivi, Thomas Gleixner, Dietmar Eggemann, Linux ARM,
Chris Zankel, Michal Simek, Thomas Bogendoerfer, Nick Hu,
Linux-MM, Vineet Gupta, LKML, Arnd Bergmann, Daniel Vetter,
Paul Mackerras, Andrew Morton, Daniel Bristot de Oliveira,
David S. Miller, Greentime Hu
In-Reply-To: <CAHk-=wiYGyrFRbA1cc71D2-nc5U9LM9jUJesXGqpPnB7E4X1YQ@mail.gmail.com>
On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > this provides a preemptible variant of kmap_atomic & related
> > interfaces. This is achieved by:
>
> Ack. This looks really nice, even apart from the new capability.
>
> The only thing I really reacted to is that the name doesn't make sense
> to me: "kmap_temporary()" seems a bit odd.
>
> Particularly for an interface that really is basically meant as a
> better replacement of "kmap_atomic()" (but is perhaps also a better
> replacement for "kmap()").
>
> I think I understand how the name came about: I think the "temporary"
> is there as a distinction from the "longterm" regular kmap(). So I
> think it makes some sense from an internal implementation angle, but I
> don't think it makes a lot of sense from an interface name.
>
> I don't know what might be a better name, but if we want to emphasize
> that it's thread-private and a one-off, maybe "local" would be a
> better naming, and make it distinct from the "global" nature of the
> old kmap() interface?
>
> However, another solution might be to just use this new preemptible
> "local" kmap(), and remove the old global one entirely. Yes, the old
> global one caches the page table mapping and that sounds really
> efficient and nice. But it's actually horribly horribly bad, because
> it means that we need to use locking for them. Your new "temporary"
> implementation seems to be fundamentally better locking-wise, and only
> need preemption disabling as locking (and is equally fast for the
> non-highmem case).
>
> So I wonder if the single-page TLB flush isn't a better model, and
> whether it wouldn't be a lot simpler to just get rid of the old
> complex kmap() entirely, and replace it with this?
>
> I agree we can't replace the kmap_atomic() version, because maybe
> people depend on the preemption disabling it also implied. But what
> about replacing the non-atomic kmap()?
My concern with that is people might use kmap() and then pass the address
to a different task. So we need to audit the current users of kmap()
and convert any that do that into using vmap() instead.
I like kmap_local(). Or kmap_thread().
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.4 101/330] powerpc/powernv/ioda: Fix ref count for devices with their own PE
From: Sasha Levin @ 2020-09-19 18:10 UTC (permalink / raw)
To: Frederic Barrat; +Cc: linuxppc-dev, linux-kernel, stable, Andrew Donnellan
In-Reply-To: <52532d8a-8e90-8a68-07bd-5a3e08c58475@linux.ibm.com>
On Fri, Sep 18, 2020 at 08:35:06AM +0200, Frederic Barrat wrote:
>
>
>Le 18/09/2020 à 03:57, Sasha Levin a écrit :
>>From: Frederic Barrat <fbarrat@linux.ibm.com>
>>
>>[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]
>>
>
>This patch is not desirable for stable, for 5.4 and 4.19 (it was
>already flagged by autosel back in April. Not sure why it's showing
>again now)
Hey Fred,
This was a bit of a "lie", it wasn't a run of AUTOSEL, but rather an
audit of patches that went into distro/vendor trees but not into the
upstream stable trees.
I can see that this patch was pulled into Ubuntu's 5.4 tree, is it not
needed in the upstream stable tree?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
From: Linus Torvalds @ 2020-09-19 19:13 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Guo Ren, linux-sparc, Vincent Chen, Will Deacon, Ard Biesheuvel,
linux-arch, Vincent Guittot, Herbert Xu, the arch/x86 maintainers,
Russell King, linux-csky, David Airlie, Mel Gorman,
open list:SYNOPSYS ARC ARCHITECTURE, linux-xtensa, Paul McKenney,
intel-gfx, linuxppc-dev, Steven Rostedt, Jani Nikula,
Rodrigo Vivi, Thomas Gleixner, Dietmar Eggemann, Linux ARM,
Chris Zankel, Michal Simek, Thomas Bogendoerfer, Nick Hu,
Linux-MM, Vineet Gupta, LKML, Arnd Bergmann, Daniel Vetter,
Paul Mackerras, Andrew Morton, Daniel Bristot de Oliveira,
David S. Miller, Greentime Hu
In-Reply-To: <20200919173906.GQ32101@casper.infradead.org>
On Sat, Sep 19, 2020 at 10:39 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> My concern with that is people might use kmap() and then pass the address
> to a different task. So we need to audit the current users of kmap()
> and convert any that do that into using vmap() instead.
Ahh. Yes, I guess they might do that. It sounds strange, but not
entirely crazy - I could imagine some "PIO thread" that does IO to a
page that has been set up by somebody else using kmap(). Or similar.
Linus
^ permalink raw reply
* Re: [PATCH v3 2/5] powerpc: apm82181: create shared dtsi for APM bluestone
From: Christian Lamparter @ 2020-09-19 20:23 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, arnd, Chris Blake, Paul Mackerras, andriy.shevchenko,
linuxppc-dev
In-Reply-To: <20200915010543.GB612463@bogus>
On 2020-09-15 03:05, Rob Herring wrote:
> On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote:
>> This patch adds an DTSI-File that can be used by various device-tree
>> files for APM82181-based devices.
>>
>> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
>> need to stick with the naming-conventions of the old times'.
>> I've added comments whenever this was the case.
>>
>> Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
>> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
>> ---
>> rfc v1 -> v2:
>> - removed PKA (this CryptoPU will need driver)
>> - stick with compatibles, nodes, ... from either
>> Bluestone (APM82181) or Canyonlands (PPC460EX).
>> - add labels for NAND and NOR to help with access.
>> v2 -> v3:
>> - nodename of pciex@d.... was changed to pcie@d..
>> due to upstream patch.
>> - use simple-bus on the ebc, opb and plb nodes
>> ---
>> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++
>> 1 file changed, 466 insertions(+)
>> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
>>
>> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi
>> new file mode 100644
>> index 000000000000..60283430978d
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/apm82181.dtsi
>> @@ -0,0 +1,466 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Device Tree template include for various APM82181 boards.
>> + *
>> + * The SoC is an evolution of the PPC460EX predecessor.
>> + * This is why dt-nodes from the canyonlands EBC, OPB, USB,
>> + * DMA, SATA, EMAC, ... ended up in here.
>> + *
>> + * Copyright (c) 2010, Applied Micro Circuits Corporation
>> + * Author: Tirumala R Marri <tmarri@apm.com>,
>> + * Christian Lamparter <chunkeey@gmail.com>,
>> + * Chris Blake <chrisrblake93@gmail.com>
>> + */
>> +
>> +#include <dt-bindings/dma/dw-dmac.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +
>> +/ {
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + dcr-parent = <&{/cpus/cpu@0}>;
>> +
>> + aliases {
>> + ethernet0 = &EMAC0; /* needed for BSP u-boot */
>> + };
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + CPU0: cpu@0 {
>> + device_type = "cpu";
>> + model = "PowerPC,apm82181";
>
> This doesn't match the existing bluestone dts file.
>
> Please separate any restructuring from changes.
"I see" (I'm including your comment of the dt-binding as well).
I'm getting the vibe that I better should not touch that bluestone.dts.
An honestly, looking at the series and patches that the APM-engineers
posted back in the day, I can see why this well is so poisoned... and
stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing.
As for the devices. In the spirit of Arnd Bergmann's post of
<https://lkml.org/lkml/2020/3/30/195>
|It would be nice to move over the the bluestone .dts to the apm82181.dtsi file
|when that gets added, if only to ensure they use the same description for each
|node, but that shouldn't stop the addition of the new file if that is needed for
|distros to make use of a popular device.
|I see a couple of additional files in openwrt.
I mean I don't have the bluestone dev board, just the consumer devices.
Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi
This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller),
the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram".
And then add nodes for PCIE+MSI, AHBDMA+SATA, I2C, Ethernet, NAND+NOR and finally
the Crypto each in separate patches.
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Arnd Bergmann @ 2020-09-19 21:16 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, io-uring,
linux-arm-kernel, Jens Axboe, Parisc List, Network Development,
LKML, LSM List, Linux FS Devel, Andrew Morton, linuxppc-dev
In-Reply-To: <CALCETrW=BzodXeTAjSvpCoUQoL+MKaKPEeSTRWnB=-C9jMotbQ@mail.gmail.com>
On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski <luto@kernel.org> wrote:
> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig <hch@lst.de> wrote:
> > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > Said that, why not provide a variant that would take an explicit
> > > "is it compat" argument and use it there? And have the normal
> > > one pass in_compat_syscall() to that...
> >
> > That would help to not introduce a regression with this series yes.
> > But it wouldn't fix existing bugs when io_uring is used to access
> > read or write methods that use in_compat_syscall(). One example that
> > I recently ran into is drivers/scsi/sg.c.
Ah, so reading /dev/input/event* would suffer from the same issue,
and that one would in fact be broken by your patch in the hypothetical
case that someone tried to use io_uring to read /dev/input/event on x32...
For reference, I checked the socket timestamp handling that has a
number of corner cases with time32/time64 formats in compat mode,
but none of those appear to be affected by the problem.
> Aside from the potentially nasty use of per-task variables, one thing
> I don't like about PF_FORCE_COMPAT is that it's one-way. If we're
> going to have a generic mechanism for this, shouldn't we allow a full
> override of the syscall arch instead of just allowing forcing compat
> so that a compat syscall can do a non-compat operation?
The only reason it's needed here is that the caller is in a kernel
thread rather than a system call. Are there any possible scenarios
where one would actually need the opposite?
Arnd
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Finn Thain @ 2020-09-19 21:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Peter Maydell, linux-aio, open list:MIPS, David Howells, Linux-MM,
keyrings, sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, Andy Lutomirski,
io-uring, linux-arm-kernel, Jens Axboe, Parisc List,
Network Development, LKML, LSM List, Linux FS Devel,
Andrew Morton, linuxppc-dev
In-Reply-To: <CAK8P3a2Mi+1yttyGk4k7HxRVrMtmFqJewouVhynqUL0PJycmog@mail.gmail.com>
On Sat, 19 Sep 2020, Arnd Bergmann wrote:
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski <luto@kernel.org> wrote:
> > On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig <hch@lst.de> wrote:
> > > On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > > > Said that, why not provide a variant that would take an explicit
> > > > "is it compat" argument and use it there? And have the normal one
> > > > pass in_compat_syscall() to that...
> > >
> > > That would help to not introduce a regression with this series yes.
> > > But it wouldn't fix existing bugs when io_uring is used to access
> > > read or write methods that use in_compat_syscall(). One example
> > > that I recently ran into is drivers/scsi/sg.c.
>
> Ah, so reading /dev/input/event* would suffer from the same issue, and
> that one would in fact be broken by your patch in the hypothetical case
> that someone tried to use io_uring to read /dev/input/event on x32...
>
> For reference, I checked the socket timestamp handling that has a number
> of corner cases with time32/time64 formats in compat mode, but none of
> those appear to be affected by the problem.
>
> > Aside from the potentially nasty use of per-task variables, one thing
> > I don't like about PF_FORCE_COMPAT is that it's one-way. If we're
> > going to have a generic mechanism for this, shouldn't we allow a full
> > override of the syscall arch instead of just allowing forcing compat
> > so that a compat syscall can do a non-compat operation?
>
> The only reason it's needed here is that the caller is in a kernel
> thread rather than a system call. Are there any possible scenarios where
> one would actually need the opposite?
>
Quite possibly. The ext4 vs. compat getdents bug is still unresolved.
Please see,
https://lore.kernel.org/lkml/CAFEAcA9W+JK7_TrtTnL1P2ES1knNPJX9wcUvhfLwxLq9augq1w@mail.gmail.com/
> Arnd
>
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Al Viro @ 2020-09-19 22:09 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, x86,
Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200918151615.GA23432@lst.de>
On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> > Said that, why not provide a variant that would take an explicit
> > "is it compat" argument and use it there? And have the normal
> > one pass in_compat_syscall() to that...
>
> That would help to not introduce a regression with this series yes.
> But it wouldn't fix existing bugs when io_uring is used to access
> read or write methods that use in_compat_syscall(). One example that
> I recently ran into is drivers/scsi/sg.c.
So screw such read/write methods - don't use them with io_uring.
That, BTW, is one of the reasons I'm sceptical about burying the
decisions deep into the callchain - we don't _want_ different
data layouts on read/write depending upon the 32bit vs. 64bit
caller, let alone the pointer-chasing garbage that is /dev/sg.
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Andy Lutomirski @ 2020-09-19 22:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, Andy Lutomirski,
io-uring, linux-arm-kernel, Jens Axboe, Parisc List,
Network Development, LKML, LSM List, Linux FS Devel,
Andrew Morton, linuxppc-dev
In-Reply-To: <CAK8P3a2Mi+1yttyGk4k7HxRVrMtmFqJewouVhynqUL0PJycmog@mail.gmail.com>
> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski <luto@kernel.org> wrote:
>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig <hch@lst.de> wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>>> Said that, why not provide a variant that would take an explicit
>>>> "is it compat" argument and use it there? And have the normal
>>>> one pass in_compat_syscall() to that...
>>>
>>> That would help to not introduce a regression with this series yes.
>>> But it wouldn't fix existing bugs when io_uring is used to access
>>> read or write methods that use in_compat_syscall(). One example that
>>> I recently ran into is drivers/scsi/sg.c.
>
> Ah, so reading /dev/input/event* would suffer from the same issue,
> and that one would in fact be broken by your patch in the hypothetical
> case that someone tried to use io_uring to read /dev/input/event on x32...
>
> For reference, I checked the socket timestamp handling that has a
> number of corner cases with time32/time64 formats in compat mode,
> but none of those appear to be affected by the problem.
>
>> Aside from the potentially nasty use of per-task variables, one thing
>> I don't like about PF_FORCE_COMPAT is that it's one-way. If we're
>> going to have a generic mechanism for this, shouldn't we allow a full
>> override of the syscall arch instead of just allowing forcing compat
>> so that a compat syscall can do a non-compat operation?
>
> The only reason it's needed here is that the caller is in a kernel
> thread rather than a system call. Are there any possible scenarios
> where one would actually need the opposite?
>
I can certainly imagine needing to force x32 mode from a kernel thread.
As for the other direction: what exactly are the desired bitness/arch semantics of io_uring? Is the operation bitness chosen by the io_uring creation or by the io_uring_enter() bitness?
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Andy Lutomirski @ 2020-09-19 22:23 UTC (permalink / raw)
To: Al Viro
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200919220920.GI3421308@ZenIV.linux.org.uk>
> On Sep 19, 2020, at 3:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>> Said that, why not provide a variant that would take an explicit
>>> "is it compat" argument and use it there? And have the normal
>>> one pass in_compat_syscall() to that...
>>
>> That would help to not introduce a regression with this series yes.
>> But it wouldn't fix existing bugs when io_uring is used to access
>> read or write methods that use in_compat_syscall(). One example that
>> I recently ran into is drivers/scsi/sg.c.
>
> So screw such read/write methods - don't use them with io_uring.
> That, BTW, is one of the reasons I'm sceptical about burying the
> decisions deep into the callchain - we don't _want_ different
> data layouts on read/write depending upon the 32bit vs. 64bit
> caller, let alone the pointer-chasing garbage that is /dev/sg.
Well, we could remove in_compat_syscall(), etc and instead have an implicit parameter in DEFINE_SYSCALL. Then everything would have to be explicit. This would probably be a win, although it could be quite a bit of work.
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Al Viro @ 2020-09-19 22:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <AA2CFC7E-E685-4596-84AD-0E314137B93F@amacapital.net>
On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>
> > On Sep 19, 2020, at 3:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
> >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
> >>> Said that, why not provide a variant that would take an explicit
> >>> "is it compat" argument and use it there? And have the normal
> >>> one pass in_compat_syscall() to that...
> >>
> >> That would help to not introduce a regression with this series yes.
> >> But it wouldn't fix existing bugs when io_uring is used to access
> >> read or write methods that use in_compat_syscall(). One example that
> >> I recently ran into is drivers/scsi/sg.c.
> >
> > So screw such read/write methods - don't use them with io_uring.
> > That, BTW, is one of the reasons I'm sceptical about burying the
> > decisions deep into the callchain - we don't _want_ different
> > data layouts on read/write depending upon the 32bit vs. 64bit
> > caller, let alone the pointer-chasing garbage that is /dev/sg.
>
> Well, we could remove in_compat_syscall(), etc and instead have an implicit parameter in DEFINE_SYSCALL. Then everything would have to be explicit. This would probably be a win, although it could be quite a bit of work.
It would not be a win - most of the syscalls don't give a damn
about 32bit vs. 64bit...
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Andy Lutomirski @ 2020-09-19 22:53 UTC (permalink / raw)
To: Al Viro
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200919224122.GJ3421308@ZenIV.linux.org.uk>
> On Sep 19, 2020, at 3:41 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote:
>>
>>>> On Sep 19, 2020, at 3:09 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>>
>>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote:
>>>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>>>> Said that, why not provide a variant that would take an explicit
>>>>> "is it compat" argument and use it there? And have the normal
>>>>> one pass in_compat_syscall() to that...
>>>>
>>>> That would help to not introduce a regression with this series yes.
>>>> But it wouldn't fix existing bugs when io_uring is used to access
>>>> read or write methods that use in_compat_syscall(). One example that
>>>> I recently ran into is drivers/scsi/sg.c.
>>>
>>> So screw such read/write methods - don't use them with io_uring.
>>> That, BTW, is one of the reasons I'm sceptical about burying the
>>> decisions deep into the callchain - we don't _want_ different
>>> data layouts on read/write depending upon the 32bit vs. 64bit
>>> caller, let alone the pointer-chasing garbage that is /dev/sg.
>>
>> Well, we could remove in_compat_syscall(), etc and instead have an implicit parameter in DEFINE_SYSCALL. Then everything would have to be explicit. This would probably be a win, although it could be quite a bit of work.
>
> It would not be a win - most of the syscalls don't give a damn
> about 32bit vs. 64bit...
Any reasonable implementation would optimize it out for syscalls that don’t care. Or it could be explicit:
DEFINE_MULTIARCH_SYSCALL(...)
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Al Viro @ 2020-09-19 23:24 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <36CF3DE7-7B4B-41FD-9818-FDF8A5B440FB@amacapital.net>
On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
> > It would not be a win - most of the syscalls don't give a damn
> > about 32bit vs. 64bit...
>
> Any reasonable implementation would optimize it out for syscalls that don’t care. Or it could be explicit:
>
> DEFINE_MULTIARCH_SYSCALL(...)
1) what would that look like?
2) have you counted the syscalls that do and do not need that?
3) how many of those realistically *can* be unified with their
compat counterparts? [hint: ioctl(2) cannot]
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Andy Lutomirski @ 2020-09-20 0:14 UTC (permalink / raw)
To: Al Viro
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, Arnd Bergmann, linux-block, io-uring,
linux-arm-kernel, Jens Axboe, Parisc List, Network Development,
LKML, LSM List, Linux FS Devel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200919232411.GK3421308@ZenIV.linux.org.uk>
On Sat, Sep 19, 2020 at 4:24 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Sat, Sep 19, 2020 at 03:53:40PM -0700, Andy Lutomirski wrote:
>
> > > It would not be a win - most of the syscalls don't give a damn
> > > about 32bit vs. 64bit...
> >
> > Any reasonable implementation would optimize it out for syscalls that don’t care. Or it could be explicit:
> >
> > DEFINE_MULTIARCH_SYSCALL(...)
>
> 1) what would that look like?
In effect, it would work like this:
/* Arch-specific, but there's a generic case for sane architectures. */
enum syscall_arch {
SYSCALL_NATIVE,
SYSCALL_COMPAT,
SYSCALL_X32,
};
DEFINE_MULTIARCH_SYSCALLn(args, arch)
{
args are the args here, and arch is the arch.
}
> 2) have you counted the syscalls that do and do not need that?
No.
> 3) how many of those realistically *can* be unified with their
> compat counterparts? [hint: ioctl(2) cannot]
There would be no requirement to unify anything. The idea is that
we'd get rid of all the global state flags.
For ioctl, we'd have a new file_operation:
long ioctl(struct file *, unsigned int, unsigned long, enum syscall_arch);
I'm not saying this is easy, but I think it's possible and the result
would be more obviously correct than what we have now.
^ permalink raw reply
* [PATCH v1 1/2] dt-bindings: usb: dwc2: add support for APM82181 SoCs USB OTG HS and FS
From: Christian Lamparter @ 2020-09-20 0:18 UTC (permalink / raw)
To: linuxppc-dev, devicetree, linux-usb
Cc: Minas Harutyunyan, Greg Kroah-Hartman, Rob Herring
adds the specific compatible string for the DWC2 IP found in the APM82181
SoCs. The APM82181's USB-OTG seems like it was taken from its direct
predecessor: the PPC460EX (canyonlands).
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
Documentation/devicetree/bindings/usb/dwc2.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index ffa157a0fce7..34ddb5c877a1 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -39,6 +39,7 @@ properties:
- amlogic,meson-g12a-usb
- const: snps,dwc2
- const: amcc,dwc-otg
+ - const: apm,apm82181-dwc-otg
- const: snps,dwc2
- const: st,stm32f4x9-fsotg
- const: st,stm32f4x9-hsotg
--
2.28.0
^ permalink raw reply related
* [PATCH v1 2/2] usb: dwc2: add support for APM82181 USB OTG
From: Christian Lamparter @ 2020-09-20 0:18 UTC (permalink / raw)
To: linuxppc-dev, devicetree, linux-usb
Cc: Minas Harutyunyan, Greg Kroah-Hartman, Rob Herring
In-Reply-To: <a43868b06566f5d959d8cfc4e763bede2885931a.1600560884.git.chunkeey@gmail.com>
adds the specific compatible string for the DWC2 IP found in the APM82181
SoCs. The IP is setup correctly through the auto detection... With the
exception of the AHB Burst Size. The default of GAHBCFG_HBSTLEN_INCR4 of
the "snps,dwc2" can cause a system hang when the USB and SATA is used
concurrently. Because the predecessor (PPC460EX (Canyonlands)) already
had the same problem, this SoC can make use of the existing
dwc2_set_amcc_params() function.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/usb/dwc2/params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 8f9d061c4d5f..6d2b9a6c247c 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -210,6 +210,7 @@ const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "amlogic,meson-g12a-usb",
.data = dwc2_set_amlogic_g12a_params },
{ .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
+ { .compatible = "apm,apm82181-dwc-otg", .data = dwc2_set_amcc_params },
{ .compatible = "st,stm32f4x9-fsotg",
.data = dwc2_set_stm32f4x9_fsotg_params },
{ .compatible = "st,stm32f4x9-hsotg" },
--
2.28.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox