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 AFFE3C021B2 for ; Sat, 22 Feb 2025 12:40:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF83C6B0085; Sat, 22 Feb 2025 07:40:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DA5D36B0088; Sat, 22 Feb 2025 07:40:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C46186B0089; Sat, 22 Feb 2025 07:40:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A519F6B0085 for ; Sat, 22 Feb 2025 07:40:43 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 35FA1AFFFE for ; Sat, 22 Feb 2025 12:40:43 +0000 (UTC) X-FDA: 83147539566.30.2F1BE50 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 66B6E4000B for ; Sat, 22 Feb 2025 12:40:40 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TWiVInF0; spf=pass (imf12.hostedemail.com: domain of oleg@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=oleg@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740228040; a=rsa-sha256; cv=none; b=Vq+ZpHwfpO8zcIuNY/VY1Ya9K/BqooLv6j2gEkho3r3Wr0EezLvyJQnQMltwjgBlkqXvwf M+Fe+/vEJXySZNLwQ8PEGT/tXYuq5gINfR8T9NY1qVgxkTtvdAFaw9PVjcOLNg25lfcgTy iqOYpdFZ0mfVGpSHvRYv9KKDSMvno7Y= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=TWiVInF0; spf=pass (imf12.hostedemail.com: domain of oleg@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=oleg@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740228040; 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=qAd8SANoOauq5uEymG+29fWeYf7y+gGWAJmdDdaiSKs=; b=vBJnayY6M7S0KXqYuwGJQ1xqJNvPcha+mGLSn/KyZHFIZF5IZ2tHg+g6GE+NfD2l4VG8e0 /NvzCg+QcnMIvpnadzrjWfSJ7Hb00IgS6SqYmJfC2LfexGqPaWNBn50sawhhnNomeiZD50 0CSVLAc8OiGvIB+erVw3TQIfH08KrNU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1740228039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qAd8SANoOauq5uEymG+29fWeYf7y+gGWAJmdDdaiSKs=; b=TWiVInF0NcltMZ4JLPeMSZ7FuqCb3ojP3yPDx3eDe1T4Z4z5XpTKzGYL1WMSSGkftQF0S7 lZjwfIOOnrz+pz4xN+UrpAL8Tvvo6SCIsokX8c8iHhPi4bjCBlzno76ufwV/yM2TIJGZlD nHfWy6bph9pSeqcs/XiY+PnA5Mpes3o= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-122-u0F871nGP4-7jWvcSvDHtQ-1; Sat, 22 Feb 2025 07:40:35 -0500 X-MC-Unique: u0F871nGP4-7jWvcSvDHtQ-1 X-Mimecast-MFC-AGG-ID: u0F871nGP4-7jWvcSvDHtQ_1740228033 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6224619560B9; Sat, 22 Feb 2025 12:40:32 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.45.224.2]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with SMTP id 8A6E8180094A; Sat, 22 Feb 2025 12:40:23 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Sat, 22 Feb 2025 13:40:03 +0100 (CET) Date: Sat, 22 Feb 2025 13:39:53 +0100 From: Oleg Nesterov To: Tong Tiangen Cc: David Hildenbrand , Andrew Morton , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Peter Xu , Ian Rogers , Adrian Hunter , "Liang, Kan" , Masami Hiramatsu , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, wangkefeng.wang@huawei.com, Guohanjun Subject: Re: [PATCH -next v2] uprobes: fix two zero old_folio bugs in __replace_page() Message-ID: <20250222123952.GA17836@redhat.com> References: <20250221015056.1269344-1-tongtiangen@huawei.com> <20250221152841.GA24705@redhat.com> <46a48eb4-5245-81ba-9779-ace8f162c31b@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Rspamd-Queue-Id: 66B6E4000B X-Stat-Signature: 48yck86x6j4j4nde45ondjahhm9q8c63 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740228040-260674 X-HE-Meta: U2FsdGVkX1+wTy/IqW4fs3O+fR/gCAvHfNu86Jw1O1AwmglZ8Zm+EoH1/GDJhAqIiFgWw6uyOCcuNOxPy4/RWxAV0UZUET8cynlgHt9m25vkoFStYphrIiTRk7O0hEnCRcDoz0FvuU3WiuC6CoDfVKiPke+9K9OeEii7dxtBIKqpnzjFf83rRTrMON4q120ERaIGdyUQdjhADvIHZ+S9g+H/ECO6ppZXe2VNrjAJMBhHpoW4K18E6f0tEpYn1PdC+UHJWln01GqyJ8uIAkI41Xczpb3aiX5fZ5dVOKYsJpW7MQ1c2s7OmtKY3sHXg4gZXcI6kmnXxAH4lvvoLkvnTGbAAFb/4hmN//SDslitHOI/cP2D5qSOyCY4U6kljMkbAAFm1ZxIHf8T6vOhdJ2xHzP+FlOOhXqmws1mqlTFEiyIuvWDVxYcj2R+1VfQPw4vPF19Fv5KWTNZWAP7JXrOB3xlAlG1HZZ5Ymc+v+MTwCs/ThHAGizYb2c7ffkEdqXUdnK5wmSCpluCQyMQDRLVItEpjJSdBzieIOv9ClI0u5aYwAm3NLwOj1xMwhDBPmVHYjL0ID6oK1hLEWx4sr2DSoDzs2lwIzE61Qm0Iac5q8GgiHfosVVuXIVxBcBHUEZd41CORqg7Cc72myAlHy/ZU5fMaEWt4aoXHQH8PCHm12fDJ5VQjflTjk02vO4eUZBEyja5kW8Tvk1Oae/Gmm0AwQTS/LfF8WF3KFti7o1CE62IU4epCGhpqzlDWEUWuiALCrdToFcrfcoq5aE9gdg/N1l3Ij2A2r9Jny0f37Swr9QFE7M4t9cDRzEBqyeYbq97D5dCLFgPSu+8thY3prjrf80GY2z0jkeTJkKVloaj8ClgTvWNRew/ot5+4ga8QYDPJwlJ5XZbouBUvSRYKwwC0vEjJUJTnTCe1AX6AYRcYqtigHmSMALIUV3ZXJwrLX6gG/TbgSJoiSejVJsjAqP HgC6o0IU XJOF10T01cycy4PyvBzmqoPnI76wVPnkLAwLtBX5zFFFFh12b4EdRSge4zWUOXikcyR80q9Czq9S7rv6RsHH8Syl6nxueGMDVx6lyvqOIslHSU9jEEZTtTWzjiUIRCZuavH7ZRhF8KEFdXTRv7VfPJtFUmKXykM4CbtFPdp7s3vKIHll37sGnnpZtrizzYIpHE2Gu3zHxXmAXrk/fRzeGQJbvj+NuRFWp3zGT6CP+k8KcIEhq/sT2R/e2Z/7e3jPAHmiyOOyuDWyNJOToI1d1I/gmQuogqVypEjZX0YJmFRWNgB1W3TrML2pM1kpBq7Acy8gPyfGyXiwJFBiByW0cREkZLveUuqOgceCCa2zYlcunpL8= 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: List-Subscribe: List-Unsubscribe: On 02/22, Tong Tiangen wrote: > > > I'm going to add a new patch to moving the "verify_opcode()" check down > , IIUC that "!PageAnon(old_page)" below also needs to be moved together, No, no. I forgot everything, but please don't do this. IIUC This is optimization for the case when the probed file has int3 at this offset. We should not skip update_ref_ctr() in this case, just we can avoid __replace_page(). > and as David said this can be triggered by user space, so delete the use > of "WARN", as follows: Hmm... I think that David meant the new WARN_ON() added by you in V1? Please don't remove the old WARN(PageCompound(old_page) check. If userspace can trigger this warning we need to to fix this code and add FOLL_SPLIT_PMD unconditionally (and likely do something else). I take my words back ;) Don't do the additional cleanups, just add the is_zero_page(old_page) check right after get_user_page_vma_remote() and update the subject/changelog as David suggests. This function needs more cleanups anyway. Say, the usage of orig_page_huge _looks_ obviously wrong even if (afaics) nothing bad can happen. It should be reinitialized after "goto retry" or it should be checked before the "orig_page = find_get_page()" code. The usage of gup_flags looks confusing too. Lets do this later. Oleg. > > > @@ -502,20 +502,16 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, > struct mm_struct *mm, > if (IS_ERR(old_page)) > return PTR_ERR(old_page); > > - ret = verify_opcode(old_page, vaddr, &opcode); > - if (ret <= 0) > + ret = -EINVAL; > + if (is_zero_page(old_page)) > goto put_old; > > - if (is_zero_page(old_page)) { > - ret = -EINVAL; > + if (!is_register && (PageCompound(old_page) || !PageAnon(old_page))) > goto put_old; > - } > > - if (WARN(!is_register && PageCompound(old_page), > - "uprobe unregister should never work on compound page\n")) > { > - ret = -EINVAL; > + ret = verify_opcode(old_page, vaddr, &opcode); > + if (ret <= 0) > goto put_old; > - } > > /* We are going to replace instruction, update ref_ctr. */ > if (!ref_ctr_updated && uprobe->ref_ctr_offset) { > @@ -526,10 +522,6 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, > struct mm_struct *mm, > ref_ctr_updated = 1; > } > > - ret = 0; > - if (!is_register && !PageAnon(old_page)) > - goto put_old; > - > ret = anon_vma_prepare(vma); > > Thanks. > > > >> > >> > >>. > > > >. >