From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AC1B1C77B7A for ; Sat, 20 May 2023 09:15:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NKolH30ZNj/sirsPY+ep24tqodx/q2NifyAB0jnsoFQ=; b=lzNcmbGoc8DBmK cyUvLUmoFR9fTgVDaIFXmnWHUDQSSdxBRCsUPl6I5mkXfJvJPgKbhVrRqr1lvyhXk+ALqlr+x3/ci vQyXLkD6Gn6yu2OFEM+OxaVW7h9ZArchYYs+H8zFHawoGmN6IN7l8sUig4UWyxus3sxa27gDoaClc yDrbDB60fWjXx6gw9fgRB5SmykOzMB+MkdaTz5SsbWiXC05SkdzCkamqLa13ecTdDjaxzCQs2I+k5 g7Ocmiy9Deq0UaCBSoOG+6b4weJW6WsxZYjFiNY8u1u9vYUm5ldg+laWNLndHGttajutgOXjKZrA8 X8ushR2EK+TiemTXEEFA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q0Ifx-0016kL-0d; Sat, 20 May 2023 09:14:57 +0000 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q0Ifu-0016iZ-1n for linux-arm-kernel@lists.infradead.org; Sat, 20 May 2023 09:14:56 +0000 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3063433fa66so2563680f8f.3 for ; Sat, 20 May 2023 02:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684574092; x=1687166092; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=p26w75jnOzAEdo+Byo9aO1qQn64wYCOl3bY13+vxNmk=; b=oOl3jkJ6SD5TY56pKAFFeCXwzDR/dT6qZPAb1m7wFYg/h9zOoYhU7nDbmXo0+iqqrR 2sUrZXzOioUEEXZEJvSlHfHYzbOVmnOM7Rx/ANRsUAX3xWe7sfrGJPy34HpJBLxEorpd M8J78EuPVkYsaA70esysc623hyLmkF3qvl2b6xwZEZsRzDlKSEB2FvgN375kCzzSHmh6 jXbozkqpMnPyaZwwKPTCCb6fsNyclb52LFRqgi8VJkY85sLrAhCQRSZGe4h6ZjzY/7s1 fEQsQCZDvusqEObIGOmEMnuziyDw5qXkCxJ+GRVrfaaVu0Qgs7vYIv6xNit10F44NfWX VZ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684574092; x=1687166092; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=p26w75jnOzAEdo+Byo9aO1qQn64wYCOl3bY13+vxNmk=; b=SOCDkNyiRbgPbSNEeRHWW/cmJlJBNq/hx5g0VS0YwAIu5/ZAt5sYrb6/6k0Q/yKYtv 8k+9VPpNPLeGvdDY6BgMvH5Sy2X/DAwSDUdBkGRu6kcT2VodC0LW8Xp8pNxj2TmGVkTR 9x6H7bG32am4UEhNEWBurikqQHbAsV5K9whqM6TjEvCYUCA8ezuE1c3E4R/IHub1XmR9 X/NsykBCKFhfuEFUekhlseEe86Ls9rwCXo2mql/srwMfWpeCd0wEMaUUn/ysRQTKFJs6 CajQeDWtfZqv5V/QcVdp3kJ9y1tdh9k3iZH3cs+ojYdvm7wIIy0PX96FLf0BH0bXOiYZ qTzA== X-Gm-Message-State: AC+VfDwaohfIi7qoSqdrEzVmgz4NI2gD2SPnrZwbqCEwH234cS8wPZo5 8/+D8woxHZJNyV/u7p60Knc= X-Google-Smtp-Source: ACHHUZ71oQFelW3p0VPKhNo3IJWJEBFsEgvGe0d+bIIqgHevklfCmsbpUHXpFr1U8wMuimNDrlbMKg== X-Received: by 2002:a5d:4385:0:b0:309:436a:fc2f with SMTP id i5-20020a5d4385000000b00309436afc2fmr2826502wrq.57.1684574091429; Sat, 20 May 2023 02:14:51 -0700 (PDT) Received: from localhost (host81-154-179-160.range81-154.btcentralplus.com. [81.154.179.160]) by smtp.gmail.com with ESMTPSA id j2-20020adfff82000000b00304832cd960sm1401962wrr.10.2023.05.20.02.14.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 May 2023 02:14:50 -0700 (PDT) Date: Sat, 20 May 2023 10:12:40 +0100 From: Lorenzo Stoakes To: Jason Gunthorpe Cc: Arnd Bergmann , Andrew Morton , Arnd Bergmann , Catalin Marinas , Will Deacon , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , 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: <0bc9dc2b-0da6-4d5c-96af-e21aa287eecb@lucifer.local> References: <20230519093953.10972-1-arnd@kernel.org> <5b071f65-7f87-4a7b-a76a-f4a1c1568ae7@lucifer.local> <1ca47b8a-292c-47ab-aa6f-ca24fdfc0d3c@lucifer.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230520_021454_612575_5F769D3D X-CRM114-Status: GOOD ( 47.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, May 20, 2023 at 05:25:52AM -0300, Jason Gunthorpe wrote: > 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 > > > > > > > > > > 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. Yeah I agree it's not exactly great that a failure to pin can be considered an ordinary case, but I don't think a wrapper function is where we should be trying to fix this. In fact this patch isn't even fixing it, it's treating EIO as a success case for the (possibly broken) uprobe case. I think we are at the wrong level of abstraction here, basically. > > > 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. Yeah missing VMA doesn't really make sense since we invoke the function with the mmap lock held (it _could_ make sense if you were calling it via one of the unlocked functions, speculatively, though how sensible doing that is another discussion...) > > > 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. The code is specifically handling a failure-to-pin separately - set_swbp() -> uprobe_write_opcode() -> install_breakpoint() explicitly does the following:- ret = set_swbp(&uprobe->arch, mm, vaddr); if (!ret) clear_bit(MMF_RECALC_UPROBES, &mm->flags); So even if this is... questionable, the code literally does want to differentiate between an error and a failure to pin. Presumably this is because of the flag check, but yeah we should be differentiating between sub-cases. > > > 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 The uprobe path thinks otherwise, but maybe the answer is that we just need to -EFAULT on missing VMA and -EPERM on invalid flags. I could look into a patch that tries to undo this convention, and then we could revisit this for the wrapper function too. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel