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;
MIME-Version: 1.0
References: <20200120121310.17601-1-cengiz@kernel.wtf>
In-Reply-To: <20200120121310.17601-1-cengiz@kernel.wtf>
From:   Miklos Szeredi <miklos@szeredi.hu>
Date:   Mon, 20 Jan 2020 14:39:18 +0100
Message-ID: <CAJfpegtOOCVrNkSmpmMY0dVH-359jc3RqXJ7K6dzvUqxtCxBtg@mail.gmail.com>
Subject: Re: [PATCH] fs: fuse: check return value of fuse_simple_request
To:     Cengiz Can <cengiz@kernel.wtf>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 20, 2020 at 1:13 PM Cengiz Can <cengiz@kernel.wtf> 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.

If this matters (not sure) then we'll need a notation to ignore the
return value.  Does casting to (void) work?

Thanks,
Miklos