* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
On 03/16/2018 06:29 PM, Linus Torvalds wrote:
Gcc people are crazy.
End of discussion from me. This is not acceptable.
Florian
On 03/16/2018 06:29 PM, Linus Torvalds wrote:
Gcc people are crazy.
End of discussion from me. This is not acceptable.
Florian
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
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
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
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
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
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
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
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
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
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
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
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
* 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
* 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.
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
>
* 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
>
* 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
* 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
* 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
* 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
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
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
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 {
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 {
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
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
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
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
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
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
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
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
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
301 - 400 of 698 matches
Mail list logo