From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFC99C4360F for ; Tue, 2 Apr 2019 11:48:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 73F8A20857 for ; Tue, 2 Apr 2019 11:48:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="idsT6mwl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730785AbfDBLs1 (ORCPT ); Tue, 2 Apr 2019 07:48:27 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:39449 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726903AbfDBLs0 (ORCPT ); Tue, 2 Apr 2019 07:48:26 -0400 Received: by mail-qt1-f196.google.com with SMTP id t28so14763363qte.6; Tue, 02 Apr 2019 04:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+epkGDPTnbfnRX+n7GHbRr4Vo3+r1zcq8jMI4fxFr+Y=; b=idsT6mwlWb4yqVGopv+2lCPl5LpCUOJBJz4bZlovN7XRJ6cdJaHJpWeUuFySDEtZl4 TKWmS7gyArNDOf3OGRatAboESY1mzPy7dhCcDogGsJNGk23qDn91HGVwEJp75nIrtnCi 22mu9cJSOQ0T4GqQYBTjVdjIeBWMNNSgmkOusWG4kheI135iVeQ6FICsX42lcqR9XvXr EpwrsGMcr2Gc4dUKx0A8NnkYykRIAU5s/XEHahAc5de8bzI6JC18DtRfeOmfv7UnA5+F d4mCGmzXX//2hOfeLe6FWfEKTKH4KVsV8sKLqwYRReEexjEgcQPzAmwW+Pf7CtyPrI9o nRTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+epkGDPTnbfnRX+n7GHbRr4Vo3+r1zcq8jMI4fxFr+Y=; b=Tgko6kk0zXRXR/xhp6pyCM8SBlG667V7MaePem6MAfLG6PKav0rmyIykDHbFxTH9hJ /KrhMGDbFQBApEKNFjwNHUbzeaCCQfG4E7xZnLRR4QyvBN4/r6rTvfuJaJ0Bq5ZQfhIa igqpIuevjQqhfL0CR6fnZ5OvKQsD0AdPz4k3g00lW1V5wcOZmnyl/ZX7cGARzOYTyCL+ +QXfjfAtCQHcQsxKYWb25Nky5moa8ZIh9KBROYbNqlwQAI/UwawjW/T6orQFwoSKO8h4 e8ZyR42gy6oL7Ss2YB4iAs32JFxLijN6Cu4t8tstPjwca8XDY1lYRGsCEEbA6ZicO7Hl itaQ== X-Gm-Message-State: APjAAAWsKOj/0Ga0PiaHjOp2uthiH1ZprflvRxyZ5dcmvnxw7xo8qTK4 O3YNugIwnx2Ez5NHZl4b/5g= X-Google-Smtp-Source: APXvYqxclthnS/HGLP/+TwTSmg46Pbu42xoez5uZtdKinAyUe/yz6kUaP9Y/IzSprOv2/stKM5z+xQ== X-Received: by 2002:a0c:91cc:: with SMTP id r12mr57122710qvr.35.1554205704923; Tue, 02 Apr 2019 04:48:24 -0700 (PDT) Received: from localhost.localdomain ([2001:1284:f016:bb35:c67:a893:4c8b:bc69]) by smtp.gmail.com with ESMTPSA id s66sm1822600qkd.90.2019.04.02.04.48.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 04:48:24 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id 63C66180C43; Tue, 2 Apr 2019 08:48:21 -0300 (-03) Date: Tue, 2 Apr 2019 08:48:21 -0300 From: Marcelo Ricardo Leitner To: Xin Long Cc: network dev , linux-sctp@vger.kernel.org, Neil Horman , davem@davemloft.net, Matteo Croce , Vladis Dronov Subject: Re: [PATCH net-next 2/2] sctp: implement memory accounting on rx path Message-ID: <20190402114821.GQ16876@localhost.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Mar 31, 2019 at 04:53:47PM +0800, Xin Long wrote: > sk_forward_alloc's updating is also done on rx path, but to be consistent > we change to use sk_mem_charge() in sctp_skb_set_owner_r(). > > In sctp_eat_data(), it's not enough to check sctp_memory_pressure only, > which doesn't work for mem_cgroup_sockets_enabled, so we change to use > sk_under_memory_pressure(). > > When it's under memory pressure, sk_mem_reclaim() and sk_rmem_schedule() > should be called on both RENEGE or CHUNK DELIVERY path exit the memory > pressure status as soon as possible. > > Note that sk_rmem_schedule() is using datalen to make things easy there. > > Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner > --- > include/net/sctp/sctp.h | 2 +- > net/sctp/sm_statefuns.c | 6 ++++-- > net/sctp/ulpevent.c | 19 ++++++++----------- > net/sctp/ulpqueue.c | 3 ++- > 4 files changed, 15 insertions(+), 15 deletions(-) > > diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h > index 1d13ec3..eefdfa5 100644 > --- a/include/net/sctp/sctp.h > +++ b/include/net/sctp/sctp.h > @@ -421,7 +421,7 @@ static inline void sctp_skb_set_owner_r(struct sk_buff *skb, struct sock *sk) > /* > * This mimics the behavior of skb_set_owner_r > */ > - sk->sk_forward_alloc -= event->rmem_len; > + sk_mem_charge(sk, event->rmem_len); > } > > /* Tests if the list has one and only one entry. */ > diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c > index c9ae340..7dfc34b 100644 > --- a/net/sctp/sm_statefuns.c > +++ b/net/sctp/sm_statefuns.c > @@ -6412,13 +6412,15 @@ static int sctp_eat_data(const struct sctp_association *asoc, > * in sctp_ulpevent_make_rcvmsg will drop the frame if we grow our > * memory usage too much > */ > - if (*sk->sk_prot_creator->memory_pressure) { > + if (sk_under_memory_pressure(sk)) { > if (sctp_tsnmap_has_gap(map) && > (sctp_tsnmap_get_ctsn(map) + 1) == tsn) { > pr_debug("%s: under pressure, reneging for tsn:%u\n", > __func__, tsn); > deliver = SCTP_CMD_RENEGE; > - } > + } else { > + sk_mem_reclaim(sk); > + } > } > > /* > diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c > index 8cb7d98..c2a7478 100644 > --- a/net/sctp/ulpevent.c > +++ b/net/sctp/ulpevent.c > @@ -634,8 +634,9 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc, > gfp_t gfp) > { > struct sctp_ulpevent *event = NULL; > - struct sk_buff *skb; > - size_t padding, len; > + struct sk_buff *skb = chunk->skb; > + struct sock *sk = asoc->base.sk; > + size_t padding, datalen; > int rx_count; > > /* > @@ -646,15 +647,12 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc, > if (asoc->ep->rcvbuf_policy) > rx_count = atomic_read(&asoc->rmem_alloc); > else > - rx_count = atomic_read(&asoc->base.sk->sk_rmem_alloc); > + rx_count = atomic_read(&sk->sk_rmem_alloc); > > - if (rx_count >= asoc->base.sk->sk_rcvbuf) { > + datalen = ntohs(chunk->chunk_hdr->length); > > - if ((asoc->base.sk->sk_userlocks & SOCK_RCVBUF_LOCK) || > - (!sk_rmem_schedule(asoc->base.sk, chunk->skb, > - chunk->skb->truesize))) > - goto fail; > - } > + if (rx_count >= sk->sk_rcvbuf || !sk_rmem_schedule(sk, skb, datalen)) > + goto fail; > > /* Clone the original skb, sharing the data. */ > skb = skb_clone(chunk->skb, gfp); > @@ -681,8 +679,7 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc, > * The sender should never pad with more than 3 bytes. The receiver > * MUST ignore the padding bytes. > */ > - len = ntohs(chunk->chunk_hdr->length); > - padding = SCTP_PAD4(len) - len; > + padding = SCTP_PAD4(datalen) - datalen; > > /* Fixup cloned skb with just this chunks data. */ > skb_trim(skb, chunk->chunk_end - padding - skb->data); > diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c > index 5dde921..770ff1f 100644 > --- a/net/sctp/ulpqueue.c > +++ b/net/sctp/ulpqueue.c > @@ -1106,7 +1106,8 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk, > freed += sctp_ulpq_renege_frags(ulpq, needed - freed); > } > /* If able to free enough room, accept this chunk. */ > - if (freed >= needed) { > + if (sk_rmem_schedule(asoc->base.sk, chunk->skb, needed) && > + freed >= needed) { > int retval = sctp_ulpq_tail_data(ulpq, chunk, gfp); > /* > * Enter partial delivery if chunk has not been > -- > 2.1.0 >