David Vrabel writes:
> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>>
>> I see two ways to fix the issue:
>> - Change the 'wire' protocol between netfront and netback to start keeping
>> the original SKB structure. We'll have to add a flag indicating
Vitaly Kuznetsov writes:
> David Vrabel writes:
>
>> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>>>
>>> I see two ways to fix the issue:
>>> - Change the 'wire' protocol between netfront and netback to start keeping
>>> the original S
Vitaly Kuznetsov writes:
> Vitaly Kuznetsov writes:
>
>> David Vrabel writes:
>>
>>> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>>>>
>>>> I see two ways to fix the issue:
>>>> - Change the 'wire' protocol between netfr
David Vrabel writes:
> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>> Small packet loss is reported on complex multi host network configurations
>> including tunnels, NAT, ... My investigation led me to the following check
>> in netback which drops packets:
>>
>>
c_send().
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/hyperv/netvsc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 720b5fa..e2bfaac 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
e locking, if we read stale
NULL value after it was already updated on a different CPU we're fine,
we'll just return -EAGAIN.
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Wednesday, October 19, 2016 2:53 PM
> To: netdev@v
David Miller writes:
> From: Vitaly Kuznetsov
> Date: Thu, 20 Oct 2016 10:51:04 +0200
>
>> Stephen Hemminger writes:
>>
>>> Do we need ACCESS_ONCE() here to avoid check/use issues?
>>>
>>
>> I think we don't: this is the only place in
David Miller writes:
> From: Vitaly Kuznetsov
> Date: Fri, 21 Oct 2016 13:15:53 +0200
>
>> David Miller writes:
>>
>>> From: Vitaly Kuznetsov
>>> Date: Thu, 20 Oct 2016 10:51:04 +0200
>>>
>>>> Stephen Hemminger writes:
>>
Michał Mirosław writes:
> Signed-off-by: Michał Mirosław
Can we have a non-empty description please?
> ---
> drivers/net/hyperv/hyperv_net.h | 2 +-
> drivers/net/hyperv/netvsc_drv.c | 13 ++---
> drivers/net/hyperv/rndis_filter.c | 4 ++--
> 3 files changed, 9 insertions(+), 10
00:15:5d:1e:91:12 link state up
This information is useful as debug at most.
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/hyperv/netvsc.c | 8
drivers/net/hyperv/rndis_filter.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c
struct netvsc_device is not suitable for storing VF information as this
structure is being destroyed on MTU change / set channel operation (see
rndis_filter_device_remove()). Move all VF related stuff to struct
net_device_context which is persistent.
Signed-off-by: Vitaly Kuznetsov
---
drivers
Kernel crash is reported after VF is removed and detached from netvsc
device. My investigation led me to PATCH2 of this series but PATCH1 is
required to support the change. I also noticed a couple of other issues
while debugging and I fix them with PATCH3 and PATCH4.
Please review.
Vitaly
We reset vf_inject on VF going down (netvsc_vf_down()) but we don't on
VF removal (netvsc_unregister_vf()) so vf_inject stays 'true' while
vf_netdev is already NULL and we're trying to inject packets into NULL
net device in netvsc_recv_callback() causing kernel to crash.
S
zero.
Instead of introducing additional synchronization I suggest we drop
gwrk.dwrk completely and call NETDEV_NOTIFY_PEERS directly. As we're
acting under rtnl lock this is legitimate.
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/hyperv/hyperv_net.h | 7 ---
drivers/net/h
We're not guaranteed to see NETDEV_REGISTER/NETDEV_UNREGISTER notifications
only once per VF but we increase/decrease module refcount unconditionally.
Check vf_netdev to make sure we don't take/release it twice. We presume
that only one VF per netvsc device may exist.
Signed-off-
Yuval Mintz writes:
>> +static void netvsc_inject_enable(struct net_device_context
>> +*net_device_ctx) {
>> +net_device_ctx->vf_inject = true;
>> +}
>> +
>> +static void netvsc_inject_disable(struct net_device_context
>> +*net_device_ctx) {
>> +net_device_ctx->vf_inject = false;
>> +
>>
Stephen Hemminger writes:
> Rather than keeping a pointer, a flag, and reference count, use RCU and
> existing
> device reference count to protect the synthetic to VF relationship.
Thanks! I like the idea. Some nitpicks below ...
>
> One other change is that injected packets must be accounted
nd call NETDEV_NOTIFY_PEERS directly. As we're
acting under rtnl lock this is legitimate.
Signed-off-by: Vitaly Kuznetsov
Acked-by: Haiyang Zhang
---
Changes since v1:
- Move the patch ahead in the series to avoid introducing new blocking
issues and solving them later in the series. [
We reset vf_inject on VF going down (netvsc_vf_down()) but we don't on
VF removal (netvsc_unregister_vf()) so vf_inject stays 'true' while
vf_netdev is already NULL and we're trying to inject packets into NULL
net device in netvsc_recv_callback() causing kernel to crash.
S
: Vitaly Kuznetsov
---
drivers/net/hyperv/netvsc_drv.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 62a4e6e..3ba29fc 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv
ght thing to do long-term, we
can either put this on top of this series or do it later in net-next.
Vitaly Kuznetsov (5):
hv_netvsc: don't lose VF information
hv_netvsc: avoid deadlocks between rtnl lock and vf_use_cnt wait
hv_netvsc: reset vf_inject on VF removal
hv_netvsc: protec
struct netvsc_device is not suitable for storing VF information as this
structure is being destroyed on MTU change / set channel operation (see
rndis_filter_device_remove()). Move all VF related stuff to struct
net_device_context which is persistent.
Signed-off-by: Vitaly Kuznetsov
Acked-by
We're not guaranteed to see NETDEV_REGISTER/NETDEV_UNREGISTER notifications
only once per VF but we increase/decrease module refcount unconditionally.
Check vf_netdev to make sure we don't take/release it twice. We presume
that only one VF per netvsc device may exist.
Signed-off-
erable short-term and shouldn't bring
significant performance degradation as such packets are rare. That's what
this patch is trying to achieve with skb_copy().
Signed-off-by: Vitaly Kuznetsov
---
drivers/net/xen-netfront.c | 14 ++
1 file changed, 14 insertions(+)
d
again after resume.
Reset drvdata in netback_changed() the same way we reset it in
netfront_probe() and check for NULL in both netfront_resume() and
netback_changed() to properly handle the situation.
Signed-off-by: Vitaly Kuznetsov
---
I apologize for sending this during the merge window, I'
David Miller writes:
> From: Vitaly Kuznetsov
> Date: Thu, 4 May 2017 14:23:04 +0200
>
>> Unavoidable crashes in netfront_resume() and netback_changed() after a
>> previous fail in talk_to_netback() (e.g. when we fail to read MAC from
>> xenstore) were disc
after resume.
Fix the bug by removing the whole xen device completely with
device_unregister(), this guarantees we won't have any calls into netfront
after a failure.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1: instead of cleaning drvdata and checking for it in
netfront_re
Tianyu Lan writes:
> From: Tianyu Lan
>
> Add visibility parameter for vmbus_establish_gpadl() and prepare
> to change host visibility when create gpadl for buffer.
>
"No functional change" as you don't actually use the parameter.
> Signed-off-by: Sunil Muthuswamy
> Co-Developed-by: Sunil Mut
Tianyu Lan writes:
> From: Tianyu Lan
>
> Add new hvcall guest address host visibility support. Mark vmbus
> ring buffer visible to host when create gpadl buffer and mark back
> to not visible when tear down gpadl buffer.
>
> Signed-off-by: Sunil Muthuswamy
> Co-Developed-by: Sunil Muthuswamy
Haiyang Zhang writes:
> Add error handling in case of failure to send switching data path message
> to the host.
>
> Reported-by: Shachar Raindel
> Signed-off-by: Haiyang Zhang
>
> ---
> drivers/net/hyperv/hyperv_net.h | 6 +-
> drivers/net/hyperv/netvsc.c | 35 +++
101 - 130 of 130 matches
Mail list logo
