Re: futex_cmpxchg_enabled breakage

* Rich Felker: > I just spent a number of hours helping someone track down a bug that > looks like it's some kind of futex_cmpxchg_enabled detection error on > powerpc64 (still not sure of the root cause; set_robust_list producing > -ENOSYS), and a while back I hit the same problem on sh2 due to

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/13/2018 09:35 PM, Andy Lutomirski wrote: Somewhat special, yes, but not overly so, and not in the type-polymorphic sense. We can't give direct access of the vDSO implementation to applications because the kernel does not know about the userspace errno variable. We do that for time on

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/13/2018 09:35 PM, Andy Lutomirski wrote: Somewhat special, yes, but not overly so, and not in the type-polymorphic sense. We can't give direct access of the vDSO implementation to applications because the kernel does not know about the userspace errno variable. We do that for time on

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/13/2018 05:22 PM, Andy Lutomirski wrote: On Sep 13, 2018, at 1:07 AM, Florian Weimer wrote: On 09/12/2018 07:11 PM, Andy Lutomirski wrote: The multiplexer interfaces need much more surgery and talking about futex, we'd need to sit down with quite some people and identify the things

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/13/2018 05:22 PM, Andy Lutomirski wrote: On Sep 13, 2018, at 1:07 AM, Florian Weimer wrote: On 09/12/2018 07:11 PM, Andy Lutomirski wrote: The multiplexer interfaces need much more surgery and talking about futex, we'd need to sit down with quite some people and identify the things

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/12/2018 07:11 PM, Andy Lutomirski wrote: The multiplexer interfaces need much more surgery and talking about futex, we'd need to sit down with quite some people and identify the things they actually care about before just splitting it up and keeping the existing overloaded trainwreck the

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/12/2018 07:11 PM, Andy Lutomirski wrote: The multiplexer interfaces need much more surgery and talking about futex, we'd need to sit down with quite some people and identify the things they actually care about before just splitting it up and keeping the existing overloaded trainwreck the

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/12/2018 04:17 PM, Thomas Gleixner wrote: On Wed, 12 Sep 2018, Florian Weimer wrote: On 09/09/2018 10:05 PM, Thomas Gleixner wrote: See the patch below. It's integrating TAI without slowing down everything and it definitely does not result in indirect calls. On a HSW it slows down

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/12/2018 04:17 PM, Thomas Gleixner wrote: On Wed, 12 Sep 2018, Florian Weimer wrote: On 09/09/2018 10:05 PM, Thomas Gleixner wrote: See the patch below. It's integrating TAI without slowing down everything and it definitely does not result in indirect calls. On a HSW it slows down

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/09/2018 10:05 PM, Thomas Gleixner wrote: See the patch below. It's integrating TAI without slowing down everything and it definitely does not result in indirect calls. On a HSW it slows down clock_gettime() by ~0.5ns. On a SKL I get a speedup by ~0.5ns. On a AMD Epyc server it's 1.2ns

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/09/2018 10:05 PM, Thomas Gleixner wrote: See the patch below. It's integrating TAI without slowing down everything and it definitely does not result in indirect calls. On a HSW it slows down clock_gettime() by ~0.5ns. On a SKL I get a speedup by ~0.5ns. On a AMD Epyc server it's 1.2ns

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/01/2018 05:39 AM, Andy Lutomirski wrote: Florian, do you think glibc would be willing to add some magic to turn clock_gettime(CLOCK_MONOTONIC, t) into __vdso_clock_gettime_monotonic(t) when CLOCK_MONOTONIC is a constant? What's the goal here? Turn the indirect call/conditional

Re: [PATCH v3] x86/vdso: Handle clock_gettime(CLOCK_TAI) in vDSO

