All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: <linux-mips@linux-mips.org>, Lars Persson <lars.persson@axis.com>,
	"stable # v4 . 1+" <stable@vger.kernel.org>,
	"Steven J. Hill" <Steven.Hill@imgtec.com>,
	David Daney <david.daney@cavium.com>,
	Huacai Chen <chenhc@lemote.com>,
	Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>,
	<linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jerome Marchand <jmarchan@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [4/4] MIPS: Sync icache & dcache in set_pte_at
Date: Fri, 4 Mar 2016 17:06:04 -0800	[thread overview]
Message-ID: <56DA30FC.10603@imgtec.com> (raw)
In-Reply-To: <56D9F78E.6090303@imgtec.com>

On Sat, Mar 05, 2016 at 12:21:54AM +0000, Paul Burton wrote:

> > On Fri, Mar 04, 2016 at 07:02:24PM +0000, Lars Persson wrote:
> > > Hi
> > >
> > > Some further thoughts on the matter. You have so far not showed a
> > > valid example of a race condition. The two examples you give in the
> > > commit message are for a _single_ thread existing in the address space
> > > (fork and execve).
> >
> > Hi Lars,
> >
> > Neither fork nor exec are limited to a single thread existing in the
> > address space - I'm not sure what you're saying? fork by its very
> > definition results in 2.
>
> Ok, exec kinda is (it's late...). Still, fork clearly isn't.
Again - fork doesn't copy any user page. Copy_page_range just 
manipulates PTE tree.

So, no user page cache flushes are needed on MIPS during fork, at least now.

- Leonid.

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org, Lars Persson <lars.persson@axis.com>,
	"stable # v4 . 1+" <stable@vger.kernel.org>,
	"Steven J. Hill" <Steven.Hill@imgtec.com>,
	David Daney <david.daney@cavium.com>,
	Huacai Chen <chenhc@lemote.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Jerome Marchand <jmarchan@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [4/4] MIPS: Sync icache & dcache in set_pte_at
Date: Fri, 4 Mar 2016 17:06:04 -0800	[thread overview]
Message-ID: <56DA30FC.10603@imgtec.com> (raw)
Message-ID: <20160305010604.Ao2Xm5WmW8er2Egdt1_5PBQTN4XB4CqIxPKzB5IEGiM@z> (raw)
In-Reply-To: <56D9F78E.6090303@imgtec.com>

On Sat, Mar 05, 2016 at 12:21:54AM +0000, Paul Burton wrote:

> > On Fri, Mar 04, 2016 at 07:02:24PM +0000, Lars Persson wrote:
> > > Hi
> > >
> > > Some further thoughts on the matter. You have so far not showed a
> > > valid example of a race condition. The two examples you give in the
> > > commit message are for a _single_ thread existing in the address space
> > > (fork and execve).
> >
> > Hi Lars,
> >
> > Neither fork nor exec are limited to a single thread existing in the
> > address space - I'm not sure what you're saying? fork by its very
> > definition results in 2.
>
> Ok, exec kinda is (it's late...). Still, fork clearly isn't.
Again - fork doesn't copy any user page. Copy_page_range just 
manipulates PTE tree.

So, no user page cache flushes are needed on MIPS during fork, at least now.

- Leonid.

  parent reply	other threads:[~2016-03-05  1:06 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01  2:37 [PATCH 0/4] MIPS cache & highmem fixes Paul Burton
2016-03-01  2:37 ` Paul Burton
2016-03-01  2:37 ` [PATCH 1/4] MIPS: Flush dcache for flush_kernel_dcache_page Paul Burton
2016-03-01  2:37   ` Paul Burton
2016-03-04 15:09   ` Lars Persson
2016-03-29  8:29     ` Ralf Baechle
2016-03-01  2:37 ` [PATCH 2/4] MIPS: Flush highmem pages in __flush_dcache_page Paul Burton
2016-03-01  2:37   ` Paul Burton
2016-03-29  8:35   ` Ralf Baechle
2016-03-29  8:55     ` Paul Burton
2016-03-29  8:55       ` Paul Burton
2016-03-01  2:37 ` [PATCH 3/4] MIPS: Handle highmem pages in __update_cache Paul Burton
2016-03-01  2:37   ` Paul Burton
2016-03-29  8:39   ` Ralf Baechle
2016-03-01  2:37 ` [PATCH 4/4] MIPS: Sync icache & dcache in set_pte_at Paul Burton
2016-03-01  2:37   ` Paul Burton
2016-03-01  9:44   ` Lars Persson
2016-03-01  9:44     ` Lars Persson
2016-03-01 17:13   ` David Daney
2016-03-01 17:13     ` David Daney
2016-03-01 17:19     ` Paul Burton
2016-03-01 17:19       ` Paul Burton
2016-03-02 14:12       ` Ralf Baechle
2016-03-02 14:24         ` Paul Burton
2016-03-02 14:24           ` Paul Burton
2016-03-04 17:43       ` David Daney
2016-03-04 17:43         ` David Daney
2016-03-04 17:47         ` Paul Burton
2016-03-04 17:47           ` Paul Burton
2016-03-03  3:03   ` [4/4] " Leonid Yegoshin
2016-03-03  3:03     ` Leonid Yegoshin
2016-03-04 10:37     ` Paul Burton
2016-03-04 10:37       ` Paul Burton
2016-03-04 15:20       ` Lars Persson
2016-03-04 21:01       ` Leonid Yegoshin
2016-03-04 21:01         ` Leonid Yegoshin
2016-03-04 21:21         ` Leonid Yegoshin
2016-03-04 21:21           ` Leonid Yegoshin
2016-03-05  1:06         ` Leonid Yegoshin [this message]
2016-03-05  1:06           ` Leonid Yegoshin
2016-03-04 19:02   ` [PATCH 4/4] " Lars Persson
2016-03-05  0:21     ` Paul Burton
2016-03-05  0:27       ` Paul Burton
2016-03-02 11:39 ` [PATCH 0/4] MIPS cache & highmem fixes Harvey Hunt
2016-03-02 11:39   ` Harvey Hunt

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=56DA30FC.10603@imgtec.com \
    --to=leonid.yegoshin@imgtec.com \
    --cc=Steven.Hill@imgtec.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=chenhc@lemote.com \
    --cc=david.daney@cavium.com \
    --cc=jmarchan@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=lars.persson@axis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=paul.burton@imgtec.com \
    --cc=ralf@linux-mips.org \
    --cc=stable@vger.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.