Re: [PATCH 4.14] tcp: refine memory limit test in tcp_fragment()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 25, 2019 at 01:29:35PM -0700, Josh Hunt wrote:
> On 6/25/19 1:26 PM, Sasha Levin wrote:
> > On Tue, Jun 25, 2019 at 01:19:37PM -0400, Josh Hunt wrote:
> > > Backport of dad3a9314ac95dedc007bc7dacacb396ea10e376:
> > 
> > You probably meant b6653b3629e5b88202be3c9abc44713973f5c4b4 here.
> 
> I wasn't sure if I should reference the upstream commit or stable commit.

The upstream commit please.

> dad3a9314 is the version of the commit from linux-4.14.y. There may be a
> similar issue with the Fixes tag below since that also references the 4.14
> vers of the change.
> 
> > 
> > > tcp_fragment() might be called for skbs in the write queue.
> > > 
> > > Memory limits might have been exceeded because tcp_sendmsg() only
> > > checks limits at full skb (64KB) boundaries.
> > > 
> > > Therefore, we need to make sure tcp_fragment() wont punish applications
> > > that might have setup very low SO_SNDBUF values.
> > > 
> > > Backport notes:
> > > Initial version used tcp_queue type which is not present in older
> > > kernels,
> > > so added a new arg to tcp_fragment() to determine whether this is a
> > > retransmit or not.
> > > 
> > > Fixes: 9daf226ff926 ("tcp: tcp_fragment() should apply sane memory
> > > limits")
> > > Signed-off-by: Josh Hunt <johunt@xxxxxxxxxx>
> > > Reviewed-by: Jason Baron <jbaron@xxxxxxxxxx>
> > > ---
> > > 
> > > Eric/Greg - This applies on top of v4.14.130. I did not see anything come
> > > through for the older (<4.19) stable kernels yet. Without this change
> > > Christoph Paasch's packetrill script (https://lore.kernel.org/netdev/CALMXkpYVRxgeqarp4gnmX7GqYh1sWOAt6UaRFqYBOaaNFfZ5sw@xxxxxxxxxxxxxx/)
> > > 
> > > will fail on 4.14 stable kernels, but passes with this change.
> > 
> > Eric, it would be great if you could Ack this, it's very different from
> > your original patch.
> 
> Yes, that would be great.

I would prefer if this looks a bit more like the upstream fix, perhaps a
backport of the function that added the "direction" of the packet first,
and then Eric's patch?  As it is, this patch adds a different parameter
to the function than what is in Linus's tree, and I bet will cause
problems at some later point in time.

thanks,

greg k-h



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux