Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 20 May 2023 06:19:37 +0100
From:   Lorenzo Stoakes <lstoakes@gmail.com>
To:     Jason Gunthorpe <jgg@nvidia.com>
Cc:     Arnd Bergmann <arnd@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Ian Rogers <irogers@google.com>,
        Adrian Hunter <adrian.hunter@intel.com>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] [suggestion] mm/gup: avoid IS_ERR_OR_NULL
Message-ID: <1ca47b8a-292c-47ab-aa6f-ca24fdfc0d3c@lucifer.local>
References: <20230519093953.10972-1-arnd@kernel.org>
 <5b071f65-7f87-4a7b-a76a-f4a1c1568ae7@lucifer.local>
 <ZGf1hV7iEQyqAim5@ziepe.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZGf1hV7iEQyqAim5@ziepe.ca>
Precedence: bulk

On Fri, May 19, 2023 at 07:17:41PM -0300, Jason Gunthorpe wrote:
> On Fri, May 19, 2023 at 03:51:51PM +0100, Lorenzo Stoakes wrote:
> > Given you are sharply criticising the code I authored here, is it too much
> > to ask for you to cc- me, the author on commentaries like this? Thanks.
> >
> > On Fri, May 19, 2023 at 11:39:13AM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > While looking at an unused-variable warning, I noticed a new interface coming
> > > in that requires the use of IS_ERR_OR_NULL(), which tends to indicate bad
> > > interface design and is usually surprising to users.
> >
> > I am not sure I understand your reasoning, why does it 'tend to indicate
> > bad interface design'? You say that as if it is an obvious truth. Not
> > obvious to me at all.
> >
> > There are 3 possible outcomes from the function - an error, the function
> > failing to pin a page, or it succeeding in doing so. For some of the
> > callers that results in an error, for others it is not an error.
>
> No, there really isn't.
>
> Either it pins the page or it doesn't. Returning "NULL" to mean a
> specific kind of failure was encountered is crazy.. Especially if we
> don't document what that specific failure even was.
>

It's not a specific kind of failure, it's literally "I didn't pin any
pages" which a caller may or may not choose to interpret as a failure.

> IIRC if you look really closely the only time get_user_pages()
> actually returns 0 is if the input argument validation fails, which I
> think is a bug that should be fixed.

That can be a reason for gup returning 0 but also if it you look at the
main loop in __get_user_pages_locked(), if it can't find the VMA it will
bail early, OR if the VMA flags are not as expected it'll bail early.

>
> get_user_pages() never returns 0, so get_user_page_vma_remote() never
> returns NULL. Until we get there collapsing the 0 to EIO is perfectly
> fine.

Well no, as shown above actually there is a distinct third state,
i.e. couldn't pin, which if you see there is at least one case where the
caller differentiates between an error and not being able to pin -
uprobe_write_opcode() - which treats failure to pin as a non-error state.

Also if we decided at some point to return -EIO as an error suddenly we
would be treating an error state as not an error state in the proposed code
which sounds like a foot gun.

>
> Jason