Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9666461ybi; Wed, 24 Jul 2019 07:59:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqyuOGh7zT+QKDV3pmVX4FfbpiRuuiEN6okEZAowm3FXY0AQ1IqMi+goJj4aMQht6lIMeGbT X-Received: by 2002:a17:902:4501:: with SMTP id m1mr86689170pld.111.1563980364311; Wed, 24 Jul 2019 07:59:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563980364; cv=none; d=google.com; s=arc-20160816; b=TEenfnnn+EGDP9VnZ1GaH9Hp/ChOiH6pEX2pGpVpqFmyL+wL11XNY4pE6CgREVkYnw uxeiS0+ylq5cwY7toGWdRhqRTyD4aqI8XVv9R6SgcKH/zff4EN64U7vJbDMPig6c7YHB S2EMiT2t6pRMtdushHN2NH24iGYv5ejkqkZYm0UN09UYEzdSYpffQtEm2bsSagvSmHIJ n4guQSL7hT80bGO/EmaItMxafDmEv+MY1HPAicRxTQ/8klM1GFvGLrdaOf53sNDkETva 7LP5gPiPwHrlWR2X+v8XhWqeJyicip8DDWs80EU6reMGiMIQ7q2HP1ATAr/S3jE+v0A9 EEMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=qUNfbcI70RVcnGa+7gNMlhjbBuJEEJ5HaEzDaXALMLY=; b=UwgQiTvuK9z/fk3cBtcSEzD8ISThtwCoEoEoMIv9pYhj+wOVJGjJPp0OGUDva5q6Z/ Y4mDaYoWVuC968rD7d/VHrnZJfA8q4W/PitRm2VsJbUJSDah/qOiVdS0+Dsr3ksVkaoU m37H+f4J25Ht09DlHdLSbr8VrIakHyM93upqTTmqjc180CS8QGHkm9HbPUP+oVgsCZ2B z5EDCpZegox+9vpGVI97mX9cSkK5DO+MawLSHgvsw1R7Biih20P4WLbBQtmigczd++pr 7ErHWKBm6Os3L8YrqW4+RM1+waYkragxtkVRIevIAoGfrR7JV1cuabtu/N+samiKCX4p VFdA== 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 i186si15458029pge.9.2019.07.24.07.59.09; Wed, 24 Jul 2019 07:59:24 -0700 (PDT) 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 S2387536AbfGXO4u (ORCPT + 99 others); Wed, 24 Jul 2019 10:56:50 -0400 Received: from mx2.suse.de ([195.135.220.15]:46450 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387502AbfGXO4u (ORCPT ); Wed, 24 Jul 2019 10:56:50 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 14E18ACCA; Wed, 24 Jul 2019 14:56:49 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 3261DDA808; Wed, 24 Jul 2019 16:57:26 +0200 (CEST) Date: Wed, 24 Jul 2019 16:57:26 +0200 From: David Sterba To: Arnd Bergmann Cc: Chris Mason , Josef Bacik , David Sterba , Johannes Thumshirn , Nikolay Borisov , Andrea Gelmini , Qu Wenruo , Liu Bo , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] btrfs: reduce stack usage for btrfsic_process_written_block Message-ID: <20190724145726.GP2868@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Arnd Bergmann , Chris Mason , Josef Bacik , David Sterba , Johannes Thumshirn , Nikolay Borisov , Andrea Gelmini , Qu Wenruo , Liu Bo , linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190708124019.3374246-1-arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190708124019.3374246-1-arnd@arndb.de> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 08, 2019 at 02:40:09PM +0200, Arnd Bergmann wrote: > btrfsic_process_written_block() cals btrfsic_process_metablock(), > which has a fairly large stack usage due to the btrfsic_stack_frame > variable. It also calls btrfsic_test_for_metadata(), which now > needs several hundreds of bytes for its SHASH_DESC_ON_STACK(). > > In some configurations, we end up with both functions on the > same stack, and gcc warns about the excessive stack usage that > might cause the available stack space to run out: > > fs/btrfs/check-integrity.c:1743:13: error: stack frame size of 1152 bytes in function 'btrfsic_process_written_block' [-Werror,-Wframe-larger-than=] > > Marking both child functions as noinline_for_stack helps because > this guarantees that the large variables are not on the same > stack frame. > > Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for checksumming") > Signed-off-by: Arnd Bergmann Added to misc-next, thanks.