Commit-ID: e96d71359e9bbea846a2111e4469a03a055dfa6f
Gitweb: https://git.kernel.org/tip/e96d71359e9bbea846a2111e4469a03a055dfa6f
Author: Mathieu Desnoyers
AuthorDate: Mon, 9 Jul 2018 15:51:50 -0400
Committer: Thomas Gleixner
CommitDate: Tue, 10 Jul 2018 22:18:51 +0200
rseq: Use __u64
Commit-ID: e96d71359e9bbea846a2111e4469a03a055dfa6f
Gitweb: https://git.kernel.org/tip/e96d71359e9bbea846a2111e4469a03a055dfa6f
Author: Mathieu Desnoyers
AuthorDate: Mon, 9 Jul 2018 15:51:50 -0400
Committer: Thomas Gleixner
CommitDate: Tue, 10 Jul 2018 22:18:51 +0200
rseq: Use __u64
Commit-ID: 8f28177014925f968baf45fc833c25848faf8c1c
Gitweb: https://git.kernel.org/tip/8f28177014925f968baf45fc833c25848faf8c1c
Author: Mathieu Desnoyers
AuthorDate: Mon, 9 Jul 2018 15:51:51 -0400
Committer: Thomas Gleixner
CommitDate: Tue, 10 Jul 2018 22:18:52 +0200
rseq: Use
Commit-ID: 8f28177014925f968baf45fc833c25848faf8c1c
Gitweb: https://git.kernel.org/tip/8f28177014925f968baf45fc833c25848faf8c1c
Author: Mathieu Desnoyers
AuthorDate: Mon, 9 Jul 2018 15:51:51 -0400
Committer: Thomas Gleixner
CommitDate: Tue, 10 Jul 2018 22:18:52 +0200
rseq: Use
- On Jul 10, 2018, at 10:49 AM, Will Deacon will.dea...@arm.com wrote:
> On Mon, Jul 09, 2018 at 01:17:54PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 9, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
>>
>> > On Mon, Jul 09, 2018 at 12:06:22PM -0400,
- On Jul 10, 2018, at 10:49 AM, Will Deacon will.dea...@arm.com wrote:
> On Mon, Jul 09, 2018 at 01:17:54PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 9, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
>>
>> > On Mon, Jul 09, 2018 at 12:06:22PM -0400,
- On Jul 10, 2018, at 2:16 AM, Michael Ellerman m...@ellerman.id.au wrote:
> Mathieu Desnoyers writes:
>> - On Jul 8, 2018, at 5:03 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> In preparation to use __u64 for the rseq_cs pointer f
- On Jul 10, 2018, at 2:16 AM, Michael Ellerman m...@ellerman.id.au wrote:
> Mathieu Desnoyers writes:
>> - On Jul 8, 2018, at 5:03 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>> In preparation to use __u64 for the rseq_cs pointer f
in benchmarks, the proper approach would be to
use user_access_begin() / unsafe_{get,put}_user() / user_access_end()
anyway.
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
Cc: Joel Fernandes
Cc: Peter Zijlstra
Cc: Catalin Marinas
Cc: Dave Watson
Cc: Will Deacon
Cc: Andi Kleen
Cc: &q
in benchmarks, the proper approach would be to
use user_access_begin() / unsafe_{get,put}_user() / user_access_end()
anyway.
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
Cc: Joel Fernandes
Cc: Peter Zijlstra
Cc: Catalin Marinas
Cc: Dave Watson
Cc: Will Deacon
Cc: Andi Kleen
Cc: &q
does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC:
flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC:
rseq as it was merged does not have rseq_finish_*() in the user-space
selftests anymore. Update the rseq_prepare_unload() helper comment to
adapt to this reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
rseq as it was merged does not have rseq_finish_*() in the user-space
selftests anymore. Update the rseq_prepare_unload() helper comment to
adapt to this reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
This header was introduced in the 4.18 merge window, and rseq does
not need it anymore. Nuke it before the final release.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave
This header was introduced in the 4.18 merge window, and rseq does
not need it anymore. Nuke it before the final release.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave
ing that the rseq_cs pointer does not need to
be loaded/stored with single-copy atomicity from the kernel anymore, we
can simply use copy_from_user()/clear_user().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy L
]
https://lkml.kernel.org/r/20180702223143.4663-1-mathieu.desnoy...@efficios.com
Mathieu Desnoyers (6):
rseq: use __u64 for rseq_cs fields, validate user inputs
rseq: use get_user/put_user rather than __get_user/__put_user
rseq: uapi: update uapi comments
rseq: uapi: declare rseq_cs field
ing that the rseq_cs pointer does not need to
be loaded/stored with single-copy atomicity from the kernel anymore, we
can simply use copy_from_user()/clear_user().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy L
]
https://lkml.kernel.org/r/20180702223143.4663-1-mathieu.desnoy...@efficios.com
Mathieu Desnoyers (6):
rseq: use __u64 for rseq_cs fields, validate user inputs
rseq: use get_user/put_user rather than __get_user/__put_user
rseq: uapi: update uapi comments
rseq: uapi: declare rseq_cs field
- On Jul 9, 2018, at 2:04 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Jul 9, 2018 at 10:28 AM Mathieu Desnoyers
> wrote:
>>
>> So, another twist to this story: ppc32 does not implement u64 get_user().
>
> I was going to say that "t
- On Jul 9, 2018, at 2:04 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Jul 9, 2018 at 10:28 AM Mathieu Desnoyers
> wrote:
>>
>> So, another twist to this story: ppc32 does not implement u64 get_user().
>
> I was going to say that "t
- On Jul 8, 2018, at 5:03 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Following the recent discussion thread [1] about rseq uapi, here is
> a set of updates submitted for integration into 4.18. Those change all
> rseq __get_user/__put_user for get_user/put_user as
- On Jul 8, 2018, at 5:03 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Following the recent discussion thread [1] about rseq uapi, here is
> a set of updates submitted for integration into 4.18. Those change all
> rseq __get_user/__put_user for get_user/put_user as
- On Jul 8, 2018, at 5:03 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> In preparation to use __u64 for the rseq_cs pointer field, 32-bit
> architectures need to read this 64-bit value located in user-space
> addresses.
>
> __get_user is used to read th
- On Jul 8, 2018, at 5:03 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> In preparation to use __u64 for the rseq_cs pointer field, 32-bit
> architectures need to read this 64-bit value located in user-space
> addresses.
>
> __get_user is used to read th
- On Jul 9, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
> On Mon, Jul 09, 2018 at 12:06:22PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 9, 2018, at 10:19 AM, Will Deacon will.dea...@arm.com wrote:
>>
>> > Hello,
>> >
>> > Thi
- On Jul 9, 2018, at 12:53 PM, Will Deacon will.dea...@arm.com wrote:
> On Mon, Jul 09, 2018 at 12:06:22PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 9, 2018, at 10:19 AM, Will Deacon will.dea...@arm.com wrote:
>>
>> > Hello,
>> >
>> > Thi
Move abort handler in-line to avoid possibility of it being
>out-of-range for conditional branch instructions
>
> I've tested both native and compat (little-endian only) with the selftests
> and they pass successfully on my Seattle box.
For the whole series:
Acked-by: Mathieu De
Move abort handler in-line to avoid possibility of it being
>out-of-range for conditional branch instructions
>
> I've tested both native and compat (little-endian only) with the selftests
> and they pass successfully on my Seattle box.
For the whole series:
Acked-by: Mathieu De
This header was introduced in the 4.18 merge window, and rseq does
not need it anymore. Nuke it before the final release.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave
This header was introduced in the 4.18 merge window, and rseq does
not need it anymore. Nuke it before the final release.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave
ays be included for both kernel and
user-space code: including stdint.h is just for u64 and u32, which are
not used in this header at all.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC
ays be included for both kernel and
user-space code: including stdint.h is just for u64 and u32, which are
not used in this header at all.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC
...@efficios.com
Mathieu Desnoyers (6):
rseq: use __u64 for rseq_cs fields, validate user inputs
rseq: use get_user/put_user rather than __get_user/__put_user
rseq: uapi: update uapi comments
rseq: uapi: declare rseq_cs field as union, update includes
rseq: remove unused types_32_64.h uapi header
...@efficios.com
Mathieu Desnoyers (6):
rseq: use __u64 for rseq_cs fields, validate user inputs
rseq: use get_user/put_user rather than __get_user/__put_user
rseq: uapi: update uapi comments
rseq: uapi: declare rseq_cs field as union, update includes
rseq: remove unused types_32_64.h uapi header
rseq as it was merged does not have rseq_finish_*() in the user-space
selftests anymore. Update the rseq_prepare_unload() helper comment to
adapt to this reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC:
rseq as it was merged does not have rseq_finish_*() in the user-space
selftests anymore. Update the rseq_prepare_unload() helper comment to
adapt to this reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC:
does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
not implement 8-byte __get_user. Rather than trying to
improve __get_user on ARM, use get_user/put_user across rseq instead.
If those end up showing up in benchmarks, the proper approach would be to
use user_access_begin() / unsafe_get/put_user() / user_access_end()
anyway.
Signed-off-by: Mathieu Desnoyers
not implement 8-byte __get_user. Rather than trying to
improve __get_user on ARM, use get_user/put_user across rseq instead.
If those end up showing up in benchmarks, the proper approach would be to
use user_access_begin() / unsafe_get/put_user() / user_access_end()
anyway.
Signed-off-by: Mathieu Desnoyers
ser-space, so it would "work".
But the guarantees provided by membarrier are not to synchronize against
preempt off per se. It's just that the current implementation happens to
do that. The point of membarrier is to turn user-space memory barriers
into compiler barriers.
If what you need is to wait for a RCU grace period for whatever RCU flavor
ebpf is using, I would against using membarrier for this. I would rather
recommend adding a dedicated BPF_SYNCHRONIZE so you won't leak
implementation details to user-space, *and* you can eventually change you
RCU implementation for e.g. SRCU in the future if needed.
Thanks,
Mathieu
>
> thanks!
>
> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ser-space, so it would "work".
But the guarantees provided by membarrier are not to synchronize against
preempt off per se. It's just that the current implementation happens to
do that. The point of membarrier is to turn user-space memory barriers
into compiler barriers.
If what you need is to wait for a RCU grace period for whatever RCU flavor
ebpf is using, I would against using membarrier for this. I would rather
recommend adding a dedicated BPF_SYNCHRONIZE so you won't leak
implementation details to user-space, *and* you can eventually change you
RCU implementation for e.g. SRCU in the future if needed.
Thanks,
Mathieu
>
> thanks!
>
> - Joel
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 6, 2018, at 3:35 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
> wrote:
>
>> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
>> wrote:
>>>
>>&g
- On Jul 6, 2018, at 3:35 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
> wrote:
>
>> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
>> wrote:
>>>
>>&g
- On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
> wrote:
>>
>> For -rc, I would favor the following simpler approach. Or I could even
>> just use get_user() instead. Thought
- On Jul 6, 2018, at 3:31 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Jul 6, 2018 at 12:23 PM Mathieu Desnoyers
> wrote:
>>
>> For -rc, I would favor the following simpler approach. Or I could even
>> just use get_user() instead. Thought
- On Jul 6, 2018, at 1:09 PM, Marc Zyngier marc.zyng...@arm.com wrote:
> On 06/07/18 18:04, Will Deacon wrote:
>> Hi Mathieu,
>>
>> On Fri, Jul 06, 2018 at 12:59:22PM -0400, Mathieu Desnoyers wrote:
>>> The 4.18-rc3 arm32 kernel defconfig fails to boot on
- On Jul 6, 2018, at 1:09 PM, Marc Zyngier marc.zyng...@arm.com wrote:
> On 06/07/18 18:04, Will Deacon wrote:
>> Hi Mathieu,
>>
>> On Fri, Jul 06, 2018 at 12:59:22PM -0400, Mathieu Desnoyers wrote:
>>> The 4.18-rc3 arm32 kernel defconfig fails to boot on
- On Jul 6, 2018, at 12:02 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
[...]
> The 0-day bot noticed that __get_user() is unimplemented for 64-bit
> values on
- On Jul 6, 2018, at 12:02 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
[...]
> The 0-day bot noticed that __get_user() is unimplemented for 64-bit
> values on
you have other approaches in mind ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
you have other approaches in mind ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[ 86.219861] [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
59.89 [ 86.227425] [] (cpu_startup_entry) from [] (start_kernel+0x44c/0x460)
59.90 [ 86.235592] [] (start_kernel) from [<>] ( (null))
59.91 [ 93.057762] timed out!
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
[ 86.219861] [] (do_idle) from [] (cpu_startup_entry+0x18/0x1c)
59.89 [ 86.227425] [] (cpu_startup_entry) from [] (start_kernel+0x44c/0x460)
59.90 [ 86.235592] [] (start_kernel) from [<>] ( (null))
59.91 [ 93.057762] timed out!
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Declaring the rseq_cs field as a union between __u64 and two __u32
> allows both 32-bit and 64-bit kernels to read the full __u64, and
> therefore validate that a 32-bit user-space cleared the
- On Jul 5, 2018, at 2:05 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> Declaring the rseq_cs field as a union between __u64 and two __u32
> allows both 32-bit and 64-bit kernels to read the full __u64, and
> therefore validate that a 32-bit user-space cleared the
ays be included for both kernel and
user-space code: including stdint.h is just for u64 and u32, which are
not used in this header at all.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC
ays be included for both kernel and
user-space code: including stdint.h is just for u64 and u32, which are
not used in this header at all.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC
flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC:
flags" fields to describe
more accurately that it's only useful to facilitate single-stepping
through rseq critical sections with debuggers.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC:
Following the recent discussion thread [1] about rseq uapi, here is
a set of updates submitted for comments.
Thanks,
Mathieu
[1]
https://lkml.kernel.org/r/20180702223143.4663-1-mathieu.desnoy...@efficios.com
Mathieu Desnoyers (5):
rseq: use __u64 for rseq_cs fields, validate user inputs
Following the recent discussion thread [1] about rseq uapi, here is
a set of updates submitted for comments.
Thanks,
Mathieu
[1]
https://lkml.kernel.org/r/20180702223143.4663-1-mathieu.desnoy...@efficios.com
Mathieu Desnoyers (5):
rseq: use __u64 for rseq_cs fields, validate user inputs
rseq as it was merged does not have rseq_finish_*() in the user-space
selftests anymore. Update the rseq_prepare_unload() helper comment to
adapt to this reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
rseq as it was merged does not have rseq_finish_*() in the user-space
selftests anymore. Update the rseq_prepare_unload() helper comment to
adapt to this reality.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
This header was introduced in the 4.18 merge window, and rseq does
not need it anymore. Nuke it before the final release.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave
This header was introduced in the 4.18 merge window, and rseq does
not need it anymore. Nuke it before the final release.
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave
does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
does not match the expected
signature, return -EINVAL rather than -EPERM to be consistent with other
input validation return codes from rseq_get_rseq_cs().
Signed-off-by: Mathieu Desnoyers
CC: "Paul E. McKenney"
CC: Peter Zijlstra
CC: Paul Turner
CC: Thomas Gleixner
CC: Andy Lutomirski
- On Jul 3, 2018, at 2:28 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 03, 2018 at 02:15:34PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 3, 2018, at 2:11 PM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Tue, Jul 03, 2018 at 01:58:37PM
- On Jul 3, 2018, at 2:28 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 03, 2018 at 02:15:34PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 3, 2018, at 2:11 PM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Tue, Jul 03, 2018 at 01:58:37PM
- On Jul 3, 2018, at 2:11 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 03, 2018 at 01:58:37PM -0400, Mathieu Desnoyers wrote:
>> I can modify the ABI to put the cpu_id_start and cpu_id fields inside
>> a union, and update it with a single store.
>>
>
- On Jul 3, 2018, at 2:11 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 03, 2018 at 01:58:37PM -0400, Mathieu Desnoyers wrote:
>> I can modify the ABI to put the cpu_id_start and cpu_id fields inside
>> a union, and update it with a single store.
>>
>
t; space needing to read and update them in word-sized chunks.
>
> End result: absolutely nothing is atomic for the kernel.
Yes, +1. If everyone is OK with that I'll go and implement the changes
within the coming day.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
t; space needing to read and update them in word-sized chunks.
>
> End result: absolutely nothing is atomic for the kernel.
Yes, +1. If everyone is OK with that I'll go and implement the changes
within the coming day.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 3, 2018, at 1:48 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 03, 2018 at 01:38:59PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 3, 2018, at 1:34 PM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Tue, Jul 03, 2018 at 10:10:37AM -07
- On Jul 3, 2018, at 1:48 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, Jul 03, 2018 at 01:38:59PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 3, 2018, at 1:34 PM, Peter Zijlstra pet...@infradead.org wrote:
>>
>> > On Tue, Jul 03, 2018 at 10:10:37AM -07
e, but the kernel does change other
> values, like for instance rseq->cpu_id. But even there, it could use
> byte stores and it is again the userspace load of that field that is
> critical again and needs to be a single op.
I can simply document that loads/stores from/to
e, but the kernel does change other
> values, like for instance rseq->cpu_id. But even there, it could use
> byte stores and it is again the userspace load of that field that is
> critical again and needs to be a single op.
I can simply document that loads/stores from/to
care less if an architecture chooses to read the u64 byte-wise while
standing on its feet.
With this added requirement, Andy's idea of using a union between __u64
and upper/lower __u32 would fit very nicely.
If everyone is OK with that approach, I can prepare an updated patch.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
care less if an architecture chooses to read the u64 byte-wise while
standing on its feet.
With this added requirement, Andy's idea of using a union between __u64
and upper/lower __u32 would fit very nicely.
If everyone is OK with that approach, I can prepare an updated patch.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jul 2, 2018, at 10:18 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Jul 2, 2018 at 7:01 PM Mathieu Desnoyers
> wrote:
>>
>> One thing to consider is how we will implement the load of that pointer
>> on the kernel side.
>
> Use &qu
- On Jul 2, 2018, at 10:18 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Jul 2, 2018 at 7:01 PM Mathieu Desnoyers
> wrote:
>>
>> One thing to consider is how we will implement the load of that pointer
>> on the kernel side.
>
> Use &qu
- On Jul 2, 2018, at 9:19 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 2, 2018, at 7:37 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>>> On Jul 2, 2018, at 4:22 PM, Mathieu Desnoyers
>>>
>>> wrote:
>>>
>
- On Jul 2, 2018, at 9:19 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 2, 2018, at 7:37 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>>> On Jul 2, 2018, at 4:22 PM, Mathieu Desnoyers
>>>
>>> wrote:
>>>
>
- On Jul 2, 2018, at 7:37 PM, Andy Lutomirski l...@amacapital.net wrote:
>> On Jul 2, 2018, at 4:22 PM, Mathieu Desnoyers
>>
>> wrote:
>>
>> - On Jul 2, 2018, at 7:16 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>&g
- On Jul 2, 2018, at 7:37 PM, Andy Lutomirski l...@amacapital.net wrote:
>> On Jul 2, 2018, at 4:22 PM, Mathieu Desnoyers
>>
>> wrote:
>>
>> - On Jul 2, 2018, at 7:16 PM, Mathieu Desnoyers
>> mathieu.desnoy...@efficios.com wrote:
>>
>>&g
- On Jul 2, 2018, at 8:35 PM, Chris Lameter c...@linux.com wrote:
> On Mon, 2 Jul 2018, Mathieu Desnoyers wrote:
>
>> >
>> > Platforms with 32 bit word size only guarantee atomicity of a 32 bit
>> > write or RMV instruction.
>> >
>> > Spec
- On Jul 2, 2018, at 8:35 PM, Chris Lameter c...@linux.com wrote:
> On Mon, 2 Jul 2018, Mathieu Desnoyers wrote:
>
>> >
>> > Platforms with 32 bit word size only guarantee atomicity of a 32 bit
>> > write or RMV instruction.
>> >
>> > Spec
- On Jul 2, 2018, at 8:19 PM, Chris Lameter c...@linux.com wrote:
> On Mon, 2 Jul 2018, Mathieu Desnoyers wrote:
>
>> Are there any kind of guarantees that a __u64 update on a 32-bit architecture
>> won't be torn into something daft like byte-per-byte stores when perfor
- On Jul 2, 2018, at 8:19 PM, Chris Lameter c...@linux.com wrote:
> On Mon, 2 Jul 2018, Mathieu Desnoyers wrote:
>
>> Are there any kind of guarantees that a __u64 update on a 32-bit architecture
>> won't be torn into something daft like byte-per-byte stores when perfor
- On Jul 2, 2018, at 7:22 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Jul 2, 2018 at 4:17 PM Mathieu Desnoyers
> wrote:
>>
>> Are there any kind of guarantees that a __u64 update on a 32-bit architecture
>> won't be torn into something daft l
- On Jul 2, 2018, at 7:22 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Mon, Jul 2, 2018 at 4:17 PM Mathieu Desnoyers
> wrote:
>>
>> Are there any kind of guarantees that a __u64 update on a 32-bit architecture
>> won't be torn into something daft l
- On Jul 2, 2018, at 7:16 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 2, 2018, at 7:06 PM, Linus Torvalds torva...@linux-foundation.org
> wrote:
>
>> On Mon, Jul 2, 2018 at 4:00 PM Mathieu Desnoyers
>> wrote:
>>>
>>>
- On Jul 2, 2018, at 7:16 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 2, 2018, at 7:06 PM, Linus Torvalds torva...@linux-foundation.org
> wrote:
>
>> On Mon, Jul 2, 2018 at 4:00 PM Mathieu Desnoyers
>> wrote:
>>>
>>>
901 - 1000 of 7281 matches
Mail list logo
