Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp76245ybj; Wed, 6 May 2020 11:57:13 -0700 (PDT) X-Google-Smtp-Source: APiQypIfjJRYQhfv8aXjVBiJMIcpC2PUF8DK0Q7vgLJrpKM0LZZc7GFfzANcUV8P/4ItPG+luFGH X-Received: by 2002:a17:906:391:: with SMTP id b17mr8588128eja.91.1588791433450; Wed, 06 May 2020 11:57:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588791433; cv=none; d=google.com; s=arc-20160816; b=LpsUgTd2/plSQCpe1orZjvkgLBiquLYJJ8kklT4GTJpHqe00LYWcwNkdIVQB31BjpM kP+kIN/bPqPHM7KazlSqA6LASHVfhn3gPUKK2oB/CQGgL/KqOEgHv3oAcAhC5oOJpmXX KQu+adNzbYSTpnLbuCTh1aZovFK/yhnld36aZZ04jQYDduuaBSBHJa40h00yZE8jJTfa 77E1B4ZlFH4Ukg28VYbV20ExLfREhY0iudDe52MPOXLlULl/fCEkPSttoHN2HCiHgkB/ qpvj7BVZxT50FH8I0S1FoIq9qDSOe9xI/YyVpt7mK9ZIwgkgJ+xHLYGSqRKbg7Pgmp7p zkAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=yYsox4XTEIC0RV2xl7BO/pEy98lQgJ+z40v5ZeGBbkY=; b=gKHj3ByHDD6o99X/Y+KDl7u9WBJIuGve2gIG4JBElGPQRhifXdX9V3dBNOeZOBQHJX 3gprUj4NSSew5aTv/m4UP9z0YnTHJX/A0zEXHVbKO1TRqfB5bMQ5CDF2MbuYE9Qe2RmN oLsMlPng6qgH82L1Jci2NkqYtIHiW8r/FIEgeDBz8FHgTdaRXZ51RAtBLwAjbRoXZLu6 Q8VXFxX2h0RyImyNBkWvNf5DRvbWgbGY+MW690NXgZ3+f2foGMp4hdywUAhRXGZF2kMo IoZjGiyiFvu/hkyroN6BSYie+v2ZON0Bl7v+ODXPbIjVRxVjUSHMlMmT2iGx3eWYnO8G z8zw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g24si1811266ejw.241.2020.05.06.11.56.49; Wed, 06 May 2020 11:57:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727998AbgEFGca (ORCPT + 99 others); Wed, 6 May 2020 02:32:30 -0400 Received: from ex13-edg-ou-001.vmware.com ([208.91.0.189]:6968 "EHLO EX13-EDG-OU-001.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725782AbgEFGc3 (ORCPT ); Wed, 6 May 2020 02:32:29 -0400 Received: from sc9-mailhost3.vmware.com (10.113.161.73) by EX13-EDG-OU-001.vmware.com (10.113.208.155) with Microsoft SMTP Server id 15.0.1156.6; Tue, 5 May 2020 23:32:25 -0700 Received: from localhost.localdomain (ashwinh-vm-1.vmware.com [10.110.19.225]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id ACE81400A2; Tue, 5 May 2020 23:32:25 -0700 (PDT) From: ashwin-h To: , CC: , , , , , , , , , , Xin Long , Ashwin H Subject: [PATCH 1/2] sctp: implement memory accounting on tx path Date: Wed, 6 May 2020 19:50:53 +0530 Message-ID: <4ce6c13946803700d235082b9c52460ed38dab1e.1588242081.git.ashwinh@vmware.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: None (EX13-EDG-OU-001.vmware.com: ashwinh@vmware.com does not designate permitted sender hosts) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Xin Long commit 1033990ac5b2ab6cee93734cb6d301aa3a35bcaa upstream. 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. Reported-by: Matteo Croce Tested-by: Matteo Croce Acked-by: Neil Horman Acked-by: Marcelo Ricardo Leitner Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Ashwin H --- 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 c93be3b..df4a7d7 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1931,7 +1931,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) @@ -8515,7 +8518,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.7.4