Acked-by: Jon Maxwell
Thanks for fixing that Eric.
On Fri, Sep 27, 2019 at 8:42 AM Eric Dumazet wrote:
>
> Yuchung Cheng and Marek Majkowski independently reported a weird
> behavior of TCP_USER_TIMEOUT option when used at connect() time.
>
> When the TCP_USER_TIMEOUT is reached, tcp_write_tim
Sounds good Eric. Thanks
On Tue, Jun 11, 2019 at 8:34 AM Eric Dumazet wrote:
>
> On Mon, Jun 10, 2019 at 3:27 PM Jonathan Maxwell wrote:
> >
> > Thanks for fixing that Eric.
>
> Hi Jonathan.
>
> There is no bug actually, at least not on sk->sk_mark part.
>
&
Thanks for fixing that Eric.
On Tue, Jun 11, 2019 at 7:45 AM Eric Dumazet wrote:
>
> TCP can send ACK packets on behalf of SYN_RECV sockets.
>
> tcp_v4_send_ack() and tcp_v6_send_response() incorrectly
> dereference sk->sk_mark for non TIME_WAIT sockets.
>
> This field is not defined for SYN_RECV
On Sat, May 26, 2018 at 6:43 AM, David Miller wrote:
> From: Jon Maxwell
> Date: Fri, 25 May 2018 07:38:29 +1000
>
>> Fixup the checksum for CHECKSUM_COMPLETE when pulling skbs on RX path.
>> Otherwise we get splats when tc mirred is used to redirect packets to ifb.
>>
>> Before fix:
>>
>> nic: h
On Thu, May 10, 2018 at 3:45 PM, Eric Dumazet wrote:
>
>
> On 05/09/2018 10:21 PM, Jon Maxwell wrote:
>
> ...
>
>> if (th->rst)
>> @@ -723,11 +724,17 @@ static void tcp_v4_send_reset(const struct sock *sk,
>> struct sk_buff *skb)
>> arg.tos = ip_hdr(skb)->tos;
>> arg.uid = sock_
On Thu, May 10, 2018 at 1:32 PM, Eric Dumazet wrote:
>
>
> On 05/09/2018 07:07 PM, Jon Maxwell wrote:
>> Aidan McGurn from Openwave Mobility systems reported the following bug:
>>
>> "Marked routing is broken on customer deployment. Its effects are large
>> increase in Uplink retransmissions cause
On Fri, Mar 10, 2017 at 3:23 PM, Eric Dumazet wrote:
> On Fri, 2017-03-10 at 14:31 +1100, Jon Maxwell wrote:
>> As Eric Dumazet pointed out this also needs to be fixed in IPv6.
>> v1: Contains the IPv6 patch as well.
>
>> Fixes: ceb3320610d6 ("ipv4: Kill routes during PMTU/redirect updates.")
>> C
On Thu, Mar 9, 2017 at 3:40 PM, Eric Dumazet wrote:
> On Thu, 2017-03-09 at 14:42 +1100, Jonathan Maxwell wrote:
>> Sorry let me resend in plain text mode.
>>
>> On Thu, Mar 9, 2017 at 1:10 PM, Eric Dumazet wrote:
>> > On Thu, 2017-03-09 at 12:15 +1100, Jon Maxwe
Sorry let me resend in plain text mode.
On Thu, Mar 9, 2017 at 1:10 PM, Eric Dumazet wrote:
> On Thu, 2017-03-09 at 12:15 +1100, Jon Maxwell wrote:
>> We have seen a few incidents lately where a dst_enty has been freed
>> with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
>>
On Sun, Feb 5, 2017 at 4:00 AM, Parav Pandit wrote:
> This patch makes use of is_vlan_dev() function instead of flag
> comparison which is exactly done by is_vlan_dev() helper function.
>
> Signed-off-by: Parav Pandit
> Reviewed-by: Daniel Jurgens
> ---
> drivers/infiniband/core/cma.c
On Wed, Dec 14, 2016 at 11:15 AM, Thomas Falcon
wrote:
> Include calculations to compute the number of segments
> that comprise an aggregated large packet.
>
> Signed-off-by: Thomas Falcon
Reviewed-by: Jonathan Maxwell
> ---
> drivers/net/ethernet/ibm/ibmveth.c | 12
On Thu, Nov 3, 2016 at 8:40 AM, Brian King wrote:
> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
>> On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>>> We recently encountered a bug where a few customers using ibmveth on the
>>> same LPAR hit an issue where a TCP session hung when large recei
On Fri, Oct 28, 2016 at 5:08 AM, Eric Dumazet wrote:
> On Thu, 2016-10-27 at 12:54 -0500, Thomas Falcon wrote:
>> On 10/27/2016 10:26 AM, Eric Dumazet wrote:
>> > On Wed, 2016-10-26 at 11:09 +1100, Jon Maxwell wrote:
>> >> We recently encountered a bug where a few customers using ibmveth on the
>>
>> + u16 hdr_len = ETH_HLEN + sizeof(struct tcphdr);
> Compiler may optmize this, but maybe move hdr_len to [*] ?>
There are other places in the stack where a u16 is used for the
same purpose. So I'll rather stick to that convention.
I'll make the other formatting changes you suggested and
r
> I personally think that drivers need to synchronize such things
> internally. They are the only entity which knows when it's "OK"
> to do whatever the netpoll method does, and they are also the only
> entity which can properly synchronize such checks.
Thanks agreed. I am testing the following i
> What if the carrier check passes, and then the chip reset starts on
> another cpu? You'll have the same problem.
Okay, let me see if I can come up with a better way to mitigate this.
On Tue, Aug 11, 2015 at 2:22 PM, David Miller wrote:
> From: Jon Maxwell
> Date: Tue, 11 Aug 2015 11:32:26 +1
> On Tue, 2015-07-07 at 14:22 +1000, Jon Maxwell wrote:
>
>
> > @@ -4887,6 +4884,7 @@ static inline void tcp_data_snd_check(struct sock
> > *sk)
> > static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
> > {
> > struct tcp_sock *tp = tcp_sk(sk);
> > +const struct dst_entry
17 matches
Mail list logo
