Received: by 2002:a89:288:0:b0:1f7:eeee:6653 with SMTP id j8csp82060lqh; Mon, 6 May 2024 11:57:57 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVH9it+d5BZ4zroH3TBid+3dFCwKFQOFxkoIQxtGP612s+GkZeqZ0dpoTjS6b1pBV6c7kHzVgc2OI7CE/3VEISpjTr8FjTSPlnp0ShBbA== X-Google-Smtp-Source: AGHT+IFQVjkEzSBb9fuLOXb8wUQq8KSwyL6qeUbhP87f7N+6+AUPfE3yponUGVuRLA3LpX9RXqPj X-Received: by 2002:a05:6a00:1483:b0:6ed:1012:9565 with SMTP id v3-20020a056a00148300b006ed10129565mr12916057pfu.15.1715021877662; Mon, 06 May 2024 11:57:57 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715021877; cv=pass; d=google.com; s=arc-20160816; b=lewJFNOKamKaSJX1/MKsX6wegWxYA5adi8Kyo3Y6TEuvZmUdTPaZxWTgJRMxxvOHna XVeroSIv9PYErcNAQN1oUYVAsE25k8VTcqWGfraqTO72TpQ8/oOgG0PD4oEtzAL9ZbUp 1tp7lTQ90fulcGlwHC0gxHwdGxv8XLfCn4wJfNgbf0uGADMdndziHp+UF9525sw4vqDM y65OqxCTETyGmx+39FUetri5P1+wpYYidffgxHDwiMNQUzwx98CWKvUENwiysk45Ed+8 mRN7SVtulbo1dxLIbq9plML9VI4x6t6+It5YV1BwbSbVodtcJddUdKNR/YdHFhzXA3gB 1iGA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=vwITn4CstTzZtAQHEM9ECl1VAD7MHWLyJIGr0JqDJWM=; fh=a9LL/IeY+UUI57ntkZLD6jccJfEotvHQ+aN95lX/7Qw=; b=GztL+NNOwsR8/d3NVLafiIrv8gD+YF7I1w2j5w49PIq53MLMFb9hD3llCkg3mHFZlM s+jUNWN0rz46z3yvtKgp64bR8DzUhG2ZLqjo1qXheuYO7jVllAjA6Scp35Y2Hzf2ejRF o4zSqMEI2gQuL2zN2ciitDoG2A1/6I2BjCsChGXpfRo2OQfarnqkngAoH1Xa3rrFLTSe IqYu34Y1Ue2zXwJQv28iQCpE3K9ZWML/bI2Y1Fw9MJeXzdxjpVBldgPXOPzjny10Ypyk vqM6WfqDTaBOvJ4jRLtrK8KQTI8QHh6Gmda6kpKlHFWdaPCNJaDOqE/oK2VJpzsWVbdN hfCA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=dGqovjk8; arc=pass (i=1 spf=pass spfdomain=wanadoo.fr dkim=pass dkdomain=wanadoo.fr dmarc=pass fromdomain=wanadoo.fr); spf=pass (google.com: domain of linux-kernel+bounces-170314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-170314-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=wanadoo.fr Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id m14-20020a63ed4e000000b005e846cc29d0si9013248pgk.226.2024.05.06.11.57.57 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 May 2024 11:57:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-170314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@wanadoo.fr header.s=t20230301 header.b=dGqovjk8; arc=pass (i=1 spf=pass spfdomain=wanadoo.fr dkim=pass dkdomain=wanadoo.fr dmarc=pass fromdomain=wanadoo.fr); spf=pass (google.com: domain of linux-kernel+bounces-170314-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-170314-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=wanadoo.fr Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 433032841BE for ; Mon, 6 May 2024 18:57:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 31247158DC9; Mon, 6 May 2024 18:57:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=wanadoo.fr header.i=@wanadoo.fr header.b="dGqovjk8" Received: from msa.smtpout.orange.fr (out-69.smtpout.orange.fr [193.252.22.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD7E28494; Mon, 6 May 2024 18:57:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.252.22.69 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715021869; cv=none; b=o4QnpTNC+WlIxrEUC1lgwCUOUJs/Pk5AqpouOwC2golW1cJ8jLzelVDtIDAtec3tO29DFxdDPGdetiU+b/oLZKeEulQgfxTI+B47ken9V48wQSEexC8x9e1TtF2+R+Je7d7zABSrIB/TJChyM5vSaxySqqq8BaDUiw2YH09abro= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715021869; c=relaxed/simple; bh=GAhjzktko9OJNax9dYX89eovXWodEDQfe816vqcI7KY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kZ0dZoNv1ACF1F53pDtIEFCXDZ1rtsdZ0ScWzLP4wj5FASNb2iS2P1PXwe7K6QDfqJmIn7RF6amYwopnbDCi6zVOBCLjH0UI/yqTWQyp3k/kflZ53Lb7j0l2JZbd7bm3RXE+aAoK/807MSKTcl54si4wATExYuiO6101y3KVWiw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wanadoo.fr; spf=pass smtp.mailfrom=wanadoo.fr; dkim=pass (2048-bit key) header.d=wanadoo.fr header.i=@wanadoo.fr header.b=dGqovjk8; arc=none smtp.client-ip=193.252.22.69 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=wanadoo.fr Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=wanadoo.fr Received: from [192.168.1.37] ([86.243.17.157]) by smtp.orange.fr with ESMTPA id 4303s7MviME2z4303s0Gms; Mon, 06 May 2024 20:23:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wanadoo.fr; s=t20230301; t=1715019829; bh=vwITn4CstTzZtAQHEM9ECl1VAD7MHWLyJIGr0JqDJWM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=dGqovjk8SpXn+6fzebG7jnal19Q9YCOe4fQ71SJ2pHcDylCc9zwstLn198z9fAnSc kGLiPW7zOmVLTimp1JWnQC1tfZZEMQzu33s73nO1THQfHx8dDoRKkG5+Cc9CChsFMb dVLXabdsyBl1aq89K9kkXBeV1W3COUGw9yuGrDNLG7l0zrKsY3+bUbrryxjpIw4kVC y/cB9NsqVfHOOBjbqphmRvNggJR0/CwzgC/rWrW169SeQvOL9DX7z9pc71BwJo3EFN klsXlnu3HhSfimK8QjXXheWEkyBwRsHCrKrdQ+sLzOZy9a+mEk4Ly5xI1kxctiuws9 BfpUu8Q9rDsWg== X-ME-Helo: [192.168.1.37] X-ME-Auth: Y2hyaXN0b3BoZS5qYWlsbGV0QHdhbmFkb28uZnI= X-ME-Date: Mon, 06 May 2024 20:23:49 +0200 X-ME-IP: 86.243.17.157 Message-ID: Date: Mon, 6 May 2024 20:23:43 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] perf/ring_buffer: Prefer struct_size over open coded arithmetic To: Kees Cook , Erick Archer Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , "Gustavo A. R. Silva" , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, llvm@lists.linux.dev References: <51a49bae-bd91-428e-b476-f862711453a0@wanadoo.fr> <202405060856.53AFAE4F22@keescook> Content-Language: en-MW From: Christophe JAILLET In-Reply-To: <202405060856.53AFAE4F22@keescook> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 06/05/2024 à 18:23, Kees Cook a écrit : > On Sun, May 05, 2024 at 07:31:24PM +0200, Erick Archer wrote: >> On Sun, May 05, 2024 at 05:24:55PM +0200, Christophe JAILLET wrote: >>> Le 05/05/2024 à 16:15, Erick Archer a écrit : >>>> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c >>>> index 4013408ce012..080537eff69f 100644 >>>> --- a/kernel/events/ring_buffer.c >>>> +++ b/kernel/events/ring_buffer.c >>>> @@ -822,9 +822,7 @@ struct perf_buffer *rb_alloc(int nr_pages, long watermark, int cpu, int flags) >>>> unsigned long size; >>> >>> Hi, >>> >>> Should size be size_t? >> >> I'm sorry, but I don't have enough knowledge to answer this question. >> The "size" variable is used as a return value by struct_size and as >> a parameter to the order_base_2() and kzalloc_node() functions. > > For Linux, size_t and unsigned long are the same (currently). > Pedantically, yes, this should be size_t, but it's the same. > >> [...] >>> all_buf = vmalloc_user((nr_pages + 1) * PAGE_SIZE); >>> if (!all_buf) >>> goto fail_all_buf; >>> >>> rb->user_page = all_buf; >>> rb->data_pages[0] = all_buf + PAGE_SIZE; >>> if (nr_pages) { <--- here >>> rb->nr_pages = 1; <--- >>> rb->page_order = ilog2(nr_pages); >>> } >> [...] >> I think that we don't need to deal with the "nr_pages = 0" case >> since the flex array will always have a length of one. >> >> Kees, can you help us with this? > > Agh, this code hurt my head for a while. > > all_buf contains "nr_pages + 1" pages. all_buf gets attached to > rb->user_page, and then rb->data_pages[0] points to the second page in > all_buf... which means, I guess, that rb->data_pages does only have 1 > entry. > > However, the nr_pages == 0 case is weird. Currently, data_pages[0] will > still get set (which points ... off the end of all_buf). If we > unconditionally set rb->nr_pages to 1, we're changing the behavior. If > we _don't_ set rb->data_pages[0], we're changing the behavior, but I > think it's an invalid pointer anyway, so this is the safer change to > make. I suspect the right replacement is: > > > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c > index 4013408ce012..7d638ce76799 100644 > --- a/kernel/events/ring_buffer.c > +++ b/kernel/events/ring_buffer.c > @@ -916,15 +916,11 @@ void rb_free(struct perf_buffer *rb) > struct perf_buffer *rb_alloc(int nr_pages, long watermark, int cpu, int flags) > { > struct perf_buffer *rb; > - unsigned long size; > void *all_buf; > int node; > > - size = sizeof(struct perf_buffer); > - size += sizeof(void *); > - > node = (cpu == -1) ? cpu : cpu_to_node(cpu); > - rb = kzalloc_node(size, GFP_KERNEL, node); > + rb = kzalloc_node(struct_size(rb, nr_pages, 1), GFP_KERNEL, node); > if (!rb) > goto fail; > > @@ -935,9 +931,9 @@ struct perf_buffer *rb_alloc(int nr_pages, long watermark, int cpu, int flags) > goto fail_all_buf; > > rb->user_page = all_buf; > - rb->data_pages[0] = all_buf + PAGE_SIZE; > if (nr_pages) { > rb->nr_pages = 1; > + rb->data_pages[0] = all_buf + PAGE_SIZE; > rb->page_order = ilog2(nr_pages); > } This is also what make the most sense to me. CJ > > > > Also, why does rb_alloc() take an "int" nr_pages? The only caller has an > unsigned long argument for nr_pages. Nothing checks for >INT_MAX that I > can find. >