This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sat Jun 15 11:16:18 2024 >From mailfetcher Thu Jul 25 20:18:00 2019 Envelope-to: lkml@grols.ch Delivery-date: Thu, 25 Jul 2019 20:18:00 +0200 Received: from stout.grols.ch [195.201.141.146] by 72459556e3a9 with IMAP (fetchmail-6.3.26) for (single-drop); Thu, 25 Jul 2019 20:18:00 +0200 (CEST) Received: from vger.kernel.org ([209.132.180.67]) by stout.grols.ch with esmtp (Exim 4.89) (envelope-from ) id 1hqiJT-0008PH-E3 for lkml@grols.ch; Thu, 25 Jul 2019 20:18:00 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725945AbfGYSRz (ORCPT ); Thu, 25 Jul 2019 14:17:55 -0400 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:39336 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725800AbfGYSRz (ORCPT ); Thu, 25 Jul 201 Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6PIEYHG027245; Thu, 25 Jul 2019 11:17:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=pq2qzrh1qaVrXV/n5Yq4sKeQS8gRbO36P48MvAQhh+E=; Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2ty9n6a231-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 25 Jul 2019 11:17:13 -0700 Received: from ash-exhub103.TheFacebook.com (2620:10d:c0a8:82::c) by ash-exhub102.TheFacebook.com (2620:10d:c0a8:82::f) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 25 Jul 2019 11:17:11 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 25 Jul 2 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aeUYo/hEE1zkjJRYMjEu2E+yVEBmXHq3VSxNmhHTwZ1Ie5FYUK6k8cjrHSunJCrD6MpkS2e4KgcsM6P/dD7XiV5IVSHtKgXr+JwDQ/LVRnFSyETADAoKLRirwlFCQw8cpxcHqXhSJloL3K1TRRQdnmS7cjCWOAleZZw9a/KDncoytnnLS3v7BnzuTwcu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pq2qzrh1qaVrXV/n5Yq4sKeQS8gRbO36P48MvAQhh+E=; b=C3EEYSBfQiJa5tc4gBDa4d5vzi8u8ou4Z51PxNWfItG ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=fb.com;dmarc=pass action=none header.from=fb.com;dkim=pass header.d=fb.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pq2qzrh1qaVrXV/n5Yq4sKeQS8gRbO36P48MvAQhh+E=; b=Ine+0bUyIbvVDOVQz66Ozicnr Received: from MWHPR15MB1165.namprd15.prod.outlook.com (10.175.3.22) by MWHPR15MB1279.namprd15.prod.outlook.com (10.175.4.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Thu, 25 Jul 2019 18:17:10 +00 Received: from MWHPR15MB1165.namprd15.prod.outlook.com ([fe80::4066:b41c:4397:27b7]) by MWHPR15MB1165.namprd15.prod.outlook.com ([fe80::4066:b41c:4397:27b7%7]) with mapi id 15.20.2094.013; Thu, 25 Jul 2019 18:17:10 +0000 From: Song Liu To: Oleg Nesterov Cc: lkml , Linux-MM , "Andrew Morton" , "matthew.wilcox@oracle.com" , "kirill.shutemov@linux.intel.com" References: <20190724083600.832091-1-songliubraving@fb.com> <20190724083600.832091-3-songliubraving@fb.com> <20190724113711.GE21599@redhat.com> <20190725081414.GB4707@redhat.com> In-Reply-To: <20190725081414.GB4707@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailer: Apple Mail (2.3445.104.11) X-Originating-IP: [2620:10d:c090:200::3:63dc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06967bf3-325c-4572-da0f-08d7112c4f45 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020);SRVR:MWHPR15MB1279; x-ms-traffictypediagnostic: MWHPR15MB1279: X-Microsoft-Antispam-PRVS: x-ms-oob-tlc-oobclassifiers: OLM:2331; X-Forefront-PRVS: 0109D382B0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(376002)(366004)(346002)(136003)(39860400002)(396003)(199004)(189003)(71200400001)(71190400001)(446003)(53546011)(6916009)(7736002)(305945005)(6506007)(57306001)(6116002)(186003)(6246003)(11346002)(229853002)(8676002)(14454004)(502 Received-SPF: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 X-Microsoft-Antispam-Message-Info: Py+MpX7eqEO6ozt7iJSCb1rz7PRouDhOlzXfz4TmBUxkK69wYT/nwCFaaEBFylXpbwmih83yI3UiGs1aLAP1n/r7OzGxuM5IJyyDgwzB4b7qO7uq4N77mygyNPlOrilAAFl6tAbDHxAmoYTYv2IBZUk5+hd0VwBxl/wD4p+8gkJdimuWhEJKtnOQLo+Y63iGFYopk3kjKye/Fh6m9ONv6IQpOVAgqBiTcihzaxj+TkAYyLy+DK9wGdEOPTa1xZ Content-Type: text/plain; charset="us-ascii" Content-ID: <8D5E5C7D092DC2418E8E69FF9C0E6753@namprd15.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06967bf3-325c-4572-da0f-08d7112c4f45 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2019 18:17:10.0784 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: songliubraving@fb.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1279 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-25_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reas X-FB-Internal: deliver Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org Received-SPF: none client-ip=209.132.180.67; envelope-from=linux-kernel-owner@vger.kernel.org; helo=vger.kernel.org X-Spam-Score: -4.9 X-Spam-Score-Bar: ---- X-Spam-Action: no action X-Spam-Report: Action: no action Symbol: TO_DN_EQ_ADDR_SOME(0.00) Symbol: HAS_XOIP(0.00) Symbol: TO_DN_SOME(0.00) Symbol: DKIM_TRACE(0.00) Symbol: DMARC_POLICY_ALLOW(-0.50) Symbol: RCPT_COUNT_SEVEN(0.00) Symbol: MAILLIST(-0.20) Symbol: RCVD_NO_TLS_LAST(0.10) Symbol: RC > On Jul 25, 2019, at 1:14 AM, Oleg Nesterov wrote: >=20 > On 07/24, Song Liu wrote: >>=20 >>=20 >>> On Jul 24, 2019, at 4:37 AM, Oleg Nesterov wrote: >>>=20 >>> On 07/24, Song Liu wrote: >>>>=20 >>>> lock_page(old_page); >>>> @@ -177,15 +180,24 @@ static int __replace_page(struct vm_area_struct = *vma, unsigned long addr, >>>> mmu_notifier_invalidate_range_start(&range); >>>> err =3D -EAGAIN; >>>> if (!page_vma_mapped_walk(&pvmw)) { >>>> - mem_cgroup_cancel_charge(new_page, memcg, false); >>>> + if (!orig) >>>> + mem_cgroup_cancel_charge(new_page, memcg, false); >>>> goto unlock; >>>> } >>>> VM_BUG_ON_PAGE(addr !=3D pvmw.address, old_page); >>>>=20 >>>> get_page(new_page); >>>> - page_add_new_anon_rmap(new_page, vma, addr, false); >>>> - mem_cgroup_commit_charge(new_page, memcg, false, false); >>>> - lru_cache_add_active_or_unevictable(new_page, vma); >>>> + if (orig) { >>>> + lock_page(new_page); /* for page_add_file_rmap() */ >>>> + page_add_file_rmap(new_page, false); >>>=20 >>>=20 >>> Shouldn't we re-check new_page->mapping after lock_page() ? Or we can't >>> race with truncate? >>=20 >> We can't race with truncate, because the file is open as binary and >> protected with DENYWRITE (ETXTBSY). >=20 > No. Yes, deny_write_access() protects mm->exe_file, but not the dynamic > libraries or other files which can be mmaped. I see. Let me see how we can cover this.=20 >=20 >>> and I am worried this code can try to lock the same page twice... >>> Say, the probed application does MADV_DONTNEED and then writes "int3" >>> into vma->vm_file at the same address to fool verify_opcode(). >>>=20 >>=20 >> Do you mean the case where old_page =3D=3D new_page? >=20 > Yes, >=20 >> I think this won't >> happen, because in uprobe_write_opcode() we only do orig_page for >> !is_register case. >=20 > See above. >=20 > !is_register doesn't necessarily mean the original page was previously co= w'ed. > And even if it was cow'ed, MADV_DONTNEED can restore the original mapping= . I guess I know the case now. We can probably avoid this with an simp=10le=20 check for old_page =3D=3D new_page? Thanks, Song