Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4794667ybl; Wed, 22 Jan 2020 04:57:28 -0800 (PST) X-Google-Smtp-Source: APXvYqwmPXGyWuOShLr16e/Y9Ou1hodZuzNlJTHJQHDY0G52NWO/fJBjgBebOmB18ps3usI0lA4V X-Received: by 2002:a9d:2dca:: with SMTP id g68mr6698866otb.150.1579697848598; Wed, 22 Jan 2020 04:57:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579697848; cv=none; d=google.com; s=arc-20160816; b=qsvwsxk1zDP5c764/c4ZE9j85cCNve9oSLyE8p97P0pDiy1pWonofgpc2WjMROGROg trpetCF1yU9jqmZO7zZiSlMyhj0gYPZOMNkoV1ST0CW6QSXkYctZHyRe2k+sXnxSQvFS teX/5lfls5+jwkm8Rq5rdOe/3Wz8rV5+vfw6bow/c7u1Ai80mI4td24MDtk2Jha42QcZ +AKaivnsLNq9S+LRytlSSo492LGBIarYm4/JfGNb5azHa5Rvs0dpwnNfuzzJ1AMOp1/I lWJNzHVciQHMVi3yJfEFVqbn9c1yabCUskMl6quZN08SkU+FVZjrP5COYkpbWIaxt9NA 680Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version; bh=WT9I70DFy0dAoIEdOl1Y+MUcLUczktfDSmeKjDfv+5I=; b=nP+XQU5i1lbskGrn2mPzYew/ZT0cUEhhi2M+8qE8hzbNK40mvnodgXSXag93pWOWfI URaKh9u9Op6htb2Ql1msKvJWLHJu1kVOCzj8VR7P6Ctl8NyAnCauMoQ5fZcgoGaCb3s4 PTTnGn0TgDAAoq8bxmWRwlGm2fHr6ApIL1QoYEg4tKQlzfQfkKiONYpaeXbbZAvtQrU0 PNkrVqkZZZ9h6Zp4BRHt5ClmINemGw+u3fAxg6+ooQAITVvO2tdcDuzfPeChuRUbXjEs GHFLzAHXwU9oZmHxvO9iLUmnLWm8ujomPk1hENb548UOoWQOZ0bTR2PKmBGwvIs6V8a1 qtEw== 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 p25si22002671oto.191.2020.01.22.04.57.15; Wed, 22 Jan 2020 04:57:28 -0800 (PST) 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 S1729045AbgAVM4I (ORCPT + 99 others); Wed, 22 Jan 2020 07:56:08 -0500 Received: from relay12.mail.gandi.net ([217.70.178.232]:46751 "EHLO relay12.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727022AbgAVM4I (ORCPT ); Wed, 22 Jan 2020 07:56:08 -0500 Received: from webmail.gandi.net (webmail23.sd4.0x35.net [10.200.201.23]) (Authenticated sender: cengiz@kernel.wtf) by relay12.mail.gandi.net (Postfix) with ESMTPA id 24DEA200008; Wed, 22 Jan 2020 12:56:05 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Jan 2020 15:56:05 +0300 From: Cengiz Can To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fs: fuse: check return value of fuse_simple_request In-Reply-To: References: <20200120121310.17601-1-cengiz@kernel.wtf> Message-ID: <8024c282d1b007c45b9655ddadd20e35@kernel.wtf> X-Sender: cengiz@kernel.wtf User-Agent: Roundcube Webmail/1.3.8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-01-20 16:39, Miklos Szeredi wrote: > On Mon, Jan 20, 2020 at 1:13 PM Cengiz Can wrote: >> >> In `fs/fuse/file.c` `fuse_simple_request` is used in multiple places, >> with its return value properly checked for possible errors. >> >> However the usage on `fuse_file_put` ignores its return value. And the >> following `fuse_release_end` call used hard-coded error value of `0`. >> >> This triggers a warning in static analyzers and such. >> >> I've added a variable to capture `fuse_simple_request` result and >> passed >> that to `fuse_release_end` instead. > > Which then goes on to ignore the error, so we are exactly where we > were with some added obscurity, which will be noticed by the next > generation of static analyzer, when you'd come up with an even more > obscure way to ignore the error, etc... This leads to nowhere. I got your point. Thanks for explaining. > If this matters (not sure) then we'll need a notation to ignore the > return value. Does casting to (void) work? It should probably work for the sake of silencing the analyzer but I think it would be easier to just ignore the warning and mark is as unimportant. IMHO code should be as readable as possible. So not point in casting it. If `fuse_simple_request` errors are very rare, we can ignore this patch. Thank you > > Thanks, > Miklos -- Cengiz Can @cengiz_io