* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Cong Wang @ 2016-05-09 4:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <1462550112.13075.47.camel@edumazet-glaptop3.roam.corp.google.com>
On Fri, May 6, 2016 at 8:55 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> @@ -193,6 +199,7 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> unsigned int idx, prev_backlog, prev_qlen;
> struct fq_codel_flow *flow;
> int uninitialized_var(ret);
> + bool memory_limited;
>
> idx = fq_codel_classify(skb, sch, &ret);
> if (idx == 0) {
> @@ -215,7 +222,9 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> flow->deficit = q->quantum;
> flow->dropped = 0;
> }
> - if (++sch->q.qlen <= sch->limit)
> + q->memory_usage += skb->truesize;
> + memory_limited = q->memory_usage > q->memory_limit;
> + if (++sch->q.qlen <= sch->limit && !memory_limited)
> return NET_XMIT_SUCCESS;
>
> prev_backlog = sch->qstats.backlog;
> @@ -229,7 +238,8 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct Qdisc *sch)
> ret = fq_codel_drop(sch, q->drop_batch_size);
>
> q->drop_overlimit += prev_qlen - sch->q.qlen;
> -
> + if (memory_limited)
> + q->drop_overmemory += prev_qlen - sch->q.qlen;
So when the packet is dropped due to memory over limit, should
we return failure for this case? Or I miss anything?
^ permalink raw reply
* Re: [PATCH] pxa168_eth: mdiobus_scan() doesn't return NULL anymore
From: David Miller @ 2016-05-09 4:14 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev
In-Reply-To: <3730936.r1jNy7SQee@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sat, 07 May 2016 22:53:40 +0300
> Now that mdiobus_scan() doesn't return NULL on failure anymore, this driver
> no longer needs to check for it...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] sh_eth: couple of software reset bit cleanups
From: David Miller @ 2016-05-09 4:15 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <1808900.MGlUzc8O9C@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 08 May 2016 00:06:53 +0300
> Here's a set of 2 patches against DaveM's 'net-next.git' repo. We can save
> on the repetitive chip reset code...
>
> [1/2] sh_eth: call sh_eth_tsu_write() from sh_eth_chip_reset_giga()
> [2/2] sh_eth: reuse sh_eth_chip_reset()
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/2] net/mlx5e: Kconfig fixes for VxLAN
From: David Miller @ 2016-05-09 4:21 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz, talal, eranbe, matt, arnd
In-Reply-To: <1462708525-23545-1-git-send-email-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Sun, 8 May 2016 14:55:23 +0300
> Reposting to net the build errors fixes posted by Arnd last week.
>
> Originally Arnd posted those fixes to net-next, while the issue
> is also seen in net. For net-next a different approach is required
> for fixing the issue as VXLAN and Device Drivers are no longer
> dependent, but there is no harm for those fixes to get into net-next.
>
> Optionally, once net is merged into net-next we can
> Revert "net/mlx5e: make VXLAN support conditional" as the
> CONFIG_MLX5_CORE_EN_VXLAN will no longer be required.
>
> Applied on top: 288928658583 ('mlxsw: spectrum: Add missing rollback in flood configuration')
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] kernel: Add noaudit variant of ns_capable()
From: Serge Hallyn @ 2016-05-09 4:23 UTC (permalink / raw)
To: Tyler Hicks
Cc: linux-security-module, netdev, linux-kernel, Serge Hallyn,
David S . Miller
In-Reply-To: <1462575854-4301-2-git-send-email-tyhicks@canonical.com>
Quoting Tyler Hicks (tyhicks@canonical.com):
> When checking the current cred for a capability in a specific user
> namespace, it isn't always desirable to have the LSMs audit the check.
> This patch adds a noaudit variant of ns_capable() for when those
> situations arise.
>
> The common logic between ns_capable() and the new ns_capable_noaudit()
> is moved into a single, shared function to keep duplicated code to a
> minimum and ease maintainability.
>
> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
> ---
> include/linux/capability.h | 5 +++++
> kernel/capability.c | 46 ++++++++++++++++++++++++++++++++++++----------
> 2 files changed, 41 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index 00690ff..5f3c63d 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -206,6 +206,7 @@ extern bool has_ns_capability_noaudit(struct task_struct *t,
> struct user_namespace *ns, int cap);
> extern bool capable(int cap);
> extern bool ns_capable(struct user_namespace *ns, int cap);
> +extern bool ns_capable_noaudit(struct user_namespace *ns, int cap);
> #else
> static inline bool has_capability(struct task_struct *t, int cap)
> {
> @@ -233,6 +234,10 @@ static inline bool ns_capable(struct user_namespace *ns, int cap)
> {
> return true;
> }
> +static inline bool ns_capable_noaudit(struct user_namespace *ns, int cap)
> +{
> + return true;
> +}
> #endif /* CONFIG_MULTIUSER */
> extern bool capable_wrt_inode_uidgid(const struct inode *inode, int cap);
> extern bool file_ns_capable(const struct file *file, struct user_namespace *ns, int cap);
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 45432b5..00411c8 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -361,6 +361,24 @@ bool has_capability_noaudit(struct task_struct *t, int cap)
> return has_ns_capability_noaudit(t, &init_user_ns, cap);
> }
>
> +static bool ns_capable_common(struct user_namespace *ns, int cap, bool audit)
> +{
> + int capable;
> +
> + if (unlikely(!cap_valid(cap))) {
> + pr_crit("capable() called with invalid cap=%u\n", cap);
> + BUG();
> + }
> +
> + capable = audit ? security_capable(current_cred(), ns, cap) :
> + security_capable_noaudit(current_cred(), ns, cap);
> + if (capable == 0) {
> + current->flags |= PF_SUPERPRIV;
> + return true;
> + }
> + return false;
> +}
> +
> /**
> * ns_capable - Determine if the current task has a superior capability in effect
> * @ns: The usernamespace we want the capability in
> @@ -374,19 +392,27 @@ bool has_capability_noaudit(struct task_struct *t, int cap)
> */
> bool ns_capable(struct user_namespace *ns, int cap)
> {
> - if (unlikely(!cap_valid(cap))) {
> - pr_crit("capable() called with invalid cap=%u\n", cap);
> - BUG();
> - }
> -
> - if (security_capable(current_cred(), ns, cap) == 0) {
> - current->flags |= PF_SUPERPRIV;
> - return true;
> - }
> - return false;
> + return ns_capable_common(ns, cap, true);
> }
> EXPORT_SYMBOL(ns_capable);
>
> +/**
> + * ns_capable_noaudit - Determine if the current task has a superior capability
> + * (unaudited) in effect
> + * @ns: The usernamespace we want the capability in
> + * @cap: The capability to be tested for
> + *
> + * Return true if the current task has the given superior capability currently
> + * available for use, false if not.
> + *
> + * This sets PF_SUPERPRIV on the task if the capability is available on the
> + * assumption that it's about to be used.
> + */
> +bool ns_capable_noaudit(struct user_namespace *ns, int cap)
> +{
> + return ns_capable_common(ns, cap, false);
> +}
> +EXPORT_SYMBOL(ns_capable_noaudit);
>
> /**
> * capable - Determine if the current task has a superior capability in effect
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH 2/2] net: Use ns_capable_noaudit() when determining net sysctl permissions
From: Serge Hallyn @ 2016-05-09 4:24 UTC (permalink / raw)
To: Tyler Hicks
Cc: linux-security-module, netdev, linux-kernel, Serge Hallyn,
David S . Miller
In-Reply-To: <1462575854-4301-3-git-send-email-tyhicks@canonical.com>
Quoting Tyler Hicks (tyhicks@canonical.com):
> The capability check should not be audited since it is only being used
> to determine the inode permissions. A failed check does not indicate a
> violation of security policy but, when an LSM is enabled, a denial audit
> message was being generated.
>
> The denial audit message caused confusion for some application authors
> because root-running Go applications always triggered the denial. To
> prevent this confusion, the capability check in net_ctl_permissions() is
> switched to the noaudit variant.
>
> BugLink: https://launchpad.net/bugs/1465724
>
> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
> ---
> net/sysctl_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sysctl_net.c b/net/sysctl_net.c
> index ed98c1f..46a71c7 100644
> --- a/net/sysctl_net.c
> +++ b/net/sysctl_net.c
> @@ -46,7 +46,7 @@ static int net_ctl_permissions(struct ctl_table_header *head,
> kgid_t root_gid = make_kgid(net->user_ns, 0);
>
> /* Allow network administrator to have same access as root. */
> - if (ns_capable(net->user_ns, CAP_NET_ADMIN) ||
> + if (ns_capable_noaudit(net->user_ns, CAP_NET_ADMIN) ||
> uid_eq(root_uid, current_euid())) {
> int mode = (table->mode >> 6) & 7;
> return (mode << 6) | (mode << 3) | mode;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [net-next PATCH v2 0/6] net sched: Fix broken late binding of actions
From: David Miller @ 2016-05-09 4:30 UTC (permalink / raw)
To: jhs; +Cc: netdev
In-Reply-To: <572F7761.2020103@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun, 8 May 2016 13:29:05 -0400
> On 16-05-08 01:26 PM, Jamal Hadi Salim wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>>
>> Some actions were broken in allowing for late binding of actions.
>
> Dave, these deserve to go into -stable as well.
Then don't target them at 'net-next'. If it's good enough for -stable
it's by definition good enough for 'net'.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Eric Dumazet @ 2016-05-09 4:31 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <CAM_iQpUfJxMxQXia8JOH5xouSFMThrdZWZMUuQ0q=bSmp8oEEQ@mail.gmail.com>
On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
> So when the packet is dropped due to memory over limit, should
> we return failure for this case? Or I miss anything?
Same behavior than before.
If we dropped some packets of this flow, we return NET_XMIT_CN
^ permalink raw reply
* Re: [net-next PATCH 1/1] export tc ife uapi header
From: David Miller @ 2016-05-09 4:31 UTC (permalink / raw)
To: jhs; +Cc: netdev, stephen
In-Reply-To: <1462627199-10276-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sat, 7 May 2016 09:19:59 -0400
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Again, this looks like a bug fix appropriate for 'net' not 'net-next'.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-05-09 4:47 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Check klogctl failure correctly, from Colin Ian King.
2) Prevent OOM when under memory pressure in flowcache, from Steffen
Klassert.
3) Fix info leak in llc and rtnetlink ifmap code, from Kangjie Lu.
4) Memory barrier and multicast handling fixes in bnxt_en, from
Michael Chan.
5) Endianness bug in mlx5, from Daniel Jurgens.
6) Fix disconnect handling in VSOCK, from Ian Campbell.
7) Fix locking of netdev list walking in get_bridge_ifindices(), from
Nikolay Aleksandrov.
8) Bridge multicast MLD parser can look at wrong packet offsets, fix
from Linus Lüssing.
9) Fix chip hang in qede driver, from Sudarsana Reddy Kalluru.
10) Fix missing setting of encapsulation before inner handling
completes in udp_offload code, from Jarno Rajahalme.
11) Missing rollbacks during LAG join and flood configuration failures
in mlxsw driver, from Ido Schimmel.
12) Fix error code checks in netxen driver, from Dan Carpenter.
13) Fix key size in new macsec driver, from Sabrina Dubroca.
14) Fix mlx5/VXLAN dependencies, from Arnd Bergmann.
Please pull, thanks a lot!
The following changes since commit 7391daf2ffc780679d6ab3fad1db2619e5dd2c2a:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-05-03 15:07:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 8846a125de97f96be64ca234906eedfd26ad778e:
Merge branch 'mlx5-build-fix' (2016-05-09 00:21:13 -0400)
----------------------------------------------------------------
Arnd Bergmann (2):
Revert "net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue"
net/mlx5e: make VXLAN support conditional
Colin Ian King (1):
tools: bpf_jit_disasm: check for klogctl failure
Dan Carpenter (4):
netxen: fix error handling in netxen_get_flash_block()
netxen: reversed condition in netxen_nic_set_link_parameters()
netxen: netxen_rom_fast_read() doesn't return -1
qede: uninitialized variable in qede_start_xmit()
Daniel Jurgens (1):
net/mlx4_en: Fix endianness bug in IPV6 csum calculation
David Ahern (1):
net: ipv6: tcp reset, icmp need to consider L3 domain
David S. Miller (3):
Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
Merge branch 'bnxt_en-fixes'
Merge branch 'mlx5-build-fix'
Eric Dumazet (1):
macvtap: segmented packet is consumed
Ian Campbell (1):
VSOCK: do not disconnect socket when peer has shutdown SEND only
Ido Schimmel (2):
mlxsw: spectrum: Fix rollback order in LAG join failure
mlxsw: spectrum: Add missing rollback in flood configuration
Jarno Rajahalme (2):
udp_tunnel: Remove redundant udp_tunnel_gro_complete().
udp_offload: Set encapsulation before inner completes.
Kangjie Lu (2):
net: fix infoleak in llc
net: fix infoleak in rtnetlink
Linus Lüssing (1):
bridge: fix igmp / mld query parsing
Matthias Brugger (1):
drivers: net: xgene: Fix error handling
Michael Chan (2):
bnxt_en: Need memory barrier when processing the completion ring.
bnxt_en: Setup multicast properly after resetting device.
Nikolay Aleksandrov (1):
net: bridge: fix old ioctl unlocked net device walk
Sabrina Dubroca (1):
macsec: key identifier is 128 bits, not 64
Shmulik Ladkani (1):
Documentation/networking: more accurate LCO explanation
Steffen Klassert (3):
flowcache: Avoid OOM condition under preasure
xfrm: Reset encapsulation field of the skb before transformation
vti: Add pmtu handling to vti_xmit.
Sudarsana Reddy Kalluru (1):
qede: prevent chip hang when increasing channels
Uwe Kleine-König (1):
net: fec: only clear a queue's work bit if the queue was emptied
Documentation/networking/checksum-offloads.txt | 14 +++++++-------
drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 7 ++++---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +++++++++++++++++++----
drivers/net/ethernet/freescale/fec_main.c | 10 ++++++++--
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 8 +++++++-
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 ++
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++++
drivers/net/ethernet/mellanox/mlx5/core/vxlan.h | 11 +++++++++--
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++--
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 8 ++++++++
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 14 +++++++++-----
drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 3 ++-
drivers/net/ethernet/qlogic/qede/qede_main.c | 8 +++-----
drivers/net/geneve.c | 5 +++--
drivers/net/macsec.c | 19 +++++++++++++------
drivers/net/macvtap.c | 2 +-
drivers/net/vxlan.c | 5 +++--
include/linux/netdevice.h | 3 +++
include/net/netns/xfrm.h | 1 +
include/net/udp_tunnel.h | 9 ---------
include/uapi/linux/if_macsec.h | 4 +++-
net/bridge/br_ioctl.c | 5 +++--
net/bridge/br_multicast.c | 12 +++++++-----
net/core/flow.c | 14 +++++++++++++-
net/core/rtnetlink.c | 18 ++++++++++--------
net/ipv4/fou.c | 6 ++++--
net/ipv4/ip_vti.c | 18 ++++++++++++++++++
net/ipv4/udp_offload.c | 8 +++++---
net/ipv6/icmp.c | 5 ++---
net/ipv6/tcp_ipv6.c | 7 ++++++-
net/llc/af_llc.c | 1 +
net/vmw_vsock/af_vsock.c | 21 +--------------------
net/xfrm/xfrm_output.c | 3 +++
tools/net/bpf_jit_disasm.c | 3 +++
36 files changed, 190 insertions(+), 100 deletions(-)
^ permalink raw reply
* Re: [PATCH iproute2 net-next] ifstat: move to new RTM_GETSTATS api
From: Roopa Prabhu @ 2016-05-09 4:49 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: stephen, netdev, davem, edumazet, tgraf, nicolas.dichtel, nikolay
In-Reply-To: <5724CC01.3030203@cumulusnetworks.com>
On 4/30/16, 8:15 AM, Roopa Prabhu wrote:
> On 4/30/16, 3:21 AM, Jamal Hadi Salim wrote:
>> On 16-04-30 02:41 AM, Roopa Prabhu wrote:
>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>
>>> This patch modifies ifstat to use the new RTM_GETSTATS api
>>> to query stats from the kernel. In the process this also
>>> moves ifstat to use 64 bit stats.
>> Breaks old kernels? May need to keep backward compat of
>> RTM_NEWLINK and even new main struct for GETSTATS.
> yes, i was wondering about that. v2 coming. If GETSTATS fails, I will fallback to RTM_NEWLINK.
>
sorry abt the delay on this one. I hit a snag and could not get back to it last week.
AFAICS ifstat history file handling today assumes all 32 bit stats.
And to preserve backward compatibility, new ifstat should work with old and
new history files with 32bit and 64 bit stats.
The file format cannot be changed because of the same backward compat issues.
So, I am leaning towards a new history file with a new option (maybe ifstat -64) to
save/query 64 bit stats using the new api when available.
I see some previous brief discussions on moving ifstat to 64 bit.
The other option is to only change 'ip -s link show' to use the new stats api.
let me know if there are other thoughts.
thanks,
Roopa
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: add memory limitation per queue
From: Cong Wang @ 2016-05-09 5:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Jesper Dangaard Brouer, Dave Täht, netdev,
moeller0
In-Reply-To: <1462768295.23934.28.camel@edumazet-glaptop3.roam.corp.google.com>
On Sun, May 8, 2016 at 9:31 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2016-05-08 at 21:14 -0700, Cong Wang wrote:
>
>> So when the packet is dropped due to memory over limit, should
>> we return failure for this case? Or I miss anything?
>
> Same behavior than before.
>
> If we dropped some packets of this flow, we return NET_XMIT_CN
I think for the limited memory case, the upper layer is supposed
to stop sending more packets when hitting the limit.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: SOCKWQ_ASYNC_NOSPACE optimizations
From: Jiri Pirko @ 2016-05-09 6:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, David S . Miller, netdev, eladr, idosch
In-Reply-To: <20160502204544.GA2349@nanopsycho.orion>
Mon, May 02, 2016 at 10:45:44PM CEST, jiri@resnulli.us wrote:
>Mon, May 02, 2016 at 10:23:27PM CEST, eric.dumazet@gmail.com wrote:
>>On Mon, 2016-05-02 at 21:12 +0200, Jiri Pirko wrote:
>>> Mon, May 02, 2016 at 06:22:18PM CEST, eric.dumazet@gmail.com wrote:
>>> >On Mon, 2016-05-02 at 18:16 +0200, Jiri Pirko wrote:
>>> >> Mon, Apr 25, 2016 at 07:39:32PM CEST, edumazet@google.com wrote:
>>> >> >SOCKWQ_ASYNC_NOSPACE is tested in sock_wake_async()
>>> >> >so that a SIGIO signal is sent when needed.
>>> >> >
>>> >> >tcp_sendmsg() clears the bit.
>>> >> >tcp_poll() sets the bit when stream is not writeable.
>>> >> >
>>> >> >We can avoid two atomic operations by first checking if socket
>>> >> >is actually interested in the FASYNC business (most sockets in
>>> >> >real applications do not use AIO, but select()/poll()/epoll())
>>> >> >
>>> >> >This also removes one cache line miss to access sk->sk_wq->flags
>>> >> >in tcp_sendmsg()
>>> >> >
>>> >> >Signed-off-by: Eric Dumazet <edumazet@google.com>
>>> >>
>>> >> I just bisected down to this. This is causing a regression for me when
>>> >> my nfs mount becomes stuck. I can easily reproduce this if you need to
>>> >> test the fix.
>>> >
>>> >What do you mean by 'when nfs mount becomes stuck' ?
>>> >
>>> >Is this patch making nfs not functional , or does it make recovery from
>>> >some nfs error bad ?
>>>
>>> I can mount nfs on the host. But when I do something (compile a kernel
>>> module in my case), it gets stuck. Then I cannot even ssh to the machine.
>>> No messages in dmesg. I didn't debug it any further. I just bisected and
>>> verified that this patch caused this behaviour.
>>
>>Interesting.
>>
>>It looks like net/sunrpc/xprtsock.c should set SOCK_FASYNC
>>even if it is not actually using fasync_list
>>
>>Could you try this quick hack to check if this is the right way ?
>
>Yep, works, I do not see the issue with this patch anymore. Thanks.
Eric, any news with this issue?
Thanks.
^ permalink raw reply
* Re: [PATCH net v4] vlan: Propagate MAC address to VLANs
From: Michal Kubecek @ 2016-05-09 6:48 UTC (permalink / raw)
To: Mike Manning; +Cc: netdev
In-Reply-To: <572DBCA9.7060906@brocade.com>
On Sat, May 07, 2016 at 11:00:09AM +0100, Mike Manning wrote:
> The MAC address of the physical interface is only copied to the VLAN
> when it is first created, resulting in an inconsistency after MAC
> address changes of only newly created VLANs having an up-to-date MAC.
>
> The VLANs should continue inheriting the MAC address of the physical
> interface until the VLAN MAC address is explicitly set to any value.
> This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
> to the MAC of the physical interface and thus for DAD to behave as
> expected.
>
> Signed-off-by: Mike Manning <mmanning@brocade.com>
> ---
> net/8021q/vlan.c | 7 +++++++
> net/8021q/vlan_dev.c | 14 ++++++++++----
> 2 files changed, 17 insertions(+), 4 deletions(-)
>
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -291,6 +291,12 @@ static void vlan_sync_address(struct net
> if (ether_addr_equal(vlan->real_dev_addr, dev->dev_addr))
> return;
>
> + /* vlan continues to inherit address of parent interface */
> + if (vlandev->addr_assign_type == NET_ADDR_STOLEN) {
> + ether_addr_copy(vlandev->dev_addr, dev->dev_addr);
> + goto out;
> + }
> +
I might have missed something in the previous discussion but as
ether_addr_copy() is just an optimized memcpy(), how is this going to
handle the setups where the vlan device itself has an upper device? For
example,
- if it is a bridge port, how is the bridge going to learn about its
address change so that it can update its FDB?
- if it is a bond slave or team port, current code preserves the vlan
device address on real device change so everything is fine; your
proposal would change vlan device's address without bond being even
notified, I believe
- there might be a macvlan on top of the vlan and you might
accidentally match its address with the new one
> /* vlan address was different from the old address and is equal to
> * the new address */
> if (!ether_addr_equal(vlandev->dev_addr, vlan->real_dev_addr) &&
> @@ -303,6 +309,7 @@ static void vlan_sync_address(struct net
> !ether_addr_equal(vlandev->dev_addr, dev->dev_addr))
> dev_uc_add(dev, vlandev->dev_addr);
>
> +out:
> ether_addr_copy(vlan->real_dev_addr, dev->dev_addr);
> }
>
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -255,9 +255,13 @@ static int vlan_dev_open(struct net_devi
> return -ENETDOWN;
>
> if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr)) {
> - err = dev_uc_add(real_dev, dev->dev_addr);
> - if (err < 0)
> - goto out;
> + if (dev->addr_assign_type == NET_ADDR_STOLEN) {
> + ether_addr_copy(dev->dev_addr, real_dev->dev_addr);
The same question here.
> + } else {
> + err = dev_uc_add(real_dev, dev->dev_addr);
> + if (err < 0)
> + goto out;
> + }
> }
>
> if (dev->flags & IFF_ALLMULTI) {
> @@ -558,8 +562,10 @@ static int vlan_dev_init(struct net_devi
> /* ipv6 shared card related stuff */
> dev->dev_id = real_dev->dev_id;
>
> - if (is_zero_ether_addr(dev->dev_addr))
> + if (is_zero_ether_addr(dev->dev_addr)) {
> eth_hw_addr_inherit(dev, real_dev);
> + dev->addr_assign_type = NET_ADDR_STOLEN;
You might want to replace eth_hw_addr_inherit() with ether_addr_copy()
here as they only differ in the former copying addr_assign_type which
you are going to rewrite anyway. (But as both are most likely inlined,
I would expect the resulting code to be the same in the end.)
Michal Kubecek
> + }
> if (is_zero_ether_addr(dev->broadcast))
> memcpy(dev->broadcast, real_dev->broadcast, dev->addr_len);
>
> --
> 1.7.10.4
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
^ permalink raw reply
* [PATCH 2/7] net: ircomm, cleanup TIOCGSERIAL
From: Jiri Slaby @ 2016-05-09 7:11 UTC (permalink / raw)
To: gregkh
Cc: linux-serial, linux-kernel, Jiri Slaby, Samuel Ortiz,
David S. Miller, netdev
In-Reply-To: <1462777919-10367-1-git-send-email-jslaby@suse.cz>
In ircomm_tty_get_serial_info, struct serial_struct is memset to 0 and
then some members set to 0 explicitly.
Remove the latter as it is obviously superfluous.
And remove the retinfo check against NULL. copy_to_user will take care
of that.
Part of hub6 cleanup series.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
net/irda/ircomm/ircomm_tty_ioctl.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/net/irda/ircomm/ircomm_tty_ioctl.c b/net/irda/ircomm/ircomm_tty_ioctl.c
index 17c49bf26313..0985588c9dec 100644
--- a/net/irda/ircomm/ircomm_tty_ioctl.c
+++ b/net/irda/ircomm/ircomm_tty_ioctl.c
@@ -246,9 +246,6 @@ static int ircomm_tty_get_serial_info(struct ircomm_tty_cb *self,
{
struct serial_struct info;
- if (!retinfo)
- return -EFAULT;
-
memset(&info, 0, sizeof(info));
info.line = self->line;
info.flags = self->port.flags;
@@ -258,11 +255,6 @@ static int ircomm_tty_get_serial_info(struct ircomm_tty_cb *self,
/* For compatibility */
info.type = PORT_16550A;
- info.port = 0;
- info.irq = 0;
- info.xmit_fifo_size = 0;
- info.hub6 = 0;
- info.custom_divisor = 0;
if (copy_to_user(retinfo, &info, sizeof(*retinfo)))
return -EFAULT;
--
2.8.2
^ permalink raw reply related
* Re: [PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
From: Marc Kleine-Budde @ 2016-05-09 7:12 UTC (permalink / raw)
To: Florian Westphal, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw,
linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
MPT-FusionLinux.pdl-dY08KVG/lbpWk0Htik3J/w,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-can-u79uwXL29TY76Z2rM5mHXA,
linux-parisc-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-hams-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1462285994-31983-1-git-send-email-fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 5464 bytes --]
On 05/03/2016 04:33 PM, Florian Westphal wrote:
> Replace all trans_start updates with netif_trans_update helper.
> change was done via spatch:
>
> struct net_device *d;
> @@
> - d->trans_start = jiffies
> + netif_trans_update(d)
>
> Compile tested only.
>
> Cc: user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Cc: linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw@public.gmane.org
> Cc: linux1394-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: MPT-FusionLinux.pdl-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
> Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-can-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-parisc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-hams-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org
> Cc: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r@public.gmane.org
> Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
> ---
> Checkpatch complains about whitespace damage, but
> this extra whitespace already exists before this patch.
>
> drivers/net/can/mscan/mscan.c | 4 ++--
> drivers/net/can/usb/ems_usb.c | 4 ++--
> drivers/net/can/usb/esd_usb2.c | 4 ++--
> drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 ++--
> diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
> index e36b740..acb708f 100644
> --- a/drivers/net/can/mscan/mscan.c
> +++ b/drivers/net/can/mscan/mscan.c
> @@ -276,7 +276,7 @@ static netdev_tx_t mscan_start_xmit(struct sk_buff *skb, struct net_device *dev)
> out_8(®s->cantflg, 1 << buf_id);
>
> if (!test_bit(F_TX_PROGRESS, &priv->flags))
> - dev->trans_start = jiffies;
> + netif_trans_update(dev);
>
> list_add_tail(&priv->tx_queue[buf_id].list, &priv->tx_head);
>
> @@ -469,7 +469,7 @@ static irqreturn_t mscan_isr(int irq, void *dev_id)
> clear_bit(F_TX_PROGRESS, &priv->flags);
> priv->cur_pri = 0;
> } else {
> - dev->trans_start = jiffies;
> + netif_trans_update(dev);
> }
>
> if (!test_bit(F_TX_WAIT_ALL, &priv->flags))
> diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
> index 3400fd1..71f0e79 100644
> --- a/drivers/net/can/usb/ems_usb.c
> +++ b/drivers/net/can/usb/ems_usb.c
> @@ -521,7 +521,7 @@ static void ems_usb_write_bulk_callback(struct urb *urb)
> if (urb->status)
> netdev_info(netdev, "Tx URB aborted (%d)\n", urb->status);
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* transmission complete interrupt */
> netdev->stats.tx_packets++;
> @@ -835,7 +835,7 @@ static netdev_tx_t ems_usb_start_xmit(struct sk_buff *skb, struct net_device *ne
> stats->tx_dropped++;
> }
> } else {
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* Slow down tx path */
> if (atomic_read(&dev->active_tx_urbs) >= MAX_TX_URBS ||
> diff --git a/drivers/net/can/usb/esd_usb2.c b/drivers/net/can/usb/esd_usb2.c
> index 113e64f..784a900 100644
> --- a/drivers/net/can/usb/esd_usb2.c
> +++ b/drivers/net/can/usb/esd_usb2.c
> @@ -480,7 +480,7 @@ static void esd_usb2_write_bulk_callback(struct urb *urb)
> if (urb->status)
> netdev_info(netdev, "Tx URB aborted (%d)\n", urb->status);
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
> }
>
> static ssize_t show_firmware(struct device *d,
> @@ -820,7 +820,7 @@ static netdev_tx_t esd_usb2_start_xmit(struct sk_buff *skb,
> goto releasebuf;
> }
>
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /*
> * Release our reference to this URB, the USB core will eventually free
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index 5a2e341..bfb91d8 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -274,7 +274,7 @@ static void peak_usb_write_bulk_callback(struct urb *urb)
> netdev->stats.tx_bytes += context->data_len;
>
> /* prevent tx timeout */
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
> break;
>
> default:
> @@ -373,7 +373,7 @@ static netdev_tx_t peak_usb_ndo_start_xmit(struct sk_buff *skb,
> stats->tx_dropped++;
> }
> } else {
> - netdev->trans_start = jiffies;
> + netif_trans_update(netdev);
>
> /* slow down tx path */
> if (atomic_read(&dev->active_tx_urbs) >= PCAN_USB_MAX_TX_URBS)
For the drivers/can part:
Acked-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
From: Johannes Berg @ 2016-05-09 7:30 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-wireless, netdev
In-Reply-To: <1462350799.2546.31.camel@strongswan.org>
On Wed, 2016-05-04 at 10:33 +0200, Martin Willi wrote:
> > This changes today's default behaviour of moving the wiphys to the
> > default namespace. Did you intend to destroy them based on the
> > netgroup, i.e. based on the namespace that created them? Actually,
> > maybe they should move back to the namespace that created them, if
> > the namespace they are in is destroyed? But that's difficult, I
> > don't
> > mind this behaviour, but I'm not sure it's what we want by default
> > for radios created in the init_net.
> With the proposed approach I destroy all radios if the owning
> namespace gets deleted, because we probably don't want them landing
> in init_net if they are created from a (unprivileged) userns process.
I agree they shouldn't land in init_net.
> I think this is what other "virtual" interfaces do (gre tunnels, veth
> etc.). If we think of hwsim radios as such a "virtual" device, that
> makes IMO sense to delete them.
Ok, I have no idea what happens there.
> If we want to keep the existing behavior, we could move radios
> belonging to the init_net-associated netgroup back to init_net, that
> shouldn't be too difficult.
>
> Moving the radio back to the creators namespace would be the most
> consistent behavior, so I'll check how difficult such a reverse
> lookup is. We then would delete the radio only if it is in the
> creators namespace, or if the creators namespace is gone. Does that
> make sense?
It does make sense, but it does also feel a bit complicated. Perhaps
just special-case the init_net case for consistency with the existing
behaviour, and reserve netgroup 0 for that so we can easily check for
it?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces
From: Johannes Berg @ 2016-05-09 7:31 UTC (permalink / raw)
To: David Laight, 'Martin Willi'
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D5F4B5302-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
> >
> > + data->netgroup = *(int *)net_generic(net, hwsim_net_id);
> Anything doing *(integer_type *) rings alarm bells.
>
> I suspect you should be defining a structure that currently contains
> one integer member.
> Something (maybe a compile time assert) needs to check that buffer
> space you are accessing (where ever it is) is large enough.
>
It does look a bit awkward, but there's no value in having a struct -
you still have an opaque pointer here and cast it to something whose
size you assume to be present... it really makes no difference.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support
From: Simon Horman @ 2016-05-09 8:04 UTC (permalink / raw)
To: Jiri Benc
Cc: pravin shelar, Linux Kernel Network Developers, ovs dev,
Lorand Jakab, Thomas Morin
In-Reply-To: <20160506112514.47f6e9dc@griffin>
On Fri, May 06, 2016 at 11:25:14AM +0200, Jiri Benc wrote:
> On Fri, 6 May 2016 14:57:07 +0900, Simon Horman wrote:
> > On Thu, May 05, 2016 at 10:37:08AM -0700, pravin shelar wrote:
> > > On transmit side you are using mac_len to detect l3 packet, why not do
> > > same while extracting the key?
>
> I agree. The skb should be self-contained, i.e. it should be obvious
> whether it has the MAC header set or not just from the skb itself at
> any point in the packet processing. Otherwise, I'd expect things like
> recirculation to break after push/pop of eth header.
>
> > Unfortunately mac_len can't be relied on here, emprically it has the same
> > value (28 in my tests) for both the TEB and layer3 case above.
>
> That's strange, it looks like there's something setting the mac header
> unconditionally in ovs code. We should find that place and change it.
It seems to be caused by the following:
1. __ipgre_rcv() calls skb_pop_mac_header() which
sets skb->mac_header to the skb->network_header.
2. __ipgre_rcv() then calls ip_tunnel_rcv() which calls
skb_reset_network_header(). This updates skb->network_header to
just after the end of the GRE header.
This is 28 bytes after the old skb->network_header
as there is a 20 byte IPv4 header followed by an
8 byte GRE header.
3. Later, dev_gro_receive() calls skb_reset_mac_len().
This calculates skb->mac_len based on skb->network_header and
skb->mac_header. I.e. 28 bytes.
I think this may be possible to address by calling
skb_reset_network_header() instead of skb_pop_mac_header()
in __ipgre_rcv().
I think that would leave skb->mac_header and skb->network_header both
set to just after the end of the GRE header and result in mac_len of 0.
It looks like this owuld be for for both TEB and non-TEB GRE packets
and that OVS would need to check against mac_len, protocol and most
likely dev->type early on.
> The ARPHRD_NONE interfaces don't even set mac_header and mac_len, this
> will need to be set by ovs upon getting frame from such interface.
Noted.
> > Perhaps that could be changed by futher enhancements in the tunneling code
> > but I think things are symetric as they stand:
> >
> > * On recieve skb->protocol can be read to distinguish TEB and layer3 packets
> > * On transmit skb->protocol should be set to distinguish TEB and layer3 packets
>
> Yes, but you need to act upon this directly after receiving the
> frame/just before sending the frame and set up an internal flag that
> will be used throughout the code. That way, the packet can be handed
> over to different parts of the code, recirculated, etc. without
> worries. skb->mac_len is probably a good candidate for such flag.
Its possible that I've overlooked something but as things stand I think
things look like this:
* ovs_flow_key_extract() keys off dev->type and skb->protocol.
* ovs_flow_key_extract() calls key_extract() which amongst other things
sets up the skb->mac_header and skb->mac_len of the skb.
* ovs_flow_key_extract() sets skb->protocol to that of the inner packet
in the case of TEB
* Actions update the above mentioned skb fields as appropriate.
So it seems to me that it should be safe to rely on skb->protocol
in the receive path. Or more specifically, in netdev_port_receive().
If mac_len is also able to be used then I think fine. But it seems to me
that it needs to be set up by OvS at least for the ARPHRD_NONE case. This
could be done early on, say in netdev_port_receive(). But it seems that
would involve duplicating some of what is already occurring in
key_extract().
^ permalink raw reply
* IPv6: proxy_ndp to a network range
From: H. Peter Anvin @ 2016-05-09 8:06 UTC (permalink / raw)
To: netdev
Hello,
There currently doesn't seem to be any support for proxy_ndp of a whole
network mask, as IPv4 proxy_arp seems to permit.
a) Am I actually correct in this, or am I just missing something important?
b) Is there a technical reason for this, or is it just a limitation of
the current implementation?
Thanks,
-hpa
^ permalink raw reply
* Re: [PATCH v9 net-next 4/7] openvswitch: add layer 3 flow/port support
From: Simon Horman @ 2016-05-09 8:18 UTC (permalink / raw)
To: Jiri Benc; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160506113504.77a9504e@griffin>
On Fri, May 06, 2016 at 11:35:04AM +0200, Jiri Benc wrote:
> On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> > +static int push_eth(struct sk_buff *skb, struct sw_flow_key *key,
> > + const struct ovs_action_push_eth *ethh)
> > +{
> > + int err;
> > +
> > + /* De-accelerate any hardware accelerated VLAN tag added to a previous
> > + * Ethernet header */
> > + err = skb_vlan_deaccel(skb);
> > + if (unlikely(err))
> > + return err;
> > +
> > + /* Add the new Ethernet header */
> > + if (skb_cow_head(skb, ETH_HLEN) < 0)
> > + return -ENOMEM;
> > +
> > + skb_push(skb, ETH_HLEN);
> > + skb_reset_mac_header(skb);
> > + skb_reset_mac_len(skb);
> > +
> > + ether_addr_copy(eth_hdr(skb)->h_source, ethh->addresses.eth_src);
> > + ether_addr_copy(eth_hdr(skb)->h_dest, ethh->addresses.eth_dst);
> > + eth_hdr(skb)->h_proto = ethh->eth_type;
>
> This doesn't seem right. We know the packet type, it's skb->protocol.
> We should fill in that.
I think that makes sense. Possibly the eth_type field
can be removed from ovs_action_push_eth.
> In addition, we should check whether mac_len > 0 and in such case,
> change skb->protocol to ETH_P_TEB first (and store that value in the
> pushed eth header).
>
> Similarly on pop_eth, we need to check skb->protocol and if it is
> ETH_P_TEB, call eth_type_trans on the modified frame to set the new
> skb->protocol correctly. It's probably not that simple, as we'd need a
> version of eth_type_trans that doesn't need a net device.
I'm not sure I understand the interaction with ETH_P_TEB here.
In my mind skb->protocol == ETH_P_TEB may be used early on in OvS's receive
processing to find the inner protocol from the packet and at that point
skb->protocol is set to that value. And that for further packet processing
the fact the packet was received as TEB is transparent.
Conversely, skb->protocol may be set as necessary on transmit as a packet
exits OvS.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: IPv6: proxy_ndp to a network range
From: Alexander Aring @ 2016-05-09 8:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: netdev
In-Reply-To: <31ff66eb-38bd-0186-9e81-0543f0558323@zytor.com>
Hi,
On Mon, May 09, 2016 at 01:06:51AM -0700, H. Peter Anvin wrote:
> Hello,
>
> There currently doesn't seem to be any support for proxy_ndp of a whole
> network mask, as IPv4 proxy_arp seems to permit.
>
> a) Am I actually correct in this, or am I just missing something important?
>
> b) Is there a technical reason for this, or is it just a limitation of the
> current implementation?
>
So far I know you can do this with the ndppd [0] userspace tool which listen
NS/NA messages and do the ip -6 neigh add proxy for you.
- Alex
[0] https://github.com/DanielAdolfsson/ndppd
^ permalink raw reply
* Re: IPv6: proxy_ndp to a network range
From: H. Peter Anvin @ 2016-05-09 8:46 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev
In-Reply-To: <20160509083903.GA2462@omega>
On May 9, 2016 1:39:08 AM PDT, Alexander Aring <alex.aring@gmail.com> wrote:
>Hi,
>
>On Mon, May 09, 2016 at 01:06:51AM -0700, H. Peter Anvin wrote:
>> Hello,
>>
>> There currently doesn't seem to be any support for proxy_ndp of a
>whole
>> network mask, as IPv4 proxy_arp seems to permit.
>>
>> a) Am I actually correct in this, or am I just missing something
>important?
>>
>> b) Is there a technical reason for this, or is it just a limitation
>of the
>> current implementation?
>>
>
>So far I know you can do this with the ndppd [0] userspace tool which
>listen
>NS/NA messages and do the ip -6 neigh add proxy for you.
>
>- Alex
>
>[0] https://github.com/DanielAdolfsson/ndppd
Sure, but it seems like a workaround for something that ought to be simpler?
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
^ permalink raw reply
* Re: [PATCH net-next 2/4] xen-netback: add control protocol implementation
From: Paul Durrant @ 2016-05-09 8:56 UTC (permalink / raw)
To: David Miller
Cc: xen-devel@lists.xenproject.org, Wei Liu, netdev@vger.kernel.org
In-Reply-To: <20160507.150921.2053537729453518863.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: 07 May 2016 20:09
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; netdev@vger.kernel.org; Wei Liu
> Subject: Re: [PATCH net-next 2/4] xen-netback: add control protocol
> implementation
>
> From: Paul Durrant <paul.durrant@citrix.com>
> Date: Thu, 5 May 2016 12:19:28 +0100
>
> > +struct xenvif_hash_cache {
> > + rwlock_t lock;
>
> You really don't want to lock on every SKB hash computation like
> this, turn this into a spin lock for locking the write side and
> use RCU locking for lookup and usage.
>
Yes, that would be better. Will do.
Cheers,
Paul
> THanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH net-next v3] block/drbd: align properly u64 in nl messages
From: Nicolas Dichtel @ 2016-05-09 9:40 UTC (permalink / raw)
To: davem, lars.ellenberg
Cc: netdev, philipp.reisner, drbd-dev, linux-kernel, Nicolas Dichtel
In-Reply-To: <20160503100644.GE16459@soda.linbit>
The attribute 0 is never used in drbd, so let's use it as pad attribute
in netlink messages. This minimizes the patch.
Note that this patch is only compile-tested.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
---
v2 -> v3:
use 0 as padattr instead of adding new attributes
v1 -> v2:
rework the patch to handle all cases
Maybe prefixing genl_magic_func.h and genl_magic_struct.h by 'drbd_'
could be interesting so that new module won't use it. What is your
opinion?
drivers/block/drbd/drbd_nl.c | 28 ++++++++++++++++------------
include/linux/genl_magic_struct.h | 7 ++++++-
2 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index 1fd1dccebb6b..0bac9c8246bc 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -3633,14 +3633,15 @@ static int nla_put_status_info(struct sk_buff *skb, struct drbd_device *device,
goto nla_put_failure;
if (nla_put_u32(skb, T_sib_reason, sib ? sib->sib_reason : SIB_GET_STATUS_REPLY) ||
nla_put_u32(skb, T_current_state, device->state.i) ||
- nla_put_u64(skb, T_ed_uuid, device->ed_uuid) ||
- nla_put_u64(skb, T_capacity, drbd_get_capacity(device->this_bdev)) ||
- nla_put_u64(skb, T_send_cnt, device->send_cnt) ||
- nla_put_u64(skb, T_recv_cnt, device->recv_cnt) ||
- nla_put_u64(skb, T_read_cnt, device->read_cnt) ||
- nla_put_u64(skb, T_writ_cnt, device->writ_cnt) ||
- nla_put_u64(skb, T_al_writ_cnt, device->al_writ_cnt) ||
- nla_put_u64(skb, T_bm_writ_cnt, device->bm_writ_cnt) ||
+ nla_put_u64_0pad(skb, T_ed_uuid, device->ed_uuid) ||
+ nla_put_u64_0pad(skb, T_capacity,
+ drbd_get_capacity(device->this_bdev)) ||
+ nla_put_u64_0pad(skb, T_send_cnt, device->send_cnt) ||
+ nla_put_u64_0pad(skb, T_recv_cnt, device->recv_cnt) ||
+ nla_put_u64_0pad(skb, T_read_cnt, device->read_cnt) ||
+ nla_put_u64_0pad(skb, T_writ_cnt, device->writ_cnt) ||
+ nla_put_u64_0pad(skb, T_al_writ_cnt, device->al_writ_cnt) ||
+ nla_put_u64_0pad(skb, T_bm_writ_cnt, device->bm_writ_cnt) ||
nla_put_u32(skb, T_ap_bio_cnt, atomic_read(&device->ap_bio_cnt)) ||
nla_put_u32(skb, T_ap_pending_cnt, atomic_read(&device->ap_pending_cnt)) ||
nla_put_u32(skb, T_rs_pending_cnt, atomic_read(&device->rs_pending_cnt)))
@@ -3657,13 +3658,16 @@ static int nla_put_status_info(struct sk_buff *skb, struct drbd_device *device,
goto nla_put_failure;
if (nla_put_u32(skb, T_disk_flags, device->ldev->md.flags) ||
- nla_put_u64(skb, T_bits_total, drbd_bm_bits(device)) ||
- nla_put_u64(skb, T_bits_oos, drbd_bm_total_weight(device)))
+ nla_put_u64_0pad(skb, T_bits_total, drbd_bm_bits(device)) ||
+ nla_put_u64_0pad(skb, T_bits_oos,
+ drbd_bm_total_weight(device)))
goto nla_put_failure;
if (C_SYNC_SOURCE <= device->state.conn &&
C_PAUSED_SYNC_T >= device->state.conn) {
- if (nla_put_u64(skb, T_bits_rs_total, device->rs_total) ||
- nla_put_u64(skb, T_bits_rs_failed, device->rs_failed))
+ if (nla_put_u64_0pad(skb, T_bits_rs_total,
+ device->rs_total) ||
+ nla_put_u64_0pad(skb, T_bits_rs_failed,
+ device->rs_failed))
goto nla_put_failure;
}
}
diff --git a/include/linux/genl_magic_struct.h b/include/linux/genl_magic_struct.h
index eecd19b37001..6270a56e5edc 100644
--- a/include/linux/genl_magic_struct.h
+++ b/include/linux/genl_magic_struct.h
@@ -62,6 +62,11 @@ extern void CONCAT_(GENL_MAGIC_FAMILY, _genl_unregister)(void);
/* MAGIC helpers {{{2 */
+static inline int nla_put_u64_0pad(struct sk_buff *skb, int attrtype, u64 value)
+{
+ return nla_put_64bit(skb, attrtype, sizeof(u64), &value, 0);
+}
+
/* possible field types */
#define __flg_field(attr_nr, attr_flag, name) \
__field(attr_nr, attr_flag, name, NLA_U8, char, \
@@ -80,7 +85,7 @@ extern void CONCAT_(GENL_MAGIC_FAMILY, _genl_unregister)(void);
nla_get_u32, nla_put_u32, true)
#define __u64_field(attr_nr, attr_flag, name) \
__field(attr_nr, attr_flag, name, NLA_U64, __u64, \
- nla_get_u64, nla_put_u64, false)
+ nla_get_u64, nla_put_u64_0pad, false)
#define __str_field(attr_nr, attr_flag, name, maxlen) \
__array(attr_nr, attr_flag, name, NLA_NUL_STRING, char, maxlen, \
nla_strlcpy, nla_put, false)
--
2.8.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox