From: Sagi Shahar
Added functionality for moving the mirror EPT table from one TD to a new
one.
This function moves the root of the mirror EPT table and overwrites the
root of the destination.
Signed-off-by: Sagi Shahar
Signed-off-by: Ryan Afranji
---
arch/x86/kvm/mmu.h | 2
From: Sagi Shahar
tdp_mmu_pages counts all the active pages used by the mmu. When we
transfer the state during intra-host migration we need to transfer the
mirror pages but not the direct ones. The direct pages are going to
be re-faulted as needed on the destination, but that approach doesn&#
On Fri, 27 Sep 2024 16:21:30 +0530 Donet Tom wrote:
> >> Test Result with this patch
> >> ===
> >> # RUN hmm2.hmm2_device_private.double_map ...
> >> #OK hmm2.hmm2_device_private.double_map
> >> ok 53 hmm2.hmm2_device_private.double_map
> >>
>
On 9/27/24 12:48, Muhammad Usama Anjum wrote:
On 9/27/24 10:07 AM, Donet Tom wrote:
The hmm2 double_map test was failing due to an incorrect
buffer->mirror size. The buffer->mirror size was 6, while buffer->ptr
size was 6 * PAGE_SIZE. The test failed because the kernel's
copy_to
On 9/27/24 10:07 AM, Donet Tom wrote:
> The hmm2 double_map test was failing due to an incorrect
> buffer->mirror size. The buffer->mirror size was 6, while buffer->ptr
> size was 6 * PAGE_SIZE. The test failed because the kernel's
> copy_to_user function was attempti
The hmm2 double_map test was failing due to an incorrect
buffer->mirror size. The buffer->mirror size was 6, while buffer->ptr
size was 6 * PAGE_SIZE. The test failed because the kernel's
copy_to_user function was attempting to copy a 6 * PAGE_SIZE buffer
to buffer->mirror.
will take in the
software data path and program the device accordingly.
If the path cannot be resolved (in this case because of an unresolved
neighbor), then mirror installation fails until the path is resolved.
This results in a race that causes the test to sometimes fail.
Fix this by setting the
will take in the
software data path and program the device accordingly.
If the path cannot be resolved (in this case because of an unresolved
neighbor), then mirror installation fails until the path is resolved.
This results in a race that causes the test to sometimes fail.
Fix this by setting the
will take in the
software data path and program the device accordingly.
If the path cannot be resolved (in this case because of an unresolved
neighbor), then mirror installation fails until the path is resolved.
This results in a race that causes the test to sometimes fail.
Fix this by setting the
will take in the
software data path and program the device accordingly.
If the path cannot be resolved (in this case because of an unresolved
neighbor), then mirror installation fails until the path is resolved.
This results in a race that causes the test to sometimes fail.
Fix this by setting the
tic int lan937x_port_mirror_add(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror,
+ bool ingress)
+{
+ struct ksz_device *dev = ds->priv;
+
+ if (ingress)
+ lan937x_port_cfg
@@ -562,7 +562,7 @@ void hl_cs_rollback_all(struct hl_device *hdev)
for (i = 0 ; i < hdev->asic_prop.completion_queues_count ; i++)
flush_workqueue(hdev->cq_wq[i]);
- /* Make sure we don't have leftovers in the H/W queues mirror list */
+ /* Make sure
0644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -838,6 +838,7 @@ ff_layout_pg_init_read(struct nfs_pageio_descriptor *pgio,
struct nfs4_ff_layout_mirror *mirror;
struct nfs4_pnfs_ds *ds;
int ds_idx;
+ u32 i
From: Trond Myklebust
commit 8b04013737341442ed914b336cde866b902664ae upstream.
If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror->pg_list.
Fixes: d600ad1f2bdb (&qu
From: Trond Myklebust
commit 8b04013737341442ed914b336cde866b902664ae upstream.
If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror->pg_list.
Fixes: d600ad1f2bdb (&qu
From: Trond Myklebust
commit 8b04013737341442ed914b336cde866b902664ae upstream.
If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror->pg_list.
Fixes: d600ad1f2bdb (&qu
From: Trond Myklebust
commit 8b04013737341442ed914b336cde866b902664ae upstream.
If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror->pg_list.
Fixes: d600ad1f2bdb (&qu
From: Trond Myklebust
commit 8b04013737341442ed914b336cde866b902664ae upstream.
If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror->pg_list.
Fixes: d600ad1f2bdb (&qu
From: Trond Myklebust
commit 8b04013737341442ed914b336cde866b902664ae upstream.
If the mirror count changes in the new layout we pick up inside
ff_layout_pg_init_write(), then we can end up adding the
request to the wrong mirror and corrupting the mirror->pg_list.
Fixes: d600ad1f2bdb (&qu
3.16.85-rc1 review patch. If anyone has any objections, please let me know.
--
From: Ben Hutchings
Change the type of next_cmd_len to unsigned char, done in upstream
commit 65c26a0f3969 "sg: relax 16 byte cdb restriction".
Move the range check from sg_write() to sg_ioctl(), wh
From: Danielle Ratson
[ Upstream commit 52feb8b588f6d23673dd7cc2b44b203493b627f6 ]
The ASIC can only mirror a packet to one port, but when user is trying
to set more than one mirror action, it doesn't fail.
Add a check if more than one mirror action was specified per rule and if so,
fai
From: Danielle Ratson
[ Upstream commit 52feb8b588f6d23673dd7cc2b44b203493b627f6 ]
The ASIC can only mirror a packet to one port, but when user is trying
to set more than one mirror action, it doesn't fail.
Add a check if more than one mirror action was specified per rule and if so,
fai
From: Danielle Ratson
[ Upstream commit 52feb8b588f6d23673dd7cc2b44b203493b627f6 ]
The ASIC can only mirror a packet to one port, but when user is trying
to set more than one mirror action, it doesn't fail.
Add a check if more than one mirror action was specified per rule and if so,
fai
:
> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h:69:20: error: field ‘mirror’
> has incomplete type
> struct hmm_mirror mirror;
> ^
> make[5]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o] Error 1
> make[4]: *** [drivers/gpu/drm/amd/amdgpu] Error 2
> mak
type
struct hmm_mirror mirror;
^
make[5]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o] Error 1
make[4]: *** [drivers/gpu/drm/amd/amdgpu] Error 2
make[3]: *** [drivers/gpu/drm] Error 2
make[2]: *** [drivers/gpu] Error 2
Kernel version: 5.2.0-next-20190708
Machine: Power 9
K
From: Jérôme Glisse
HMM mirror is a device driver helpers to mirror range of virtual address.
It means that the process jobs running on the device can access the same
virtual address as the CPU threads of that process. This patch adds support
for mirroring mapping of file that are on a DAX block
From: Jérôme Glisse
HMM mirror is a device driver helpers to mirror range of virtual address.
It means that the process jobs running on the device can access the same
virtual address as the CPU threads of that process. This patch adds support
for hugetlbfs mapping (ie range of virtual address
On Thu, Mar 28, 2019 at 11:04:26AM -0700, Ira Weiny wrote:
> On Mon, Mar 25, 2019 at 10:40:09AM -0400, Jerome Glisse wrote:
> > From: Jérôme Glisse
> >
> > HMM mirror is a device driver helpers to mirror range of virtual address.
> > It means that the process job
On Mon, Mar 25, 2019 at 10:40:09AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> HMM mirror is a device driver helpers to mirror range of virtual address.
> It means that the process jobs running on the device can access the same
> virtual address as the CPU threads of tha
On Mon, Mar 25, 2019 at 10:40:08AM -0400, Jerome Glisse wrote:
> From: Jérôme Glisse
>
> HMM mirror is a device driver helpers to mirror range of virtual address.
> It means that the process jobs running on the device can access the same
> virtual address as the CPU threads of tha
From: Jérôme Glisse
HMM mirror is a device driver helpers to mirror range of virtual address.
It means that the process jobs running on the device can access the same
virtual address as the CPU threads of that process. This patch adds support
for mirroring mapping of file that are on a DAX block
From: Jérôme Glisse
HMM mirror is a device driver helpers to mirror range of virtual address.
It means that the process jobs running on the device can access the same
virtual address as the CPU threads of that process. This patch adds support
for hugetlbfs mapping (ie range of virtual address
On Wed, Mar 13, 2019 at 09:06:04AM -0700, Andrew Morton wrote:
> On Tue, 12 Mar 2019 20:10:19 -0400 Jerome Glisse wrote:
>
> > > You're correct. We chose to go this way because the HMM code is so
> > > large and all-over-the-place that developing it in a standalone tree
> > > seemed impractical
On Tue, 12 Mar 2019 20:10:19 -0400 Jerome Glisse wrote:
> > You're correct. We chose to go this way because the HMM code is so
> > large and all-over-the-place that developing it in a standalone tree
> > seemed impractical - better to feed it into mainline piecewise.
> >
> > This decision very
On Tue, Mar 12, 2019 at 1:34 PM Dave Chinner wrote:
>
> On Tue, Mar 12, 2019 at 12:30:52PM -0700, Dan Williams wrote:
> > On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> > > On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> > > > On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse
On Tue, Mar 12, 2019 at 05:46:51PM -0700, Dan Williams wrote:
> On Tue, Mar 12, 2019 at 5:10 PM Jerome Glisse wrote:
> >
> > On Tue, Mar 12, 2019 at 02:52:14PM -0700, Andrew Morton wrote:
> > > On Tue, 12 Mar 2019 12:30:52 -0700 Dan Williams
> > > wrote:
> > >
> > > > On Tue, Mar 12, 2019 at 12:
On Tue, Mar 12, 2019 at 5:10 PM Jerome Glisse wrote:
>
> On Tue, Mar 12, 2019 at 02:52:14PM -0700, Andrew Morton wrote:
> > On Tue, 12 Mar 2019 12:30:52 -0700 Dan Williams
> > wrote:
> >
> > > On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> > > > On Tue, Mar 12, 2019 at 09:06:12AM -0700
On Tue, Mar 12, 2019 at 02:52:14PM -0700, Andrew Morton wrote:
> On Tue, 12 Mar 2019 12:30:52 -0700 Dan Williams
> wrote:
>
> > On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> > > On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> > > > On Tue, Mar 12, 2019 at 8:26 AM Jerom
On Tue, 12 Mar 2019 12:30:52 -0700 Dan Williams
wrote:
> On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> > On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> > > On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote:
> [..]
> > > > Spirit of the rule is better than blind app
On Tue, Mar 12, 2019 at 12:30:52PM -0700, Dan Williams wrote:
> On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> > On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> > > On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote:
> [..]
> > > > Spirit of the rule is better than blind
On Tue, Mar 12, 2019 at 12:06 PM Jerome Glisse wrote:
> On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> > On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote:
[..]
> > > Spirit of the rule is better than blind application of rule.
> >
> > Again, I fail to see why HMM is suddenly u
On Tue, Mar 12, 2019 at 09:06:12AM -0700, Dan Williams wrote:
> On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote:
> >
> > On Mon, Mar 11, 2019 at 08:13:53PM -0700, Dan Williams wrote:
> > > On Thu, Mar 7, 2019 at 10:56 AM Jerome Glisse wrote:
> > > >
> > > > On Thu, Mar 07, 2019 at 09:46:54AM
On Tue, Mar 12, 2019 at 8:26 AM Jerome Glisse wrote:
>
> On Mon, Mar 11, 2019 at 08:13:53PM -0700, Dan Williams wrote:
> > On Thu, Mar 7, 2019 at 10:56 AM Jerome Glisse wrote:
> > >
> > > On Thu, Mar 07, 2019 at 09:46:54AM -0800, Andrew Morton wrote:
> > > > On Tue, 5 Mar 2019 20:20:10 -0800 Dan
On Mon, Mar 11, 2019 at 08:13:53PM -0700, Dan Williams wrote:
> On Thu, Mar 7, 2019 at 10:56 AM Jerome Glisse wrote:
> >
> > On Thu, Mar 07, 2019 at 09:46:54AM -0800, Andrew Morton wrote:
> > > On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams
> > > wrote:
> > >
> > > > My hesitation would be drast
On Thu, Mar 7, 2019 at 10:56 AM Jerome Glisse wrote:
>
> On Thu, Mar 07, 2019 at 09:46:54AM -0800, Andrew Morton wrote:
> > On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams
> > wrote:
> >
> > > My hesitation would be drastically reduced if there was a plan to
> > > avoid dangling unconsumed symbol
On Thu, Mar 07, 2019 at 09:46:54AM -0800, Andrew Morton wrote:
> On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams
> wrote:
>
> > My hesitation would be drastically reduced if there was a plan to
> > avoid dangling unconsumed symbols and functionality. Specifically one
> > or more of the following
On Tue, 5 Mar 2019 20:20:10 -0800 Dan Williams wrote:
> My hesitation would be drastically reduced if there was a plan to
> avoid dangling unconsumed symbols and functionality. Specifically one
> or more of the following suggestions:
>
> * EXPORT_SYMBOL_GPL on all exports to avoid a growing liab
The track record to date has not been "merge HMM patch in one release
> > > > and merge the driver updates the next". If that is the plan going
> > > > forward that's great, and I do appreciate that this set came with
> > > > driver changes, and maintai
at's great, and I do appreciate that this set came with
> > > driver changes, and maintain hope the existing exports don't go
> > > user-less for too much longer.
> >
> > Decision time. Jerome, how are things looking for getting these driver
> > changes merged
abandoned.
> > > >
> > > > * No new symbol exports and functionality while existing symbols go
> > > > unconsumed.
> > > >
> > > > These are the minimum requirements I would expect my work, or any
> > > > core-mm work for tha
to be held to, I see no reason why HMM
> > > could not meet the same.
> >
> > nouveau use all of this and other driver patchset have been posted to
> > also use this API.
> >
> > > On this specific patch I would ask that the changelog incorporate the
> &g
On Wed, Mar 6, 2019 at 7:51 AM Jerome Glisse wrote:
>
> On Tue, Mar 05, 2019 at 08:20:10PM -0800, Dan Williams wrote:
> > On Tue, Mar 5, 2019 at 2:16 PM Andrew Morton
> > wrote:
> > >
> > > On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
> > > wrote:
> > >
> > > > >
> > > > > > Another way to
On Tue, Mar 05, 2019 at 08:20:10PM -0800, Dan Williams wrote:
> On Tue, Mar 5, 2019 at 2:16 PM Andrew Morton
> wrote:
> >
> > On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
> > wrote:
> >
> > > >
> > > > > Another way to help allay these worries is commit to no new exports
> > > > > without in
On Tue, Mar 05, 2019 at 02:16:35PM -0800, Andrew Morton wrote:
> On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
> wrote:
>
> > >
> > > > Another way to help allay these worries is commit to no new exports
> > > > without in-tree users. In general, that should go without saying for
> > > > any c
On Tue, Mar 5, 2019 at 2:16 PM Andrew Morton wrote:
>
> On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
> wrote:
>
> > >
> > > > Another way to help allay these worries is commit to no new exports
> > > > without in-tree users. In general, that should go without saying for
> > > > any core chang
On Wed, 30 Jan 2019 21:44:46 -0800 Dan Williams
wrote:
> >
> > > Another way to help allay these worries is commit to no new exports
> > > without in-tree users. In general, that should go without saying for
> > > any core changes for new or future hardware.
> >
> > I always intend to have an up
On Wed, Jan 30, 2019 at 8:17 PM Jerome Glisse wrote:
> On Wed, Jan 30, 2019 at 07:28:12PM -0800, Dan Williams wrote:
[..]
> > > Again HMM API can evolve, i am happy to help with any such change, given
> > > it provides benefit to either mm or device driver (ie changing the HMM
> > > just for the s
On Wed, Jan 30, 2019 at 07:28:12PM -0800, Dan Williams wrote:
> On Wed, Jan 30, 2019 at 10:36 AM Jerome Glisse wrote:
> [..]
> > > > This
> > > > is one of the motivation behind HMM ie have it as an impedence layer
> > > > between mm and device drivers so that mm folks do not have to under-
> > >
On Wed, Jan 30, 2019 at 10:36 AM Jerome Glisse wrote:
[..]
> > > This
> > > is one of the motivation behind HMM ie have it as an impedence layer
> > > between mm and device drivers so that mm folks do not have to under-
> > > stand every single device driver but only have to understand the
> > > c
ased solution without pulling in all of HMM?
> >
> > Kind of both, some of the GPU driver i am converting will use HMM for
> > more than just this GUP reason. But when and for what hardware they
> > will use HMM for is not something i can share (it is up to each vendor
> >
at hardware they
> will use HMM for is not something i can share (it is up to each vendor
> to announce their hardware and feature on their own timeline).
Typically a spec document precedes specific hardware announcement and
Linux enabling is gated on public spec availability.
> So yes you c
gt; > > > On Tue, Jan 29, 2019 at 10:41:23AM -0800, Dan Williams wrote:
> > > > > On Tue, Jan 29, 2019 at 8:54 AM wrote:
> > > > > >
> > > > > > From: Jérôme Glisse
> > > > > >
> > > > > > This add suppor
> > On Tue, Jan 29, 2019 at 8:54 AM wrote:
> > > > >
> > > > > From: Jérôme Glisse
> > > > >
> > > > > This add support to mirror vma which is an mmap of a file which is on
> > > > > a filesystem that using a DAX block
t; From: Jérôme Glisse
> > > >
> > > > This add support to mirror vma which is an mmap of a file which is on
> > > > a filesystem that using a DAX block device. There is no reason not to
> > > > support that case.
> > > >
> > >
>
On Tue, Jan 29, 2019 at 11:32 AM Jerome Glisse wrote:
>
> On Tue, Jan 29, 2019 at 10:41:23AM -0800, Dan Williams wrote:
> > On Tue, Jan 29, 2019 at 8:54 AM wrote:
> > >
> > > From: Jérôme Glisse
> > >
> > > This add support to mirror vma which is
On Tue, Jan 29, 2019 at 10:41:23AM -0800, Dan Williams wrote:
> On Tue, Jan 29, 2019 at 8:54 AM wrote:
> >
> > From: Jérôme Glisse
> >
> > This add support to mirror vma which is an mmap of a file which is on
> > a filesystem that using a DAX block device. Ther
On Tue, Jan 29, 2019 at 8:54 AM wrote:
>
> From: Jérôme Glisse
>
> This add support to mirror vma which is an mmap of a file which is on
> a filesystem that using a DAX block device. There is no reason not to
> support that case.
>
The reason not to support it would be if
From: Jérôme Glisse
This add support to mirror vma which is an mmap of a file which is on
a filesystem that using a DAX block device. There is no reason not to
support that case.
Note that unlike GUP code we do not take page reference hence when we
back-off we have nothing to undo.
Signed-off
tead of arm_syscall in arch/arm/kernel/entry-common.S, which returns
> > > -ENOSYS instead of raising SIGILL. Mirror this behavior for compat
> > > syscalls in arm64.
> > >
> > > Fixes: 532826f3712b607 ("arm64: Mirror arm for unimplemented compat
> > &
t; -ENOSYS instead of raising SIGILL. Mirror this behavior for compat
> > syscalls in arm64.
> >
> > Fixes: 532826f3712b607 ("arm64: Mirror arm for unimplemented compat
> > syscalls")
> > Signed-off-by: Pi-Hsun Shih
> > ---
> > arch/arm6
On Thu, Jan 03, 2019 at 03:45:47PM +0800, Pi-Hsun Shih wrote:
> For syscall number smaller than 0xf, arm calls sys_ni_syscall
> instead of arm_syscall in arch/arm/kernel/entry-common.S, which returns
> -ENOSYS instead of raising SIGILL. Mirror this behavior for compat
> sysca
For syscall number smaller than 0xf, arm calls sys_ni_syscall
instead of arm_syscall in arch/arm/kernel/entry-common.S, which returns
-ENOSYS instead of raising SIGILL. Mirror this behavior for compat
syscalls in arm64.
Fixes: 532826f3712b607 ("arm64: Mirror arm for unimplemented c
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Tigran Mkrtchyan
commit 320f35b7bf8cccf1997ca3126843535e1b95e9c4 upstream.
Since commit bb21ce0ad227 we always enforce per-mirror stateid.
However, this makes sense only for v4+ servers
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Tigran Mkrtchyan
commit 320f35b7bf8cccf1997ca3126843535e1b95e9c4 upstream.
Since commit bb21ce0ad227 we always enforce per-mirror stateid.
However, this makes sense only for v4+ servers
On Wed, Dec 12, 2018 at 08:06:14AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 11, 2018 at 07:49:27PM +0100, Mkrtchyan, Tigran wrote:
> >
> >
> > Hi Greg,
> >
> > Thanks for pushing this into sable as well. However, I think patch makes
> > more sense
> > with 320f35b7bf8cccf1997ca3126843535e
On Tue, Dec 11, 2018 at 07:49:27PM +0100, Mkrtchyan, Tigran wrote:
>
>
> Hi Greg,
>
> Thanks for pushing this into sable as well. However, I think patch makes more
> sense
> with 320f35b7bf8cccf1997ca3126843535e1b95e9c4
I need an ack from the nfs maintainer before I can do that...
quot; , "stable"
> , "Tigran Mkrtchyan"
> , "Rick Macklem" , "Trond
> Myklebust" ,
> "Sasha Levin"
> Sent: Tuesday, December 11, 2018 4:41:10 PM
> Subject: [PATCH 4.19 051/118] flexfiles: use per-mirror
quot; , "stable"
> , "Tigran Mkrtchyan"
> , "Rick Macklem" , "Trond
> Myklebust" ,
> "Sasha Levin"
> Sent: Tuesday, December 11, 2018 4:41:26 PM
> Subject: [PATCH 4.14 26/67] flexfiles: use per-mirror specif
implementation replaces per-mirror provided stateid with
by open or lock stateid.
Ensure that per-mirror stateid is used by ff_layout_write_prepare_v4 and
nfs4_ff_layout_prepare_ds.
Signed-off-by: Tigran Mkrtchyan
Signed-off-by: Rick Macklem
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha
implementation replaces per-mirror provided stateid with
by open or lock stateid.
Ensure that per-mirror stateid is used by ff_layout_write_prepare_v4 and
nfs4_ff_layout_prepare_ds.
Signed-off-by: Tigran Mkrtchyan
Signed-off-by: Rick Macklem
Signed-off-by: Trond Myklebust
Signed-off-by: Sasha
On Sat, Dec 08, 2018 at 10:49:44PM +0800, Bob Liu wrote:
> On 11/28/18 3:45 PM, Christoph Hellwig wrote:
> > On Wed, Nov 28, 2018 at 04:33:03PM +1100, Dave Chinner wrote:
> >>- how does propagation through stacked layers work?
> >
> > The only way it works is by each layering driving it. Thus
On 11/28/18 3:45 PM, Christoph Hellwig wrote:
> On Wed, Nov 28, 2018 at 04:33:03PM +1100, Dave Chinner wrote:
>> - how does propagation through stacked layers work?
>
> The only way it works is by each layering driving it. Thus my
> recommendation above bilding on your earlier one to use an
From: Tigran Mkrtchyan
[ Upstream commit bb21ce0ad227b69ec0f83279297ee44232105d96 ]
rfc8435 says:
For tight coupling, ffds_stateid provides the stateid to be used by
the client to access the file.
However current implementation replaces per-mirror provided stateid with
by open or lock
From: Tigran Mkrtchyan
[ Upstream commit bb21ce0ad227b69ec0f83279297ee44232105d96 ]
rfc8435 says:
For tight coupling, ffds_stateid provides the stateid to be used by
the client to access the file.
However current implementation replaces per-mirror provided stateid with
by open or lock
be ip, not ipv6 even in mirror-to-ip6gretap case,
because the overlay packet is still IPv4.
- Similarly ip_proto matches the innermost IP protocol, so can't be used
to filter out GRE packet. Drop the corresponding condition.
- Because the above fixes the filters to match in slow path as
From: Petr Machata
[ Upstream commit ec9fdc99f5a6a2cfe4061e807fcb0cc1129f0a2d ]
When running mirror_gre_bridge_1d_vlan tests on veth, several issues
cause spurious failures:
- vlan_ethtype should be ip, not ipv6 even in mirror-to-ip6gretap case,
because the overlay packet is still IPv4
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Nir Dotan
[ Upstream commit caebd1b389708bf3d0465be829480fc706a68720 ]
In previous patch mlxsw_afa_resource_del() was added to avoid a duplicate
resource detruction scenario.
For mirror
en in multiple cases related to failing the primary mirror dev while
syncing.
Reported-by: Jonathan Brassow
Signed-off-by: Mike Snitzer
Signed-off-by: Sasha Levin
---
drivers/md/dm-raid1.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-raid
In kernel code, if 'movable_node' specified, it will skip the mirror
feature. So also skip mirror feature in KASLR.
Signed-off-by: Chao Fan
Acked-by: Baoquan He
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed
In kernel code, if 'movable_node' specified, it will skip the mirror
feature. So also skip mirror feature in KASLR.
Acked-by: Baoquan He
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed
On 01/19/18 at 11:33am, Chao Fan wrote:
> In kernel code, if movable_node specified, it will skip the mirror
> feature. So we should also skip mirror feature in KASLR.
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/kaslr.c | 7 +++
> 1 file changed,
In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in KASLR.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot
On Wed, Jan 17, 2018 at 10:03:54PM +0800, Baoquan He wrote:
>On 01/17/18 at 06:53pm, Chao Fan wrote:
>> In kernel code, if movable_node specified, it will skip the mirror
>> feature. So we should also skip mirror feature in KASLR.
>>
>> Signed-off-by: Chao Fan
>>
On 01/17/18 at 06:53pm, Chao Fan wrote:
> In kernel code, if movable_node specified, it will skip the mirror
> feature. So we should also skip mirror feature in KASLR.
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/kaslr.c | 7 +++
> 1 file changed, 7 in
In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in KASLR.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot
In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in kaslr.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot
In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in kaslr.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot
In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in kaslr.
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
Cc: Randy Dunlap
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 7 +++
1 file changed, 7 insertions
In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in kaslr.
Signed-off-by: Chao Fan
---
arch/x86/boot/compressed/kaslr.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/x86/boot/compressed
On 10/29/2017 09:18 PM, Anshuman Khandual wrote:
> This adds two tests to validate mirror functionality with mremap()
> system call on shared and private anon mappings. After the commit
> dba58d3b8c5 ("mm/mremap: fail map duplication attempts for private
> mappings"), any att
1 - 100 of 347 matches
Mail list logo
