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 A9EEDE77179 for ; Fri, 6 Dec 2024 16:08:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 363776B029A; Fri, 6 Dec 2024 11:08:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 313126B029B; Fri, 6 Dec 2024 11:08:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DA976B029C; Fri, 6 Dec 2024 11:08:26 -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 F32076B029A for ; Fri, 6 Dec 2024 11:08:25 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7F0C21A1C5C for ; Fri, 6 Dec 2024 16:08:25 +0000 (UTC) X-FDA: 82865015772.08.2DDDEAB Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by imf24.hostedemail.com (Postfix) with ESMTP id 08581180007 for ; Fri, 6 Dec 2024 16:08:20 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=morinfr.org header.s=20170427 header.b=vWb4fPEy; dmarc=pass (policy=quarantine) header.from=morinfr.org; spf=pass (imf24.hostedemail.com: domain of guillaume@morinfr.org designates 212.27.42.2 as permitted sender) smtp.mailfrom=guillaume@morinfr.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733501296; 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=NSaDf9G/Xwl7b+3XUHvNR5VSpgYRF37voCO22C3bBPY=; b=oUSwc0u290KdnnlVZy/9vhyhiDUyUkZRfeIkIyGhthmTp51qV0vmNLrXnpEY5oQ9uCX7k6 pFfbbb9wXubEa4opDOmxGdSHxdNCcGU34osxFBqwqLiSlBhK3xBQYmQLGyPy25b1bnlS0r SDJbeglg85ZGFT26afTvgCW29SeEMYU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733501296; a=rsa-sha256; cv=none; b=sQdm4YSh8CGSWwLJab6m8Kjn62MhXjJm+ypFiwTbtJXVX/GAhS8DOy6TptErGwHQFZbI4R zqxIuW3kV5m1RIcjRjo12zqRjoblBJ7i9gL8Zl5JdW8LYt9p8vDeokzXVvr0o1vCUXe+TV DUF7TH2Kh2iiAywQ0j255kF6Ba6NLX4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=morinfr.org header.s=20170427 header.b=vWb4fPEy; dmarc=pass (policy=quarantine) header.from=morinfr.org; spf=pass (imf24.hostedemail.com: domain of guillaume@morinfr.org designates 212.27.42.2 as permitted sender) smtp.mailfrom=guillaume@morinfr.org Received: from bender.morinfr.org (unknown [82.66.66.112]) by smtp2-g21.free.fr (Postfix) with ESMTPS id 311352003EF; Fri, 6 Dec 2024 17:08:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=morinfr.org ; s=20170427; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NSaDf9G/Xwl7b+3XUHvNR5VSpgYRF37voCO22C3bBPY=; b=vWb4fPEyE/fV5PmHvEnwxKfQls m2ULZ2rYvzhb66+wTq0qPYQ4PPWnRPXH2ycsW094pifv4jKynV4v9x9nLg04pdsR6DYWPLBAdWMRe Nuf6eDeeZL1OFGoXWSEM0QkMDejUCIRNkzBgeq14glxbBGkcvQGjZ1xEunxulSOdidlA=; Received: from guillaum by bender.morinfr.org with local (Exim 4.96) (envelope-from ) id 1tJasH-002MXC-22; Fri, 06 Dec 2024 17:08:13 +0100 Date: Fri, 6 Dec 2024 17:08:13 +0100 From: Guillaume Morin To: David Hildenbrand Cc: Guillaume Morin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Muchun Song , Andrew Morton , Peter Xu , Eric Hagberg Subject: Re: [PATCH v4] mm/hugetlb: support FOLL_FORCE|FOLL_WRITE Message-ID: References: <8395af7d-328a-425c-84a7-517e78a602b1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8395af7d-328a-425c-84a7-517e78a602b1@redhat.com> X-Stat-Signature: m1367ppwqbo7dpawadwyfoy9sj6xcp6o X-Rspamd-Queue-Id: 08581180007 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733501300-291461 X-HE-Meta: U2FsdGVkX18TUDeqACGAXvEOFDzUEIzEGWj6aZbnWTdccKWubD98n/TcEpAPb+qBXqTsITwobjvSEW/F/W2VS9zTta3UZ5WyvNEXPuulb6kh1pgUpg94KFHC1uz0Rd+ehFabGXnxTSX77WnEolCIQoxEtilp6UrJdwvvizDnvb11rkkkFB7IBKmu1HlTFJCpkrhEAIP+VVskQwF+LPZgn2POJAIh2+LlQqBUjIFkolVPlDYh7OylKmDtzJVlegcwdmQ40TFfAA8zuqZcwMoAKREhBS0iZjADOfVXXofgksSc+C8g8LEd+laKOWGQPt8g/8w5p43ZXtlOAwLULUsDHcvbSP+Bsl0Ebw/pPFda0VL+hZcehtxTkFRQfo6wmm3E9ZgoSODlIiGHZOhB/rpQ1DrDmYZQ8LRylemRrvd77NrxBCCI9YUn4Dxumz1M4U/Cvwp4bpr1NBPNETVpfshwfAxXqMv/7L1Qq0Fx/XLqTfUpC+yaQ11z9B5BIDbJF3GSF+n2Dvr4Q3iwivKErRqAhzu+yV2EzKMYxAub1YJXrykhnmgxWHuDVBzk65XGGYVHTJNNwi6OlWIH8Af0uVEu+6wg3v9nZqw+ZqZCxaU0akpRSNCpmiWdHgPeGYrFhFgWyDMQyz6f71GRV2QKObuzGn+rEW2sum9Cjj/01UyWRkcAAOekiz9FF2S+14p4FelOkyXyTkSrsXN+/oiCGsOx06yfbNMW0fNZqAeAD+Zi7h2GUklcQqdPsbrmZAqfeZkxY+SX0B/NxUQUZT15RrMVYBRxDA2reiNCKo8tnkP+nqALqkPWYCZUMlqgVx9pu+EFpNtjR60n4Jzr7CnjFOlbEA+ASkbTayqETX6M1zQUtqtNI0jnui/lcSn+dC7zybz7QPdvO9lYzPZsXidFigwWbAb5upKVJB7a23ZlcvvetW/cwfg5/eJgVzho8f/O57yhWKEDiYx+H5RUJZbpTrC izWtXBL1 U3oqXzgmJ8JHivgdxnlN7XJD+/N2mWPKGBLOaZ2VXRGjV35v00A9p8hQ7ncqvjQjZbRw/qVt8JfIIV63gYqqlAndcfkGcf/ipagbjR+fFtPIzy9teLH6vF+pG7lKk3WWyl4qwa7fr85Pz9hUAszujnJN65z///OT8xQ0Mdug+fVAu84wQMCuLFtEyXn36nrh3ZwIHDTp/U+/e6lFsyxVSvo0scLAeIJ54Bcf2JhErR6MSASlWD+I8PeDI4p0NsTEslwnq4+MSwX1YP9aE3exEGn55iu93/Z5Xw0BtH+kKvisCcGdgt/Y0lQrPj1vLXyx+L2ykfYGtErl4Rves8NifYFjq3xTvyRXWqr64199dv6X1CBWySXaoaz/bsVhIcD3QuazAKSgiO/8s5RglLYpGqOPhOiNb20ZZFzC38EAehBAksXpXOAqA44n22fY2s+3TER3lo76FX+rDu4C7/1f2+hsfK1K9JFBjwgoPQwbS9ZroDIM= 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 06 Dec 17:03, David Hildenbrand wrote: > > On 06.12.24 15:49, Guillaume Morin wrote: > > Eric reported that PTRACE_POKETEXT fails when applications use hugetlb > > for mapping text using huge pages. Before commit 1d8d14641fd9 > > ("mm/hugetlb: support write-faults in shared mappings"), PTRACE_POKETEXT > > worked by accident, but it was buggy and silently ended up mapping pages > > writable into the page tables even though VM_WRITE was not set. > > > > In general, FOLL_FORCE|FOLL_WRITE does currently not work with hugetlb. > > Let's implement FOLL_FORCE|FOLL_WRITE properly for hugetlb, such that > > what used to work in the past by accident now properly works, allowing > > applications using hugetlb for text etc. to get properly debugged. > > > > This change might also be required to implement uprobes support for > > hugetlb [1]. > > > > [1] https://lore.kernel.org/lkml/ZiK50qob9yl5e0Xz@bender.morinfr.org/ > > > > Cc: Muchun Song > > Cc: Andrew Morton > > Cc: Peter Xu > > Cc: David Hildenbrand > > Cc: Eric Hagberg > > Signed-off-by: Guillaume Morin > > --- > > Changes in v2: > > - Improved commit message > > Changes in v3: > > - Fix potential unitialized mem access in follow_huge_pud > > - define pud_soft_dirty when soft dirty is not enabled > > Changes in v4: > > - Remove the soft dirty pud check > > - Remove the pud_soft_dirty added in v3 > > > > mm/gup.c | 95 +++++++++++++++++++++++++--------------------------- > > mm/hugetlb.c | 20 ++++++----- > > 2 files changed, 57 insertions(+), 58 deletions(-) > > > > diff --git a/mm/gup.c b/mm/gup.c > > index 746070a1d8bf..63c705ff4162 100644 > > --- a/mm/gup.c > > +++ b/mm/gup.c > > @@ -587,6 +587,33 @@ static struct folio *try_grab_folio_fast(struct page *page, int refs, > > } > > #endif /* CONFIG_HAVE_GUP_FAST */ > > +/* Common code for can_follow_write_* */ > > +static inline bool can_follow_write_common(struct page *page, > > + struct vm_area_struct *vma, unsigned int flags) > > +{ > > + /* Maybe FOLL_FORCE is set to override it? */ > > + if (!(flags & FOLL_FORCE)) > > + return false; > > + > > + /* But FOLL_FORCE has no effect on shared mappings */ > > + if (vma->vm_flags & (VM_MAYSHARE | VM_SHARED)) > > + return false; > > + > > + /* ... or read-only private ones */ > > + if (!(vma->vm_flags & VM_MAYWRITE)) > > + return false; > > + > > + /* ... or already writable ones that just need to take a write fault */ > > + if (vma->vm_flags & VM_WRITE) > > + return false; > > + > > + /* > > + * See can_change_pte_writable(): we broke COW and could map the page > > + * writable if we have an exclusive anonymous page ... > > + */ > > + return page && PageAnon(page) && PageAnonExclusive(page); > > +} > > + > > static struct page *no_page_table(struct vm_area_struct *vma, > > unsigned int flags, unsigned long address) > > { > > @@ -613,6 +640,18 @@ static struct page *no_page_table(struct vm_area_struct *vma, > > } > > #ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES > > +/* FOLL_FORCE can write to even unwritable PUDs in COW mappings. */ > > +static inline bool can_follow_write_pud(pud_t pud, struct page *page, > > + struct vm_area_struct *vma, > > + unsigned int flags) > > +{ > > + /* If the pud is writable, we can write to the page. */ > > + if (pud_write(pud)) > > + return true; > > + > > + return can_follow_write_common(page, vma, flags); > > +} > > + > > static struct page *follow_huge_pud(struct vm_area_struct *vma, > > unsigned long addr, pud_t *pudp, > > int flags, struct follow_page_context *ctx) > > @@ -625,13 +664,16 @@ static struct page *follow_huge_pud(struct vm_area_struct *vma, > > assert_spin_locked(pud_lockptr(mm, pudp)); > > - if ((flags & FOLL_WRITE) && !pud_write(pud)) > > + pfn += (addr & ~PUD_MASK) >> PAGE_SHIFT; > > + page = pfn_to_page(pfn); > > + > > + if ((flags & FOLL_WRITE) && > > + !can_follow_write_pud(pud, page, vma, flags)) > > return NULL; > > if (!pud_present(pud)) > > return NULL; > > - pfn += (addr & ~PUD_MASK) >> PAGE_SHIFT; > > That looks wrong. See follow_huge_pmd() for reference > > (1) You must not do a pfn_to_page() before we verified that we have a > present PUD. > > (2) can_follow_write_pud() must be called with the first mapped page. It > would currently with hugetlb not be strictly required, but is not > future proof. > > > > It must be likely be something like: > > > if (!pud_present(pud)) > return NULL; > > if ((flags & FOLL_WRITE) && > !can_follow_write_pud(pud, pfn_to_page(pfn), vma, flags)) > return NULL; > > pfn += (addr & ~PUD_MASK) >> PAGE_SHIFT; > page = pfn_to_page(pfn); > Ok, let me fix that. > > delayacct_wpcopy_end(); > > return 0; > > @@ -5943,7 +5944,8 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_folio, > > spin_lock(vmf->ptl); > > vmf->pte = hugetlb_walk(vma, vmf->address, huge_page_size(h)); > > if (likely(vmf->pte && pte_same(huge_ptep_get(mm, vmf->address, vmf->pte), pte))) { > > - pte_t newpte = make_huge_pte(vma, &new_folio->page, !unshare); > > + const bool writable = !unshare && (vma->vm_flags & VM_WRITE); > > + pte_t newpte = make_huge_pte(vma, &new_folio->page, writable); > ); > > You probably missed my earlier comment. After the recent changes to > make_huge_pte() that are already in mm/mm-unstable, this hunk can be dropped > and left unchanged. make_huge_pte() will perform the VM_WRITE check. Ok, will fix as well -- Guillaume Morin