2024年9月29日 06:10，Alan Huang wrote：
>
> 2024年9月28日 06:18，Jonas Oberhauser wrote：
>>
>>
>>
>> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
>>> On 2024-09-27 21:23, Jonas Oberhauser wrote:
>>> [...]
That idea seems to be confirmed by this (atrocious, not to be copied!)
example:
2024年9月28日 06:18，Jonas Oberhauser wrote：
>
>
>
> Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
>> On 2024-09-27 21:23, Jonas Oberhauser wrote:
>> [...]
>>> That idea seems to be confirmed by this (atrocious, not to be copied!)
>>> example:
>>>
>>> int fct_escape_address_of_b(void)
>>> {
Am 9/27/2024 um 10:10 PM schrieb Mathieu Desnoyers:
On 2024-09-27 21:23, Jonas Oberhauser wrote:
[...]
That idea seems to be confirmed by this (atrocious, not to be copied!)
example:
int fct_escape_address_of_b(void)
{
int *a, *b;
do {
a = READ_ONCE(p);
asm vola
On 2024-09-27 21:23, Jonas Oberhauser wrote:
[...]
That idea seems to be confirmed by this (atrocious, not to be copied!)
example:
int fct_escape_address_of_b(void)
{
int *a, *b;
do {
a = READ_ONCE(p);
asm volatile ("" : : : "memory");
b = READ_ONCE(p);
On Fri, 27 Sept 2024 at 12:28, Linus Torvalds
wrote:
>
> Dammit, people, read the code I posted.
Actually, no, apologies. You were right, and I was wrong.
It does need both of the sources of the comparison to be hidden,
because while even hiding just one side makes the comparison result
"meaning
On 2024-09-27 20:13, Linus Torvalds wrote:
On Fri, 27 Sept 2024 at 10:53, Mathieu Desnoyers
wrote:
(b) the value barrier needs to be on *both* values so that the order
of the equality testing doesn't matter.
If we use OPTIMIZER_HIDE_VAR() on both parameters, it indeed minimizes
the odds
On Fri, 27 Sept 2024 at 12:12, Jonas Oberhauser
wrote:
>
> I think it depends on which one you hide.
No.
Dammit, people, read the code I posted.
> But for
>
> z = a;
> hide(z);
> if (z==b) { *b; }
No.
I *intentionally* made it an inline function, and only hid the
arguments to the equali
Two comments inline,
Am 9/27/2024 um 6:38 AM schrieb Boqun Feng:
compilers can replace 'ptr' with 'head' because of the equality, and
even putting barrier() here cannot prevent compiler to rewrite the else
branch into:
else {
barrier();
return head;
Am 9/27/2024 um 8:13 PM schrieb Linus Torvalds:
Because even hiding the value one from the compiler will mean that it
can't use the comparison to decide that the originals are equal, even
if one of them is unhidden.
No?
Linus
I think it depends on which one you hide.
If yo
On Fri, 27 Sept 2024 at 10:53, Mathieu Desnoyers
wrote:
>
> > (b) the value barrier needs to be on *both* values so that the order
> > of the equality testing doesn't matter.
>
> If we use OPTIMIZER_HIDE_VAR() on both parameters, it indeed minimizes
> the odds that someone get the order wrong, b
On 2024-09-27 19:23, Linus Torvalds wrote:
On Fri, 27 Sept 2024 at 10:17, Mathieu Desnoyers
wrote:
The barrier() is ineffective at fixing the issue.
It does not prevent the compiler CSE from losing the
address dependency:
Ok. Thanks for actually specifying code.
That needs to be
(a) in a
On Fri, 27 Sept 2024 at 10:17, Mathieu Desnoyers
wrote:
>
> The barrier() is ineffective at fixing the issue.
> It does not prevent the compiler CSE from losing the
> address dependency:
Ok. Thanks for actually specifying code.
That needs to be
(a) in a comment
(b) the value barrier needs to
On 2024-09-27 18:44, Linus Torvalds wrote:
On Thu, 26 Sept 2024 at 18:38, Boqun Feng wrote:
Note that ADDRESS_EQ() only hide first parameter, so this should be
ADDRESS_EQ(b, a).
Yeah, please stop making things unnecessarily complicated.
Just use a barrier(). Please. Stop these stupid games
On Thu, 26 Sept 2024 at 18:38, Boqun Feng wrote:
>
> Note that ADDRESS_EQ() only hide first parameter, so this should be
> ADDRESS_EQ(b, a).
Yeah, please stop making things unnecessarily complicated.
Just use a barrier(). Please. Stop these stupid games until you can
show why it matters.
And b
2024年9月27日 12:28，Boqun Feng wrote：
>
> On Fri, Sep 27, 2024 at 09:37:50AM +0800, Boqun Feng wrote:
>>
>>
>> On Fri, Sep 27, 2024, at 9:30 AM, Mathieu Desnoyers wrote:
>>> On 2024-09-27 02:01, Boqun Feng wrote:
#define ADDRESS_EQ(var, expr) \
({ \
bool _cmp_res = (unsigned lon
On 2024-09-27 16:43, Mathieu Desnoyers wrote:
On 2024-09-27 12:59, Mathieu Desnoyers wrote:
On 2024-09-27 06:28, Boqun Feng wrote:
[...]
I replaced ADDRESS_EQ(a, b) with ADDRESS_EQ(b, a), and the compile
result shows it can prevent the issue:
I see, yes. It prevents the issue by making the c
On 2024-09-27 12:59, Mathieu Desnoyers wrote:
On 2024-09-27 06:28, Boqun Feng wrote:
[...]
I replaced ADDRESS_EQ(a, b) with ADDRESS_EQ(b, a), and the compile
result shows it can prevent the issue:
I see, yes. It prevents the issue by making the compiler create
a copy of the value "modified" b
On 2024-09-27 06:28, Boqun Feng wrote:
On Fri, Sep 27, 2024 at 09:37:50AM +0800, Boqun Feng wrote:
On Fri, Sep 27, 2024, at 9:30 AM, Mathieu Desnoyers wrote:
On 2024-09-27 02:01, Boqun Feng wrote:
#define ADDRESS_EQ(var, expr)
\
On Fri, Sep 27, 2024 at 03:20:40AM +0200, Mathieu Desnoyers wrote:
> On 2024-09-26 18:12, Linus Torvalds wrote:
> > On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser
> > wrote:
> > >
> > > No, the issue introduced by the compiler optimization (or by your
> > > original patch) is that the CPU can sp
On Fri, Sep 27, 2024 at 09:37:50AM +0800, Boqun Feng wrote:
>
>
> On Fri, Sep 27, 2024, at 9:30 AM, Mathieu Desnoyers wrote:
> > On 2024-09-27 02:01, Boqun Feng wrote:
> >>#define ADDRESS_EQ(var, expr)
> >> \
> >>({
On 2024-09-27 02:01, Boqun Feng wrote:
#define ADDRESS_EQ(var, expr)
\
({
\
bool _cmp_res = (unsigned long)(var) == (unsigned
long)
On Fri, Sep 27, 2024, at 9:30 AM, Mathieu Desnoyers wrote:
> On 2024-09-27 02:01, Boqun Feng wrote:
>> #define ADDRESS_EQ(var, expr)
>> \
>> ({
>> \
>>
On 2024-09-26 18:12, Linus Torvalds wrote:
On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser
wrote:
No, the issue introduced by the compiler optimization (or by your
original patch) is that the CPU can speculatively load from the first
pointer as soon as it has completed the load of that pointer
On Thu, Sep 26, 2024 at 09:54:33AM -0700, Linus Torvalds wrote:
> On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser
> wrote:
> >
> > Boqun seems to be unhappy with a barrier though, because it would
> > theoretically also forbid unrelated optimizations.
>
> Well, doing a "barrier()" is kind of a bi
On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser
wrote:
>
> No, the issue introduced by the compiler optimization (or by your
> original patch) is that the CPU can speculatively load from the first
> pointer as soon as it has completed the load of that pointer:
You mean the compiler can do it. The
On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser
wrote:
>
> Boqun seems to be unhappy with a barrier though, because it would
> theoretically also forbid unrelated optimizations.
Well, doing a "barrier()" is kind of a big hammer thing, but honestly,
I don't think we've ever seen any real situation
Am 9/26/2024 um 6:12 PM schrieb Linus Torvalds:
On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser
wrote:
No, the issue introduced by the compiler optimization (or by your
original patch) is that the CPU can speculatively load from the first
pointer as soon as it has completed the load of that
Am 9/26/2024 um 8:16 AM schrieb Mathieu Desnoyers:
On 2024-09-25 15:20, Mathieu Desnoyers wrote:
[...]
static inline
bool same_ptr(void *a, void *b)
{
asm goto (
"cmpq %[a], %[b]\n\t"
"jne %l[ne]\n\t"
: : [a] "r" (a), [b] "r" (b)
: : ne);
return t
On 2024-09-25 15:20, Mathieu Desnoyers wrote:
[...]
static inline
bool same_ptr(void *a, void *b)
{
asm goto (
"cmpq %[a], %[b]\n\t"
"jne %l[ne]\n\t"
: : [a] "r" (a), [b] "r" (b)
: : ne);
return true;
ne:
return false;
}
Based on the informatio
On 2024-09-25 15:10, Mathieu Desnoyers wrote:
[...]
Cleaner without goto in the user code:
#include
#include
static inline
bool same_ptr(void *a, void *b)
{
asm goto (
"cmpq %[a], %[b]\n\t"
"jne %l[ne]\n\t"
: : [a] "r" (a), [b] "r" (b)
: : ne);
return t
On 2024-09-25 14:47, Mathieu Desnoyers wrote:
[...]
Like so:
#include
#define __str_1(x) #x
#define __str(x) __str_1(x)
/* x86-64 */
#define bne_ptr(_a, _b, _label) \
asm goto ( \
"cmpq %[a], %[b]\n\t" \
"jne %l[" __str(_label) "]\n\t" \
: : [a] "r" (_a),
Am 9/25/2024 um 1:59 PM schrieb Mathieu Desnoyers:
On 2024-09-25 12:45, Boqun Feng wrote:
On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote:
Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
Hi Jonas,
Of
course, if we are really worried about compilers being too "smart"
Ah, I
On 2024-09-25 14:16, Boqun Feng wrote:
On Wed, Sep 25, 2024 at 01:59:06PM +0200, Mathieu Desnoyers wrote:
On 2024-09-25 12:45, Boqun Feng wrote:
On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote:
Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
Hi Jonas,
Of
course, if we are rea
On Wed, Sep 25, 2024 at 01:59:06PM +0200, Mathieu Desnoyers wrote:
> On 2024-09-25 12:45, Boqun Feng wrote:
> > On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote:
> > >
> > >
> > > Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
> > > > Hi Jonas,
> > > >
> > > > Of
> > > > course, if
On 2024-09-25 12:45, Boqun Feng wrote:
On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote:
Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
Hi Jonas,
Of
course, if we are really worried about compilers being too "smart"
Ah, I see you know me better and better...
we can always d
On Wed, Sep 25, 2024 at 12:11:52PM +0200, Jonas Oberhauser wrote:
>
>
> Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
> > Hi Jonas,
> >
> > Of
> > course, if we are really worried about compilers being too "smart"
>
> Ah, I see you know me better and better...
>
> > we can always do the compari
Am 9/25/2024 um 12:02 PM schrieb Boqun Feng:
Hi Jonas,
Of
course, if we are really worried about compilers being too "smart"
Ah, I see you know me better and better...
we can always do the comparison in asm code, then compilers don't know
anything of the equality between 'ptr' and 'head -
Hi Jonas,
On Fri, Sep 20, 2024 at 09:41:15AM +0200, Jonas Oberhauser wrote:
>
>
> Am 9/17/2024 um 4:33 PM schrieb Boqun Feng:
> > +static inline void *__hazptr_tryprotect(hazptr_t *hzp,
> > + void *const *p,
> > + unsigned long
Am 9/19/2024 um 10:30 PM schrieb Jonas Oberhauser:
Am 9/19/2024 um 2:12 AM schrieb Jann Horn:
On Tue, Sep 17, 2024 at 4:33 PM Boqun Feng wrote:
Hazard pointers [1] provide a way to dynamically distribute refcounting
and can be used to improve the scalability of refcounting without
signif
Am 9/17/2024 um 4:33 PM schrieb Boqun Feng:
+static inline void *__hazptr_tryprotect(hazptr_t *hzp,
+ void *const *p,
+ unsigned long head_offset)
+{
+ void *ptr;
+ struct callback_head *head;
+
+ ptr
Am 9/19/2024 um 2:12 AM schrieb Jann Horn:
On Tue, Sep 17, 2024 at 4:33 PM Boqun Feng wrote:
Hazard pointers [1] provide a way to dynamically distribute refcounting
and can be used to improve the scalability of refcounting without
significant space cost.
+static inline void *__hazptr_try
2024年9月20日 02:58，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 09:57:12PM +0800, Alan Huang wrote:
> [...]
>>>
>>> I think you're right. (Although the node will be eventually deleted at
>>> cleanup_hazptr_context(), however there could be a long-live
>>> hazptr_context). It should be:
>>>
>>> h
On Thu, Sep 19, 2024 at 09:57:12PM +0800, Alan Huang wrote:
[...]
> >
> > I think you're right. (Although the node will be eventually deleted at
> > cleanup_hazptr_context(), however there could be a long-live
> > hazptr_context). It should be:
> >
> > hazptr_t val = smp_load_acquire(&hzcp->slots
Am 9/19/2024 um 8:56 AM schrieb Boqun Feng:
On Wed, Sep 18, 2024 at 11:17:37PM +0800, Alan Huang wrote:
[...]
+#define hazptr_tryprotect(hzp, gp, field) (typeof(gp))__hazptr_tryprotect(hzp,
(void **)&(gp), offsetof(typeof(*gp), field))
+#define hazptr_protect(hzp, gp, field) ({ \
+ typeof(gp
2024年9月19日 15:10，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
Am 9/17/2024 um 4:33 PM schrieb Boqun Feng:
+#define hazptr_protect(hzp, gp, field) ({ \
+ typeof(gp) ___p;\
+ \
+ ___p = hazptr_trypro
2024年9月19日 15:10，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
2024年9月19日 15:10，Boqun Feng wrote：
>
> On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
>> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>>
>>> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
>>> *tree,
>>> +
On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
> +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
> *tree,
> + struct hazptr_context *hzcp)
> +{
> + lockdep_assert_held(hzcp->lock);
> +
> + for (int i = 0; i <
On Wed, Sep 18, 2024 at 11:17:37PM +0800, Alan Huang wrote:
[...]
> > +#define hazptr_tryprotect(hzp, gp, field)
> > (typeof(gp))__hazptr_tryprotect(hzp, (void **)&(gp), offsetof(typeof(*gp),
> > field))
> > +#define hazptr_protect(hzp, gp, field) ({ \
> > + typeof(gp) ___p; \
> > + \
> > + ___p
On Thu, Sep 19, 2024 at 02:39:13PM +0800, Lai Jiangshan wrote:
> On Tue, Sep 17, 2024 at 10:34 PM Boqun Feng wrote:
>
> > +static void hazptr_context_snap_readers_locked(struct hazptr_reader_tree
> > *tree,
> > + struct hazptr_context *hzcp)
> > +{
>
On Tue, Sep 17, 2024 at 4:33 PM Boqun Feng wrote:
> Hazard pointers [1] provide a way to dynamically distribute refcounting
> and can be used to improve the scalability of refcounting without
> significant space cost.
> +static inline void *__hazptr_tryprotect(hazptr_t *hzp,
> +
2024年9月17日 22:33，Boqun Feng wrote：
>
> Hazard pointers [1] provide a way to dynamically distribute refcounting
> and can be used to improve the scalability of refcounting without
> significant space cost.
>
> Hazard pointers are similar to RCU: they build the synchronization
> between two part,
On 2024-09-17 16:33, Boqun Feng wrote:
[...]
The synchronization between readers and updaters is built around "hazard
pointer slots": a slot readers can use to store a pointer value.
Reader side protection:
1. Read the value of a pointer to the target data element.
2. Store it to a h
Hazard pointers [1] provide a way to dynamically distribute refcounting
and can be used to improve the scalability of refcounting without
significant space cost.
Hazard pointers are similar to RCU: they build the synchronization
between two part, readers and updaters. Readers are refcount users, t
55 matches
Mail list logo
