Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966297AbcKOJL1 (ORCPT ); Tue, 15 Nov 2016 04:11:27 -0500 Received: from mgwkm02.jp.fujitsu.com ([202.219.69.169]:28837 "EHLO mgwkm02.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966236AbcKOJLW (ORCPT ); Tue, 15 Nov 2016 04:11:22 -0500 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.2.3 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140219-2 Subject: Re: [PATCH] perf/ring_buffer: Fix invalid page order To: References: <20161115071559.3756-1-indou.takao@jp.fujitsu.com> <20161115084814.GB6130@gmail.com> From: Takao Indoh CC: , , , , Message-ID: <2f85aee4-1a17-1962-8398-cf6170a7fe1e@jp.fujitsu.com> Date: Tue, 15 Nov 2016 18:11:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161115084814.GB6130@gmail.com> Content-Type: text/plain; charset="iso-2022-jp"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1284 Lines: 38 On 2016/11/15 17:48, Ingo Molnar wrote: > > * Takao Indoh wrote: > >> In rb_alloc_aux_page(), a page order is set to MAX_ORDER when order is >> greater than MAX_ORDER, but page order should be less than MAX_ORDER, >> therefore alloc_pages_node fails at least once. This patch fixes page >> order so that it can be always less than MAX_ORDER. >> >> Signed-off-by: Takao Indoh >> --- >> kernel/events/ring_buffer.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c >> index 257fa46..3f76fdd 100644 >> --- a/kernel/events/ring_buffer.c >> +++ b/kernel/events/ring_buffer.c >> @@ -502,8 +502,8 @@ static struct page *rb_alloc_aux_page(int node, int order) >> { >> struct page *page; >> >> - if (order > MAX_ORDER) >> - order = MAX_ORDER; >> + if (order >= MAX_ORDER) >> + order = MAX_ORDER - 1; >> >> do { >> page = alloc_pages_node(node, PERF_AUX_GFP, order); > > I'm wondering under what circumstances this allocation failure was seen in > practice - why did others not hit this? I found this when I ran perf with -m,2048. I think in the most cases users use default buffer size hence they does not notice. Thanks, Takao Indoh