Received: by 10.223.176.5 with SMTP id f5csp134157wra; Fri, 26 Jan 2018 19:26:11 -0800 (PST) X-Google-Smtp-Source: AH8x225oC/k82ejK02iHHlQKKi7RjPghyW7sy+dnT5pFj+Hj4VACsg9GgR0venfhqObddRBExkQy X-Received: by 2002:a17:902:6b49:: with SMTP id g9-v6mr16063951plt.9.1517023571551; Fri, 26 Jan 2018 19:26:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517023571; cv=none; d=google.com; s=arc-20160816; b=qvILqSiu6apJSw9ng2LoHOuZrHhUILbDM3mC7v3Xwlra3jRLaBTRxcAlq7DGIid8/k YFcSoqmtnI3/xpYpM7Qidp19ibKfqUTUxjTpJOYYHK7G+bqrNvCXqBz8gGd0tc2Slvl2 tOTaoY5sShh25oP/RdBqw5mz03yGCgHJKU0R1kgt7xgMFLcpKUdEYs859TDsP5ITDsDv P8xDbz0S9lmwNOPBN4mGin8NKC/VGMdTcEmyDaQnBxpxU1j5jOGIY70AgBV28sT8MEJi wqtlZbUHa6nWPkGja6NrY6lSR9XtEw06+Cs/T4WKoxVQODsnfhNIB2+8PJ6PquBFy2+X q9vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:cc:date:message-id:subject :mime-version:content-transfer-encoding:from:dkim-signature :arc-authentication-results; bh=Aa0vM+jPI0DzK66+8YGVXwvvrvUEcUBV9VPh/DE90xs=; b=oURWBZn4TfWZPgQvqipgTK982TtRxvJ0CqcOxXXp8kJPRUlV3DJ50AwFphiiU8kZC7 ZaH1kvdJbAgfB53+qqUvRjE5keg03mmSIFmVI2D3WJgGdQb0u0sjtd8Xtza+ZPG2zAQ8 R68fgGjChqxwptccUSNtiQs3OUacUBJvLF1Pb/WllhmO7n12ycJ61Xr/3UTIeyB1GP76 XvHVCzcY9rT1ICHyA57bykT2i12cMJakaWM2Kzad4UNBMt3wIjR7a3aUoi6CgbcvB76f gcSpGi6oz/GsLN2MpjYbEdSrQFEOF6fRx+QKcALIiY0GEpGZq5dMvVVBGkV7373ShKn4 GSYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=lWz5dnHu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p28si3860031pgc.96.2018.01.26.19.25.57; Fri, 26 Jan 2018 19:26:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=lWz5dnHu; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbeA0DZe (ORCPT + 99 others); Fri, 26 Jan 2018 22:25:34 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:49318 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514AbeA0DZd (ORCPT ); Fri, 26 Jan 2018 22:25:33 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0R3OhDm169578; Sat, 27 Jan 2018 03:25:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : cc : to; s=corp-2017-10-26; bh=Aa0vM+jPI0DzK66+8YGVXwvvrvUEcUBV9VPh/DE90xs=; b=lWz5dnHuezX/aEdldTFNq1U4s6kwlXui2Z27goVgGIoZhCamyEb4dGmhJYz1D8CuNJ2g 3V/MA+CkFE5wEcJE0DzIGqOS3pP/pAM2WJabK2vRKU276vGOpkOO8f77axXmr8g0E1K1 53v/SwpWWtwGfpbFJ8kvvGpZDcaU7wBIvujkP1C7qmF4FtzGcKRMG6GBK10tqZyh7QkB CwE+W2Xgy9WvrYw6YwGOvyzBagGS7dO8ez/8oBjAIMKh1jJLkDh2Q1BELtYQSc8oKF0i ELMXJMQeBU8vkGF4CaJ4YmvNBJCx+MRWLvfeM+3USlS/Vw+IsU3PjFdvK+e0BQDi0FLv Yw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2frh9c80m1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Jan 2018 03:25:27 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w0R3PQKR014782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 27 Jan 2018 03:25:26 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w0R3PQ2O008433; Sat, 27 Jan 2018 03:25:26 GMT Received: from dhcp-10-154-108-180.vpn.oracle.com (/10.154.108.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 26 Jan 2018 19:25:25 -0800 From: William Kucharski Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.9\)) Subject: [PATCH v2] mm: Correct comments regarding do_fault_around() Message-Id: <302D0B14-C7E9-44C6-8BED-033F9ACBD030@oracle.com> Date: Fri, 26 Jan 2018 20:25:25 -0700 Cc: Andrew Morton , Michal Hocko , "Kirill A. Shutemov" To: linux-kernel@vger.kernel.org, linux-mm@kvack.org X-Mailer: Apple Mail (2.3445.6.9) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8786 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=970 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801270039 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org mm: Correct comments regarding do_fault_around() There are multiple comments surrounding do_fault_around that memtion fault_around_pages() and fault_around_mask(), two routines that do not exist. These comments should be reworded to reference = fault_around_bytes, the value which is used to determine how much do_fault_around() will attempt to read when processing a fault. These comments should have been updated when fault_around_pages() and fault_around_mask() were removed in commit aecd6f44266c13b8709245b21ded2d19291ab070. Signed-off-by: William Kucharski Reviewed-by: Larry Bassel --- memory.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 793004608332..885dffe194f8 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3485,9 +3485,8 @@ static int fault_around_bytes_get(void *data, u64 = *val) } =20 /* - * fault_around_pages() and fault_around_mask() expects = fault_around_bytes - * rounded down to nearest page order. It's what do_fault_around() = expects to - * see. + * fault_around_bytes must be rounded down to the nearest page order as = it's + * what do_fault_around() expects to see. */ static int fault_around_bytes_set(void *data, u64 val) { @@ -3530,13 +3529,14 @@ late_initcall(fault_around_debugfs); * This function doesn't cross the VMA boundaries, in order to call = map_pages() * only once. * - * fault_around_pages() defines how many pages we'll try to map. - * do_fault_around() expects it to return a power of two less than or = equal to - * PTRS_PER_PTE. + * fault_around_bytes defines how many bytes we'll try to map. + * do_fault_around() expects it to be set to a power of two less than = or equal + * to PTRS_PER_PTE. * - * The virtual address of the area that we map is naturally aligned to = the - * fault_around_pages() value (and therefore to page order). This way = it's - * easier to guarantee that we don't cross page table boundaries. + * The virtual address of the area that we map is naturally aligned to + * fault_around_bytes rounded down to the machine page size + * (and therefore to page order). This way it's easier to guarantee + * that we don't cross page table boundaries. */ static int do_fault_around(struct vm_fault *vmf) { @@ -3553,8 +3553,8 @@ static int do_fault_around(struct vm_fault *vmf) start_pgoff -=3D off; =20 /* - * end_pgoff is either end of page table or end of vma - * or fault_around_pages() from start_pgoff, depending what is = nearest. + * end_pgoff is either the end of the page table, the end of + * the vma or nr_pages from start_pgoff, depending what is = nearest. */ end_pgoff =3D start_pgoff - ((vmf->address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1)) +