From: Eric Dumazet
Date: Thu, 23 Apr 2015 09:48:12 -0700
> On Thu, 2015-04-23 at 09:16 -0700, Eric Dumazet wrote:
>> On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
>> > From: Eric Dumazet
>> > Date: Thu, 23 Apr 2015 07:02:47 -0700
>> >
>> > > +if (!tcp_send_head(sk)) {
>
On Thu, 2015-04-23 at 09:16 -0700, Eric Dumazet wrote:
> On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
> > From: Eric Dumazet
> > Date: Thu, 23 Apr 2015 07:02:47 -0700
> >
> > > + if (!tcp_send_head(sk)) {
> > > + tp->snd_nxt++;
> > > + return;
> >
On Thu, 2015-04-23 at 11:54 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Thu, 23 Apr 2015 07:02:47 -0700
>
> > + if (!tcp_send_head(sk)) {
> > + tp->snd_nxt++;
> > + return;
> > + }
>
> I'm not so sure about this. Why is this ne
From: Eric Dumazet
Date: Thu, 23 Apr 2015 07:02:47 -0700
> + if (!tcp_send_head(sk)) {
> + tp->snd_nxt++;
> + return;
> + }
I'm not so sure about this. Why is this needed?
Otherwise patch looks fine to me.
--
To unsubscribe from
On Thu, 2015-04-23 at 08:48 -0500, Josh Hunt wrote:
> On 04/21/2015 07:09 PM, Eric Dumazet wrote:
> >
> > Note that this patch adds a deadlock possibility in some stress
> > situations.
> >
> > If a process owning some tcp socket dies, and tcp_mem[2] is already hit,
> > all sk_stream_alloc_skb() ca
On 04/21/2015 07:09 PM, Eric Dumazet wrote:
Note that this patch adds a deadlock possibility in some stress
situations.
If a process owning some tcp socket dies, and tcp_mem[2] is already hit,
all sk_stream_alloc_skb() can return NULL and we loop in tcp_send_fin(),
making no progress because we
On Tue, 2015-03-24 at 01:11 -0500, Josh Hunt wrote:
> On 03/24/2015 01:10 AM, David Miller wrote:
> > From: Josh Hunt
> > Date: Fri, 20 Mar 2015 12:36:24 -0500
> >
> >> Would it be possible to queue up 355a901e6cf1 (tcp: make connect()
> >> mem charging friendly) for stable as well? That is the co
