Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp952211pxb; Wed, 3 Mar 2021 22:18:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJysKxk45ZGGTNduKfzNvilmuDpOjZQZgLh9Y+bAOS+prNGahftsmYqhis5eUZGFWLbTMZG9 X-Received: by 2002:a17:906:18aa:: with SMTP id c10mr2519150ejf.248.1614838692232; Wed, 03 Mar 2021 22:18:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614838692; cv=none; d=google.com; s=arc-20160816; b=kP+WyhIx1fa2VW2Jz8Pr42ZeRmRMlJPyGEXOrjSr0EeKSbpFgl4aMUCUBfroZs8Kqj 1AwjVtiuaJwI5tOTZWzPnCcje0+FKmnbOS80uwKxn9ywQLL0CW7F2YLt+EM6g11uk67x VmRURzEG+MAceLUAA7fvqrpexQyf2cWkgQZqQqW0KUFxVM35OUAby/HsKF72/IC+vB4E OA0iU0+vOUIdCEP3pQLP2pEubUZAR9nQzUhBJPo9c6h1G6t6X2u9yp4zVeNid3NW+mqW 6eD/WV5Ek6IGYyiALJ6yiqrq7/z7AMffYvcBqosCao4Gum1ShJYt2J66DlvHJZkuR3qJ Goig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date; bh=p/4n02Gme2G18ePP6VL2RdWPpaLgLEVI6h+gHaUcsVg=; b=vDznY4B0O4xn89AuYnkZ80yqj4fVvAU0LWsKhTFCkaoS40Ga2s7hZw533ZsodyslSb Nm3zmKLq1TvPEBOrsXUC2GgtYGGy8YROIT4kGMwOQH85J9G6nhDTaAGrgA/7ZErI6Vil j7fVli1F6xHJATc/G28DBFxLDrtJE0QR6cEh7qxSxDCcp6GM/wru9djqd7NuigrRNtvS 1ApG6+pzcETglGSeW6lEWgYGyiU6kTL10680Bcw2Ya54840gTv771ndQqnciEH6j47LA O8KEYz3+00oCNL9KCLrf+cCCezmyYG+ybFTvt3Q7AvnKULfTNDMiNbxOJzMbavnpi5VH fnUg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g10si17674926edf.314.2021.03.03.22.17.48; Wed, 03 Mar 2021 22:18:12 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350788AbhCBMsc (ORCPT + 99 others); Tue, 2 Mar 2021 07:48:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:40188 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1383849AbhCBMLa (ORCPT ); Tue, 2 Mar 2021 07:11:30 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8F58AAF44; Tue, 2 Mar 2021 12:09:03 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 74266DA8BB; Tue, 2 Mar 2021 13:07:08 +0100 (CET) Date: Tue, 2 Mar 2021 13:07:08 +0100 From: David Sterba To: Yang Li Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] btrfs: turn btrfs_destroy_all_ordered_extents() into void functions Message-ID: <20210302120708.GH7604@suse.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Yang Li , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org References: <1614675476-79534-1-git-send-email-yang.lee@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1614675476-79534-1-git-send-email-yang.lee@linux.alibaba.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 02, 2021 at 04:57:56PM +0800, Yang Li wrote: > These functions always return '0' and no callers use the return > value. So make it a void function. The reasoning needs to go the other way around: you can make a function return void iff all callees also return void and don't do BUG_ON instead of proper error handling. Which in this case does not hold, because the function itself still does BUG_ON. > It fixes the following warning detected by coccinelle: > ./fs/btrfs/disk-io.c:4522:5-8: Unneeded variable: "ret". Return "0" on > line 4530 Yeah tools can identify the simple cases but fixing that properly needs to extend to the whole callgraph and understand all the contexts where local data are undone and errors propagated up the callchanin.