Messages in this thread | | | Date | Mon, 9 Jan 2023 10:08:33 -0500 | From | Steven Rostedt <> | Subject | Re: [External] Re: [PATCH v4] sock: add tracepoint for send recv length |
| |
On Mon, 9 Jan 2023 15:54:38 +0100 Eric Dumazet <edumazet@google.com> wrote:
> > static inline int sock_sendmsg_nosec(struct socket *sock, struct msghdr *msg) > > { > > int ret = INDIRECT_CALL_INET(sock->ops->sendmsg, inet6_sendmsg, > > inet_sendmsg, sock, msg, > > msg_data_left(msg)); > > BUG_ON(ret == -EIOCBQUEUED); > > > > if (trace_sock_send_length_enabled()) { > > A barrier() is needed here, with the current state of affairs. > > IMO, ftrace/x86 experts should take care of this generic issue ?
trace_*_enabled() is a static_branch() (aka. jump label).
It's a nop, where the if block is in the out-of-line code and skipped. When the tracepoint is enabled, it gets turned into a jump to the if block (which returns back to this location).
That is, when the tracepoint in the block gets enabled so does the above branch. Sure, there could be a race between the two being enabled, but I don't see any issue if there is. But the process to modify the jump labels, does a bunch of synchronization between the CPUs.
What barrier are you expecting?
-- Steve
> > > > > call_trace_sock_send_length(sock->sk, sock->sk->sk_family, > > sock->sk->sk_protocol, ret, 0); > > } > > return ret; > > } > > > > What do you think?
| |