unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Andy Lutomirski
AMA Capital Management, LLC
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
I broke them in this commit:
commit 1be374a0518a288147c6a7398792583200a67261
Author: Andy Lutomirski
Date: Wed May 22 14:07:44 2013 -0700
net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
On Thu, Jun 25, 2015 at 7:16 AM, Eric B Munson wrote:
> On Tue, 23 Jun 2015, Vlastimil Babka wrote:
>
>> On 06/15/2015 04:43 PM, Eric B Munson wrote:
>> >>
>> >>If the new LOCKONFAULT functionality is indeed desired (I haven't
>> >>still decided myself) then I agree that would be the cleanest way.
Signed-off-by: Andy Lutomirski
---
arch/arm64/include/asm/page.h | 3 ---
arch/arm64/kernel/vdso.c | 19 ---
arch/ia64/include/asm/page.h | 2 ++
arch/ia64/mm/init.c| 26 ++
arch/powerpc/include/asm/page.h| 3 ---
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: linux...@kvack.org
Signed-off-by: Andy Lutomirski
---
arch/arm64/include/asm/page.h | 3 ---
arch/arm64/kernel/vdso.c | 19 ---
arch/ia64/include/asm/page.h | 2 ++
arch/ia64/mm/init.c| 26 +
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: linux...@kvack.org
Signed-off-by: Andy Lutomirski
---
It would be nice to get this into some tree that's in -next and that
people can base on.
Changes from v1 and v2: Nothing except Will Deacon's ack and splitting
this out from the la
On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski wrote:
> The core mm code will provide a default gate area based on
> FIXADDR_USER_START and FIXADDR_USER_END if
> !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
>
> This default is only useful for ia64. arm
On Jul 18, 2014 3:20 AM, "Richard Weinberger" wrote:
>
> Am 18.07.2014 12:14, schrieb Will Deacon:
> > On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
> >> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski
wrote:
> >>> The core mm cod
arm64]
For convenience, I've attached the patch w/ the acked-by's folded in
and with no other changes.
Thanks,
Andy
On Fri, Jul 18, 2014 at 9:53 AM, Andy Lutomirski wrote:
>
> On Jul 18, 2014 3:20 AM, "Richard Weinberger" wrote:
>>
>> Am 18.07.2014 12:14, sch
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: linux...@kvack.org
Acked-by: Nathan Lynch
Acked-by: H. Peter Anvin
Acked-by: Benjamin Herrenschmidt [in principle]
Acked-by: Richard Weinberger [for um]
Acked-by: Will Deacon [for arm64]
Signed-off-by: Andy Lutomirski
---
Changes from v3: Fix ia64 build (I was
I'm running a Fedora distro kernel (3.13.7-200.fc20.x86_64) in kvm
with these options:
-chardev null,id=hvc0,signal=off
-device virtio-serial-pci
-device virtconsole,chardev=hvc0,name=virtme_console
-append console=hvc0 console=ttyS0
-nographic
(There are more, but these are the interesting ones,
On Mon, Mar 31, 2014 at 3:31 PM, Andy Lutomirski wrote:
> I'm running a Fedora distro kernel (3.13.7-200.fc20.x86_64) in kvm
> with these options:
>
> -chardev null,id=hvc0,signal=off
> -device virtio-serial-pci
> -device virtconsole,chardev=hvc0,name=virtme_console
> -a
On 04/28/2016 08:18 AM, Christopher Covington wrote:
> Please take a look at the following prototype of sharing the PowerPC
> VDSO unmap and remap code with other architectures. I've only hooked
> up arm64 to begin with. If folks think this is a reasonable approach I
> can work on 32 bit ARM as wel
On Wed, Nov 4, 2015 at 4:50 PM, Amanieu d'Antras wrote:
> One issue that isn't resolved in this series is sending signals between a
> 32-bit
> process and 64-bit process. Sending a si_int will work correctly, but a si_ptr
> value will likely get corrupted due to the different layouts of the 32-bi
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 s
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 +00
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
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 mat
> On Oct 5, 2018, at 7:14 AM, Peter Zijlstra wrote:
>
>> On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote:
>> diff --git a/include/linux/ffp.h b/include/linux/ffp.h
>> new file mode 100644
>> index ..8fc3b4c9b38f
>> --- /dev/null
>> +++ b/include/linux/ffp.h
>> @@ -0,
On Fri, Oct 5, 2018 at 8:24 AM Ard Biesheuvel wrote:
>
> On 5 October 2018 at 17:08, Andy Lutomirski wrote:
> >
> >
> >> On Oct 5, 2018, at 7:14 AM, Peter Zijlstra wrote:
> >>
> >>> On Fri, Oct 05, 2018 at 10:13:25AM +0200, Ard Biesheuvel wrote:
On Fri, Oct 5, 2018 at 10:11 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 18:58, Andy Lutomirski wrote:
> > On Fri, Oct 5, 2018 at 8:24 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 5 October 2018 at 17:08, Andy Lutomirski wrote:
> >> >
On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 15:37, Jason A. Donenfeld wrote:
> ...
> > Therefore, I think this patch goes in exactly the wrong direction. I
> > mean, if you want to introduce dynamic patching as a means for making
> > the crypto API's dynamic dis
On Fri, Oct 5, 2018 at 10:23 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 19:20, Andy Lutomirski wrote:
> > On Fri, Oct 5, 2018 at 10:11 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 5 October 2018 at 18:58, Andy Lutomirski wrote:
> >> &g
On Fri, Oct 5, 2018 at 10:38 AM Jason A. Donenfeld wrote:
>
> On Fri, Oct 5, 2018 at 7:29 PM Andy Lutomirski wrote:
> > (None of this is to say that I disagree with Jason, though -- I'm not
> > entirely convinced that this makes sense for Zinc. But maybe it can
> >
On Fri, Oct 5, 2018 at 10:28 AM Ard Biesheuvel
wrote:
>
> On 5 October 2018 at 19:26, Andy Lutomirski wrote:
> > On Fri, Oct 5, 2018 at 10:15 AM Ard Biesheuvel
> > wrote:
> >>
> >> On 5 October 2018 at 15:37, Jason A. Donenfeld wrote:
> >> ...
On Thu, Oct 25, 2018 at 9:42 AM Michael Sammler wrote:
>
> On 10/25/2018 11:12 AM, Florian Weimer wrote:
> >> I understand your concern about exposing the number of protection keys
> >> in the ABI. One idea would be to state, that the pkru field (which
> >> should probably be renamed) contains an
> 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 the eBPF
&g
their argument.
>
> This change partially reverts commit 5e937a9ae913 ("syscall_get_arch:
> remove useless function arguments").
>
Reviewed-by: Andy Lutomirski # for x86
> 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 PKEY_DISABLE_
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 mappings.
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 g
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 suppor
On Tue, Jul 3, 2018 at 4:34 PM, Laura Abbott wrote:
>
> The vDSO needs to have a unique build id in a similar manner
> to the kernel and modules. Use the build salt macro.
>
Looks good to me. I have no idea whose tree these would go through.
> Signed-off-by: Laura Abbott
> ---
> v5: Switched t
Sure.
On Thu, Jul 5, 2018 at 12:08 PM, Laura Abbott wrote:
> On 07/05/2018 08:58 AM, Andy Lutomirski wrote:
>>
>> On Tue, Jul 3, 2018 at 4:34 PM, Laura Abbott wrote:
>>>
>>>
>>> The vDSO needs to have a unique build id in a similar manner
>>>
On Thu, Jul 19, 2018 at 9:45 AM, Andy Lutomirski wrote:
> [I added PeterZ and Vitaly -- can you see any way in which this would
> break something obscure? I don't.]
>
> On Thu, Jul 19, 2018 at 7:14 AM, Rik van Riel wrote:
>> I guess we can skip both switch_ldt and l
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
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
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.
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 syscall'
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 fu
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 cal
> 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
> 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
> 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
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
> 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
>>>
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 considering
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
>
> Pleas
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
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
> __cvdso_clock_gettime(cl
> 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 differen
> 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 _another
> 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
On Mon, Jun 26, 2023, at 10:48 AM, Song Liu wrote:
> On Mon, Jun 26, 2023 at 5:31 AM Mark Rutland wrote:
>>
> [...]
>> >
>> > So the idea was that jit_text_alloc() will have a cache of large pages
>> > mapped ROX, will allocate memory from those caches and there will be
>> > jit_update() that u
On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> module_alloc() is used everywhere as a mean to allocate memory for code.
>
> Beside being semantically wrong, this unnecessarily ties all subsystems
> that need to allocate code, such as ftrace, kprobes and BP
On Sun, Jun 18, 2023, at 1:00 AM, Mike Rapoport wrote:
> On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote:
>> On Fri, Jun 16, 2023, at 1:50 AM, Mike Rapoport wrote:
>> > From: "Mike Rapoport (IBM)"
>> >
>> > module_alloc() is used ev
On Mon, Jun 19, 2023, at 1:18 PM, Nadav Amit wrote:
>> On Jun 19, 2023, at 10:09 AM, Andy Lutomirski wrote:
>>
>> But jit_text_alloc() can't do this, because the order of operations doesn't
>> match. With jit_text_alloc(), the executable mapping shows up be
On Sun, Jun 25, 2023, at 9:14 AM, Mike Rapoport wrote:
> On Mon, Jun 19, 2023 at 10:09:02AM -0700, Andy Lutomirski wrote:
>>
>> On Sun, Jun 18, 2023, at 1:00 AM, Mike Rapoport wrote:
>> > On Sat, Jun 17, 2023 at 01:38:29PM -0700, Andy Lutomirski wrote:
>> >&
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
> >>
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
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...
> 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
> 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?
> 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:
&
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
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) how m
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 in_compat_s
If you'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
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
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
> 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
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
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 t
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. Currentl
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 architectu
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
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 behin
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
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 switc
> 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
> 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 Lutom
> 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:
Excerpts
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
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 core
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
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 |
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 swit
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
> &
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,
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.gma
> 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 basic
@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 28, 2020 at 8:02 AM Nicholas Piggin wrote:
>>>>>
>&
us the scheduler code provides the barriers
that membarrier 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 cor
tch as is. That
being said, getting rid of the active_mm refcounting shouldn't be
so hard, since x86 (in this 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
> 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 k
> 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 b
ly me) needs to make
sure we don't need 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 membarrie
d it's 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 Lutomirsk
mask() 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/fo
> 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:
>>
>>
1 - 100 of 186 matches
Mail list logo
