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 05:25:52 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Lorenzo Stoakes <lstoakes@gmail.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: <ZGiEEPXdAMnKqkqx@nvidia.com>
References: <20230519093953.10972-1-arnd@kernel.org>
 <5b071f65-7f87-4a7b-a76a-f4a1c1568ae7@lucifer.local>
 <ZGf1hV7iEQyqAim5@ziepe.ca>
 <1ca47b8a-292c-47ab-aa6f-ca24fdfc0d3c@lucifer.local>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1ca47b8a-292c-47ab-aa6f-ca24fdfc0d3c@lucifer.local>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+YVCb6CfRzbjlWJ0OzSt17NdufTAjKs59irVKXlmT8wr4GelbNTNEvq3JSqc?=
 =?us-ascii?Q?zGPgPrGTUJ9cyZPDc4zO715Xk8Ff6XWYo2dHFj5jw/crC236/Vtt58QTfqA2?=
 =?us-ascii?Q?nxt33/QyniM+rfdhvlNvS0hliXqUIe90CwtI1FIDti9pwUTkYq4B2caOQeu1?=
 =?us-ascii?Q?7fPlth+dzjv9ynBYrBu8dVPi4JwpB7Tz5vJdXw6ImU2W6Y5UAPI+LM9WdNbg?=
 =?us-ascii?Q?UhJw6vjd2+uQuU52Y1S2fKBT+bc/NdTJblIZ0FoNwIL0knd3iIj/aSZq6TAe?=
 =?us-ascii?Q?tq4O5nGKAjktLwP7wnp/v0H3Q4AqHl8ti83LcOA4NSr7Vp7gYQTmkSVXvkqt?=
 =?us-ascii?Q?6Z121PsOZJt9VdsSwZwWOb/X6fKkJTtUgPPF/IJ7ErmcN5IbYWy2LaIJi+wE?=
 =?us-ascii?Q?Op0oio2AHYBrlAgk4Clxo26A5y042Kh/zh+/shK732Xj8RAoa5IAmbmq4UQp?=
 =?us-ascii?Q?zWUHx07M0ist9EDVQgQSBYXyTcJT7LxCwnKeXA3SeIdqHS1c//jxCVwfKcBV?=
 =?us-ascii?Q?d+AwEP5TfoOPcJEdrDfNayQE6P7oZ+EpNRmyUDsgz8vc7M7oQNIykPblV+nV?=
 =?us-ascii?Q?szQBil2g3WsJJgd5wSSrEI7aSeilIUbixu5XvpfxSfGQAmiX9o8CT45owIhq?=
 =?us-ascii?Q?O6PEdqXu/jF3wGZJSW6xYAIZj4BAALf7f9N3QMtAXVby0C14+btMwqJRVy4o?=
 =?us-ascii?Q?V1XeJAbTnxup/jPsEWWPtrwHcL75o4YwENFjBUWfb2ua/JUNUQGXprKpPXzm?=
 =?us-ascii?Q?mhQEEoUANz+FMlKOQlwCVKNFDTBbrpzLC0poTHuVsX/yNx3ni0Uu63acssBh?=
 =?us-ascii?Q?MNux8n2ZIz3tz/Hmhhjdn/dHb945MSIG+qHQ0AI8AnKNV3TSNeNhw9BnoMsm?=
 =?us-ascii?Q?A99YZ03OT/Pwf0GDoqAigOOH14UBbPQ8ETM24bktyFZAh1kf63MzCj7jU00P?=
 =?us-ascii?Q?eiw/miGYlzciobIK/Rxnntf8rH3FW50scf7zh+V7exsviWIeooiKxZVm7hsG?=
 =?us-ascii?Q?yisxFKsmWeXycRRsvnuuDXksaM1VaD8ia7ky/+aiq1clP2G1jWEWcyiqVOfP?=
 =?us-ascii?Q?Wdpu7WZsmvmsm4tstOLnOflwpAICG6v+LEvUzQL42YXIoE1Ok4oYUt0oAOKA?=
 =?us-ascii?Q?eqyt7ZJDgmvGRz/MlUCam3PWxZHCRlaPQU4913CzW4du0ujnFNx8QQkq+mw9?=
 =?us-ascii?Q?jpuSesapgfXFtRB4LeO9bnTO+Bm4lVq/ZIY1+AgqF2rU/YvDXnKppTG29S6k?=
 =?us-ascii?Q?3RQptmqEJ/mzU9kiZnCaqIAXXNlCJoPyo3o73Eib1t38yucdWbwQBciL+mWH?=
 =?us-ascii?Q?vJQJawIeZQsyyXmLnAacv1Miz++BIDLWFg6/RoDcf3v9wTumxF2QUiSp/5CA?=
 =?us-ascii?Q?9eFwWW5x37lXekkH6PwurbPPNJ9TGwN2SpzwNviBaSzzp3n+gfh6zjwdzt1/?=
 =?us-ascii?Q?x182Ncz8zBQdPNynZRD9JTM/L0vXWE64SIS3i3redmSVVzBa2D/oawMLC3Ed?=
 =?us-ascii?Q?qCqpxe0RhG4D4e8IuhnucJCiibsKcz9FnB4mYmG5LoB+47Kap+2eJnXVw91D?=
 =?us-ascii?Q?Ksb5KchvZ922rOyg2BY4Zafdc7YKUbDBIvSxWsrw?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 12be1df0-fe10-4ad3-c8c0-08db590bd3c0
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 May 2023 08:25:53.7107
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WpC5RyqbWNlKmcKZ9I9sm+nYnerCOVP9R4OVmpr6ybTxNpAuVGZyBBY1acydzoqe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6542
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=no autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, May 20, 2023 at 06:19:37AM +0100, Lorenzo Stoakes wrote:
> 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.

Any time gup fails it didn't pin any pages, that is the whole
point. All that is happening is some ill defined subset of gup errors
are returning 0 instead of an error code.

If we want to enable callers to ignore certain errors then we need to
return error codes with well defined meanings, have documentation what
errors are included and actually make it sane.

> 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.

And how does that make any sense? Missing VMA should be EFAULT.
 
> caller differentiates between an error and not being able to pin -
> uprobe_write_opcode() - which treats failure to pin as a non-error state.

That looks like a bug since the function returns 0 on success but it
clearly didn't succeed.

> 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.

No, this returning 0 on failure is a foot gun. Failing to pin a single
page is always an error, the only question is what sub reason caused
the error to happen. There is no third case where it is not an error.

Jason