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 2DE8EC4332F for ; Thu, 10 Nov 2022 22:03:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B10D36B0078; Thu, 10 Nov 2022 17:03:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC0126B007B; Thu, 10 Nov 2022 17:03:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98A7D8E0001; Thu, 10 Nov 2022 17:03:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 87E506B0078 for ; Thu, 10 Nov 2022 17:03:00 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 59DFCC0BED for ; Thu, 10 Nov 2022 22:03:00 +0000 (UTC) X-FDA: 80118908520.03.C65553B Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf22.hostedemail.com (Postfix) with ESMTP id D0174C0014 for ; Thu, 10 Nov 2022 22:02:59 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id y4so2705070plb.2 for ; Thu, 10 Nov 2022 14:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0hUxSNiyiP1FDxtyo/mybNyzLXRprRaysx2LPFaFTIg=; b=iFKKKqEsH752Yu9uMRK7Rbwse7YpvoeLmOwrxmv4hOT0T4Qjibq/cSYYi89cBhCMJZ GY2x49iXFuIz7pi02LbkQYc5NO8fA46+IjPy/oV/vYakFl3ap8hHgUHHLHi3KULiqg4M 6VLdVaPLHwJO4ppMmQ9dxvamh9PwVPz0X2o0c4Qx8RA+I4zF7Aqau9z9KlJGgzB/BnsU TOZx/yAFYJBujkCLha1e3nseIptn2GnOMYWzDV6kiKja3rfnPJ3/ba7n0KhIoaXOkrpk Y/8y2qhqr1Vo5RQIT+S6Q+bEAmOo5C/BP0PrA+h2tdNyaCQ5DXoD4MFG2VHUyUtX/CDQ 6FRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0hUxSNiyiP1FDxtyo/mybNyzLXRprRaysx2LPFaFTIg=; b=03feM/JwAUUIDNtoiaETvkD5/KZvB2ZOKSdy7ROgQuZ2OmV77n+/9EhjLg9za1+VMF AjPr3zkJ9ZmIpHJqT+ycCGdP4OpyNrP62SMcb7sht0G9AF4S1qz6cWUwPXlEilasJCAn 5CcwclLdzVDFowdj1NEY0URjPhm4c51jcwy3RmlxNE82tBxoI9nDTtvua3ATiS7csRUQ hwDBQlcyLbiJJyf5BBeNE2iw3dQ6NhSn6s3ZpqiRBzvaNu+BPoO4QExpK/x8LVpBOWCU 0bYtPyuAnj/kiWWdCE/HD89GR0SPNke1Jay7LjwStbeR4DWO5I7yBZwdC5Y7zIEu//KA QJEQ== X-Gm-Message-State: ACrzQf09iofiR0+l4BBTlJvpRnYK2ZAAEpGhsxnhra0Ut6PXbQtzF1LU 9dyOqSsY8EAyz81aR5atYHQ= X-Google-Smtp-Source: AMsMyM7/Wb2clQiZC8X/DJgAfJ62LgZY7EjD+MfsEcrYj3vVkIYrcx05UVRdFV6YX8hh7tpx61/hgQ== X-Received: by 2002:a17:90b:1d4c:b0:210:a844:217c with SMTP id ok12-20020a17090b1d4c00b00210a844217cmr2298643pjb.150.1668117778506; Thu, 10 Nov 2022 14:02:58 -0800 (PST) Received: from smtpclient.apple ([66.170.99.95]) by smtp.gmail.com with ESMTPSA id r17-20020a170903411100b00186c3727294sm141647pld.270.2022.11.10.14.02.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2022 14:02:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH v8 2/2] mm: remove zap_page_range and change callers to use zap_vma_range From: Nadav Amit In-Reply-To: Date: Thu, 10 Nov 2022 14:02:56 -0800 Cc: Mike Kravetz , Linux-MM , kernel list , Naoya Horiguchi , David Hildenbrand , Axel Rasmussen , Mina Almasry , Rik van Riel , Vlastimil Babka , Matthew Wilcox , Andrew Morton Content-Transfer-Encoding: quoted-printable Message-Id: References: <20221108011910.350887-1-mike.kravetz@oracle.com> <20221108011910.350887-3-mike.kravetz@oracle.com> <7140E1D7-B1B9-4462-ADDA-E313A7A90A68@gmail.com> To: Peter Xu X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668117779; a=rsa-sha256; cv=none; b=2IcGo+RkKw0HbhV+WXKzOlMBuQZZ/RX64P6rVR7hHtGM3b+vx0z26zIAOEDoxqD4ohG3A9 rYr2XqjvmuP2PcOLXjg+1Ka/NVKcC5MYU5iQ7v2HLYm8JGFyH3yBYkWVIOY/eFLACqAtA3 99c4SFzSYjsorIcc30cGMrsvK/5WHk4= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=iFKKKqEs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668117779; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0hUxSNiyiP1FDxtyo/mybNyzLXRprRaysx2LPFaFTIg=; b=rqvo7Edlba7K+z7MNffvigQ+TBGXQcB+rzv99ztWgC0VMfZrXY/YZnA/7MAgnR1HO+yajN VznqQaCoLKKXlqSdgmW9wptOFs+NE+sr8OpvwIvUKPxLklhPOrmwN8nQxhKgWZaCOFPdJC cEGwA44Y5kj8B88R+vz6IzoLZAu1vDI= X-Rspamd-Queue-Id: D0174C0014 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=iFKKKqEs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-Rspam-User: X-Rspamd-Server: rspam01 X-Stat-Signature: kzhuiaqtdpuzt19zde5qmtxr3sk9r7ej X-HE-Tag: 1668117779-726700 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 Nov 10, 2022, at 1:27 PM, Peter Xu wrote: > Hi, Nadav, >=20 > On Thu, Nov 10, 2022 at 01:09:43PM -0800, Nadav Amit wrote: >> But, are the callers really able to guarantee that the ranges are all = in a >> single VMA? I am not familiar with the users, but how for instance >> tcp_zerocopy_receive() can guarantee that no one did some mprotect() = of some >> sorts that caused the original VMA to be split? >=20 > Let me try to answer this one for Mike.. We have two callers in tcp > zerocopy code for this function: >=20 > tcp_zerocopy_vm_insert_batch_error[2095] zap_page_range(vma, *address, = maybe_zap_len); > tcp_zerocopy_receive[2237] zap_page_range(vma, address, = total_bytes_to_map); >=20 > Both of them take the mmap lock for read, so firstly mprotect is not > possible. >=20 > The 1st call has: >=20 > mmap_read_lock(current->mm); >=20 > vma =3D vma_lookup(current->mm, address); > if (!vma || vma->vm_ops !=3D &tcp_vm_ops) { > mmap_read_unlock(current->mm); > return -EINVAL; > } > vma_len =3D min_t(unsigned long, zc->length, vma->vm_end - = address); > avail_len =3D min_t(u32, vma_len, inq); > total_bytes_to_map =3D avail_len & ~(PAGE_SIZE - 1); > if (total_bytes_to_map) { > if (!(zc->flags & = TCP_RECEIVE_ZEROCOPY_FLAG_TLB_CLEAN_HINT)) > zap_page_range(vma, address, = total_bytes_to_map); >=20 > Here total_bytes_to_map comes from avail_len <--- vma_len, which is a = min() > of the rest vma range. So total_bytes_to_map will never go beyond the = vma. >=20 > The 2nd call uses maybe_zap_len as len, we need to look two layers of = the > callers, but ultimately it's something smaller than total_bytes_to_map = we > discussed. Hopefully it proves 100% safety on tcp zerocopy. Thanks Peter for the detailed explanation. I had another look at the code and indeed it should not break. I am not = sure whether users who zero-copy receive and mprotect() part of the memory = would not be surprised, but I guess that=E2=80=99s a different story, which I = should further study at some point.=