[PATCH 07/23] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2022-01-08 Thread Andy Lutomirski
519 ("membarrier: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski --- .../membarrier-sync-core/arch-support.txt | 69 ++- arch/arm/include/asm/membarrier.h | 21 ++ arch/arm64/include/asm/membarrier.h | 19 + arch

[PATCH 06/23] powerpc/membarrier: Remove special barrier on mm switch

2022-01-08 Thread Andy Lutomirski
: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Cc: Nicholas Piggin Cc: Mathieu Desnoyers Cc: Peter Zijlstra Signed-off-by: Andy Lutomirski --- arch/powerpc/include/asm/membarrier.h | 24 arch/powerpc/mm/mmu_context.c | 1 - 2 fil

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-19 Thread Andy Lutomirski
On Fri, Jun 18, 2021, at 11:02 PM, Nicholas Piggin wrote: > Excerpts from Mathieu Desnoyers's message of June 19, 2021 6:09 am: > > - On Jun 18, 2021, at 3:58 PM, Andy Lutomirski l...@kernel.org wrote: > > > >> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers w

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-18 Thread Andy Lutomirski
On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote: > - On Jun 17, 2021, at 8:12 PM, Andy Lutomirski l...@kernel.org wrote: > > > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote: > > > >> Please change back this #ifndef / #else / #endif within function for

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-17 Thread Andy Lutomirski
On 6/17/21 8:16 AM, Mathieu Desnoyers wrote: > - On Jun 15, 2021, at 11:21 PM, Andy Lutomirski l...@kernel.org wrote: > > [...] > >> +# An architecture that wants to support >> +# MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE needs to define precisely what >&

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-17 Thread Andy Lutomirski
On 6/17/21 7:47 AM, Mathieu Desnoyers wrote: > Please change back this #ifndef / #else / #endif within function for > > if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE)) { > ... > } else { > ... > } > > I don't think mixing up preprocessor and code logic makes it more readable. I

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-16 Thread Andy Lutomirski
On Wed, Jun 16, 2021, at 3:20 AM, Will Deacon wrote: > > For the arm64 bits (docs and asm/sync_core.h): > > Acked-by: Will Deacon > Thanks. Per Nick's suggestion, I renamed the header to membarrier.h. Unless I hear otherwise, I'll keep the ack. > Will >

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-16 Thread Andy Lutomirski
On Wed, Jun 16, 2021, at 11:52 AM, Andy Lutomirski wrote: > On 6/15/21 9:45 PM, Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm: > >> The old sync_core_before_usermode() comments suggested that a > >> non-icache-sync

Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-16 Thread Andy Lutomirski
On 6/15/21 9:45 PM, Nicholas Piggin wrote: > Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm: >> The old sync_core_before_usermode() comments suggested that a >> non-icache-syncing >> return-to-usermode instruction is x86-specific and that all other >> architectures automatically

[PATCH 6/8] powerpc/membarrier: Remove special barrier on mm switch

2021-06-15 Thread Andy Lutomirski
Cc: Peter Zijlstra Signed-off-by: Andy Lutomirski --- arch/powerpc/include/asm/membarrier.h | 27 --- arch/powerpc/mm/mmu_context.c | 2 -- 2 files changed, 29 deletions(-) delete mode 100644 arch/powerpc/include/asm/membarrier.h diff --git a/arch/powerpc/i

[PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation

2021-06-15 Thread Andy Lutomirski
uxppc-dev@lists.ozlabs.org Cc: Nicholas Piggin Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org Cc: Mathieu Desnoyers Cc: Nicholas Piggin Cc: Peter Zijlstra Cc: x...@kernel.org Cc: sta...@vger.kernel.org Fixes: 70216e18e519 ("membarrier: Provide core serializing

Re: [PATCH v4 2/4] lazy tlb: allow lazy tlb mm refcounting to be configurable

2021-06-15 Thread Andy Lutomirski
On 6/14/21 5:55 PM, Nicholas Piggin wrote: > Excerpts from Andy Lutomirski's message of June 15, 2021 2:20 am: >> Replying to several emails at once... >> > > So the only documentation relating to the current active_mm value or > refcounting is that it may not match what the x86 specific code

Re: [PATCH v4 2/4] lazy tlb: allow lazy tlb mm refcounting to be configurable

2021-06-14 Thread Andy Lutomirski
Replying to several emails at once... On 6/13/21 10:21 PM, Nicholas Piggin wrote: > Excerpts from Nicholas Piggin's message of June 14, 2021 2:47 pm: >> Excerpts from Nicholas Piggin's message of June 14, 2021 2:14 pm: >>> Excerpts from Andy Lutomirski's message of June 14, 2021 1:52 pm: On

Re: [PATCH v4 2/4] lazy tlb: allow lazy tlb mm refcounting to be configurable

2021-06-13 Thread Andy Lutomirski
On 6/13/21 5:45 PM, Nicholas Piggin wrote: > Excerpts from Andy Lutomirski's message of June 9, 2021 2:20 am: >> On 6/4/21 6:42 PM, Nicholas Piggin wrote: >>> Add CONFIG_MMU_TLB_REFCOUNT which enables refcounting of the lazy tlb mm >>> when it is context switched. This can be disabled by

Re: [PATCH v4 2/4] lazy tlb: allow lazy tlb mm refcounting to be configurable

2021-06-08 Thread Andy Lutomirski
On 6/4/21 6:42 PM, Nicholas Piggin wrote: > Add CONFIG_MMU_TLB_REFCOUNT which enables refcounting of the lazy tlb mm > when it is context switched. This can be disabled by architectures that > don't require this refcounting if they clean up lazy tlb mms when the > last refcount is dropped.

Re: [PATCH v3 0/4] shoot lazy tlbs

2021-06-04 Thread Andy Lutomirski
On 6/4/21 9:54 AM, Andy Lutomirski wrote: > On 5/31/21 11:22 PM, Nicholas Piggin wrote: >> There haven't been objections to the series since last posting, this >> is just a rebase and tidies up a few comments minor patch rearranging. >> > > I continue to object to hav

Re: [PATCH v3 0/4] shoot lazy tlbs

2021-06-04 Thread Andy Lutomirski
On 5/31/21 11:22 PM, Nicholas Piggin wrote: > There haven't been objections to the series since last posting, this > is just a rebase and tidies up a few comments minor patch rearranging. > I continue to object to having too many modes. I like my more generic improvements better. Let me try to

Re: [RFC 00/20] TLB batching consolidation and enhancements

2021-01-30 Thread Andy Lutomirski
On Sat, Jan 30, 2021 at 4:16 PM Nadav Amit wrote: > > From: Nadav Amit > > There are currently (at least?) 5 different TLB batching schemes in the > kernel: > > 1. Using mmu_gather (e.g., zap_page_range()). > > 2. Using {inc|dec}_tlb_flush_pending() to inform other threads on the >ongoing

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2021-01-05 Thread Andy Lutomirski
> On Jan 5, 2021, at 5:26 AM, Will Deacon wrote: > > Hi Andy, > > Sorry for the slow reply, I was socially distanced from my keyboard. > >> On Mon, Dec 28, 2020 at 04:36:11PM -0800, Andy Lutomirski wrote: >> On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin w

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 4:36 PM Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 29, 2020 7:06 am: > > On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers > > wrote: > >> > >> ----- On Dec 28, 2020, at 2:44 PM, A

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 4:11 PM Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 28, 2020 4:28 am: > > The old sync_core_before_usermode() comments said that a non-icache-syncing > > return-to-usermode instruction is x86-specific and that all other > > architectures

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 1:09 PM Mathieu Desnoyers wrote: > > - On Dec 27, 2020, at 4:36 PM, Andy Lutomirski l...@kernel.org wrote: > > [...] > > >> You seem to have noticed odd cases on arm64 where this guarantee does not > >> match reality. Where exa

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 12:32 PM Mathieu Desnoyers wrote: > > - On Dec 28, 2020, at 2:44 PM, Andy Lutomirski l...@kernel.org wrote: > > > On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin > > wrote: > >> > >> On Mon, Dec 28, 20

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin wrote: > > On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote: > > After chatting with rmk about this (but without claiming that any of > > this is his opinion), based on the manpage, I think membarrier() > > currently doesn't

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 10:30 AM Jann Horn wrote: > > On Mon, Dec 28, 2020 at 6:14 PM Andy Lutomirski wrote: > > On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin > > wrote: > > > > > > On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 9:23 AM Russell King - ARM Linux admin wrote: > > On Mon, Dec 28, 2020 at 09:14:23AM -0800, Andy Lutomirski wrote: > > On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin > > wrote: > > > > > > On Sun, Dec 27, 2020 at 01:

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-28 Thread Andy Lutomirski
On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin wrote: > > On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote: > > On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers > > wrote: > > > > > > ----- On Dec 27, 2020, at 1:28 PM, A

Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-27 Thread Andy Lutomirski
On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers wrote: > > - On Dec 27, 2020, at 1:28 PM, Andy Lutomirski l...@kernel.org wrote: > > > > > I admit that I'm rather surprised that the code worked at all on arm64, > > and I'm suspicious that it has never been very

[RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-27 Thread Andy Lutomirski
r: Provide core serializing command, *_SYNC_CORE") Signed-off-by: Andy Lutomirski --- Hi arm64 and powerpc people- This is part of a series here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/fixes Before I send out the whole series, I'm hoping that some arm64 an

Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-10 Thread Andy Lutomirski
> On Dec 5, 2020, at 7:59 PM, Nicholas Piggin wrote: > > I'm still going to persue shoot-lazies for the merge window. As you > see it's about a dozen lines and a if (IS_ENABLED(... in core code. > Your change is common code, but a significant complexity (which > affects all archs) so needs a lot

Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-05 Thread Andy Lutomirski
On Sat, Dec 5, 2020 at 3:15 PM Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 6, 2020 2:11 am: > > > If an mm was lazy tlb for a kernel thread and then it becomes unlazy, > and if switch_mm is serialising but return to user is not, then you > need a serialising

Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-05 Thread Andy Lutomirski
> On Dec 5, 2020, at 12:00 AM, Nicholas Piggin wrote: > > > I disagree. Until now nobody following it noticed that the mm gets > un-lazied in other cases, because that was not too clear from the > code (only indirectly using non-standard terminology in the arch > support document). > In

Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

2020-12-04 Thread Andy Lutomirski
> On Dec 3, 2020, at 11:54 PM, Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm: >> This is a mockup. It's designed to illustrate the algorithm and how the >> code might be structured. There are several things blatantly wrong with >> it: >> >>

[RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

2020-12-03 Thread Andy Lutomirski
() not being reliable. Signed-off-by: Andy Lutomirski --- kernel/fork.c| 4 ++ kernel/sched/core.c | 128 +-- kernel/sched/sched.h | 11 +++- 3 files changed, 126 insertions(+), 17 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index

[RFC v2 1/2] [NEEDS HELP] x86/mm: Handle unlazying membarrier core sync in the arch code

2020-12-03 Thread Andy Lutomirski
not clear to me that these barriers are actually present in all paths through the code. So I think this change makes the code more comprehensible and has no effect on the code's correctness, but I'm not at all convinced that the code is correct. Signed-off-by: Andy Lutomirski --- arch/x86/mm/tlb.c

[RFC v2 0/2] lazy mm refcounting

2020-12-03 Thread Andy Lutomirski
some extra barriers. power: Similar to x86. s390x: Should be essentially the same as arm64. Other arches: I don't know. Further research is required. What do you all think? Andy Lutomirski (2): [NEEDS HELP] x86/mm: Handle unlazying membarrier core sync in the arch code [MOCKUP] sched/mm

Re: [MOCKUP] x86/mm: Lightweight lazy mm refcounting

2020-12-03 Thread Andy Lutomirski
> On Dec 3, 2020, at 2:13 PM, Nicholas Piggin wrote: > > Excerpts from Peter Zijlstra's message of December 3, 2020 6:44 pm: >>> On Wed, Dec 02, 2020 at 09:25:51PM -0800, Andy Lutomirski wrote: >>> >>> power: same as ARM, except that the loop may be

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-12-03 Thread Andy Lutomirski
> On Dec 3, 2020, at 9:09 AM, Alexander Gordeev wrote: > > On Mon, Nov 30, 2020 at 10:31:51AM -0800, Andy Lutomirski wrote: >> other arch folk: there's some background here: > >> >> power: Ridiculously complicated, seems to vary by system and kernel

[MOCKUP] x86/mm: Lightweight lazy mm refcounting

2020-12-02 Thread Andy Lutomirski
s tree) no longer uses active_mm at all. I should contemplate whether the calling CPU is special in arch_fixup_lazy_mm_refs(). On a very very quick think, it's not, but it needs more thought. Signed-off-by: Andy Lutomirski arch/x86/include/asm/tlbflush.h | 20 arch/x86/mm

Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-12-02 Thread Andy Lutomirski
embarrier needs is quite complicated, and it's not clear to me that the code is even correct. At the very least I'm pretty sure that the x86 comments are misleading. With your patches, someone trying to audit the code would have to follow core code calling into arch code and back out into core code to

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-12-02 Thread Andy Lutomirski
l.com >> >>> On Sun, Nov 29, 2020 at 12:16 PM Andy Lutomirski wrote: >>> >>> On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote: >>>> >>>> On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: >>>>> >>&g

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-12-02 Thread Andy Lutomirski
> On Dec 2, 2020, at 6:20 AM, Peter Zijlstra wrote: > > On Sun, Nov 29, 2020 at 02:01:39AM +1000, Nicholas Piggin wrote: >> + * - A delayed freeing and RCU-like quiescing sequence based on >> + * mm switching to avoid IPIs completely. > > That one's interesting too. so

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-12-01 Thread Andy Lutomirski
On Tue, Dec 1, 2020 at 1:28 PM Will Deacon wrote: > > On Mon, Nov 30, 2020 at 10:31:51AM -0800, Andy Lutomirski wrote: > > other arch folk: there's some background here: > > > > https://lkml.kernel.org/r/calcetrvxube8lfnn-qs+dzroqaiw+sfug1j047ybyv31sat...@mail.gmail.co

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-11-30 Thread Andy Lutomirski
other arch folk: there's some background here: https://lkml.kernel.org/r/calcetrvxube8lfnn-qs+dzroqaiw+sfug1j047ybyv31sat...@mail.gmail.com On Sun, Nov 29, 2020 at 12:16 PM Andy Lutomirski wrote: > > On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote: > > > > On Sat, Nov 2

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-11-29 Thread Andy Lutomirski
On Sat, Nov 28, 2020 at 7:54 PM Andy Lutomirski wrote: > > On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: > > > > On big systems, the mm refcount can become highly contented when doing > > a lot of context switching with threaded applications (particularly > &

Re: [PATCH 6/8] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-11-28 Thread Andy Lutomirski
On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: > > On big systems, the mm refcount can become highly contented when doing > a lot of context switching with threaded applications (particularly > switching between the idle thread and an application thread). > > Abandoning lazy tlb slows

Re: [PATCH 1/8] lazy tlb: introduce exit_lazy_tlb

2020-11-28 Thread Andy Lutomirski
On Sat, Nov 28, 2020 at 8:01 AM Nicholas Piggin wrote: > > This is called at points where a lazy mm is switched away or made not > lazy (by its owner switching back). > > Signed-off-by: Nicholas Piggin > --- > arch/arm/mach-rpc/ecard.c| 1 + > arch/powerpc/mm/book3s64/radix_tlb.c |

Re: [PATCH 5/8] lazy tlb: allow lazy tlb mm switching to be configurable

2020-11-28 Thread Andy Lutomirski
On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: > > NOMMU systems could easily go without this and save a bit of code > and the refcount atomics, because their mm switch is a no-op. I > haven't flipped them over because haven't audited all arch code to > convert over to using the _lazy_tlb

Re: [PATCH 2/8] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-11-28 Thread Andy Lutomirski
On Sat, Nov 28, 2020 at 8:02 AM Nicholas Piggin wrote: > > And get rid of the generic sync_core_before_usermode facility. This is > functionally a no-op in the core scheduler code, but it also catches > > This helper is the wrong way around I think. The idea that membarrier > state requires a

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-22 Thread Andy Lutomirski
> On Sep 22, 2020, at 2:01 AM, Arnd Bergmann wrote: > > On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov > wrote: >>> On 22/09/2020 10:23, Arnd Bergmann wrote: >>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov >>> wrote: >>>> On 22/09/2

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-21 Thread Andy Lutomirski
On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov wrote: > > > > On 22/09/2020 02:51, Andy Lutomirski wrote: > > On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov > > wrote: > >> > >> On 21/09/2020 19:10, Pavel Begunkov wrote: > >>> On 20/09/2020

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-21 Thread Andy Lutomirski
On Mon, Sep 21, 2020 at 9:15 AM Pavel Begunkov wrote: > > On 21/09/2020 19:10, Pavel Begunkov wrote: > > On 20/09/2020 01:22, Andy Lutomirski wrote: > >> > >>> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote: > >>> > >>> On Sat, Sep 1

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-20 Thread Andy Lutomirski
u're a 32-bit process, you don't get to use io_uring. Would > any real users actually care about that? We could go one step farther and declare that we're done adding *any* new compat syscalls :) -- Andy Lutomirski AMA Capital Management, LLC

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-20 Thread Andy Lutomirski
On Sun, Sep 20, 2020 at 11:07 AM Al Viro wrote: > > On Sun, Sep 20, 2020 at 04:15:10PM +0100, Matthew Wilcox wrote: > > On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote: > > > Add a flag to force processing a syscall as a compat syscall. This is > > > required so that

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-20 Thread Andy Lutomirski
On Sat, Sep 19, 2020 at 7:57 PM Al Viro wrote: > > On Sat, Sep 19, 2020 at 05:14:41PM -0700, Andy Lutomirski wrote: > > > > 2) have you counted the syscalls that do and do not need that? > > > > No. > > Might be illuminating... > > > > 3)

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-19 Thread Andy Lutomirski
On Sat, Sep 19, 2020 at 4:24 PM Al Viro 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 implementa

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-19 Thread Andy Lutomirski
> On Sep 19, 2020, at 3:41 PM, Al Viro wrote: > > On Sat, Sep 19, 2020 at 03:23:54PM -0700, Andy Lutomirski wrote: >> >>>> On Sep 19, 2020, at 3:09 PM, Al Viro wrote: >>> >>> On Fri, Sep 18, 2020 at 05:16:15PM +0200, Christoph Hellwig wrote: &

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-19 Thread Andy Lutomirski
> On Sep 19, 2020, at 3:09 PM, Al Viro 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?

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-19 Thread Andy Lutomirski
> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann wrote: > > On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski wrote: >>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig wrote: >>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote: >>>> Said that, wh

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

2020-09-19 Thread Andy Lutomirski
On Fri, Sep 18, 2020 at 8:16 AM 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...

Re: ptrace_syscall_32 is failing

2020-09-02 Thread Andy Lutomirski
On Wed, Sep 2, 2020 at 1:29 AM Thomas Gleixner wrote: > > On Tue, Sep 01 2020 at 17:09, Andy Lutomirski wrote: > > On Tue, Sep 1, 2020 at 4:50 PM Thomas Gleixner wrote: > >> > I think that they almost work for x86, but not quite as > >> > indicated by this bug

Re: ptrace_syscall_32 is failing

2020-09-01 Thread Andy Lutomirski
On Tue, Sep 1, 2020 at 4:50 PM Thomas Gleixner wrote: > > On Sun, Aug 30 2020 at 08:52, Andy Lutomirski wrote: > >> > [RUN]SYSCALL > >> > [FAIL]Initial args are wrong (nr=29, args=0 0 0 0 0 4289172732) > >> > [RUN]SYSCALL > >>

Re: ptrace_syscall_32 is failing

2020-08-30 Thread Andy Lutomirski
On Sat, Aug 29, 2020 at 9:40 PM Brian Gerst wrote: > > On Sat, Aug 29, 2020 at 12:52 PM Andy Lutomirski wrote: > > > > Seems to be a recent regression, maybe related to entry/exit work changes. > > > > # ./tools/testing/selftests/x86/ptrace_syscall_32 > > [RUN

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-07-15 Thread Andy Lutomirski
> On Jul 15, 2020, at 9:15 PM, Nicholas Piggin wrote: > > Excerpts from Mathieu Desnoyers's message of July 14, 2020 12:13 am: >> - On Jul 13, 2020, at 9:47 AM, Nicholas Piggin npig...@gmail.com wrote: >> >>> Excerpts from Nicholas Piggin's message of July 13, 2020 2:45 pm:

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-14 Thread Andy Lutomirski
> On Jul 13, 2020, at 11:31 PM, Nicholas Piggin wrote: > > Excerpts from Nicholas Piggin's message of July 14, 2020 3:04 pm: >> Excerpts from Andy Lutomirski's message of July 14, 2020 4:18 am: >>> On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote: Excerpts from Andy

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-13 Thread Andy Lutomirski
> On Jul 13, 2020, at 9:48 AM, Nicholas Piggin wrote: > > Excerpts from Andy Lutomirski's message of July 14, 2020 1:59 am: >>> On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote: >>> >>> On big systems, the mm refcount can become highly contented when doing >>> a lot of context switching

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

2020-07-13 Thread Andy Lutomirski
On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote: > > On big systems, the mm refcount can become highly contented when doing > a lot of context switching with threaded applications (particularly > switching between the idle thread and an application thread). > > Abandoning lazy tlb slows

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-07-13 Thread Andy Lutomirski
On Mon, Jul 13, 2020 at 7:13 AM Mathieu Desnoyers wrote: > > - On Jul 13, 2020, at 9:47 AM, Nicholas Piggin npig...@gmail.com wrote: > > > Excerpts from Nicholas Piggin's message of July 13, 2020 2:45 pm: > >> Excerpts from Andy Lutomirski's message of July 11, 2020 3:04 am: > >>> Also, as it

Re: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode

2020-07-10 Thread Andy Lutomirski
On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin wrote: > > And get rid of the generic sync_core_before_usermode facility. > > This helper is the wrong way around I think. The idea that membarrier > state requires a core sync before returning to user is the easy one > that does not need hiding

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Andy Lutomirski
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote: > >  >> >> Are we planning to keep PASID live once a task has used it once or are we >> going to swap it lazily? If the latter, a percpu variable might be better. > > Current plan is "touch it once and the task owns it until exit(2)" > >

Re: [PATCH v2 12/12] x86/traps: Fix up invalid PASID

2020-06-15 Thread Andy Lutomirski
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote: > > Hi, Peter, > >> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote: >>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote: >>> >>> Or do you suggest to add a random new flag in struct thread_info instead >>> of a TIF

Re: [RFC PATCH v3 08/12] lib: vdso: allow arches to provide vdso data pointer

2020-01-16 Thread Andy Lutomirski
On Thu, Jan 16, 2020 at 2:35 AM Thomas Gleixner wrote: > > static __maybe_unused int > __cvdso_data_clock_gettime(clockid_t clock, struct __kernel_timespec *ts, >const struct vdso_data *vd) > { > . > } > > static __maybe_unused int >

Re: [RFC PATCH v4 10/11] lib: vdso: Allow arches to override the ns shift operation

2020-01-16 Thread Andy Lutomirski
On Thu, Jan 16, 2020 at 11:57 AM Thomas Gleixner wrote: > > Andy Lutomirski writes: > > On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy > > > > Would mul_u64_u64_shr() be a good alternative? Could we adjust it to > > assume the shift is less than 32? That functio

Re: [RFC PATCH v4 08/11] lib: vdso: allow fixed clock mode

2020-01-16 Thread Andy Lutomirski
On Thu, Jan 16, 2020 at 12:14 PM Thomas Gleixner wrote: > > Christophe Leroy writes: > > Can you please adjust the prefix for future patches to lib/vdso: and > start the sentence after the colon with an uppercase letter? > > > On arches like POWERPC, the clock is always the timebase, it > >

Re: [RFC PATCH v4 10/11] lib: vdso: Allow arches to override the ns shift operation

2020-01-16 Thread Andy Lutomirski
On Thu, Jan 16, 2020 at 9:58 AM Christophe Leroy wrote: > > On powerpc/32, GCC (8.1) generates pretty bad code for the > ns >>= vd->shift operation taking into account that the > shift is always < 32 and the upper part of the result is > likely to be nul. GCC makes reversed assumptions

Re: [RFC PATCH v2 01/10] lib: vdso: ensure all arches have 32bit fallback

2020-01-10 Thread Andy Lutomirski
> On Jan 10, 2020, at 10:56 AM, Thomas Gleixner wrote: > > Andy Lutomirski writes: > >>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy >>> wrote: >>> >>> In order to simplify next step which moves fallback call at arch >>&g

Re: [RFC PATCH v2 04/10] lib: vdso: get pointer to vdso data from the arch

2019-12-24 Thread Andy Lutomirski
On Tue, Dec 24, 2019 at 4:15 AM Andy Lutomirski wrote: > > > > > On Dec 24, 2019, at 7:53 PM, christophe leroy > > wrote: > > > >  > > > >> Le 24/12/2019 à 03:27, Andy Lutomirski a écrit : > >>> On Mon, Dec 23, 2019 at 6

Re: [RFC PATCH v2 04/10] lib: vdso: get pointer to vdso data from the arch

2019-12-24 Thread Andy Lutomirski
> On Dec 24, 2019, at 7:53 PM, christophe leroy wrote: > >  > >> Le 24/12/2019 à 03:27, Andy Lutomirski a écrit : >>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy >>> wrote: >>> >>> On powerpc, __arch_get_vdso_data() clobbers the

Re: [RFC PATCH v2 02/10] lib: vdso: move call to fallback out of common code.

2019-12-24 Thread Andy Lutomirski
> On Dec 24, 2019, at 7:41 PM, christophe leroy wrote: > >  > >> Le 24/12/2019 à 03:24, Andy Lutomirski a écrit : >>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy >>> wrote: >>> >>> On powerpc, VDSO functions and syscalls canno

Re: [RFC PATCH v2 07/10] lib: vdso: don't use READ_ONCE() in __c_kernel_time()

2019-12-24 Thread Andy Lutomirski
> On Dec 24, 2019, at 7:12 PM, christophe leroy wrote: > >  > >> Le 24/12/2019 à 02:58, Andy Lutomirski a écrit : >>> On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy >>> wrote: >>> >>> READ_ONCE() forces the read of the 64 bit value

Re: [RFC PATCH v2 05/10] lib: vdso: inline do_hres()

2019-12-23 Thread Andy Lutomirski
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy wrote: > > do_hres() is called from several places, so GCC doesn't inline > it at first. > > do_hres() takes a struct __kernel_timespec * parameter for > passing the result. In the 32 bits case, this parameter corresponds > to a local var in the

Re: [RFC PATCH v2 04/10] lib: vdso: get pointer to vdso data from the arch

2019-12-23 Thread Andy Lutomirski
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy wrote: > > On powerpc, __arch_get_vdso_data() clobbers the link register, > requiring the caller to set a stack frame in order to save it. > > As the parent function already has to set a stack frame and save > the link register to call the C vdso

Re: [RFC PATCH v2 02/10] lib: vdso: move call to fallback out of common code.

2019-12-23 Thread Andy Lutomirski
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy wrote: > > On powerpc, VDSO functions and syscalls cannot be implemented in C > because the Linux kernel ABI requires that CR[SO] bit is set in case > of error and cleared when no error. > > As this cannot be done in C, C VDSO functions and

Re: [RFC PATCH v2 01/10] lib: vdso: ensure all arches have 32bit fallback

2019-12-23 Thread Andy Lutomirski
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy wrote: > > In order to simplify next step which moves fallback call at arch > level, ensure all arches have a 32bit fallback instead of handling > the lack of 32bit fallback in the common code based > on VDSO_HAS_32BIT_FALLBACK I don't like this.

Re: [RFC PATCH v2 08/10] lib: vdso: Avoid duplication in __cvdso_clock_getres()

2019-12-23 Thread Andy Lutomirski
On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy wrote: > > VDSO_HRES and VDSO_RAW clocks are handled the same way. > > Don't duplicate code. > > Signed-off-by: Christophe Leroy Reviewed-by: Andy Lutomirski

Re: [RFC PATCH v2 07/10] lib: vdso: don't use READ_ONCE() in __c_kernel_time()

2019-12-23 Thread Andy Lutomirski
ction really ought to be considered deprecated -- 32-bit time_t is insufficient. Do you get even better code if you move the read into the if statement? Reviewed-by: Andy Lutomirski --Andy

Re: [RFC PATCH] powerpc/32: Switch VDSO to C implementation.

2019-10-26 Thread Andy Lutomirski
On Tue, Oct 22, 2019 at 6:56 AM Christophe Leroy wrote: > > > >>> The performance is rather disappoiting. That's most likely all > >>> calculation in the C implementation are based on 64 bits math and > >>> converted to 32 bits at the very end. I guess C implementation should > >>> use 32 bits

Re: [PATCH v12 11/12] open: openat2(2) syscall

2019-09-07 Thread Andy Lutomirski
> On Sep 7, 2019, at 10:45 AM, Linus Torvalds > wrote: > >> On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski wrote: >> >> Linus, you rejected resolveat() because you wanted a *nice* API > > No. I rejected resoveat() because it was a completely broken ga

Re: [PATCH v12 11/12] open: openat2(2) syscall

2019-09-07 Thread Andy Lutomirski
> On Sep 7, 2019, at 9:58 AM, Linus Torvalds > wrote: > >> On Sat, Sep 7, 2019 at 5:40 AM Jeff Layton wrote: >> >> After thinking about this a bit, I wonder if we might be better served >> with a new set of OA2_* flags instead of repurposing the O_* flags? > > I'd hate to have yet

Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory

2019-08-19 Thread Andy Lutomirski
> On Aug 18, 2019, at 8:58 PM, Daniel Axtens wrote: > >>> Each page of shadow memory represent 8 pages of real memory. Could we use >>> page_ref to count how many pieces of a shadow page are used so that we can >>> free it when the ref count decreases to 0. > > I'm not sure how much of a

Re: [PATCH v4 1/3] kasan: support backing vmalloc space with real shadow memory

2019-08-16 Thread Andy Lutomirski
On Fri, Aug 16, 2019 at 10:08 AM Mark Rutland wrote: > > Hi Christophe, > > On Fri, Aug 16, 2019 at 09:47:00AM +0200, Christophe Leroy wrote: > > Le 15/08/2019 à 02:16, Daniel Axtens a écrit : > > > Hook into vmalloc and vmap, and dynamically allocate real shadow > > > memory to back the

Re: [PATCH v2 3/6] x86: clean up _TIF_SYSCALL_EMU handling using ptrace_syscall_enter hook

2019-04-30 Thread Andy Lutomirski
On Mon, Mar 18, 2019 at 3:49 AM Sudeep Holla wrote: > > Now that we have a new hook ptrace_syscall_enter that can be called from > syscall entry code and it handles PTRACE_SYSEMU in generic code, we > can do some cleanup using the same in syscall_trace_enter. > > Further the extra logic to find

Re: [PATCH v2 0/6] ptrace: consolidate PTRACE_SYSEMU handling and add support for arm64

2019-03-18 Thread Andy Lutomirski
On Mon, Mar 18, 2019 at 3:49 AM Sudeep Holla wrote: > > Hi, > > This patchset evolved from the discussion in the thread[0][1]. When we > wanted to add PTRACE_SYSEMU support to ARM64, we thought instead of > duplicating what other architectures like x86 and powerpc have done, > let consolidate the

Re: [PATCH 3/6] x86: clean up _TIF_SYSCALL_EMU handling using ptrace_syscall_enter hook

2019-03-11 Thread Andy Lutomirski
On Mon, Mar 11, 2019 at 6:35 PM Haibo Xu (Arm Technology China) wrote: > > On 2019/3/12 2:34, Sudeep Holla wrote: > > (I thought I had sent this email, last Tuesday itself, but saw this in my > > draft today, something went wrong, sorry for the delay) > > > > On Tue, Mar 05, 2019 at 02:14:47AM

Re: [PATCH 3/6] x86: clean up _TIF_SYSCALL_EMU handling using ptrace_syscall_enter hook

2019-03-02 Thread Andy Lutomirski
On Thu, Feb 28, 2019 at 10:32 AM Sudeep Holla wrote: > > Now that we have a new hook ptrace_syscall_enter that can be called from > syscall entry code and it handles PTRACE_SYSEMU in generic code, we > can do some cleanup using the same in syscall_trace_enter. > > Further the extra logic to find

Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

2019-01-18 Thread Andy Lutomirski
On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > > - Once we get to 512, we clash with the x32 numbers (unless > > > we remove x32 sup

Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures

2019-01-18 Thread Andy Lutomirski
On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This

Re: pkeys: Reserve PKEY_DISABLE_READ

2018-12-05 Thread Andy Lutomirski
> On Dec 2, 2018, at 8:02 PM, Ram Pai wrote: > >> On Thu, Nov 29, 2018 at 12:37:15PM +0100, Florian Weimer wrote: >> * Dave Hansen: >> On 11/27/18 3:57 AM, Florian Weimer wrote: I would have expected something that translates PKEY_DISABLE_WRITE | PKEY_DISABLE_READ into

Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument

2018-11-21 Thread Andy Lutomirski
their argument. > > This change partially reverts commit 5e937a9ae913 ("syscall_get_arch: > remove useless function arguments"). > Reviewed-by: Andy Lutomirski # for x86

Re: [PATCH] seccomp: Add pkru into seccomp_data

2018-10-25 Thread Andy Lutomirski
> On Oct 25, 2018, at 5:35 PM, Kees Cook wrote: > >> On Fri, Oct 26, 2018 at 12:00 AM, Andy Lutomirski >> wrote: >> You could bite the bullet and add seccomp eBPF support :) > > I'm not convinced this is a good enough reason for gaining

  1   2   >