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:   Fri, 19 May 2023 15:51:51 +0100
From:   Lorenzo Stoakes <lstoakes@gmail.com>
To:     Arnd Bergmann <arnd@kernel.org>
Cc:     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: <5b071f65-7f87-4a7b-a76a-f4a1c1568ae7@lucifer.local>
References: <20230519093953.10972-1-arnd@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230519093953.10972-1-arnd@kernel.org>
Precedence: bulk

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.

Overloading EIO on the assumption that gup will never, ever return this
indicating an error seems to me a worse solution.

>
> Change get_user_page_vma_remote() to return -EIO when no pages were
> found and adapt the callers to match.
>
> Fixes: eca1a00155df ("mm/gup: remove vmas parameter from get_user_pages_remote()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I see the real bug is already fixed, but this seemed worth pointing out still.
> Not sure if this is the best way to handle the return types here, but the version
> in linux-next doesn't look great either.
> ---
>  arch/arm64/kernel/mte.c | 4 ++--
>  include/linux/mm.h      | 2 +-
>  kernel/events/uprobes.c | 5 ++++-
>  mm/memory.c             | 2 +-
>  4 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 4c5ef9b20065..6983ba35ce16 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -434,8 +434,8 @@ static int __access_remote_tags(struct mm_struct *mm, unsigned long addr,
>  		struct page *page = get_user_page_vma_remote(mm, addr,
>  							     gup_flags, &vma);
>
> -		if (IS_ERR_OR_NULL(page)) {
> -			err = page == NULL ? -EIO : PTR_ERR(page);
> +		if (IS_ERR(page)) {
> +			err = PTR_ERR(page);
>  			break;
>  		}
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 42ff3e04c006..4bb172e4818c 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2397,7 +2397,7 @@ static inline struct page *get_user_page_vma_remote(struct mm_struct *mm,
>  	if (got < 0)
>  		return ERR_PTR(got);
>  	if (got == 0)
> -		return NULL;
> +		return ERR_PTR(-EIO);
>
>  	vma = vma_lookup(mm, addr);
>  	if (WARN_ON_ONCE(!vma)) {
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index cac3aef7c6f7..9cf2d4ba760e 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -474,7 +474,10 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,
>  		gup_flags |= FOLL_SPLIT_PMD;
>  	/* Read the page with vaddr into memory */
>  	old_page = get_user_page_vma_remote(mm, vaddr, gup_flags, &vma);
> -	if (IS_ERR_OR_NULL(old_page))
> +	if (old_page == ERR_PTR(-EIO))
> +		return 0;
> +
> +	if (IS_ERR(old_page))
>  		return PTR_ERR(old_page);

I hate this, you're now using an error to indicate a non-error state.

Also you have no idea whether get_user_page_vma_remote() has encountered an
error condition returning -EIO rather than not pinning anything so this
could also be broken.

>
>  	ret = verify_opcode(old_page, vaddr, &opcode);
> diff --git a/mm/memory.c b/mm/memory.c
> index 8358f3b853f2..f9a81278e76d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5604,7 +5604,7 @@ int __access_remote_vm(struct mm_struct *mm, unsigned long addr, void *buf,
>  		struct page *page = get_user_page_vma_remote(mm, addr,
>  							     gup_flags, &vma);
>
> -		if (IS_ERR_OR_NULL(page)) {
> +		if (IS_ERR(page)) {
>  #ifndef CONFIG_HAVE_IOREMAP_PROT
>  			break;
>  #else
> --
> 2.39.2
>

Not a fan at all of this patch, it doesn't achieve anything useful, is in
service of some theoretical improvement, and actually introduces a new
class of bug (differentiating EIO and failing to pin).