Eric Dumazet writes:
[...]
> Since this sock_gen_cookie() is lock-free and IRQ ready, it should be
> not be a problem to pretend it works with a const socket.
>
> I am a bit unsure about revealing in socket cookie a precise count of
> sockets created on a netns. Some attackers might use this in
On Wed, 2017-10-11 at 11:21 -0700, Alexei Starovoitov wrote:
> On Wed, Oct 11, 2017 at 06:31:45AM -0700, Eric Dumazet wrote:
> > On Tue, 2017-10-10 at 19:56 -0700, Alexei Starovoitov wrote:
> >
> > > actually we hit that too for completely different tracing use case.
> > > Indeed would be good to
On Wed, Oct 11, 2017 at 06:31:45AM -0700, Eric Dumazet wrote:
> On Tue, 2017-10-10 at 19:56 -0700, Alexei Starovoitov wrote:
>
> > actually we hit that too for completely different tracing use case.
> > Indeed would be good to generate socket cookie unconditionally
> > for all sockets. I don't thi
On Tue, 2017-10-10 at 19:56 -0700, Alexei Starovoitov wrote:
> actually we hit that too for completely different tracing use case.
> Indeed would be good to generate socket cookie unconditionally
> for all sockets. I don't think there is any harm.
>
Simply call sock_gen_cookie() when needed.
If
On Tue, Oct 10, 2017 at 11:58:53PM +0200, Hannes Frederic Sowa wrote:
> Alexei Starovoitov writes:
>
> > On Mon, Oct 09, 2017 at 10:35:47PM -0700, Cong Wang wrote:
>
> [...]
>
> >> + trace_tcp_retransmit_skb(sk, skb, segs);
> >
> > I'm happy to see new tracepoints being added to tcp st
On Tue, Oct 10, 2017 at 02:37:11PM -0700, Cong Wang wrote:
> >
> > More concrete, if you can make this trace_tcp_retransmit_skb() to record
> > sk, skb pointers and err code at the end of __tcp_retransmit_skb() it will
> > solve
> > our need as well.
>
>
> Note, currently I only call trace_tcp_r
Alexei Starovoitov writes:
> On Mon, Oct 09, 2017 at 10:35:47PM -0700, Cong Wang wrote:
[...]
>> +trace_tcp_retransmit_skb(sk, skb, segs);
>
> I'm happy to see new tracepoints being added to tcp stack, but I'm concerned
> with practical usability of them.
> Like the above tracepoint
On Tue, Oct 10, 2017 at 10:38 AM, Alexei Starovoitov
wrote:
>
> I'm happy to see new tracepoints being added to tcp stack, but I'm concerned
> with practical usability of them.
> Like the above tracepoint definition makes it not very useful from bpf point
> of view,
> since 'sk' pointer is not re
On Mon, Oct 09, 2017 at 10:35:47PM -0700, Cong Wang wrote:
> We need a real-time notification for tcp retransmission
> for monitoring.
>
> Of course we could use ftrace to dynamically instrument this
> kernel function too, however we can't retrieve the connection
> information at the same time, fo
On Tue, Oct 10, 2017 at 4:21 AM, Eric Dumazet wrote:
> On Mon, Oct 9, 2017 at 10:35 PM, Cong Wang wrote:
>> We need a real-time notification for tcp retransmission
>> for monitoring.
>
> Hi Cong
>
> This seems to not be well defined.
>
> For example, why a retransmission triggered by TLP is not t
On Mon, Oct 9, 2017 at 10:35 PM, Cong Wang wrote:
> We need a real-time notification for tcp retransmission
> for monitoring.
Hi Cong
This seems to not be well defined.
For example, why a retransmission triggered by TLP is not traced ?
We need a real-time notification for tcp retransmission
for monitoring.
Of course we could use ftrace to dynamically instrument this
kernel function too, however we can't retrieve the connection
information at the same time, for example perf-tools [1] reads
/proc/net/tcp for socket details, which
12 matches
Mail list logo