On 09/01/2018 05:39 AM, Andy Lutomirski wrote: Florian, do you think glibc would be willing to add some magic to turn clock_gettime(CLOCK_MONOTONIC, t) into __vdso_clock_gettime_monotonic(t) when CLOCK_MONOTONIC is a constant? What's the goal here? Turn the indirect call/conditional

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 08/04/2018 01:04 PM, Mikulas Patocka wrote: There's plenty of memcpy's in the graphics stack. No one will be rewriting all the graphics drivers because of tiny market share that ARM has in desktop computers. So if you refuse to fix things and blame everyone else, you can as well announce that

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 08/04/2018 01:04 PM, Mikulas Patocka wrote: There's plenty of memcpy's in the graphics stack. No one will be rewriting all the graphics drivers because of tiny market share that ARM has in desktop computers. So if you refuse to fix things and blame everyone else, you can as well announce that

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 08/03/2018 09:11 AM, Andrew Pinski wrote: Yes fix Links not to use memcpy on the framebuffer. It is undefined behavior to use device memory with memcpy. Some (de facto) ABIs require that it is supported, though. For example, the POWER string functions avoid unaligned loads and stores for

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 08/03/2018 09:11 AM, Andrew Pinski wrote: Yes fix Links not to use memcpy on the framebuffer. It is undefined behavior to use device memory with memcpy. Some (de facto) ABIs require that it is supported, though. For example, the POWER string functions avoid unaligned loads and stores for

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/02/2018 10:46 AM, Yury Norov wrote: Is my understanding correct that glibc community finds inappropriate for their use, and prefer to re-introduce (duplicate) its functionality locally? I think it's wrong. The right way to go is to make kernel headers comfortable for users instead of

