Le 06/12/2019 à 20:37, Mindaugas Rasiukevicius a écrit :
Maxime Villard wrote:
Le 06/12/2019 à 17:53, Andrew Doran a écrit :
On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote:
/* Update the worker */
- worker_ci = hci;
+ atomic_swap_ptr(_ci, hci);
Why
jnem...@cue.bc.ca (John Nemeth) writes:
> Are you perhaps thinking of COBOL, which is traditionally all
>upper case. I could be mistaken since I've never written and likely
>have never seen ALGOL, but I have written COBOL.
There were several variants to distinguish between keywords and
On Dec 6, 5:22pm, Don Lee wrote:
}
} Writing Kernel code *requires* knowledge of what code is generated
} sometimes. In my experience, there have been standard techniques,
} like pragmas and insertions of assembly code to suppress this
} sort of undesirable optimization.
}
} Don't those
On Dec 6, 3:02pm, Jason Thorpe wrote:
} > On Dec 6, 2019, at 11:44 AM, paul.kon...@dell.com wrote:
} >
} > For clean semantics, I like ALGOL; too bad it is no longer used
}
} There's just too much shouting in ALGOL.
Are you perhaps thinking of COBOL, which is traditionally all
upper case.
Please educate me. It’s been a while for me.
Writing Kernel code *requires* knowledge of what code is generated sometimes.
In my experience, there have been standard techniques, like pragmas and
insertions of assembly code to suppress this sort of undesirable optimization.
Don’t those
> On Dec 6, 2019, at 11:44 AM, paul.kon...@dell.com wrote:
>
> For clean semantics, I like ALGOL; too bad it is no longer used
There's just too much shouting in ALGOL.
-- thorpej
> On Dec 6, 2019, at 10:21 AM, Mouse wrote:
>
>
> [EXTERNAL EMAIL]
>
>> Compilers have became much more aggressive over the years. But they
>> are allowed to be so by the C standard. Specifically, in addition to
>> code-level re-ordering, plain accesses (loads/stores) are subject to
>>
On Fri, Dec 06, 2019 at 09:00:33AM +, Andrew Doran wrote:
>
> Please don't commit this. These accesses are racy by design. There is no
> safety issue and we do not want to disturb the activity of other CPUs in
> this code path by locking them. We also don't want to use atomics either.
Maxime Villard wrote:
> Le 06/12/2019 à 17:53, Andrew Doran a écrit :
> > On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote:
> >
> >>/* Update the worker */
> >> - worker_ci = hci;
> >> + atomic_swap_ptr(_ci, hci);
> >
> > Why atomic_swap_ptr() not atomic_store_relaxed()? I
On Fri, Dec 06, 2019 at 06:33:32PM +0100, Maxime Villard wrote:
> Le 06/12/2019 à 17:53, Andrew Doran a écrit :
> >Why atomic_swap_ptr() not atomic_store_relaxed()? I don't see any bug that
> >it fixes. Other than that it look OK to me.
>
> Because I suggested it; my concern was that if not
Le 06/12/2019 à 17:53, Andrew Doran a écrit :
On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote:
/* Update the worker */
- worker_ci = hci;
+ atomic_swap_ptr(_ci, hci);
Why atomic_swap_ptr() not atomic_store_relaxed()? I don't see any bug that
it fixes.
On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote:
> /* Update the worker */
> - worker_ci = hci;
> + atomic_swap_ptr(_ci, hci);
Why atomic_swap_ptr() not atomic_store_relaxed()? I don't see any bug that
it fixes. Other than that it look OK to me.
Cheers,
Andrew
On Fri, Dec 06, 2019 at 02:55:47PM +, Mindaugas Rasiukevicius wrote:
> Compilers have became much more aggressive over the years. But they are
> allowed to be so by the C standard. Specifically, in addition to code-level
> re-ordering,
Yup the rules around that are well understood.
>
> Compilers have became much more aggressive over the years. But they
> are allowed to be so by the C standard. Specifically, in addition to
> code-level re-ordering, plain accesses (loads/stores) are subject to
> load/store fusing, tearing as well as invented loads/stores.
Then, honestly, it
Le 06/12/2019 à 11:28, Andrew Doran a écrit :
> On Fri, Dec 06, 2019 at 10:27:20AM +0100, Maxime Villard wrote:
>
>> With 'worker_ci', there is an actual safety issue, because the compiler could
>> split the accesses and the hardware may not use atomics by default like x86.
>> This could cause
On Fri, Dec 06, 2019 at 10:27:20AM +0100, Maxime Villard wrote:
> With 'worker_ci', there is an actual safety issue, because the compiler could
> split the accesses and the hardware may not use atomics by default like x86.
> This could cause random page faults; so it needs to be strictly atomic.
Hi,
On 2019/12/06 18:00, Andrew Doran wrote:
Hi,
On Fri, Dec 06, 2019 at 03:52:23PM +0900, Kengo NAKAHARA wrote:
There are some racy accesses in kern_runq.c detected by KCSAN. Those
racy access messages is so frequency that they cover other messages,
so I want to fix them. They can be
Le 06/12/2019 à 10:00, Andrew Doran a écrit :
> Hi,
>
> On Fri, Dec 06, 2019 at 03:52:23PM +0900, Kengo NAKAHARA wrote:
>
>> There are some racy accesses in kern_runq.c detected by KCSAN. Those
>> racy access messages is so frequency that they cover other messages,
>> so I want to fix them.
Le 06/12/2019 à 07:52, Kengo NAKAHARA a écrit :
> Hi,
>
> There are some racy accesses in kern_runq.c detected by KCSAN. Those
> racy access messages is so frequency that they cover other messages,
> so I want to fix them. They can be fixed by the following patch.
>
>
>
Hi,
On Fri, Dec 06, 2019 at 03:52:23PM +0900, Kengo NAKAHARA wrote:
> There are some racy accesses in kern_runq.c detected by KCSAN. Those
> racy access messages is so frequency that they cover other messages,
> so I want to fix them. They can be fixed by the following patch.
Please don't
Hi,
Thank you for your comment.
On 2019/12/06 16:42, Maxime Villard wrote:
Le 06/12/2019 à 07:52, Kengo NAKAHARA a écrit :
Hi,
There are some racy accesses in kern_runq.c detected by KCSAN. Those
racy access messages is so frequency that they cover other messages,
so I want to fix them.
Hi,
There are some racy accesses in kern_runq.c detected by KCSAN. Those
racy access messages is so frequency that they cover other messages,
so I want to fix them. They can be fixed by the following patch.
diff --git a/sys/kern/kern_runq.c b/sys/kern/kern_runq.c
index
22 matches
Mail list logo
