All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	David Airlie <airlied@linux.ie>, Ingo Molnar <mingo@redhat.com>,
	Inki Dae <inki.dae@samsung.com>, Jonathan Corbet <corbet@lwn.net>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Kukjin Kim <kgene@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Patrik Jakobsson <patrik.r.j>
Subject: Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600	[thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>

On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> >  	if (!pte)
> >  		goto out;
> >  	retval = -EBUSY;
> > -	if (!pte_none(*pte))
> > -		goto out_unlock;
> > +	if (!pte_none(*pte)) {
> > +		if (mkwrite) {
> > +			if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

	if (!pte_none(*pte)) {
		if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
			goto out_unlock;
		if (mkwrite) {
			entry = *pte;
			goto out_mkwrite;
		} else
			goto out_unlock;
	}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	David Airlie <airlied@linux.ie>, Ingo Molnar <mingo@redhat.com>,
	Inki Dae <inki.dae@samsung.com>, Jonathan Corbet <corbet@lwn.net>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Kukjin Kim <kgene@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Patrik Jakobsson <patrik.r.j
Subject: Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600	[thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>

On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> >  	if (!pte)
> >  		goto out;
> >  	retval = -EBUSY;
> > -	if (!pte_none(*pte))
> > -		goto out_unlock;
> > +	if (!pte_none(*pte)) {
> > +		if (mkwrite) {
> > +			if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

	if (!pte_none(*pte)) {
		if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
			goto out_unlock;
		if (mkwrite) {
			entry = *pte;
			goto out_mkwrite;
		} else
			goto out_unlock;
	}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-doc@vger.kernel.org, David Airlie <airlied@linux.ie>,
	Dave Chinner <david@fromorbit.com>,
	dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Christoph Hellwig <hch@lst.de>,
	linux-samsung-soc@vger.kernel.org,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Patrik Jakobsson <patrik.r.jakobsson@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-ext4@vger.kernel.org,
	Matthew Wilcox <mawilcox@microsoft.com>,
	linux-arm-msm@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	Inki Dae <inki.dae@samsung.com>,
	linux-nvdimm@lists.01.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	Theodore Ts'o <tytso@mit.edu>, Jonathan Corbet <corbet@lwn.net>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Rob Clark <robdclark@gmail.com>, Kukjin Kim <kgene@kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600	[thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>

On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> >  	if (!pte)
> >  		goto out;
> >  	retval = -EBUSY;
> > -	if (!pte_none(*pte))
> > -		goto out_unlock;
> > +	if (!pte_none(*pte)) {
> > +		if (mkwrite) {
> > +			if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

	if (!pte_none(*pte)) {
		if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
			goto out_unlock;
		if (mkwrite) {
			entry = *pte;
			goto out_mkwrite;
		} else
			goto out_unlock;
	}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	David Airlie <airlied@linux.ie>, Ingo Molnar <mingo@redhat.com>,
	Inki Dae <inki.dae@samsung.com>, Jonathan Corbet <corbet@lwn.net>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Kukjin Kim <kgene@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Patrik Jakobsson <patrik.r.jakobsson@gmail.com>,
	Rob Clark <robdclark@gmail.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	linux-samsung-soc@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600	[thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>

On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> >  	if (!pte)
> >  		goto out;
> >  	retval = -EBUSY;
> > -	if (!pte_none(*pte))
> > -		goto out_unlock;
> > +	if (!pte_none(*pte)) {
> > +		if (mkwrite) {
> > +			if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

	if (!pte_none(*pte)) {
		if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
			goto out_unlock;
		if (mkwrite) {
			entry = *pte;
			goto out_mkwrite;
		} else
			goto out_unlock;
	}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)

WARNING: multiple messages have this Message-ID (diff)
From: ross.zwisler@linux.intel.com (Ross Zwisler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600	[thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>

On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> >  	if (!pte)
> >  		goto out;
> >  	retval = -EBUSY;
> > -	if (!pte_none(*pte))
> > -		goto out_unlock;
> > +	if (!pte_none(*pte)) {
> > +		if (mkwrite) {
> > +			if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

	if (!pte_none(*pte)) {
		if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
			goto out_unlock;
		if (mkwrite) {
			entry = *pte;
			goto out_mkwrite;
		} else
			goto out_unlock;
	}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)

WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Theodore Ts'o <tytso@mit.edu>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Christoph Hellwig <hch@lst.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Chinner <david@fromorbit.com>,
	David Airlie <airlied@linux.ie>, Ingo Molnar <mingo@redhat.com>,
	Inki Dae <inki.dae@samsung.com>, Jonathan Corbet <corbet@lwn.net>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Kukjin Kim <kgene@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Matthew Wilcox <mawilcox@microsoft.com>,
	Patrik Jakobsson <patrik.r.jakobsson@gmail.com>,
	Rob Clark <robdclark@gmail.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	linux-samsung-soc@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600	[thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>

On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> >  	if (!pte)
> >  		goto out;
> >  	retval = -EBUSY;
> > -	if (!pte_none(*pte))
> > -		goto out_unlock;
> > +	if (!pte_none(*pte)) {
> > +		if (mkwrite) {
> > +			if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

	if (!pte_none(*pte)) {
		if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
			goto out_unlock;
		if (mkwrite) {
			entry = *pte;
			goto out_mkwrite;
		} else
			goto out_unlock;
	}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-07-24 15:23 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-21 22:39 [PATCH v4 0/5] DAX common 4k zero page Ross Zwisler
2017-07-21 22:39 ` Ross Zwisler
2017-07-21 22:39 ` Ross Zwisler
2017-07-21 22:39 ` Ross Zwisler
2017-07-21 22:39 ` Ross Zwisler
     [not found] ` <20170721223956.29485-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-21 22:39   ` [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed() Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-22 16:21     ` Dan Williams
2017-07-22 16:21       ` Dan Williams
2017-07-22 16:21       ` Dan Williams
2017-07-22 16:21       ` Dan Williams
2017-07-22 16:21       ` Dan Williams
2017-07-22 16:21       ` Dan Williams
2017-07-24 11:15       ` Jan Kara
2017-07-24 11:15         ` Jan Kara
2017-07-24 11:15         ` Jan Kara
2017-07-24 11:15         ` Jan Kara
2017-07-24 11:15         ` Jan Kara
2017-07-24 11:15         ` Jan Kara
     [not found]         ` <20170724111531.GG652-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-07-24 15:13           ` Ross Zwisler
2017-07-24 15:13             ` Ross Zwisler
2017-07-24 15:13             ` Ross Zwisler
2017-07-24 15:13             ` Ross Zwisler
2017-07-24 15:13             ` Ross Zwisler
2017-07-24 15:13             ` Ross Zwisler
2017-07-24 11:25     ` Jan Kara
2017-07-24 11:25       ` Jan Kara
2017-07-24 11:25       ` Jan Kara
2017-07-24 11:25       ` Jan Kara
2017-07-24 15:23       ` Ross Zwisler [this message]
2017-07-24 15:23         ` Ross Zwisler
2017-07-24 15:23         ` Ross Zwisler
2017-07-24 15:23         ` Ross Zwisler
2017-07-24 15:23         ` Ross Zwisler
2017-07-24 15:23         ` Ross Zwisler
     [not found]         ` <20170724152357.GB1639-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-24 15:59           ` Jan Kara
2017-07-24 15:59             ` Jan Kara
2017-07-24 15:59             ` Jan Kara
2017-07-24 15:59             ` Jan Kara
2017-07-24 15:59             ` Jan Kara
2017-07-21 22:39   ` [PATCH v4 2/5] dax: relocate some dax functions Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
     [not found]     ` <20170721223956.29485-3-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-24 11:35       ` Jan Kara
2017-07-24 11:35         ` Jan Kara
2017-07-24 11:35         ` Jan Kara
2017-07-24 11:35         ` Jan Kara
2017-07-21 22:39   ` [PATCH v4 3/5] dax: use common 4k zero page for dax mmap reads Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-24 11:46     ` Jan Kara
2017-07-24 11:46       ` Jan Kara
2017-07-24 11:46       ` Jan Kara
2017-07-24 11:46       ` Jan Kara
2017-07-24 11:46       ` Jan Kara
2017-07-21 22:39   ` [PATCH v4 4/5] dax: remove DAX code from page_cache_tree_insert() Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-24 11:47     ` Jan Kara
2017-07-24 11:47       ` Jan Kara
2017-07-24 11:47       ` Jan Kara
2017-07-24 11:47       ` Jan Kara
2017-07-24 11:47       ` Jan Kara
2017-07-21 22:39   ` [PATCH v4 5/5] dax: move all DAX radix tree defs to fs/dax.c Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-21 22:39     ` Ross Zwisler
2017-07-24 11:48     ` Jan Kara
2017-07-24 11:48       ` Jan Kara
2017-07-24 11:48       ` Jan Kara
2017-07-24 11:48       ` Jan Kara
2017-07-24 11:48       ` Jan Kara

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=20170724152357.GB1639@linux.intel.com \
    --to=ross.zwisler@linux.intel.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=airlied@linux.ie \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=inki.dae@samsung.com \
    --cc=jack@suse.cz \
    --cc=jy0922.shim@samsung.com \
    --cc=kgene@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=mingo@redhat.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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.