Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2354440ybz; Sat, 2 May 2020 22:31:55 -0700 (PDT) X-Google-Smtp-Source: APiQypJ8zxSFzlWKmUUn/kkYE4uUjtRRUjB+DfDT1sO+Uo6rI7Vsc+4o1LvGr5zPJfxvsC6CKb8y X-Received: by 2002:a17:906:4048:: with SMTP id y8mr9824185ejj.258.1588483915347; Sat, 02 May 2020 22:31:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588483915; cv=none; d=google.com; s=arc-20160816; b=hRGkhFCQ6N8uKyEVht9JdGcSXkAy/7JtK2UTYI6UIlcpbBZhfU8McJKV5EUPO7X+nw E+5snmSigWE2f0eA1Cq5VGR5vK+s9NE4U9k2TVAaUTsbNaW6wR124WVxhZhMSkbptrKL gWZU3prKv06iLDRpuZ/ofUKwhiEwEp6Q3i29o5c38v4CC/egNDwbSWIMJwIzOakanvCU d0l1N5xkzVd4g2LvWOD+XEaYKA5VxZL8Ff6dywP8D0X5SkPJsSKPpBp6wX5fsZB2s8rI F7LoZnpylKDtZ7fnhnK9BIwm4YFr5qAYG9QxCfZWhGtBTsCwOJSQjfLw3rKOhECKoDPE aO0Q== 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:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=nkciSSSypQ36odRIEazZn5GLekNFcMpPwIKz2EBHzr8=; b=lObdyKxMCNXpBuruKZCg2el2P4xv295N8lrmK0/mOyFP6Bla8ti6cCC1w8fqeyJLqj 9ym5F2PcGR0t4/qP0dg1f5zFOW4xR/Z5MCBFEOLO4vp157erTyMdsNwqyJvo96TlKNCV F8B1mIJQIlQ6/Od8PP6XvtIZ2vs6ADrtnyGQ1pYYVIZ0PQU0lUF/FJ76AVFJe4VjFHMh WARBm3rl1pQmciL9ZGk3b8vRGNVkFJRsBjCmzudaLzRLUhlD+1N4XnC+GqIOmeifxif0 oF9EDZLU14dTk/wYhPu0IAjuysNR1YE4nzn7ir3Hz4JDWlWUTgNyUJ9qBVIvtfBupKSm HwRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=w8u5Ehmd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s5si4465558edx.330.2020.05.02.22.31.30; Sat, 02 May 2020 22:31:55 -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; dkim=pass header.i=@kernel.org header.s=default header.b=w8u5Ehmd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726922AbgECFaK (ORCPT + 99 others); Sun, 3 May 2020 01:30:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:49122 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726883AbgECFaK (ORCPT ); Sun, 3 May 2020 01:30:10 -0400 Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F19B120752; Sun, 3 May 2020 05:30:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588483809; bh=WtCk5/q8+MaoojxvwsgJEVRFB6x1Zkn5zzl85+0q0CU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=w8u5EhmdphVWSvbyOCnsjz6uAcfLr8HpI8YnkcO55IcnQpIiaqKSYqPCcbcRSLAjq nqCYNTucxOcnETvOIzdpcl+kx3gYa+mIZAc+TAB5pk6V5qvhplr8RCd2tslAySMrh0 bSdIqBlW/yoMkzXWb03kg6Jb5A0K5BpZXqmDdCik= Date: Sun, 3 May 2020 08:30:05 +0300 From: Leon Romanovsky To: Arnd Bergmann Cc: Saeed Mahameed , "David S. Miller" , Moshe Shemesh , Greg Kroah-Hartman , Networking , linux-rdma , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] net/mlx5: reduce stack usage in qp_read_field Message-ID: <20200503053005.GC111287@unreal> References: <20200428212357.2708786-1-arnd@arndb.de> <20200430052157.GD432386@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 30, 2020 at 04:37:14PM +0200, Arnd Bergmann wrote: > On Thu, Apr 30, 2020 at 7:22 AM Leon Romanovsky wrote: > > On Tue, Apr 28, 2020 at 11:23:47PM +0200, Arnd Bergmann wrote: > > > Moving the mlx5_ifc_query_qp_out_bits structure on the stack was a bit > > > excessive and now causes the compiler to complain on 32-bit architectures: > > > > > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function 'qp_read_field': > > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:274:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > > > > > Revert the previous patch partially to use dynamically allocation as > > > the code did before. Unfortunately there is no good error handling > > > in case the allocation fails. > > > > > > Fixes: 57a6c5e992f5 ("net/mlx5: Replace hand written QP context struct with automatic getters") > > > Signed-off-by: Arnd Bergmann > > > --- > > > drivers/net/ethernet/mellanox/mlx5/core/debugfs.c | 12 +++++++++--- > > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > Thanks Arnd, I'll pick it to mlx5-next. > > > > I was under impression that the frame size was increased a long > > time ago. Is this 1K limit still effective for all archs? > > Or is it is 32-bit leftover? > > I got the output on a 32-bit build, but that doesn't make the code > right on 64-bit. > > While warning limit is generally 1024 bytes for 32-bit architectures, > and 2048 bytes fro 64-bit architectures, we should probably > reduce the latter to something like 1280 bytes and fix up the > warnings that introduces. It a chicken and an egg problem, I tried to use default frame size, but the output of my kernel build was constantly flooded with those warnings and made hard to spot real issues in the code I developed. Thanks > > Generally speaking, I'd say a function using more than a few hundred > bytes tends to be a bad idea, but we can't warn about those without > also warning about the handful of cases that do it for a good reason > and using close to 1024 bytes on 32 bit systems or a little more on > 64-bit systems, in places that are known not to have deep call chains. > > Arnd