Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2988502imu; Sun, 9 Dec 2018 14:24:24 -0800 (PST) X-Google-Smtp-Source: AFSGD/USBjR9XB4vgtwwqxcO0vmAKsdSZECFGsMabmTz2o7yGJOikfFwVvwu1W/ZxUvHnrMofya1 X-Received: by 2002:a62:442:: with SMTP id 63mr9955982pfe.156.1544394264856; Sun, 09 Dec 2018 14:24:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544394264; cv=none; d=google.com; s=arc-20160816; b=LL05MC5cB/rvAcNFiT+2i/LJFauB8RGvqoD/KSvZGs7fkAwzmcVgAAkF5FUp636vA/ Pxc6dKYc1qFXyKB1Emkg74ufkU6GHlcxqhcEmLv2ibEUe67eQNBmgsiKvO57vRGPPjKY pBHxRR3aoYWOCCzi8XIKPG+3V+1+buZb8giBhm1BvRBMIvjId2eTLTxRWKG2EbAhhriM RrVmgtJ9eTCVdNBFbXU9dzu6V3aGEtgnPBWsy6yRCW5GkZhRpYFWk9eENSCVRKZU9Lnt VEQ1Sq5UsVGiLfG2GMIFUYt0tUyKG5D3Cbm/hpWW/SKtAw4s+NB85/4VBUWkXHZnVvlp iU6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=QoWmR2DC31mqYPCwM0o6n9bomZ/8YtGThbME8J3xfQU=; b=ZuqY1vJ552x/SzvH7G72F/j2vSUgCZmMhTxiwLeL1XmFOEBHY/OZ26zGsCHl+g5js2 PZssLIatXn1B/rjR+YRWK0L1g1rmRPG8rtURSIE08PP+qDqD9cBlIOYJYaXaKxCXRR/P IelS5tQ6p/8bveEHrfICKeBGda3+w2QNFWZIp3g1SHECNS7h4a9UM+g7ClcsOxkhEUI5 fkSuZl1vle8IdiLUnrTu4SUFlnX8LBW11ukWwPwreLxl7byENnvkOm/+0hxEQ2A88tQ2 fP/sV+IuHBEw+N9b3HTjeMN49RpKgaqQK6FGbnU443YjeNR5ioAXaJtBvTTWdG+CUs9c 4ZIg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o68si10111126pfo.140.2018.12.09.14.24.09; Sun, 09 Dec 2018 14:24:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728295AbeLIWVw (ORCPT + 99 others); Sun, 9 Dec 2018 17:21:52 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:35198 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726514AbeLIVzV (ORCPT ); Sun, 9 Dec 2018 16:55:21 -0500 Received: from pub.yeoldevic.com ([81.174.156.145] helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gW72k-0002pp-RA; Sun, 09 Dec 2018 21:55:18 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gW72i-0003Zv-7t; Sun, 09 Dec 2018 21:55:16 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Steven Rostedt (VMware)" , "Vaibhav Nagarnaik" , "Jason Behmer" Date: Sun, 09 Dec 2018 21:50:33 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 244/328] ring-buffer: Allow for rescheduling when removing pages In-Reply-To: X-SA-Exim-Connect-IP: 81.174.156.145 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.62-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Vaibhav Nagarnaik commit 83f365554e47997ec68dc4eca3f5dce525cd15c3 upstream. When reducing ring buffer size, pages are removed by scheduling a work item on each CPU for the corresponding CPU ring buffer. After the pages are removed from ring buffer linked list, the pages are free()d in a tight loop. The loop does not give up CPU until all pages are removed. In a worst case behavior, when lot of pages are to be freed, it can cause system stall. After the pages are removed from the list, the free() can happen while the work is rescheduled. Call cond_resched() in the loop to prevent the system hangup. Link: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic") Reported-by: Jason Behmer Signed-off-by: Vaibhav Nagarnaik Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Ben Hutchings --- kernel/trace/ring_buffer.c | 2 ++ 1 file changed, 2 insertions(+) --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -1541,6 +1541,8 @@ rb_remove_pages(struct ring_buffer_per_c tmp_iter_page = first_page; do { + cond_resched(); + to_remove_page = tmp_iter_page; rb_inc_page(cpu_buffer, &tmp_iter_page);