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.8 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_GIT 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 D8EB3C43381 for ; Sun, 31 Mar 2019 08:54:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7787206DD for ; Sun, 31 Mar 2019 08:54:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="uGEu+8mG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726834AbfCaIyE (ORCPT ); Sun, 31 Mar 2019 04:54:04 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:35733 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725888AbfCaIyE (ORCPT ); Sun, 31 Mar 2019 04:54:04 -0400 Received: by mail-pg1-f195.google.com with SMTP id g8so3241062pgf.2; Sun, 31 Mar 2019 01:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=OTvJEiWWeRWRw/6kD2dJWD6ACZT18vcTU19HeK3kC+U=; b=uGEu+8mGXqJtCLbFXQu/qsTHHFAFhVNLawkqmtLis7aOYU/37a+I69AXhmZddpGaR7 ALYIBFEdbvgxz/CeUsJJq6QN6bOWVAVx4/NYC1sVfAoscYshd9ON7FsZS1Bdgv7Y99Ks jFc7xEqMg75pR6L2NDsfP5OMaM6WMX7my39JKtF1MsDr4PntFSe8OXgfxSc0pdC8YlPt scXz4Uvm3lVEML5CMfGZtSQdDjaMJSoTuq2iSgk/zfh9E60e3yGkeL/6Z9b+/haMuSqb 61rWzzJBNhTKXeq+z9svu/EapRv9Ts9qrOFCVS8CLSh7OnFXlciRbZLVycCv5c9UDUkl +j3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=OTvJEiWWeRWRw/6kD2dJWD6ACZT18vcTU19HeK3kC+U=; b=NNoU65E8WpmqoPzDcACspvP+N5jC7JCIOwjE6oIfw00mWSWMibeVmErl2LZeKI5xil pKGj1j0zWseFjDrVwho15I0nwEw61ytklyRN848N71NYDdIUw9mTBA7P06MsShtsLOSk itmqCRk2aXgM2pnjwy/9X3yNaYlakwWQZzqK5Xz3kN3XgolwTohsiSLQugit9fYtYUPK 9h3mQKQrkW5sOEL07rrcWNMBVpMSMchDdTSdmu04mrJ1RwqypXvZCM9hkMADUKBA1iaK UewcSmvrrAXjjepeIxt05ygCRhSvtN8uM+J3xm+BHlxqJYC+34SdJnWBHJWlETvluVkQ HlQg== X-Gm-Message-State: APjAAAWIuLh+gxgJON4Rda+hnaT6lNimp2hnHLnr7fjVJkDqcS2At1df HpHww/8ib9AXVHushTPNWo9igeoAV6M= X-Google-Smtp-Source: APXvYqyj4ty5LQ7AUm9v0D4a0xc2c76pGVddB/nLJL9S5NnMi8xB+PNKPQXbzwBoqW0Adcte9KEjOQ== X-Received: by 2002:a63:6786:: with SMTP id b128mr45533086pgc.318.1554022443712; Sun, 31 Mar 2019 01:54:03 -0700 (PDT) Received: from localhost ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id l184sm5913097pfc.98.2019.03.31.01.54.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 01:54:03 -0700 (PDT) From: Xin Long To: network dev , linux-sctp@vger.kernel.org Cc: Marcelo Ricardo Leitner , Neil Horman , davem@davemloft.net, Matteo Croce , Vladis Dronov Subject: [PATCH net-next 1/2] sctp: implement memory accounting on tx path Date: Sun, 31 Mar 2019 16:53:46 +0800 Message-Id: <57b7c29e160acf1a7e5f86ae8549b23ba8946c4b.1554022192.git.lucien.xin@gmail.com> X-Mailer: git-send-email 2.1.0 In-Reply-To: References: In-Reply-To: References: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to check if the allocated should be raised, and call sk_mem_reclaim() to check if the allocated should be reduced when it's under memory pressure. If sk_wmem_schedule() returns false, which means no memory is allowed to allocate, it will block and wait for memory to become available. Note different from tcp, sctp wait_for_buf happens before allocating any skb, so memory accounting check is done with the whole msg_len before it too. Signed-off-by: Xin Long --- net/sctp/socket.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 6140471..06c6f4a 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1913,7 +1913,10 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc, if (sctp_wspace(asoc) < (int)msg_len) sctp_prsctp_prune(asoc, sinfo, msg_len - sctp_wspace(asoc)); - if (sctp_wspace(asoc) <= 0) { + if (sk_under_memory_pressure(sk)) + sk_mem_reclaim(sk); + + if (sctp_wspace(asoc) <= 0 || !sk_wmem_schedule(sk, msg_len)) { timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT); err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len); if (err) @@ -8891,7 +8894,10 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, goto do_error; if (signal_pending(current)) goto do_interrupted; - if ((int)msg_len <= sctp_wspace(asoc)) + if (sk_under_memory_pressure(sk)) + sk_mem_reclaim(sk); + if ((int)msg_len <= sctp_wspace(asoc) && + sk_wmem_schedule(sk, msg_len)) break; /* Let another process have a go. Since we are going -- 2.1.0