All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Will Deacon <will@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jan Kara <jack@suse.cz>, Minchan Kim <minchan@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Vinayak Menon <vinmenon@codeaurora.org>,
	Hugh Dickins <hughd@google.com>,
	kernel-team@android.com
Subject: Re: [PATCH v2 2/3] mm: Allow architectures to request 'old' entries when prefaulting
Date: Mon, 11 Jan 2021 17:47:13 +0300	[thread overview]
Message-ID: <20210111144713.3akhv75xzk7u6rgu@box> (raw)
In-Reply-To: <20210111143742.GD7642@willie-the-truck>

On Mon, Jan 11, 2021 at 02:37:42PM +0000, Will Deacon wrote:
> On Mon, Jan 11, 2021 at 05:25:33PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jan 08, 2021 at 05:15:16PM +0000, Will Deacon wrote:
> > > diff --git a/mm/filemap.c b/mm/filemap.c
> > > index c1f2dc89b8a7..0fb9d1714797 100644
> > > --- a/mm/filemap.c
> > > +++ b/mm/filemap.c
> > > @@ -3051,14 +3051,18 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
> > >  		if (!pte_none(*vmf->pte))
> > >  			goto unlock;
> > >  
> > > +		/* We're about to handle the fault */
> > > +		if (vmf->address == address) {
> > > +			vmf->flags &= ~FAULT_FLAG_PREFAULT;
> > > +			ret = VM_FAULT_NOPAGE;
> > > +		} else {
> > > +			vmf->flags |= FAULT_FLAG_PREFAULT;
> > > +		}
> > > +
> > 
> > Do we need to restore the oririnal status of the bit once we are done?
> 
> I can certainly add that, although it doesn't look like we do that for
> vmf->pte, so it's hard to tell what the rules are here. It certainly feels
> odd to restore some fields but not others, as it looks like vmf->address
> will be out-of-whack with vmf->pte when filemap_map_pages() returns. Am I
> missing something?

Unlike vmf->flags or vmf->address, vmf->pte is not going to be reused.
finish_fault() will overwrite it.

Yeah, it's messy.

-- 
 Kirill A. Shutemov

WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Will Deacon <will@kernel.org>
Cc: kernel-team@android.com, Jan Kara <jack@suse.cz>,
	Minchan Kim <minchan@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Vinayak Menon <vinmenon@codeaurora.org>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/3] mm: Allow architectures to request 'old' entries when prefaulting
Date: Mon, 11 Jan 2021 17:47:13 +0300	[thread overview]
Message-ID: <20210111144713.3akhv75xzk7u6rgu@box> (raw)
In-Reply-To: <20210111143742.GD7642@willie-the-truck>

On Mon, Jan 11, 2021 at 02:37:42PM +0000, Will Deacon wrote:
> On Mon, Jan 11, 2021 at 05:25:33PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jan 08, 2021 at 05:15:16PM +0000, Will Deacon wrote:
> > > diff --git a/mm/filemap.c b/mm/filemap.c
> > > index c1f2dc89b8a7..0fb9d1714797 100644
> > > --- a/mm/filemap.c
> > > +++ b/mm/filemap.c
> > > @@ -3051,14 +3051,18 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
> > >  		if (!pte_none(*vmf->pte))
> > >  			goto unlock;
> > >  
> > > +		/* We're about to handle the fault */
> > > +		if (vmf->address == address) {
> > > +			vmf->flags &= ~FAULT_FLAG_PREFAULT;
> > > +			ret = VM_FAULT_NOPAGE;
> > > +		} else {
> > > +			vmf->flags |= FAULT_FLAG_PREFAULT;
> > > +		}
> > > +
> > 
> > Do we need to restore the oririnal status of the bit once we are done?
> 
> I can certainly add that, although it doesn't look like we do that for
> vmf->pte, so it's hard to tell what the rules are here. It certainly feels
> odd to restore some fields but not others, as it looks like vmf->address
> will be out-of-whack with vmf->pte when filemap_map_pages() returns. Am I
> missing something?

Unlike vmf->flags or vmf->address, vmf->pte is not going to be reused.
finish_fault() will overwrite it.

Yeah, it's messy.

-- 
 Kirill A. Shutemov

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-11 14:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08 17:15 [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Will Deacon
2021-01-08 17:15 ` Will Deacon
2021-01-08 17:15 ` [PATCH v2 1/3] mm: Cleanup faultaround and finish_fault() codepaths Will Deacon
2021-01-08 17:15   ` Will Deacon
2021-01-11 14:26   ` Kirill A. Shutemov
2021-01-11 14:26     ` Kirill A. Shutemov
2021-01-11 14:27     ` Will Deacon
2021-01-11 14:27       ` Will Deacon
2021-01-08 17:15 ` [PATCH v2 2/3] mm: Allow architectures to request 'old' entries when prefaulting Will Deacon
2021-01-08 17:15   ` Will Deacon
2021-01-11 14:25   ` Kirill A. Shutemov
2021-01-11 14:25     ` Kirill A. Shutemov
2021-01-11 14:37     ` Will Deacon
2021-01-11 14:37       ` Will Deacon
2021-01-11 14:47       ` Kirill A. Shutemov [this message]
2021-01-11 14:47         ` Kirill A. Shutemov
2021-01-08 17:15 ` [PATCH v2 3/3] arm64: mm: Implement arch_wants_old_prefaulted_pte() Will Deacon
2021-01-08 17:15   ` Will Deacon
2021-01-08 19:34 ` [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Linus Torvalds
2021-01-08 19:34   ` Linus Torvalds
2021-01-08 19:34   ` Linus Torvalds
2021-01-08 19:42   ` Linus Torvalds
2021-01-08 19:42     ` Linus Torvalds
2021-01-08 19:42     ` Linus Torvalds
2021-01-11 14:01     ` Will Deacon
2021-01-11 14:01       ` Will Deacon
2021-01-11 13:30   ` Will Deacon
2021-01-11 13:30     ` Will Deacon
2021-01-11 21:03     ` Hugh Dickins
2021-01-11 21:03       ` Hugh Dickins
2021-01-11 21:03       ` Hugh Dickins
2021-01-12 21:46       ` Will Deacon
2021-01-12 21:46         ` Will Deacon
2021-01-11 14:24   ` Kirill A. Shutemov
2021-01-11 14:24     ` Kirill A. Shutemov
2021-01-11 19:25     ` Linus Torvalds
2021-01-11 19:25       ` Linus Torvalds
2021-01-11 19:25       ` Linus Torvalds
2021-01-12 21:47       ` Will Deacon
2021-01-12 21:47         ` Will Deacon
2021-01-12 21:55         ` Linus Torvalds
2021-01-12 21:55           ` Linus Torvalds
2021-01-12 21:55           ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210111144713.3akhv75xzk7u6rgu@box \
    --to=kirill@shutemov.name \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=kernel-team@android.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vinmenon@codeaurora.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.