- On Jul 8, 2020, at 8:33 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 7, 2020, at 8:59 PM, Segher Boessenkool
> seg...@kernel.crashing.org
> wrote:
[...]
>>
>> So perhaps you have code like
>>
>> int *p;
>> int x
- On Jul 7, 2020, at 8:59 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
> Hi!
>
> On Tue, Jul 07, 2020 at 03:17:10PM -0400, Mathieu Desnoyers wrote:
>> I'm trying to build librseq at:
>>
>> https://git.kernel.org/pub/scm/libs/librseq/librseq.git
&
The following commit has been merged into the sched/urgent branch of tip:
Commit-ID: ce3614daabea8a2d01c1dd17ae41d1ec5e5ae7db
Gitweb:
https://git.kernel.org/tip/ce3614daabea8a2d01c1dd17ae41d1ec5e5ae7db
Author:Mathieu Desnoyers
AuthorDate:Mon, 06 Jul 2020 16:49:10 -04:00
ions requires it to be accurate. If it is not accurate, it
can cause corruption in the per-cpu data targeted by rseq critical
sections in user-space.
Link: https://sourceware.org/pipermail/libc-alpha/2020-July/115816.html
Signed-off-by: Mathieu Desnoyers
Tested-By: Florian Weimer
Cc: Peter Zijl
ry operand addressed by just a base register."
I suspect that lwz and stw don't expect some kind of immediate offset which
can be kept with "m", and "Q" fixes this. Is that the right fix ?
And should we change all operands passed to lwz and stw to a "Q"
- 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 ve
- 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
ing case. I thought it was okay (because
> the IPI would cause a hard interrupt which does do the rfi) but that
> should at least be written.
Yes.
> The context synchronisation happens before
> the Linux IPI function is called, but for the purpose of membarrier I
> think that is okay
- On Jul 7, 2020, at 3:30 AM, Florian Weimer f...@deneb.enyo.de wrote:
> * Mathieu Desnoyers:
>
>> While integrating rseq into glibc and replacing glibc's sched_getcpu
>> implementation with rseq, glibc's tests discovered an issue with
>> incorrect __rseq_abi.cpu_id
- 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 fl
- On Jul 6, 2020, at 2:11 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> - On Jul 6, 2020, at 1:50 PM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> * Mathieu Desnoyers:
>>>
>>>> Now we need to discuss how we
ystem
call needs to be performed for each new thread in glibc, minimize the
amount of overhead required.
This is needed for introducing a new RSEQ_FLAG_RELIABLE_CPU_ID flag in a
later change.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
Cc: Florian Weimer
Cc: &
user-space per-cpu
data updated with rseq, it is recommended that user-space detects
availability of this fix by using the RSEQ_FLAG_RELIABLE_CPU_ID flag
either combined with registration or on its own before using rseq.
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Thomas Gl
aiming for quick inclusion into the Linux kernel, unless
we prefer reverting the entire rseq glibc integration and try again in 6
months. Their upcoming release is on August 3rd, so we need to take a
decision on this matter quickly.
Thanks,
Mathieu
Mathieu Desnoyers (4):
sched: Fix unreliable
The rseq selftests should discover whether the kernel implements the
RSEQ_FLAG_RELIABLE_CPU_ID flag, which indicates that the
__rseq_abi.cpu_id field is reliable.
Signed-off-by: Mathieu Desnoyers
Cc: Shuah Khan
Cc: Peter Zijlstra (Intel)
Cc: Thomas Gleixner
Cc: Florian Weimer
Cc: "P
ions requires it to be accurate. If it is not accurate, it
can cause corruption in the per-cpu data targeted by rseq critical
sections in user-space.
Link: https://sourceware.org/pipermail/libc-alpha/2020-July/115816.html
Signed-off-by: Mathieu Desnoyers
Cc: Peter Zijlstra (Intel)
Cc: Thomas Glei
- On Jul 6, 2020, at 1:50 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Now we need to discuss how we introduce that fix in a way that will
>> allow user-space to trust the __rseq_abi.cpu_id field's content.
>
> I don't think that's ne
- On Jul 6, 2020, at 10:49 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jul 6, 2020, at 9:59 AM, Florian Weimer fwei...@redhat.com wrote:
>
>> * Mathieu Desnoyers:
>>
>>> When available, use the cpu_id field from __rseq_abi on Linux to
- On Jul 6, 2020, at 9:59 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> When available, use the cpu_id field from __rseq_abi on Linux to
>> implement sched_getcpu(). Fall-back on the vgetcpu vDSO if
>> unavailable.
>
> I'
fork, clone or daemon, then
helper libraries need to be preloaded with the daemon following instructions
in the man-page lttng-ust(3) under section "Using LTTng-UST with daemons".
Failure to preload those libraries in daemons would trigger the observed
scenario: the application hangs up t
return 0;
>}
>
> @@ -1132,7 +1136,7 @@ int tcp_md5_do_add(struct sock *sk, const union
> tcp_md5_addr *addr,
> rcu_assign_pointer(tp->md5sig_info, md5sig);
>}
>
> - key = sock_kmalloc(sk, sizeof(*key), gfp);
> + key = sock_kmalloc(sk, sizeof(*key), gfp | __GFP_ZERO);
>if (!key)
>return -ENOMEM;
> if (!tcp_alloc_md5sig_pool()) {
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
some
>> reasons I can't update it. So, is this a known bug? If yes, It will be very
>> appreciated if you can give me any advice about the bug info(I can cherry
>> pick
>> the correspond fix). Otherwise, maybe I have to give up my favoriate
>> Lttng
>> Thank you in advan
tcp_md5_do_add(struct sock *sk, const union
> tcp_md5_addr *addr,
>if (key) {
>/* Pre-existing entry - just update that one. */
>memcpy(key->key, newkey, newkeylen);
> +
> + smp_wmb(); /* pairs with smp_rmb() in tcp_md5_hash_key() */
> +
>key->keylen = newkeylen;
>return 0;
> }
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
u cases is do determine the behavior
> of all these stacks vs :
> SACK option
> TCP TS option.
I will ask my customer's networking team to investigate these behaviors,
which will allow me to prepare a thorough reply to the questions raised
by Eric and David. I expect to have an answer within 2-3 weeks at most.
Thank you!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ing a customer increase their contributions and feedback to upstream.
As we can see, they have accumulated some backlog over time.
Clearly reverting a security fix is not acceptable here. Coming up with a
proper ABI-compatible fix should not be out of our reach though.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
vailable space.
I welcome advice on what should be the end goal here.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jun 29, 2020, at 8:21 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 25 Jun 2020 15:35:02 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> >> So the reservation is not "just" an add instruction, it's actually an
>> >> xadd on x86. Is that
- On May 13, 2020, at 3:56 PM, Eric Dumazet eduma...@google.com wrote:
> On Wed, May 13, 2020 at 12:49 PM Eric Dumazet wrote:
>>
>>
>> On Wed, May 13, 2020 at 12:38 PM Mathieu Desnoyers
>> wrote:
>> >
>> > Hi,
>> >
>> > I am
q.2 system call man page.
Changes since v21:
- Update manual following feedback from Florian.
- Remove static assert and alignof from sys/rseq.h to align with current
Linux UAPI header, based on feedback from Florian.
Signed-off-by: Mathieu Desnoyers
CC: Carlos O'Donell
CC: Florian Weimer
CC:
When available, use the cpu_id field from __rseq_abi on Linux to
implement sched_getcpu(). Fall-back on the vgetcpu vDSO if unavailable.
Benchmarks:
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
glibc sched_getcpu(): 13.7 ns (baseline)
glibc sched_getcpu() using
alse;
>
> *ret = rb_time_val(top, bottom);
> return true;
> }
If __rb_time_read or rb_time_cmpxchg are used in an interrupt over
rb_time_set (between setting top and bottom), those will never succeed.
How is this case handled ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jun 26, 2020, at 12:00 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Thu, Jun 25, 2020 at 10:56:35AM -0400, Mathieu Desnoyers wrote:
>> - On Jun 24, 2020, at 3:50 PM, Peter Zijlstra pet...@infradead.org wrote:
>
> I'll try and read the earlier bit later, I ca
- On Jun 26, 2020, at 11:16 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jun 25, 2020, at 12:34 PM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Jun 25, 2020, at 10:56 AM, Mathieu Desnoyers
>> mathieu.desnoy.
- On Jun 25, 2020, at 12:34 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jun 25, 2020, at 10:56 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
>> - On Jun 24, 2020, at 3:50 PM, Peter Zijlstra pet...@infradead.org wrote:
>>
- On Jun 25, 2020, at 3:09 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 25 Jun 2020 13:55:07 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> What are the types used for before_stamp and write_stamp ? If those
>> are 64-bit integers, how does sharing them between ne
- On Jun 25, 2020, at 3:04 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 25 Jun 2020 13:55:07 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>
>> What worries me about this "optimization" is what happens in a multi-nesting
>> scenario.
>> If we j
- On Jun 25, 2020, at 2:35 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 25 Jun 2020 13:55:07 -0400 (EDT)
> Mathieu Desnoyers wrote
>
>> > Here's the design of this solution:
>> >
>> > All this is per cpu, and only needs to worry about nes
* Well, there's no use to try to know what the time
> stamp
>* is for the previous event. Just set delta to zero and
>* be the same time as that event that preempted us
> before
>* the reservation of the buffer. */
>
> delta = 0;
If this is a rare case, why not just use a full timestamp instead ?
Thanks,
Mathieu
> }
> /* No need to use full timestamps here */
> abs = 0;
> }
> --
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jun 25, 2020, at 10:56 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Jun 24, 2020, at 3:50 PM, Peter Zijlstra pet...@infradead.org wrote:
>
>> On Wed, Jun 24, 2020 at 02:31:33PM -0400, Mathieu Desnoyers wrote:
>>
> [...]
>> The
- On Jun 24, 2020, at 3:50 PM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Jun 24, 2020 at 02:31:33PM -0400, Mathieu Desnoyers wrote:
>
[...]
>
>> >> + /*
>> >> + * Consume CPU time as long as an associated task is running on another
>>
several failed attempts, I finally have a solution
> to solve this puzzle.
Out of curiosity, considering that LTTng has solved this problem 10+ years ago
with a simpler concurrency-friendly time-stamping model, why not simply use it
rather than add complexity to the current ftrace timestamp scheme
- On Jun 24, 2020, at 3:24 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>>> I think we should keep things simple on the glibc side for now and do
>>> this changes to the kernel headers first.
>>
>> Just to be sure I understand
- On Jun 24, 2020, at 3:11 PM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>>> I'm still worried that __rseq_static_assert and __rseq_alignof will show
>>> up in the UAPI with textually different definitions. (This does not
>>> apply to
- On Jun 24, 2020, at 10:20 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> diff --git a/manual/threads.texi b/manual/threads.texi
>> index bb7a42c655..d5069d5581 100644
>> --- a/manual/threads.texi
>> +++ b/manual/threads.texi
&
- On Jun 24, 2020, at 8:11 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Fri, Jun 19, 2020 at 04:25:16PM -0400, Mathieu Desnoyers wrote:
>
>> @@ -660,6 +685,13 @@ struct task_struct {
>> #ifdef CONFIG_THREAD_INFO_IN_TASK
>> /* Current CPU:
nual to remove uptr field, which is removed from sys/rseq.h.
- Rebase on current master branch.
Changes since v20:
- Rebase on current glibc master.
- Update TLS_STATIC_SURPLUS value.
- Use attribute __aligned__ to have same approach as Linux UAPI header.
- Update manual to include link to librseq rse
When available, use the cpu_id field from __rseq_abi on Linux to
implement sched_getcpu(). Fall-back on the vgetcpu vDSO if unavailable.
Benchmarks:
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
glibc sched_getcpu(): 13.7 ns (baseline)
glibc sched_getcpu() using
- On Jun 11, 2020, at 4:26 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Thu, 11 Jun 2020, Mathieu Desnoyers wrote:
>
>> I managed to get a repository up and running for librseq, and have integrated
>> the rseq.2 man page with comments from Michael Kerrisk
ret = rseq_addv(v, count, percpu_current_cpu());
sched_pair_cpu_clear();
goto check;
}
return 0;
}
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Peter Zijlstra
CC: Joel Fernandes
CC: "H . Peter Anvin"
CC: Paul Turner
- On Jun 18, 2020, at 8:22 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> The 06/11/2020 20:26, Joseph Myers wrote:
>> On Thu, 11 Jun 2020, Mathieu Desnoyers wrote:
>> > I managed to get a repository up and running for librseq, and have
>> > integrat
ount, int cpu)
{
int ret;
ret = rseq_addv(v, count, cpu);
check:
if (rseq_unlikely(ret)) {
sched_pair_cpu_set(cpu);
ret = rseq_addv(v, count, percpu_current_cpu());
sched_pair_cpu_clear();
goto check;
,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jun 4, 2020, at 1:46 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Thu, 4 Jun 2020, Mathieu Desnoyers via Libc-alpha wrote:
>
>> That external piece of documentation would be part of the Linux man-pages
>> project, maintained by Michael Kerrisk. I have submitt
Hi,
This is an announcement of a patch level 1.8.3 update for the Common
Trace Format. It clarifies a few unspecified areas of CTF 1.8.2.
You can find the specification at:
https://diamon.org/ctf/
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
n
"readers" elements rather than bytes.
By doing so, struct registry_chunk will adapt to have the proper alignment.
Thanks,
Mathieu
>
> Dmitry
>
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/list
rmal" home:
https://github.com/compudj/librseq
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On Jun 3, 2020, at 8:31 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> - On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote:
>>
>>> * Mathieu Desnoyers:
>>>
>>>> +#ifdef __cplusplus
&g
- On Jun 3, 2020, at 8:05 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> +#ifdef __cplusplus
>> +# if __cplusplus >= 201103L
>> +# define __rseq_static_assert(expr, diagnostic) static_assert (expr,
>> diagnostic)
ck on how we can
improve LTTng to make it acceptable for integration into Linux.
Thanks,
Mathieu
[1] https://lwn.net/Articles/817988/
[2] https://lore.kernel.org/r/20200302192811.n6o5645rsib44vco@localhost
[3]
https://lore.kernel.org/r/20200409193543.18115-1-mathieu.desnoy...@efficios.com
--
ck on how we can
improve LTTng to make it acceptable for integration into Linux.
Thanks,
Mathieu
[1] https://lwn.net/Articles/817988/
[2] https://lore.kernel.org/r/20200302192811.n6o5645rsib44vco@localhost
[3]
https://lore.kernel.org/r/20200409193543.18115-1-mathieu.desnoy...@efficios.com
--
and --with-babeltrace-bin. If any of those are
not set, respectively use "babeltrace2" and "babeltrace".
Ensure all shell scripts and python tests use the BABELTRACE_BIN
environment variable.
Fixes #1270
Signed-off-by: Mathieu Desnoyers
Co-developed-by: Jonatha
t regards,
> Lukasz
> ___
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
When available, use the cpu_id field from __rseq_abi on Linux to
implement sched_getcpu(). Fall-back on the vgetcpu vDSO if unavailable.
Benchmarks:
x86-64: Intel E5-2630 v3@2.40GHz, 16-core, hyperthreading
glibc sched_getcpu(): 13.7 ns (baseline)
glibc sched_getcpu() using
ch is unexpected.
- Abort libc in rseq_register_current_thread () on all
errno except EPERM (seccomp), EACCES (seccomp), and ENOSYS
(not implemented).
Changes since v19:
- Take care of feedback from Florian.
- Update manual to remove uptr field, which is removed from sys/rseq.h.
- Rebase on c
- On May 26, 2020, at 10:57 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>>> Like the attribute, it needs to come right after the struct keyword, I
>>> think. (Trailing attributes can be ambiguous, but not in this case.)
>>
>>
- On May 26, 2020, at 10:38 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> AFAIU, the only gain here would be to make sure we don't emit useless
>> ";" in the "/* nothing */" case. But does it matter ?
>
>
- On May 26, 2020, at 8:41 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> Something like this ?
>>
>> #ifdef __cplusplus
>> # if __cplusplus >= 201103L
>> # define rseq_static_assert (expr, diagnostic) static_as
- On May 25, 2020, at 11:20 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> The larger question here is: considering that we re-implement the entire
>> uapi header within glibc (which includes the uptr addition), do we still
>> care about u
- On May 20, 2020, at 7:40 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers via Libc-alpha:
>
>> diff --git a/NEWS b/NEWS
>> index 141078c319..c4e0370fc4 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -23,6 +23,16 @@ Major new features:
>>
__
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
- On May 15, 2020, at 11:45 AM, Will Deacon w...@kernel.org wrote:
> On Fri, May 15, 2020 at 04:04:39PM +0200, Frederic Weisbecker wrote:
>> On Wed, May 13, 2020 at 07:28:34PM -0400, Mathieu Desnoyers wrote:
>> > - On May 5, 2020, at 9:16 AM, Thomas Gleixner t...@l
- On May 15, 2020, at 8:47 AM, Lai Jiangshan la...@linux.alibaba.com wrote:
[...]
> So the serarch should stop when diving down up to
> 2*BITS_PER_LONG depth.
serarch -> search
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On May 15, 2020, at 5:34 AM, Thomas Gleixner t...@linutronix.de wrote:
[...]
>
> Can you please trim your replies?
Sorry, will do,
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On May 14, 2020, at 1:28 PM, Thomas Gleixner t...@linutronix.de wrote:
> Mathieu Desnoyers writes:
>> - On May 5, 2020, at 9:49 AM, Thomas Gleixner t...@linutronix.de wrote:
>>> +
>>> +static __always_inline void debug_exit(unsigned long dr7)
>>
- On May 14, 2020, at 1:38 PM, Thomas Gleixner t...@linutronix.de wrote:
> Mathieu Desnoyers writes:
>> - On May 5, 2020, at 9:16 AM, Thomas Gleixner t...@linutronix.de wrote:
>>
>>> From: Peter Zijlstra
>>>
>>
>> Patch title: singa
- On May 14, 2020, at 12:39 PM, Borislav Petkov b...@alien8.de wrote:
> On Thu, May 14, 2020 at 12:03:30PM -0400, Mathieu Desnoyers wrote:
>> - #MC triggered, queuing task work,
>> - unrelated signal happens to be delivered to task,
>> - exit to usermode loop ha
ibly other relevant information for siginfo_t) triggering the
exception in a scenario where we have:
- #MC triggered, queuing task work,
- unrelated signal happens to be delivered to task,
- exit to usermode loop handles do_signal first,
- then it runs task work.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- Thomas Gleixner wrote:
> Mathieu Desnoyers writes:
> > - On May 14, 2020, at 12:31 AM, Andy Lutomirski l...@kernel.org wrote:
> >> On Wed, May 13, 2020 at 6:44 PM Mathieu Desnoyers
> >> wrote:
> >> They're needed for all entries except SYSCALL, bu
- On May 14, 2020, at 12:31 AM, Andy Lutomirski l...@kernel.org wrote:
> On Wed, May 13, 2020 at 6:44 PM Mathieu Desnoyers
> wrote:
>>
>> - On May 5, 2020, at 9:44 AM, Thomas Gleixner t...@linutronix.de wrote:
>>
>> [...]
>>
>> > +.macro id
- On May 13, 2020, at 8:12 PM, Thomas Gleixner t...@linutronix.de wrote:
[...]
>
>>> Mathieu Desnoyers wrote:
>
>>> Also, color me confused: is "do_signal()" actually running any user-space,
>>> or just setting up the user-space stack for event
/*
>* The SDM says "The processor clears the BTF flag when it
> @@ -777,7 +800,7 @@ dotraplinkage void do_debug(struct pt_re
> #endif
>
> if (notify_die(DIE_DEBUG, "debug", regs, (long), error_code,
> -
86, I notice a lack of consistency in use of the following instruction
sequence at the asm entry point:
- ASM_CLAC,
- cld (clear direction flag).
Are they always needed, or only for interrupt handlers ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
* idtentry_enter() invoked rcu_irq_enter(). This
> + * needs to undone before scheduling.
Nit: "to undone" -> "to be undone".
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On May 5, 2020, at 9:44 AM, Thomas Gleixner t...@linutronix.de wrote:
[...]
>
> +/**
> + * rcu_irq_exit_preempt - Inform RCU that current CPU is exiting irq
> + * towards in kernel preemption
Not sure what "towards in" means.
Thanks,
Mathieu
bled or not in fixup_bad_iret() ? And of
course that change should be documented in the commit message.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
So replace ist_enter() with nmi_enter(). Also observe that any nmi_enter()
> caller must be both notrace and NOKPROBE, or in the noinstr text section.
Are there similar issues with non-x86 architectures, or is this
exception-behaves-like-an-interrupt issue specific to x86 ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
sing).
If it's the case, I think it should be clearly stated as the intent of the
earlier patch.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
p_recursion += LOCKDEP_OFF;
> -}
> -EXPORT_SYMBOL(lockdep_off);
> -
> -void lockdep_on(void)
> -{
> - current->lockdep_recursion -= LOCKDEP_OFF;
> -}
> -EXPORT_SYMBOL(lockdep_on);
> -
> static inline void lockdep_recursion_finish(void)
> {
> if (WARN_ON_ONCE(--current->lockdep_recursion))
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_hcr, hcr_el2); \
And not here ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
ure is used, and
> * gcc detects corruption of the on-stack canary value
> */
> -__visible void __stack_chk_fail(void)
> +__visible noinstr void __stack_chk_fail(void)
> {
> + instr_begin();
> panic("stack-protector: Kernel stack is corrupted in: %pB",
> __builtin_return_address(0));
> + instr_end();
> }
> EXPORT_SYMBOL(__stack_chk_fail);
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
scall_32.o = $(CC_FLAGS_FTRACE) -fstack-protector
>> -fstack-protector-strong
>> +CFLAGS_REMOVE_syscall_64.o = $(CC_FLAGS_FTRACE) -fstack-protector
>> -fstack-protector-strong
>> +
>> OBJECT_FILES_NON_STANDARD_entry_64_compat.o := y
>>
>> CFLAGS_syscall_64.o+= $(call cc-option,-Wno-override-init,)
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
IST exception
> - *
> - * Ends a non-atomic section started with ist_begin_non_atomic().
> - */
> -void ist_end_non_atomic(void)
> -{
> - preempt_disable();
> -}
> -
> int is_valid_bugaddr(unsigned long addr)
> {
> unsigned short ud;
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On May 13, 2020, at 5:10 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 13 May 2020 16:56:41 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On May 5, 2020, at 9:16 AM, Thomas Gleixner t...@linutronix.de wrote:
>>
>> > Make sure task_work runs before
delivery */
> + if (cached_flags & _TIF_SIGPENDING)
> + do_signal(regs);
> +
> if (cached_flags & _TIF_USER_RETURN_NOTIFY)
> fire_user_return_notifiers();
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
as the resulting combination of options does not exceed the available
header space.
Can we please fix this KASAN report in a way that does not break user-space
applications expectations about Linux' implementation of RFC2385 ?
Thanks,
Mathieu
[1] RFC2385: https://tools.ietf.org/html/rfc2385
call(2) man page), or
does it call into libc ? Is your entire libc compiled with
-fno-omit-frame-pointer ?
As soon as one library in the chain to the system call is compiled without
frame pointers, this is where the
stack walk stops. This is usually libc.
Thanks,
Math
after the NMI, rather than from NMI context.
AFAIK this is how this is done today by perf, ftrace, ebpf, and lttng.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
- On May 6, 2020, at 9:55 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Tue, May 05, 2020 at 04:27:44PM -0400, Mathieu Desnoyers wrote:
>> Actually, if the goal is to do code patching of the call, I wonder
>> what makes it OK to "guess" all the call patterns
- On May 5, 2020, at 3:57 PM, ndesaulniers ndesaulni...@google.com wrote:
> On Tue, May 5, 2020 at 12:00 PM Mathieu Desnoyers
> wrote:
>>
>> - On May 5, 2020, at 2:48 PM, Linus Torvalds
>> torva...@linux-foundation.org
>> wrote:
>> [...]
>> &g
semantically
changed to just invoking an empty function which effectively does nothing.
This would remove the need to do a pointer check in the first place. But maybe
I'm missing something subtle about why it has not been done in this context.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
801 - 900 of 11966 matches
Mail list logo
