From bpf verifier point of view, for the code:

int kretprobe__tcp_v4_connect(struct pt_regs _ctx)
{
u32 pid = bpf_get_current_pid_tgid();
struct sock *_skpp;
skpp = currsock.lookup(&pid);
if (skpp) {
struct sock *skp = *skpp;
bpf_trace_printk("addr: %lx\n", skp->__sk_common.skc_daddr);
currsock.delete(&pid);
}
return 0;
}

After "skp = *skpp", skp becomes an unknown value since the verifier has no idea of
what the *skpp could be. hence later skp->__sk_common.skc_daddr will have
verification error.

I guess in this case that bcc rewriter could automatically convert the skp->__sk_common.sdk_addr to a bpf_probe_read since it can recognize the map value is dereferenced.

Yes, I think I know what's missing in the rewriter. Shouldn't be too hard.
On Sep 26, 2015 1:51 AM, "yonghong-song" notifications@github.com wrote:

From bpf verifier point of view, for the code:

int kretprobe__tcp_v4_connect(struct pt_regs

_ctx) { u32 pid = bpf_get_current_pid_tgid(); struct sock *_skpp;
skpp = currsock.lookup(&pid);
if (skpp) {
struct sock *skp = *skpp;
bpf_trace_printk("addr: %lx\n", skp->__sk_common.skc_daddr);
currsock.delete(&pid);
}
return 0;
}

After "skp = *skpp", skp becomes an unknown value since the verifier has
no idea of
what the *skpp could be. hence later skp->__sk_common.skc_daddr will have
verification error.

I guess in this case that bcc rewriter could automatically convert the
skp->__sk_common.sdk_addr to a bpf_probe_read since it can recognize the
map value is dereferenced.

—
Reply to this email directly or view it on GitHub
#253 (comment).

Thanks; navigating from sk to skc_daddr will likely be common, so would be good to improve.

PS, for anyone trying to understand this code... I'm doing it on kretprobe instead of kprobe for two reasons:

• I wanted the return status of the TCP connection (eg, ECONNREFUSED). However, ctx->ax in kretprobe isn't what I hoped it would be: it is always 0.
• Fetching skc_daddr on tcp_v4_connect on kprobe was always zero. I assume it's not populated on entry, but haven't read all the code to confirm. The sk is certainly populated on return.

@brendangregg , for your question above ctx->ax is always 0.
tcp_v4_connect function returning 0 means the SYNC has been successfully sent to the other side.
If SYNC is not able to sent out to the other side, ctx->ax will not be 0.

On the other hand, ctx->ax=0 in tcp_v4_connect does not mean the syscall "connect" will succeed.
If the remote site sends back a RST, the connect will fail.

In your code, I guess you still want to check ctx->ax. Otherwise, the value you tried to print may not
be populated.

I'm trying to implement

        if (ip_hdr(skb)->protocol!=IPPROTO_TCP)
                return 0;

and getting a similar error:

0: (79) r1 = *(u64 *)(r1 +104)
1: (69) r2 = *(u16 *)(r1 +196)
R1 invalid mem access 'inv'

This operation seems simple enough but after two inlined function, it expands to a number of derefences.

        struct iphdr *iph = (struct iphdr *)(skb->head + skb->network_header);
        if (iph->protocol!=IPPROTO_TCP)
                return 0;

Which fails with a similar error.

The doc for bpf_probe_read says

This happens automatically in some cases, such as dereferencing kernel variables, as bcc will rewrite the BPF program to include the necessary bpf_probe_reads().

Why is this case not covered by the compiler? Do I need to use bpf_probe_read for every dereference?