eval_map_work_func() and was not preempted by the stop_machine() task.
Adding a call to cond_resched() in trace_event_eval_update() allows
other tasks to be executed and thus continue working asynchronously
like before without blocking any pending task at boot time.
Signed-off-by: Clément Léger
On 29/09/2023 17:06, Steven Rostedt wrote:
> On Fri, 29 Sep 2023 16:13:48 +0200
> Clément Léger wrote:
>
>> When kernel is compiled without preemption, the eval_map_work_func()
>> (which calls trace_event_eval_update()) will not be preempted up to its
>> complete e
eval_map_work_func() and was not preempted by the stop_machine() task.
Adding a call to schedule() in trace_event_eval_update() allows to let
other tasks to be executed and thus continue working asynchronously like
before without blocking any pending task at boot time.
Signed-off-by: Clément Léger
On 25/09/2023 20:04, Clément Léger wrote:
>
>
> On 25/09/2023 18:04, Beau Belgrave wrote:
>> On Mon, Sep 25, 2023 at 09:53:16AM +0200, Clément Léger wrote:
>>>
>>>
>>> On 22/09/2023 21:22, Beau Belgrave wrote:
>>>> On Tue,
On 25/09/2023 18:04, Beau Belgrave wrote:
> On Mon, Sep 25, 2023 at 09:53:16AM +0200, Clément Léger wrote:
>>
>>
>> On 22/09/2023 21:22, Beau Belgrave wrote:
>>> On Tue, Sep 19, 2023 at 02:59:12PM +0200, Clément Léger wrote:
>>>>
>>>>
>&g
On 22/09/2023 22:00, Beau Belgrave wrote:
> On Tue, Sep 19, 2023 at 02:59:12PM +0200, Clément Léger wrote:
>>
>>
>> On 14/09/2023 19:29, Steven Rostedt wrote:
>>> On Thu, 14 Sep 2023 13:17:00 -0400
>>> Steven Rostedt wrote:
>>>
>>&
On 22/09/2023 21:22, Beau Belgrave wrote:
> On Tue, Sep 19, 2023 at 02:59:12PM +0200, Clément Léger wrote:
>>
>>
>> On 14/09/2023 19:29, Steven Rostedt wrote:
>>> On Thu, 14 Sep 2023 13:17:00 -0400
>>> Steven Rostedt wrote:
>>>
>>&
On 14/09/2023 19:29, Steven Rostedt wrote:
> On Thu, 14 Sep 2023 13:17:00 -0400
> Steven Rostedt wrote:
>
>> Now lets look at big endian layout:
>>
>> uaddr = 0xbeef0004
>> enabler = 1;
>>
>> memory at 0xbeef: 00 00 00 00 00 00 00 02
>> ^
>>
On 17/09/2023 23:09, David Laight wrote:
> From: Clément Léger
>> Sent: 14 September 2023 14:11
>>
>> enabler->uaddr can be aligned on 32 or 64 bits. If aligned on 32 bits,
>> this will result in a misaligned access on 64 bits architectures since
>> se
On 15/09/2023 04:54, Masami Hiramatsu (Google) wrote:
> On Thu, 14 Sep 2023 15:11:02 +0200
> Clément Léger wrote:
>
>> enabler->uaddr can be aligned on 32 or 64 bits. If aligned on 32 bits,
>> this will result in a misaligned access on 64 bits architectures since
>
On 14/09/2023 18:42, Beau Belgrave wrote:
> On Thu, Sep 14, 2023 at 03:11:02PM +0200, Clément Léger wrote:
>> enabler->uaddr can be aligned on 32 or 64 bits. If aligned on 32 bits,
>> this will result in a misaligned access on 64 bits architectures since
>> set_bit()/c
On 14/09/2023 19:29, Steven Rostedt wrote:
> On Thu, 14 Sep 2023 13:17:00 -0400
> Steven Rostedt wrote:
>
>> Now lets look at big endian layout:
>>
>> uaddr = 0xbeef0004
>> enabler = 1;
>>
>> memory at 0xbeef: 00 00 00 00 00 00 00 02
>> ^
>>
nel. Align uaddr on unsigned long size to avoid such behavior.
This bug was found while running kselftests on RISC-V.
Fixes: 7235759084a4 ("tracing/user_events: Use remote writes for event
enablement")
Signed-off-by: Clément Léger
---
kernel/trace/trace_events_user.c | 12 +---
1
13 matches
Mail list logo
