- On Jul 11, 2020, at 11:54 AM, Christian Brauner
christian.brau...@ubuntu.com wrote:
>
> The registration is a thread-group property I'll assume, right, i.e. all
> threads will have rseq TLS or no thread will have it?
No, rseq registration is a per-thread property, but it would arguably be
On Thu, Jul 09, 2020 at 11:15:57AM -0400, Mathieu Desnoyers wrote:
> - On Jul 9, 2020, at 8:49 AM, Christian Brauner
> christian.brau...@ubuntu.com wrote:
>
> > On Wed, Jul 08, 2020 at 01:34:48PM -0400, Mathieu Desnoyers wrote:
> >> - On Jul 8, 2020, at 12:22 PM, Christian Brauner
> >> ch
- On Jul 9, 2020, at 8:49 AM, Christian Brauner
christian.brau...@ubuntu.com wrote:
> On Wed, Jul 08, 2020 at 01:34:48PM -0400, Mathieu Desnoyers wrote:
>> - On Jul 8, 2020, at 12:22 PM, Christian Brauner
>> christian.brau...@ubuntu.com wrote:
>> [...]
>> > I've been following this a litt
On Wed, Jul 08, 2020 at 01:34:48PM -0400, Mathieu Desnoyers wrote:
> - On Jul 8, 2020, at 12:22 PM, Christian Brauner
> christian.brau...@ubuntu.com wrote:
> [...]
> > I've been following this a little bit. The kernel version itself doesn't
> > really mean anything and the kernel version is im
- On Jul 8, 2020, at 12:22 PM, Christian Brauner
christian.brau...@ubuntu.com wrote:
[...]
> I've been following this a little bit. The kernel version itself doesn't
> really mean anything and the kernel version is imho not at all
> interesting to userspace applications. Especially for cross-d
* Christian Brauner:
> I've been following this a little bit. The kernel version itself doesn't
> really mean anything and the kernel version is imho not at all
> interesting to userspace applications. Especially for cross-distro
> programs. We can't go around and ask Red Hat, SUSE, Ubuntu, Archli
On Wed, Jul 08, 2020 at 11:33:51AM -0400, Mathieu Desnoyers wrote:
> [ Context for Linus: I am dropping this RFC patch, but am curious to
> hear your point of view on exposing to user-space which system call
> behavior fixes are present in the kernel, either through feature
> flags or system-
[ Context for Linus: I am dropping this RFC patch, but am curious to
hear your point of view on exposing to user-space which system call
behavior fixes are present in the kernel, either through feature
flags or system-call versioning. The intent is to allow user-space
to make better decisio
* Mathieu Desnoyers:
> Allright, thanks for the insight! I'll drop these patches and focus only
> on the bugfix.
Thanks, much appreciated!
* Carlos O'Donell:
> It's not a great fit IMO. Just let the kernel version be the arbiter of
> correctness.
For manual review, sure. But checking it programmatically does not
yield good results due to backports. Even those who use the stable
kernel series sometimes pick up critical fixes before
- On Jul 7, 2020, at 2:53 PM, Carlos O'Donell car...@redhat.com wrote:
> On 7/7/20 8:06 AM, Mathieu Desnoyers wrote:
>> - On Jul 7, 2020, at 7:32 AM, Florian Weimer f...@deneb.enyo.de wrote:
>>
>>> * Mathieu Desnoyers:
>>>
Those are very good points. One possibility we have would be
On 7/7/20 8:06 AM, Mathieu Desnoyers wrote:
> - On Jul 7, 2020, at 7:32 AM, Florian Weimer f...@deneb.enyo.de wrote:
>
>> * Mathieu Desnoyers:
>>
>>> Those are very good points. One possibility we have would be to let
>>> glibc do the rseq registration without the RSEQ_FLAG_RELIABLE_CPU_ID
>>>
- On Jul 7, 2020, at 7:32 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>> Those are very good points. One possibility we have would be to let
>> glibc do the rseq registration without the RSEQ_FLAG_RELIABLE_CPU_ID
>> flag. On kernels with the bug present, the cpu_id f
* Mathieu Desnoyers:
> Those are very good points. One possibility we have would be to let
> glibc do the rseq registration without the RSEQ_FLAG_RELIABLE_CPU_ID
> flag. On kernels with the bug present, the cpu_id field is still good
> enough for typical uses of sched_getcpu() which does not appea
- On Jul 7, 2020, at 3:29 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>> commit 93b585c08d16 ("Fix: sched: unreliable rseq cpu_id for new tasks")
>> addresses an issue with cpu_id field of newly created processes. Expose
>> a flag which can be used by user-space to q
* Mathieu Desnoyers:
> commit 93b585c08d16 ("Fix: sched: unreliable rseq cpu_id for new tasks")
> addresses an issue with cpu_id field of newly created processes. Expose
> a flag which can be used by user-space to query whether the kernel
> implements this fix.
>
> Considering that this issue can
commit 93b585c08d16 ("Fix: sched: unreliable rseq cpu_id for new tasks")
addresses an issue with cpu_id field of newly created processes. Expose
a flag which can be used by user-space to query whether the kernel
implements this fix.
Considering that this issue can cause corruption of user-space pe
17 matches
Mail list logo
