On Wed, Jul 18, 2018 at 8:01 AM, Pablo Alvarez via Lists.Iovisor.Org
<palvarez=akamai.com@...> wrote:

Hi Daniel,

Yes. If you look at the bug report, you will see that what it actually
returns is some form of the increment. that is,

__sync_add_and_fetch(myptr, increment)

returns either increment or (increment * 2) (I am not sure which right now)

The fact that other builtins don't compile with LLVM is not too
surprising, given that it's a very restricted subset of C. The fact that
something does compile but then does not produce the promised result...
that's a little more of an issue!

Are there people on this list who have worked on the LLVM BPF compiler?
I might be willing to try to tackle fixing the bug, but I would need
some guidance...

Pablo,

I added the below comment in the bug report:

===

The table description for bpf_xadd operation is at BPFInstrInfo.td:

// Atomics
class XADD<BPFWidthModifer SizeOp, string OpcodeStr, PatFrag OpNode>
: TYPE_LD_ST<BPF_XADD.Value, SizeOp.Value,
(outs GPR:$dst),
(ins MEMri:$addr, GPR:$val),
"lock *("#OpcodeStr#" *)($addr) += $val",
[(set GPR:$dst, (OpNode ADDRri:$addr, GPR:$val))]> {
bits<4> dst;
bits<20> addr;

let Inst{51-48} = addr{19-16}; // base reg
let Inst{55-52} = dst;
let Inst{47-32} = addr{15-0}; // offset
let BPFClass = BPF_STX;
}

let Constraints = "$dst = $val" in {
def XADD32 : XADD<BPF_W, "u32", atomic_load_add_32>;
def XADD64 : XADD<BPF_DW, "u64", atomic_load_add_64>;
// undefined def XADD16 : XADD<1, "xadd16", atomic_load_add_16>;
// undefined def XADD8 : XADD<2, "xadd8", atomic_load_add_8>;
}
===

Please feel free to take a look how to address this issue.
I can help discussion/review along the way.

Thanks!

Yonghong

Best

Pablo Alvarez

On 07/18/18 09:27, Daniel Zozin wrote:

Hi Pablo,
I'm facing the same problem by compiling and running on kernel 4.15.
Calls to __sync_fetch_and_add keeps returning the same value while the
actual value has been incremented.
Also I add __sync_val_compare_and_swap to your list of primitives
generating compiling errors.

I Investigated a bit but I have no clue on how this can be fixed.

Daniel

On Wed, Jul 18, 2018 at 1:46 PM, Pablo Alvarez via Lists.Iovisor.Org
<https://urldefense.proofpoint.com/v2/url?u=http-3A__Lists.Iovisor.Org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=0Y4-Ozye8rzL2OdOod5_xTXo5tWHsrs0CqSpjE-K1PQ&e=>
<palvarez=akamai.com@...
<mailto:palvarez=akamai.com@...>> wrote:

Hi all,

A while ago, I filed a bug with LLVM about __sync_add_and_fetch as
compiled into eBPF code.

https://bugs.llvm.org/show_bug.cgi?id=36573
<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D36573&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=A4pMWnUIf29oD7glNQD3MEAAX27WhbV-L7TCaM9koNk&e=>

Both it and __sync_fetch_and_add fail to return the correct value of
the item being incremented, returning instead the increment (or
double the increment). This means I end up with race conditions. Has
anyone else run into this, and do you have a workaround for it?

The bug report, sadly, has not been touched by anyone else.

Best

Pablo Alvarez






--
Daniel Zozin, Dr.
Research Engineer
RiSING - Robust and Secure Distributed Computing
----------------------------------------
CREATE-NET Research Center
Fondazione Bruno Kessler (FBK)
via alla Cascata 56D
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstreetmap.org_search-3Fquery-3D46.07056-252C11.15092-23map-3D19_46.07056_11.15092-26layers-3DN&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=dk6ixv2SUmNaTT-TrXohRsrqnojkqI89jO8eHVMFhbM&e=>
38123 Povo, Trento (Italy)
Tel.: +39 0461 312480
e-mail: d.zozin@... <mailto:d.zozin@...>
www: https://create-net.fbk.eu/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__create-2Dnet.fbk.eu_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=5x4K78Gqgp18NTNSXDzYVtGgk-aFnm2lzGr5F5OlXNo&m=OAuCIM_YEJpjFDD-bT0wDxmA_cUJTH23eKW9r-qXzPs&s=HU2BzKZl_Wb0rxi6vLbplXVWa-e4N2f1PD3e82TAk28&e=>
GPG KEY: 0x6F66193EC7034588

--
Le informazioni contenute nella presente comunicazione sono di
natura privata e come tali sono da considerarsi riservate ed
indirizzate esclusivamente ai destinatari indicati e per le finalità
strettamente legate al relativo contenuto. Se avete ricevuto questo
messaggio per errore, vi preghiamo di eliminarlo e di inviare una
comunicazione all’indirizzo e-mail del mittente.
--
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you received this in error, please contact the sender and
delete the material.

On Wed, Jul 18, 2018 at 8:01 AM, Pablo Alvarez via Lists.Iovisor.Org
<palvarez=akamai.com@...> wrote:

Hi Daniel,

Yes. If you look at the bug report, you will see that what it actually
returns is some form of the increment. that is,

__sync_add_and_fetch(myptr, increment)

I added a comment to bugzilla.
Thank you for bringing it up.
It was considered a known quirk before, but we should improve it.
__sync_add_and_fetch semantics are cleaner and more useful
than what we have today.

Hi Daniel,

Yes. If you look at the bug report, you will see that what it actually
returns is some form of the increment. that is,

__sync_add_and_fetch(myptr, increment)

returns either increment or (increment * 2) (I am not sure which right now)

The fact that other builtins don't compile with LLVM is not too
surprising, given that it's a very restricted subset of C. The fact that
something does compile but then does not produce the promised result...
that's a little more of an issue!

Are there people on this list who have worked on the LLVM BPF compiler?
I might be willing to try to tackle fixing the bug, but I would need
some guidance...

Best

Pablo Alvarez

--

Hi all,

A while ago, I filed a bug with LLVM about __sync_add_and_fetch as compiled into eBPF code.

https://bugs.llvm.org/show_bug.cgi?id=36573

Both it and __sync_fetch_and_add fail to return the correct value of the item being incremented, returning instead the increment (or double the increment). This means I end up with race conditions. Has anyone else run into this, and do you have a workaround for it?

The bug report, sadly, has not been touched by anyone else.

Best

Pablo Alvarez