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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58694EB64D7 for ; Fri, 30 Jun 2023 16:19:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F14D88E0036; Fri, 30 Jun 2023 12:19:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC5708E000F; Fri, 30 Jun 2023 12:19:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DB4008E0036; Fri, 30 Jun 2023 12:19:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id CDC0E8E000F for ; Fri, 30 Jun 2023 12:19:52 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 83A861C80D5 for ; Fri, 30 Jun 2023 16:19:52 +0000 (UTC) X-FDA: 80959925424.26.CB29361 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf08.hostedemail.com (Postfix) with ESMTP id 4FAE6160020 for ; Fri, 30 Jun 2023 16:19:49 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="GrJQAo/9"; dmarc=none; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688141990; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=j3I7zANFd6QAuWoZlCVaHAW7HE1PeX5cogAMvb+4P44=; b=KjvmPmMH1cwWdOVIEDPHj0hEYXpF2+ht4LNonOQKQirgMatlPYtA+PLU00SHvS0zF2Yr/x 3vrev0vTkblmBgQD5mcIE3gbTg/+J8mHYBDRSQEeIJdIbHCGt7VVBlURUPcSp21heVnygw 66ckulDobetUUUtxQPmtqQfqficVV1M= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="GrJQAo/9"; dmarc=none; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688141990; a=rsa-sha256; cv=none; b=q2W4oo2jxNgIKSItX58hyRk6Fq38gyqJCa+48cAvdDUP7D5hjfoFuPzuJFd26ZnmsbXRYx ziaR4rlloOoOOAo9V4h61MdNioR4Tx8RT/xWP1PVzj5oPt93KiP2iY4VRYaoqzURla4eEh 6IOWqr/vPdscXANFUck77NH6K38R2EU= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-4f122ff663eso3354380e87.2 for ; Fri, 30 Jun 2023 09:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1688141988; x=1690733988; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j3I7zANFd6QAuWoZlCVaHAW7HE1PeX5cogAMvb+4P44=; b=GrJQAo/99ujxjtCM9Fh85YRwlV1iYIFAmoj36GFuJhWYbEHO6kt62yYldyzOplG+A7 dgUFTFrKwfPsDGKGHZpAZ56sfXF1+WAICLcuQ+b4bXOg2MMP9Yps/1ZcET1dqppLaKUw 16ek9zvj1YHAcMVJangXNUpiystZ/wz8Fj5Yc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688141988; x=1690733988; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j3I7zANFd6QAuWoZlCVaHAW7HE1PeX5cogAMvb+4P44=; b=cpKoB1EKx2BjCVG4m1c4lFqkpbwdvoylfAZzImokYYmcfqzLR+i0AKZyRBR2f2U6ko BA8b7ng/keb9PHACu1eOp/bPgEDtg0glVT3/n1u+MfkFl7JJuInCKNDv4x6UDcIypUNV AERpahW/eGR7954f9K9L606nn+PBElCosXohf/tGz4zwbe/yicXIkrfugfe/mdUcxPBt QLghcOSOntvKYE+fTX/ZCKecm6fmFzNYLg2iNyNR+Kz1R1rR16W4/8S+07F8hbRGqBk0 qAa7Nod5LZOIBfY1+NZsESLPL53qiyhAZLLeRDj/3NtPN3ao8EZPq7ujeZYS5r9tEhON iGOw== X-Gm-Message-State: ABy/qLbV7t4sFwF7niahlcu4UaOvlsxlOEhtRFrRGX9Yk9//z6DEMOe5 P1+ESduRkcoWVFcoSHnOGqZrTUpjHHTyxhKExGrxV5rl X-Google-Smtp-Source: APBJJlHIhXCPqYx2WvkBhDnskStKGkw3iUxDcGzsu631Ta545CPkxFYPmv7Y6YsAXLwkYiJ4BFUS2w== X-Received: by 2002:a05:6512:20d4:b0:4fb:9168:1fce with SMTP id u20-20020a05651220d400b004fb91681fcemr2222414lfr.59.1688141987957; Fri, 30 Jun 2023 09:19:47 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id x15-20020ac259cf000000b004f4b42e2d7dsm1126471lfn.230.2023.06.30.09.19.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jun 2023 09:19:47 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-4fb7b2e3dacso3379949e87.0 for ; Fri, 30 Jun 2023 09:19:47 -0700 (PDT) X-Received: by 2002:a05:6512:3994:b0:4f9:58bd:9e5a with SMTP id j20-20020a056512399400b004f958bd9e5amr2835506lfu.27.1688141987079; Fri, 30 Jun 2023 09:19:47 -0700 (PDT) MIME-Version: 1.0 References: <20230630160519.3869505-1-Liam.Howlett@oracle.com> In-Reply-To: <20230630160519.3869505-1-Liam.Howlett@oracle.com> From: Linus Torvalds Date: Fri, 30 Jun 2023 09:19:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm: Update do_vmi_align_munmap() return semantics To: "Liam R. Howlett" Cc: Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Stat-Signature: zbhxk3asz65okjs1sxu9pw8p1cyzkp7k X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 4FAE6160020 X-HE-Tag: 1688141989-441860 X-HE-Meta: U2FsdGVkX1/JvYR+GjBvHGDL09Lgx3CbRtIO8FwSNlcZ1g88eJO5/Ykz+sfQSBUMpZW/EjW+WKXgHlfqfb+RkSnKCpfpoGgsMCEtqnOfa3R+tW4DUvxQS2OGlF0q+SHsYwefkTx4BHyPHOzxVwGRFdSOpAz9Dg8RSb3rppUS7yiRS9j/D8UNvEUTEwJpBiQ5+ZYan4VrwmaNkAyfkZ14PdTqIXp7eP7bALpmk9hrjLzZ3wVc0SD5vZ3hT2hXGfad125kyYYl+tl2nWZJmwzeSiqyIw1MBZYQhQTkZee1CEd6YNg64r1vvf5GT9rlpBU+lcQ2CszVn4dItbfRNzxKSPnC8gwN86RILcVZf2hBVvy1wEZSEFxMi6NblMAxHPFWEqxcLoHPBx9HSfR3Em7lBWrNqz0BO+mxrYeLE9/KLwVo/zKypq3GuIP90fCN6ue6fB4AI+ISFQvY+UD1DP+QDscAfOO17LHSdt9ZvPixJBpOwY2ednRBnf3AgoMW1MK4gcQ475rnATcfcUCyXrVPvu9Xrzy9lBVYQoGcSj/a9EWn/OYkykUfWlebWoUEqPyOqtFerdqDR30H22CeOxvvR+a4M2SMdM/KF6uuC12wIDWKoKPF3q1If4j9X3qxG/+I0fhvPi1X6Mjgqp9lVStxh+1zRJ+ls3QkVEfjdaNKzETqiTYBAgR3kUanIA9fcgBXQsCvraKgEMXLbRLVfZBFP6ZdTWWkuv6wxedjkUWkavi/V8OqtbJYw3EdNlFdmsViUTtzWZmWdggyyUi0O/gqC0FsMpBXxBy5cwxkeQ19lwcIgO4T6don3ab3jiHV1c8O0O2eDp4yCiLrfH1sBEqqIoqbKGxJZVflG1WAokLBu+in0ZRAPSH/4Gm9UGQk+nNYW2EdqWGDgaS925oMDVBtPW1KjoDapG+gnxxRx6X4EQd8WkjYge5zeP80IcynmKp2uo/LYOWEYaD1KCx/Rnr 04BIVpNt X52uMXxLNcMC6zAkjGJ0CV7RDG2AJeag957ifjdkkxVmue/E0sxhNke6Nc8BeRp+fg8zd0Xlzux7TxPbQm4YTNpwWNSGb8SP+UWUMV2b4A5dOhhh3wCAAZSgv0KhMAlc9GYdy+WgGx/zhzdXAugfz4k/As6rDWgQZucH3/1ACkPSYIu7e+D3yfvW5yGlfpZPeqCa1EKPG2RkxOa1IuPCKDkViVyF8m97waxtjM4HUGl3R6qRQBsPSc8RlG8EtsHF5du9KNtZLrThlxMKMrVYHh0OHVBooQZ0Jswc3c+e48qNZL9FdpSRo/mHpPAysaGlPuPJCkMZgB7L2SAToPVzD9Kl0OmaKtGZETl/y6vwyGk8KTu3S1rnVlzBvce2TIR91kCoem6Ccnv83uCjHJ+4eCuBr6zsR/f4on+uQB09fciC9ITuUh5L2JBQJLYTMJejEoLG5ubfmi5JaGYvson+Ya5zVRhyN7T+DlYVXmZg2BlWIixgfwoHg0adATWW67GjGJbH/xIRt4SrOrg7USvC+PRFKjjr1Gey3qS9Nkjb0fK0DxmBgSYNQoPt7+yEP069TP/SE X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 30 Jun 2023 at 09:06, Liam R. Howlett wrote: > > Update do_vmi_align_munmap() to return 0 for success. Clean up the > callers and comments to always expect the lock downgrade to be honored > on the success path. The error path will always leave the lock > untouched. Thanks for doing this, but with this cleanup, it becomes clear that some of the callers that asked for a downgrade didn't actually want that at all... For example: > + if (do_vma_munmap(&vmi, brkvma, newbrk, oldbrk, &uf, true)) > + goto out; > + > + mmap_read_unlock(mm); > + goto success_unlocked; this clearly wanted the lock to be dropped entirely. As did this one: > ret = do_vmi_munmap(&vmi, mm, start, len, &uf, downgrade); > /* > - * Returning 1 indicates mmap_lock is downgraded. > - * But 1 is not legal return value of vm_munmap() and munmap(), reset > - * it to 0 before return. > + * Returning 0 is successful, but the lock status depends what was > + * passed in. > */ > - if (ret == 1) { > + if (!ret && downgrade) > mmap_read_unlock(mm); > - ret = 0; > - } else > + else > mmap_write_unlock(mm); And this one: > + ret = do_vmi_munmap(&vmi, mm, addr + new_len, old_len - new_len, > + &uf_unmap, true); > + if (ret) > + goto out; > + > + mmap_read_unlock(current->mm); I didn't look at what all the indirect callers here were doing, but it really looked to me like *most* callers wanted the lock dropped entirely at the end. In fact, looking at that patch, it looks like *all* of the callers that asked for downgrading actually really wanted the lock dropped entirely. But I may well be missing some context. So take this not as a NAK, but as a "you looked at all this code, could it perhaps be simplified a bit more still?" Linus