Re: [PATCH] Add renameat2 function [BZ #17662]

On 07/02/2018 10:46 AM, Yury Norov wrote: Is my understanding correct that glibc community finds inappropriate for their use, and prefer to re-introduce (duplicate) its functionality locally? I think it's wrong. The right way to go is to make kernel headers comfortable for users instead of

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:46 PM, Mathieu Desnoyers wrote: This would allow registering various TLS data structures with a single system call without hindering flexibility on the user-space side. For instance, we could still use initial-exec and the __rseq_abi symbol for rseq with this approach. Thoughts

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:46 PM, Mathieu Desnoyers wrote: This would allow registering various TLS data structures with a single system call without hindering flexibility on the user-space side. For instance, we could still use initial-exec and the __rseq_abi symbol for rseq with this approach. Thoughts

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote: Another alternative would be to somehow let glibc handle the registration, perhaps only doing it for applications expressing their interest for rseq. That's not really possible. We can't rely on the visibility of symbol bindings due to lazy

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:01 PM, Mathieu Desnoyers wrote: Another alternative would be to somehow let glibc handle the registration, perhaps only doing it for applications expressing their interest for rseq. That's not really possible. We can't rely on the visibility of symbol bindings due to lazy

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 02:27 PM, Pavel Machek wrote: Should we treat it the same way? Always allocate it for each new thread and register it with the kernel? That would be an efficient way to do it, indeed. There is very little performance overhead to have rseq registered for all threads, whether or

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 02:27 PM, Pavel Machek wrote: Should we treat it the same way? Always allocate it for each new thread and register it with the kernel? That would be an efficient way to do it, indeed. There is very little performance overhead to have rseq registered for all threads, whether or

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 04:36 PM, Mathieu Desnoyers wrote: - On Jun 14, 2018, at 10:00 AM, Florian Weimer fwei...@redhat.com wrote: On 06/14/2018 03:49 PM, Pavel Machek wrote: Hi! - rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread flag, so

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 04:36 PM, Mathieu Desnoyers wrote: - On Jun 14, 2018, at 10:00 AM, Florian Weimer fwei...@redhat.com wrote: On 06/14/2018 03:49 PM, Pavel Machek wrote: Hi! - rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread flag, so

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:49 PM, Pavel Machek wrote: Hi! - rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread flag, so rseq_handle_notify_resume() can check whether it's in a rseq critical section when returning to user-space, - rseq_signal_deliver(): on signal

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:49 PM, Pavel Machek wrote: Hi! - rseq_preempt(): on preemption, the scheduler sets the TIF_NOTIFY_RESUME thread flag, so rseq_handle_notify_resume() can check whether it's in a rseq critical section when returning to user-space, - rseq_signal_deliver(): on signal

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:25 PM, Pavel Machek wrote: But the proposal wanted to add a syscall to thread creation, right? And I believe that may be noticeable. We already call set_robust_list, so we could just pass a larger area to that and the kernel could use it. Then no additional system call

Re: Restartable Sequences system call merged into Linux

On 06/14/2018 03:25 PM, Pavel Machek wrote: But the proposal wanted to add a syscall to thread creation, right? And I believe that may be noticeable. We already call set_robust_list, so we could just pass a larger area to that and the kernel could use it. Then no additional system call

Re: Restartable Sequences system call merged into Linux

On 06/12/2018 06:31 PM, Mathieu Desnoyers wrote: - On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote: On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote: - On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote: On 06/11/2018 09:49 PM, Mathieu Desnoyers

Re: Restartable Sequences system call merged into Linux

On 06/12/2018 06:31 PM, Mathieu Desnoyers wrote: - On Jun 12, 2018, at 9:11 AM, Florian Weimer fwei...@redhat.com wrote: On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote: - On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote: On 06/11/2018 09:49 PM, Mathieu Desnoyers

Re: Restartable Sequences system call merged into Linux

On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote: - On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote: On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote: It should be noted that there can be only one rseq TLS area registered per thread, which can then be used by many

Re: Restartable Sequences system call merged into Linux

On 06/11/2018 10:04 PM, Mathieu Desnoyers wrote: - On Jun 11, 2018, at 3:55 PM, Florian Weimer fwei...@redhat.com wrote: On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote: It should be noted that there can be only one rseq TLS area registered per thread, which can then be used by many

Re: Restartable Sequences system call merged into Linux

On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote: It should be noted that there can be only one rseq TLS area registered per thread, which can then be used by many libraries and by the executable, so this is a process-wide (per-thread) resource that we need to manage carefully. Is it possible

Re: Restartable Sequences system call merged into Linux

On 06/11/2018 09:49 PM, Mathieu Desnoyers wrote: It should be noted that there can be only one rseq TLS area registered per thread, which can then be used by many libraries and by the executable, so this is a process-wide (per-thread) resource that we need to manage carefully. Is it possible

Re: kselftest archives etc.

On 04/28/2018 02:17 AM, Randy Dunlap wrote: (2) for this patch:http://www.spinics.net/lists/linux-kselftest/msg03136.html [PATCH] selftests/x86: Detect -no-pie availability Acked-by: Randy Dunlap Tested-by: Randy Dunlap What is the status of this

Re: kselftest archives etc.

On 04/28/2018 02:17 AM, Randy Dunlap wrote: (2) for this patch:http://www.spinics.net/lists/linux-kselftest/msg03136.html [PATCH] selftests/x86: Detect -no-pie availability Acked-by: Randy Dunlap Tested-by: Randy Dunlap What is the status of this patch? Yours is the first reaction to it.

sendmmsg flags userspace ABI change in kernel 4.6

Since this commit: commit 28a94d8fb35b3a75b802f368ae6f4a9f6b0d435a Author: Tom Herbert Date: Mon Mar 7 14:11:02 2016 -0800 net: Allow MSG_EOR in each msghdr of sendmmsg This patch allows setting MSG_EOR in each individual msghdr passed in sendmmsg. This

sendmmsg flags userspace ABI change in kernel 4.6

Since this commit: commit 28a94d8fb35b3a75b802f368ae6f4a9f6b0d435a Author: Tom Herbert Date: Mon Mar 7 14:11:02 2016 -0800 net: Allow MSG_EOR in each msghdr of sendmmsg This patch allows setting MSG_EOR in each individual msghdr passed in sendmmsg. This allows a sendmmsg to send

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 06:29 PM, Linus Torvalds wrote: Gcc people are crazy. End of discussion from me. This is not acceptable. Florian

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 06:29 PM, Linus Torvalds wrote: Gcc people are crazy. End of discussion from me. This is not acceptable. Florian

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 05:25 AM, Kees Cook wrote: In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On 03/16/2018 05:25 AM, Kees Cook wrote: In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/14/2018 09:00 AM, Florian Weimer wrote: On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/14/2018 09:00 AM, Florian Weimer wrote: On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:00 PM, Ram Pai wrote: On Fri, Mar 09, 2018 at 12:04:49PM +0100, Florian Weimer wrote: On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior. mprotect without a key does not necessarily use key 0, e.g. if protection keys are used to emulate page

Re: [PATCH] x86, powerpc : pkey-mprotect must allow pkey-0

On 03/09/2018 09:12 AM, Ram Pai wrote: Once an address range is associated with an allocated pkey, it cannot be reverted back to key-0. There is no valid reason for the above behavior. mprotect without a key does not necessarily use key 0, e.g. if protection keys are used to emulate page

Re: Removing architectures without upstream gcc support

On 02/23/2018 12:37 PM, Arnd Bergmann wrote: That makes more sense, yes. I'm still unsure about this one though. Chris in fact made the suggestion to remove the architecture from both glibc and kernel as with his departure from Mellanox there is nobody left from to maintain it. I suggested

Re: Removing architectures without upstream gcc support

On 02/23/2018 12:37 PM, Arnd Bergmann wrote: That makes more sense, yes. I'm still unsure about this one though. Chris in fact made the suggestion to remove the architecture from both glibc and kernel as with his departure from Mellanox there is nobody left from to maintain it. I suggested

Re: [PATCH 4/6] s390: add system call to run tasks with modified branch prediction

On 01/17/2018 10:48 AM, Martin Schwidefsky wrote: rc = syscall(__NR_s390_modify_bp); if (rc) { perror("s390_modify_bp"); exit(EXIT_FAILURE); } Isn't this traditionally done through personality or prctl? This looks like something

Re: [PATCH 4/6] s390: add system call to run tasks with modified branch prediction

On 01/17/2018 10:48 AM, Martin Schwidefsky wrote: rc = syscall(__NR_s390_modify_bp); if (rc) { perror("s390_modify_bp"); exit(EXIT_FAILURE); } Isn't this traditionally done through personality or prctl? This looks like something

Re: [PATCH 0/7] IBRS patch series

* Linus Torvalds: > On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen wrote: >> >> Speculation on Skylake and later requires these patches ("dynamic IBRS") >> be used instead of retpoline[1]. > > Can somebody explain this part? > > I was assuming that retpoline would work

Re: [PATCH 0/7] IBRS patch series

* Linus Torvalds: > On Thu, Jan 4, 2018 at 9:56 AM, Tim Chen wrote: >> >> Speculation on Skylake and later requires these patches ("dynamic IBRS") >> be used instead of retpoline[1]. > > Can somebody explain this part? > > I was assuming that retpoline would work around this issue on all uarchs.

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/08/2017 03:27 PM, Pavel Machek wrote: On Fri 2017-12-08 22:08:07, Michael Ellerman wrote: If we had a time machine, the right set of flags would be: - MAP_FIXED: don't treat addr as a hint, fail if addr is not free - MAP_REPLACE: replace an existing mapping (or force or clobber)

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/08/2017 03:27 PM, Pavel Machek wrote: On Fri 2017-12-08 22:08:07, Michael Ellerman wrote: If we had a time machine, the right set of flags would be: - MAP_FIXED: don't treat addr as a hint, fail if addr is not free - MAP_REPLACE: replace an existing mapping (or force or clobber)

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/06/2017 09:06 AM, John Hubbard wrote: On 12/05/2017 11:35 PM, Florian Weimer wrote: On 12/06/2017 08:33 AM, John Hubbard wrote: In that case, maybe: MAP_EXACT ? ...because that's the characteristic behavior. Is that true?  mmap still silently rounding up the length to the page

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/06/2017 09:06 AM, John Hubbard wrote: On 12/05/2017 11:35 PM, Florian Weimer wrote: On 12/06/2017 08:33 AM, John Hubbard wrote: In that case, maybe: MAP_EXACT ? ...because that's the characteristic behavior. Is that true?  mmap still silently rounding up the length to the page

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/06/2017 08:33 AM, John Hubbard wrote: In that case, maybe: MAP_EXACT ? ...because that's the characteristic behavior. Is that true? mmap still silently rounding up the length to the page size, I assume, so even that name is misleading. Thanks, Florian

Re: [PATCH 0/2] mm: introduce MAP_FIXED_SAFE

On 12/06/2017 08:33 AM, John Hubbard wrote: In that case, maybe: MAP_EXACT ? ...because that's the characteristic behavior. Is that true? mmap still silently rounding up the length to the page size, I assume, so even that name is misleading. Thanks, Florian

Re: [RFC] a question about stack size form /proc/pid/task/child pid/limits

On 09/06/2017 04:14 AM, Xishi Qiu wrote: Hi, I find if I use a defined stack size to create a child thread, then the max stack size from /proc/pid/task/child pid/limits still shows "Max stack size8388608", it doesn't update to the user defined size, is it a problem? This reflects

Re: [RFC] a question about stack size form /proc/pid/task/child pid/limits

On 09/06/2017 04:14 AM, Xishi Qiu wrote: Hi, I find if I use a defined stack size to create a child thread, then the max stack size from /proc/pid/task/child pid/limits still shows "Max stack size8388608", it doesn't update to the user defined size, is it a problem? This reflects

Re: [PATCH] VFS: use synchronize_rcu_expedited() in namespace_unlock()

On 10/26/2017 02:27 PM, Paul E. McKenney wrote: But just for completeness, one way to make this work across the board might be to instead use call_rcu(), with the callback function kicking off a workqueue handler to do the rest of the unmount. Of course, in saying that, I am ignoring any

Re: [PATCH] VFS: use synchronize_rcu_expedited() in namespace_unlock()

On 10/26/2017 02:27 PM, Paul E. McKenney wrote: But just for completeness, one way to make this work across the board might be to instead use call_rcu(), with the callback function kicking off a workqueue handler to do the rest of the unmount. Of course, in saying that, I am ignoring any

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/20/2017 10:33 AM, Michal Hocko wrote: On Mon 20-11-17 10:10:32, Florian Weimer wrote: On 11/20/2017 09:55 AM, Michal Hocko wrote: On Fri 17-11-17 08:30:48, Florian Weimer wrote: On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + st

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/20/2017 10:33 AM, Michal Hocko wrote: On Mon 20-11-17 10:10:32, Florian Weimer wrote: On 11/20/2017 09:55 AM, Michal Hocko wrote: On Fri 17-11-17 08:30:48, Florian Weimer wrote: On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + st

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/20/2017 09:55 AM, Michal Hocko wrote: On Fri 17-11-17 08:30:48, Florian Weimer wrote: On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + struct vm_area_struct *vma = find_vma(mm, addr); + + if (vma && vma->v

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/20/2017 09:55 AM, Michal Hocko wrote: On Fri 17-11-17 08:30:48, Florian Weimer wrote: On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + struct vm_area_struct *vma = find_vma(mm, addr); + + if (vma && vma->v

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + struct vm_area_struct *vma = find_vma(mm, addr); + + if (vma && vma->vm_start <= addr) + return -ENOMEM; + } Could you pick a different error code which

Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE

On 11/16/2017 11:18 AM, Michal Hocko wrote: + if (flags & MAP_FIXED_SAFE) { + struct vm_area_struct *vma = find_vma(mm, addr); + + if (vma && vma->vm_start <= addr) + return -ENOMEM; + } Could you pick a different error code which

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/08/2017 07:08 AM, Michael Ellerman wrote: "Kirill A. Shutemov" <kir...@shutemov.name> writes: On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/08/2017 07:08 AM, Michael Ellerman wrote: "Kirill A. Shutemov" writes: On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: On 11/07/2017 12:15

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 06:07 AM, Nicholas Piggin wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 06:07 AM, Nicholas Piggin wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

* Ram Pai: > On Mon, Nov 06, 2017 at 10:28:41PM +0100, Florian Weimer wrote: >> * Ram Pai: >> >> > Testing: >> > --- >> > This patch series has passed all the protection key >> > tests available in the selftest directory.The >

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

* Ram Pai: > On Mon, Nov 06, 2017 at 10:28:41PM +0100, Florian Weimer wrote: >> * Ram Pai: >> >> > Testing: >> > --- >> > This patch series has passed all the protection key >> > tests available in the selftest directory.The >

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

* Ram Pai: > Testing: > --- > This patch series has passed all the protection key > tests available in the selftest directory.The > tests are updated to work on both x86 and powerpc. > The selftests have passed on x86 and powerpc hardware. How do you deal with the key reuse problem? Is it

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

* Ram Pai: > Testing: > --- > This patch series has passed all the protection key > tests available in the selftest directory.The > tests are updated to work on both x86 and powerpc. > The selftests have passed on x86 and powerpc hardware. How do you deal with the key reuse problem? Is it

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

* Mathieu Desnoyers: > Speaking of optimization, I think the rseq.c helper library > (and eventually glibc) should define the __rseq_abi TLS > variable with __attribute__((tls_model("initial-exec"))). > It provides faster, and signal-safe, accesses to the TLS > variable from libraries. > > The

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

* Mathieu Desnoyers: > Speaking of optimization, I think the rseq.c helper library > (and eventually glibc) should define the __rseq_abi TLS > variable with __attribute__((tls_model("initial-exec"))). > It provides faster, and signal-safe, accesses to the TLS > variable from libraries. > > The

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 07:24 PM, Andy Lutomirski wrote: On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote: - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed AB

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 07:24 PM, Andy Lutomirski wrote: On Fri, Oct 13, 2017 at 7:27 AM, Mathieu Desnoyers wrote: - On Oct 13, 2017, at 9:56 AM, Florian Weimer fwei...@redhat.com wrote: On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not require to store any function

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not require to store any function pointer. For a given rseq_finish() critical section, pointers to specific instructions (within a function) are emitted at link-time into a struct rseq_cs: struct rseq_cs {

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 03:40 PM, Mathieu Desnoyers wrote: The proposed ABI does not require to store any function pointer. For a given rseq_finish() critical section, pointers to specific instructions (within a function) are emitted at link-time into a struct rseq_cs: struct rseq_cs {

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: Expose a new system call allowing each thread to register one userspace memory area to be used as an ABI between kernel and user-space for two purposes: user-space restartable sequences and quick access to read the current CPU number value from

Re: [RFC PATCH v9 for 4.15 01/14] Restartable sequences system call

On 10/13/2017 01:03 AM, Mathieu Desnoyers wrote: Expose a new system call allowing each thread to register one userspace memory area to be used as an ABI between kernel and user-space for two purposes: user-space restartable sequences and quick access to read the current CPU number value from

Re: Draft manpage explaining kernel lockdown

On 10/05/2017 01:00 PM, David Howells wrote: Lockdown is typically enabled during boot and may be terminated, if configured, by typing a special key combination on a directly attached physical keyboard. Does this include a Bluetooth keyboard (which might not actually exist and might in

Re: Draft manpage explaining kernel lockdown

On 10/05/2017 01:00 PM, David Howells wrote: Lockdown is typically enabled during boot and may be terminated, if configured, by typing a special key combination on a directly attached physical keyboard. Does this include a Bluetooth keyboard (which might not actually exist and might in

Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

On 10/02/2017 11:54 AM, Konstantin Khlebnikov wrote: This patch implements write-behind policy which tracks sequential writes and starts background writeback when have enough dirty pages in a row. Does this apply to data for files which have never been written to disk before? I think one of

Re: [PATCH RFC] mm: implement write-behind policy for sequential file writes

On 10/02/2017 11:54 AM, Konstantin Khlebnikov wrote: This patch implements write-behind policy which tracks sequential writes and starts background writeback when have enough dirty pages in a row. Does this apply to data for files which have never been written to disk before? I think one of

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/25/2017 04:52 PM, Michal Hocko wrote: On Mon 25-09-17 15:16:09, Florian Weimer wrote: On 09/25/2017 02:52 PM, Michal Hocko wrote: So, how are you going to deal with the CoW and the implementation which basically means that the newm mmap content is not the same as the original one? I

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/25/2017 04:52 PM, Michal Hocko wrote: On Mon 25-09-17 15:16:09, Florian Weimer wrote: On 09/25/2017 02:52 PM, Michal Hocko wrote: So, how are you going to deal with the CoW and the implementation which basically means that the newm mmap content is not the same as the original one? I

Re: [patch] mremap.2: Add description of old_size == 0 functionality

On 09/25/2017 02:52 PM, Michal Hocko wrote: So, how are you going to deal with the CoW and the implementation which basically means that the newm mmap content is not the same as the original one? I don't understand why CoW would kick in. The approach I outlined is desirable because it avoids

<    1   2   3   4   5   6   7   >