bpf_get_prandom_u32 has the wrong type and can't be called

[goldshtn]

It seems that bpf_get_prandom_u32 is declared as a u32 * in the headers. That's due to missing parens.

- static u32 (*bpf_get_prandom_u32) =
+ static u32 (*bpf_get_prandom_u32)(void) =

Also, after fixing the signature, a BPF program that uses this function doesn't pass verification. I get the following error:

bpf: Invalid argument                                                                
0: (bf) r6 = r1                                                                      
1: (85) call 14                                                                      
2: (67) r0 <<= 32                                                                    
3: (77) r0 >>= 32                                                                    
4: (15) if r0 == 0x437c goto pc+27                                                   
R0=inv R6=ctx R10=fp                                                                
5: (85) call 7                                                                       
unknown func 7 

[drzaeus77]

Oops, obvious syntax issue. However, the second issue is there because this func is only exported to networking programs.

[goldshtn]

Oh. Is there any particular reason for that?

[4ast]

it's not exposed to tracing, because there was no use case for it yet. could you describe how you want to use it?

[goldshtn]

Well, for the trace tool, it could be useful if the user could do something like ($random & 7 == 0) to sample traces. It could be done by looking at the time stamp too, I guess.

[goldshtn]

@4ast So, do you think it will be exposed to tracing programs in the future, or do you not see this use case as compelling?

[4ast]

I would like to see a real use case when random sampling is actually needed. Do you want to prepare and test a kernel patch?

[goldshtn]

I've never done it, but I'm willing to learn. Is there some kind of Kernel Patches for Dummies that you recommend?

Regarding a test case, @brendangregg - what do you think?

[4ast]

the real use case came up. When we're doing sampling in kprobes and tracepoints it's often useful not to process every event and instead randomly drop most of them. arraymap counter can be used as token but random is easier to use. timestamp doesn't have entropy when there are lots of events. So pretty much what @goldshtn said. We just faced the issue on our own :)

[pchaigno]

Fixed with 8937bd80fce6.