> Are there any issues with this patch
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov
submitted back in September? I am willing to help if there's anything I
can do to help get it accepted.
Hi, Stuart, I asked James Bottomley about the patch status offlist and
it seems t
"Initial patch" changes these places without any goal,
without any behavior. Remove the changes.
Please, merge this to "Initial patch" on rebase.
Signed-off-by: Kirill Tkhai
---
net/ipv4/tcp_ipv4.c |8 +++-
net/ipv6/tcp_ipv6.c | 10 --
2 files changed, 7 insertions(+), 11 dele
The commit is pushed to "branch-rh7-3.10.0-693.1.1.vz7.37.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-693.1.1.vz7.37.25
-->
commit 2149800a70af636b2b22289fc5aa977420b392c2
Author: Stanislav Kinsburskiy
Date: Thu Nov 9 14:12:42 2017 +0300
nfs:
The commit is pushed to "branch-rh7-3.10.0-693.1.1.vz7.37.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-693.1.1.vz7.37.25
-->
commit 99bfffc43ae40204d445f2c138071176d3e7b03d
Author: Stanislav Kinsburskiy
Date: Thu Nov 9 14:12:41 2017 +0300
sunrp
Currently they are noops and just introduce unnecessary
changes in "Initial patch". Kill them.
Please, merge this to "Initial patch" on rebase.
Signed-off-by: Kirill Tkhai
---
fs/exec.c |4 ++--
include/linux/mm.h |4 +---
kernel/fork.c |8
mm/mmap.c
"Initial patch" changes these places without any goal,
without any behavior. Remove the changes.
Please, merge this to "Initial patch" on rebase.
Signed-off-by: Kirill Tkhai
---
net/ipv4/tcp_ipv4.c |8 +++-
net/ipv6/tcp_ipv6.c |8 +++-
2 files changed, 6 insertions(+), 10 deleti
On 08.11.2017 20:23, Stanislav Kinsburskiy wrote:
> The idea is to use mutex for protecting callback execution agains per-net
> callback shutdown and destroying all the net-related backchannel requests
> before transports destruction.
>
>
> ---
>
> Stanislav Kinsburskiy (2):
> sunrpc: bc_s
09.11.2017 10:33, Kirill Tkhai пишет:
>
> Looks good for me, except there is one more call of nfs_callback_down_net()
> in nfs_callback_up().
> It's not clear for me, we shouldn't protect it via the mutex too. Should we?
>
Looks like no, mount is not ready yet and there is no connection to se
On 08.11.2017 20:23, Stanislav Kinsburskiy wrote:
> From: Stanislav Kinsburskiy
>
> Here is the race:
>
> CPU #0CPU#1
>
> cleanup_mnt nfs41_callback_svc (get xprt from the list)
> nfs_callback_down ...
> ...