* Re: brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events
From: Kalle Valo @ 2017-12-14 12:40 UTC (permalink / raw)
To: Colin Ian King
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171207102047.21635-1-colin.king@canonical.com>
Colin Ian King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Use the ARRAY_SIZE macro on rfseq_updategainu_events to determine
> size of the array. Improvement suggested by coccinelle.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
18907f20ea71 brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events
--
https://patchwork.kernel.org/patch/10098257/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC PATCH] net: stmmac: enable EEE in MII, GMII or RGMII only
From: Arnaud Patard @ 2017-12-14 12:41 UTC (permalink / raw)
To: Jerome Brunet
Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-amlogic,
linux-kernel
In-Reply-To: <20171205102809.4347-1-jbrunet@baylibre.com>
Jerome Brunet <jbrunet@baylibre.com> writes:
> Note in the databook - Section 4.4 - EEE :
> " The EEE feature is not supported when the MAC is configured to use the
> TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC
> supports multiple PHY interfaces, you should activate the EEE mode only
> when the MAC is operating with GMII, MII, or RGMII interface."
>
> Applying this restriction solves a stability issue observed on Amlogic
> gxl platforms operating with RMII interface and the internal PHY.
I was having the issue on my libretech AML-S905X-CC / potato board. With
this patch, I've not been able to trigger it at all. Without it and with
my test case, I was able to trigger the hang several times reliably.
Any hope to see this merged ?
>
> Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Arnaud Patard <arnaud.patard@rtp-net.org>
^ permalink raw reply
* Re: [1/1] rtlwifi: always initialize variables given to RT_TRACE()
From: Kalle Valo @ 2017-12-14 12:44 UTC (permalink / raw)
To: Nicolas Iooss
Cc: Larry Finger, Chaoming Li, linux-wireless, netdev, linux-kernel,
Nicolas Iooss
In-Reply-To: <20171210195159.7454-1-nicolas.iooss_linux@m4x.org>
Nicolas Iooss <nicolas.iooss_linux@m4x.org> wrote:
> In rtl_rx_ampdu_apply(), when rtlpriv->cfg->ops->get_btc_status()
> returns false, RT_TRACE() is called with the values of variables
> reject_agg and agg_size, which have not been initialized.
>
> Always initialize these variables in order to prevent using
> uninitialized values.
>
> This issue has been found with clang. The compiler reported:
>
> drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable
> 'agg_size' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> if (rtlpriv->cfg->ops->get_btc_status())
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/base.c:1671:31: note:
> uninitialized use occurs here
> reject_agg, ctrl_agg_size, agg_size);
> ^~~~~~~~
>
> drivers/net/wireless/realtek/rtlwifi/base.c:1665:6: error: variable
> 'reject_agg' is used uninitialized whenever 'if' condition
> is false [-Werror,-Wsometimes-uninitialized]
> if (rtlpriv->cfg->ops->get_btc_status())
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/base.c:1671:4: note:
> uninitialized use occurs here
> reject_agg, ctrl_agg_size, agg_size);
> ^~~~~~~~~~
>
> Fixes: 2635664e6e4a ("rtlwifi: Add rx ampdu cfg for btcoexist.")
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Patch applied to wireless-drivers-next.git, thanks.
e4779162f737 rtlwifi: always initialize variables given to RT_TRACE()
--
https://patchwork.kernel.org/patch/10103995/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wlcore: fix unused function warning
From: Kalle Valo @ 2017-12-14 12:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Reizer, Eyal, Johannes Berg, Iain Hunter,
Arend Van Spriel, Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171211114718.3637010-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The newly added wlcore_fw_sleep function is called conditionally,
> which causes a warning without CONFIG_PM:
>
> drivers/net/wireless/ti/wlcore/main.c:981:12: error: 'wlcore_fw_sleep' defined but not used [-Werror=unused-function]
>
> Instead of trying to keep track of what should be in the #ifdef and what
> should not, it's easier to mark the top-level suspend/resume functions
> as __maybe_unused so the compiler can silently drop all the unused code.
>
> Fixes: 37bf241b8e7b ("wlcore: allow elp during wowlan suspend")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
7de241f3b705 wlcore: fix unused function warning
--
https://patchwork.kernel.org/patch/10104839/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4 net-next 0/4] bpftool: cgroup bpf operations
From: Daniel Borkmann @ 2017-12-14 12:45 UTC (permalink / raw)
To: Roman Gushchin, netdev
Cc: linux-kernel, kernel-team, ast, jakub.kicinski, kafai,
Quentin Monnet, David Ahern
In-Reply-To: <20171213151854.21960-1-guro@fb.com>
On 12/13/2017 04:18 PM, Roman Gushchin wrote:
> This patchset adds basic cgroup bpf operations to bpftool.
>
> Right now there is no convenient way to perform these operations.
> The /samples/bpf/load_sock_ops.c implements attach/detacg operations,
> but only for BPF_CGROUP_SOCK_OPS programs. Bps (part of bcc) implements
> bpf introspection, but lacks any cgroup-related specific.
>
> I find having a tool to perform these basic operations in the kernel tree
> very useful, as it can be used in the corresponding bpf documentation
> without creating additional dependencies. And bpftool seems to be
> a right tool to extend with such functionality.
>
> v4:
> - ATTACH_FLAGS and ATTACH_TYPE are listed and described in docs and usage
> - ATTACH_FLAG names converted to "multi" and "override"
> - do_attach() recognizes ATTACH_FLAG abbreviations, e.g "mul"
> - Local variables sorted ("reverse Christmas tree")
> - unknown attach flags value will be never truncated
Series applied to bpf-next, thanks everyone!
^ permalink raw reply
* Re: [patch net-next v3 05/10] net: sched: keep track of offloaded filters and check tc offload feature
From: Jiri Pirko @ 2017-12-14 13:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, jhs, xiyou.wangcong, mlxsw, andrew, vivien.didelot,
f.fainelli, michael.chan, ganeshgr, saeedm, matanb, leonro,
idosch, simon.horman, pieter.jansenvanvuuren, john.hurley,
alexander.h.duyck, ogerlitz, john.fastabend, daniel
In-Reply-To: <20171214094716.GA1926@nanopsycho>
Thu, Dec 14, 2017 at 10:47:16AM CET, jiri@resnulli.us wrote:
>Thu, Dec 14, 2017 at 02:05:55AM CET, jakub.kicinski@netronome.com wrote:
>>On Wed, 13 Dec 2017 16:10:33 +0100, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> During block bind, we need to check tc offload feature. If it is
>>> disabled yet still the block contains offloaded filters, forbid the
>>> bind. Also forbid to register callback for a block that already
>>> containes offloaded filters, as the play back is not supported now.
>>> For keeping track of offloaded filters there is a new counter
>>> introduced, alongside with couple of helpers called from cls_* code.
>>> These helpers set and clear TCA_CLS_FLAGS_IN_HW flag.
>>>
>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>
>>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>> index de9dbcb..ac25142 100644
>>> --- a/net/sched/cls_api.c
>>> +++ b/net/sched/cls_api.c
>>> @@ -266,31 +266,50 @@ void tcf_chain_put(struct tcf_chain *chain)
>>> }
>>> EXPORT_SYMBOL(tcf_chain_put);
>>>
>>> -static void tcf_block_offload_cmd(struct tcf_block *block, struct Qdisc *q,
>>> +static bool tcf_block_offload_in_use(struct tcf_block *block)
>>> +{
>>> + return block->offloadcnt;
>>> +}
>>> +
>>> +static void tcf_block_offload_cmd(struct tcf_block *block,
>>> + struct net_device *dev,
>>> struct tcf_block_ext_info *ei,
>>> enum tc_block_command command)
>>> {
>>> - struct net_device *dev = q->dev_queue->dev;
>>> struct tc_block_offload bo = {};
>>>
>>> - if (!dev->netdev_ops->ndo_setup_tc)
>>> - return;
>>> bo.command = command;
>>> bo.binder_type = ei->binder_type;
>>> bo.block = block;
>>> dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
>>> }
>>>
>>> -static void tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
>>> - struct tcf_block_ext_info *ei)
>>> +static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
>>> + struct tcf_block_ext_info *ei)
>>> {
>>> - tcf_block_offload_cmd(block, q, ei, TC_BLOCK_BIND);
>>> + struct net_device *dev = q->dev_queue->dev;
>>> +
>>> + if (!dev->netdev_ops->ndo_setup_tc)
>>> + return 0;
>>> +
>>> + /* If tc offload feature is disabled and the block we try to bind
>>> + * to already has some offloaded filters, forbid to bind.
>>> + */
>>> + if (!tc_can_offload(dev) && tcf_block_offload_in_use(block))
>>> + return -EOPNOTSUPP;
>>
>>I don't understand the tc_can_offload(dev) check here. The flow is -
>>on bind if TC offloads are enabled the new port will get a TC_BLOCK_BIND
>>and request a register, but the register will fail since the block is
>>offloaded?
>
>The point of this check is to disallow dev with tc offload disabled to
>share a block which already holds offloaded filters.
>
>That is similar to disallow disabling tc offload on device that shares a
>block which contains offloaded filters.
>
>
>
>>
>>But the whole bind operation does not fail, so user will not see an
>>error. The block will get bound but port's driver has no way to
>>register the callback. I'm sorry if I'm just being slow here..
>>
>>> + tcf_block_offload_cmd(block, dev, ei, TC_BLOCK_BIND);
>>> + return 0;
>
>The thing is that driver which does not support TC_BLOCK_BIND would
>return -EOPNOTSUPP here. For those drivers we continue, they just won't
>have block cb registered so they won't receive cb calls to offload
>filters.
>
>
>>> }
>>>
>>> static void tcf_block_offload_unbind(struct tcf_block *block, struct Qdisc *q,
>>> struct tcf_block_ext_info *ei)
>>> {
>>> - tcf_block_offload_cmd(block, q, ei, TC_BLOCK_UNBIND);
>>> + struct net_device *dev = q->dev_queue->dev;
>>> +
>>> + if (!dev->netdev_ops->ndo_setup_tc)
>>> + return;
>>> + tcf_block_offload_cmd(block, dev, ei, TC_BLOCK_UNBIND);
>>> }
>>>
>>> static int
>>> @@ -499,10 +518,15 @@ int tcf_block_get_ext(struct tcf_block **p_block, struct Qdisc *q,
>>> if (err)
>>> goto err_chain_head_change_cb_add;
>>>
>>> - tcf_block_offload_bind(block, q, ei);
>>> + err = tcf_block_offload_bind(block, q, ei);
>>> + if (err)
>>> + goto err_block_offload_bind;
>>
>>Would it perhaps make more sense to add a TC_BLOCK_JOIN or some such?
>
>Why? Just a namechange?
>
>
>>IIUC the problem is we don't know whether the driver/callee of the new
>>port is aware of previous callbacks/filters and we can't replay them.
Well, the problem is a bit different.
There are 2 scenarios when we need to fail here:
1) tc offload feature is turned off, there are some filters offloaded in
the block. That is what I commented above.
2) tc offload feature is turned on, there are some filters offloaded in
the block but the block is not accounted by the driver. This is
because of the lack or replay. This is taken care of in the beginning
of __tcf_block_cb_register function - see below, there is a comment
there.
>>
>>Obviously registering new callbacks on offloaded blocks is a no-go.
>>For simple bind to a new port of an ASIC which already knows the rule
>>set, we just need to ask all callbacks if they know the port and as
>>long as any of them responds "yes" we are safe to assume the bind is OK.
>>
>>(Existing drivers will all respond with EOPNOTSUPP to a new unknown command.)
>>
>>Does that make sense?
>
>Hmm, I understand what you say. I have to think about that a bit more.
As you see, both cases where we need to bail out are covered. Do you see
any other problem?
>
>Thanks!
>
>>
>>> *p_block = block;
>>> return 0;
>>>
>>> +err_block_offload_bind:
>>> + tcf_chain_head_change_cb_del(tcf_block_chain_zero(block), ei);
>>> err_chain_head_change_cb_add:
>>> tcf_block_owner_del(block, q, ei->binder_type);
>>> err_block_owner_add:
>>> @@ -630,9 +654,16 @@ struct tcf_block_cb *__tcf_block_cb_register(struct tcf_block *block,
>>> {
>>> struct tcf_block_cb *block_cb;
>>>
>>> + /* At this point, playback of previous block cb calls is not supported,
>>> + * so forbid to register to block which already has some offloaded
>>> + * filters present.
>>> + */
>>> + if (tcf_block_offload_in_use(block))
>>> + return ERR_PTR(-EOPNOTSUPP);
>>>
>>> block_cb = kzalloc(sizeof(*block_cb), GFP_KERNEL);
>>> if (!block_cb)
>>> - return NULL;
>>> + return ERR_PTR(-ENOMEM);
>>> block_cb->cb = cb;
>>> block_cb->cb_ident = cb_ident;
>>> block_cb->cb_priv = cb_priv;
>>> @@ -648,7 +679,7 @@ int tcf_block_cb_register(struct tcf_block *block,
>>> struct tcf_block_cb *block_cb;
>>>
>>> block_cb = __tcf_block_cb_register(block, cb, cb_ident, cb_priv);
>>> - return block_cb ? 0 : -ENOMEM;
>>> + return IS_ERR(block_cb) ? PTR_ERR(block_cb) : 0;
>>> }
>>> EXPORT_SYMBOL(tcf_block_cb_register);
>>>
^ permalink raw reply
* [PATCH] wireless: Always rewrite generated files from scratch
From: Thierry Reding @ 2017-12-14 13:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: David S . Miller, linux-wireless, netdev, linux-kernel
From: Thierry Reding <treding@nvidia.com>
Currently the certs C code generation appends to the generated files,
which is most likely a leftover from commit 715a12334764 ("wireless:
don't write C files on failures"). This causes duplicate code in the
generated files if the certificates have their timestamps modified
between builds and thereby trigger the generation rules.
Fixes: 715a12334764 ("wireless: don't write C files on failures")
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Based on next-20171214
net/wireless/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index d7d6cb00c47b..b662be3422e1 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -43,7 +43,7 @@ $(obj)/shipped-certs.c: $(wildcard $(srctree)/$(src)/certs/*.x509)
echo "$$allf"; \
echo '};'; \
echo 'unsigned int shipped_regdb_certs_len = sizeof(shipped_regdb_certs);'; \
- ) >> $@)
+ ) > $@)
$(obj)/extra-certs.c: $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%) \
$(wildcard $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%)/*.x509)
@@ -66,4 +66,4 @@ $(obj)/extra-certs.c: $(CONFIG_CFG80211_EXTRA_REGDB_KEYDIR:"%"=%) \
echo "$$allf"; \
echo '};'; \
echo 'unsigned int extra_regdb_certs_len = sizeof(extra_regdb_certs);'; \
- ) >> $@)
+ ) > $@)
--
2.15.1
^ permalink raw reply related
* Re: [RFC PATCH] reuseport: compute the ehash only if needed
From: David Miller @ 2017-12-14 13:41 UTC (permalink / raw)
To: pabeni; +Cc: netdev, kraig, edumazet
In-Reply-To: <1513240186.2604.10.camel@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 14 Dec 2017 09:29:46 +0100
> I was unable to measure any performance regression for the hash based
> demultiplexing, and I think that the number of function calls is
> unchanged in such scenario (with vanilla kernel we have ehash() and
> reuseport_select_sock(), with the patched one __reuseport_get_info()
> and ehash()).
>
> I agree you are right about the additional stack usage introduced by
> this patch.
>
> Overall I see we need something better than this.
Thanks for checking whether it's slower or not. I wonder if x86-64
is putting the argument parts on the stack anyways...
^ permalink raw reply
* [PATCH v7 1/3] sock: Change the netns_core member name.
From: Tonghao Zhang @ 2017-12-14 13:51 UTC (permalink / raw)
To: xiyou.wangcong, davem; +Cc: netdev, Tonghao Zhang
Change the member name will make the code more readable.
This patch will be used in next patch.
Signed-off-by: Martin Zhang <zhangjunweimartin@didichuxing.com>
Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
---
include/net/netns/core.h | 2 +-
net/core/sock.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/net/netns/core.h b/include/net/netns/core.h
index 0ad4d0c..45cfb5d 100644
--- a/include/net/netns/core.h
+++ b/include/net/netns/core.h
@@ -11,7 +11,7 @@ struct netns_core {
int sysctl_somaxconn;
- struct prot_inuse __percpu *inuse;
+ struct prot_inuse __percpu *prot_inuse;
};
#endif
diff --git a/net/core/sock.c b/net/core/sock.c
index c0b5b2f..c2dd2d3 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -3045,7 +3045,7 @@ struct prot_inuse {
void sock_prot_inuse_add(struct net *net, struct proto *prot, int val)
{
- __this_cpu_add(net->core.inuse->val[prot->inuse_idx], val);
+ __this_cpu_add(net->core.prot_inuse->val[prot->inuse_idx], val);
}
EXPORT_SYMBOL_GPL(sock_prot_inuse_add);
@@ -3055,7 +3055,7 @@ int sock_prot_inuse_get(struct net *net, struct proto *prot)
int res = 0;
for_each_possible_cpu(cpu)
- res += per_cpu_ptr(net->core.inuse, cpu)->val[idx];
+ res += per_cpu_ptr(net->core.prot_inuse, cpu)->val[idx];
return res >= 0 ? res : 0;
}
@@ -3063,13 +3063,13 @@ int sock_prot_inuse_get(struct net *net, struct proto *prot)
static int __net_init sock_inuse_init_net(struct net *net)
{
- net->core.inuse = alloc_percpu(struct prot_inuse);
- return net->core.inuse ? 0 : -ENOMEM;
+ net->core.prot_inuse = alloc_percpu(struct prot_inuse);
+ return net->core.prot_inuse ? 0 : -ENOMEM;
}
static void __net_exit sock_inuse_exit_net(struct net *net)
{
- free_percpu(net->core.inuse);
+ free_percpu(net->core.prot_inuse);
}
static struct pernet_operations net_inuse_ops = {
--
1.8.3.1
^ permalink raw reply related
* [PATCH v7 2/3] sock: Move the socket inuse to namespace.
From: Tonghao Zhang @ 2017-12-14 13:51 UTC (permalink / raw)
To: xiyou.wangcong, davem; +Cc: netdev, Tonghao Zhang
In-Reply-To: <1513259519-32332-1-git-send-email-xiangxia.m.yue@gmail.com>
In some case, we want to know how many sockets are in use in
different _net_ namespaces. It's a key resource metric.
This patch add a member in struct netns_core. This is a counter
for socket-inuse in the _net_ namespace. The patch will add/sub
counter in the sk_alloc, sk_clone_lock and __sk_free.
This patch will not counter the socket created in kernel.
It's not very useful for userspace to know how many kernel
sockets we created.
The main reasons for doing this are that:
1. When linux calls the 'do_exit' for process to exit, the functions
'exit_task_namespaces' and 'exit_task_work' will be called sequentially.
'exit_task_namespaces' may have destroyed the _net_ namespace, but
'sock_release' called in 'exit_task_work' may use the _net_ namespace
if we counter the socket-inuse in sock_release.
2. socket and sock are in pair. More important, sock holds the _net_
namespace. We counter the socket-inuse in sock, for avoiding holding
_net_ namespace again in socket. It's a easy way to maintain the code.
Signed-off-by: Martin Zhang <zhangjunweimartin@didichuxing.com>
Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
---
include/net/netns/core.h | 3 +++
include/net/sock.h | 1 +
net/core/sock.c | 47 +++++++++++++++++++++++++++++++++++++++++++++--
net/socket.c | 21 ++-------------------
4 files changed, 51 insertions(+), 21 deletions(-)
diff --git a/include/net/netns/core.h b/include/net/netns/core.h
index 45cfb5d..a5e8a66 100644
--- a/include/net/netns/core.h
+++ b/include/net/netns/core.h
@@ -11,6 +11,9 @@ struct netns_core {
int sysctl_somaxconn;
+#ifdef CONFIG_PROC_FS
+ int __percpu *sock_inuse;
+#endif
struct prot_inuse __percpu *prot_inuse;
};
diff --git a/include/net/sock.h b/include/net/sock.h
index 9a90472..0a32f3c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1262,6 +1262,7 @@ static inline void sk_sockets_allocated_inc(struct sock *sk)
/* Called with local bh disabled */
void sock_prot_inuse_add(struct net *net, struct proto *prot, int inc);
int sock_prot_inuse_get(struct net *net, struct proto *proto);
+int sock_inuse_get(struct net *net);
#else
static inline void sock_prot_inuse_add(struct net *net, struct proto *prot,
int inc)
diff --git a/net/core/sock.c b/net/core/sock.c
index c2dd2d3..72d14b2 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -145,6 +145,8 @@
static DEFINE_MUTEX(proto_list_mutex);
static LIST_HEAD(proto_list);
+static void sock_inuse_add(struct net *net, int val);
+
/**
* sk_ns_capable - General socket capability test
* @sk: Socket to use a capability on or through
@@ -1531,8 +1533,11 @@ struct sock *sk_alloc(struct net *net, int family, gfp_t priority,
sk->sk_kern_sock = kern;
sock_lock_init(sk);
sk->sk_net_refcnt = kern ? 0 : 1;
- if (likely(sk->sk_net_refcnt))
+ if (likely(sk->sk_net_refcnt)) {
get_net(net);
+ sock_inuse_add(net, 1);
+ }
+
sock_net_set(sk, net);
refcount_set(&sk->sk_wmem_alloc, 1);
@@ -1595,6 +1600,9 @@ void sk_destruct(struct sock *sk)
static void __sk_free(struct sock *sk)
{
+ if (likely(sk->sk_net_refcnt))
+ sock_inuse_add(sock_net(sk), -1);
+
if (unlikely(sock_diag_has_destroy_listeners(sk) && sk->sk_net_refcnt))
sock_diag_broadcast_destroy(sk);
else
@@ -1716,6 +1724,8 @@ struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority)
newsk->sk_priority = 0;
newsk->sk_incoming_cpu = raw_smp_processor_id();
atomic64_set(&newsk->sk_cookie, 0);
+ if (likely(newsk->sk_net_refcnt))
+ sock_inuse_add(sock_net(newsk), 1);
/*
* Before updating sk_refcnt, we must commit prior changes to memory
@@ -3061,15 +3071,44 @@ int sock_prot_inuse_get(struct net *net, struct proto *prot)
}
EXPORT_SYMBOL_GPL(sock_prot_inuse_get);
+static void sock_inuse_add(struct net *net, int val)
+{
+ this_cpu_add(*net->core.sock_inuse, val);
+}
+
+int sock_inuse_get(struct net *net)
+{
+ int cpu, res = 0;
+
+ for_each_possible_cpu(cpu)
+ res += *per_cpu_ptr(net->core.sock_inuse, cpu);
+
+ return res;
+}
+
+EXPORT_SYMBOL_GPL(sock_inuse_get);
+
static int __net_init sock_inuse_init_net(struct net *net)
{
net->core.prot_inuse = alloc_percpu(struct prot_inuse);
- return net->core.prot_inuse ? 0 : -ENOMEM;
+ if (net->core.prot_inuse == NULL)
+ return -ENOMEM;
+
+ net->core.sock_inuse = alloc_percpu(int);
+ if (net->core.sock_inuse == NULL)
+ goto out;
+
+ return 0;
+
+out:
+ free_percpu(net->core.prot_inuse);
+ return -ENOMEM;
}
static void __net_exit sock_inuse_exit_net(struct net *net)
{
free_percpu(net->core.prot_inuse);
+ free_percpu(net->core.sock_inuse);
}
static struct pernet_operations net_inuse_ops = {
@@ -3112,6 +3151,10 @@ static inline void assign_proto_idx(struct proto *prot)
static inline void release_proto_idx(struct proto *prot)
{
}
+
+static void sock_inuse_add(struct net *net, int val)
+{
+}
#endif
static void req_prot_cleanup(struct request_sock_ops *rsk_prot)
diff --git a/net/socket.c b/net/socket.c
index 05f361f..bbd2e9c 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -163,12 +163,6 @@ static ssize_t sock_splice_read(struct file *file, loff_t *ppos,
static const struct net_proto_family __rcu *net_families[NPROTO] __read_mostly;
/*
- * Statistics counters of the socket lists
- */
-
-static DEFINE_PER_CPU(int, sockets_in_use);
-
-/*
* Support routines.
* Move socket addresses back and forth across the kernel/user
* divide and look after the messy bits.
@@ -578,7 +572,6 @@ struct socket *sock_alloc(void)
inode->i_gid = current_fsgid();
inode->i_op = &sockfs_inode_ops;
- this_cpu_add(sockets_in_use, 1);
return sock;
}
EXPORT_SYMBOL(sock_alloc);
@@ -605,7 +598,6 @@ void sock_release(struct socket *sock)
if (rcu_dereference_protected(sock->wq, 1)->fasync_list)
pr_err("%s: fasync list not empty!\n", __func__);
- this_cpu_sub(sockets_in_use, 1);
if (!sock->file) {
iput(SOCK_INODE(sock));
return;
@@ -2622,17 +2614,8 @@ static int __init sock_init(void)
#ifdef CONFIG_PROC_FS
void socket_seq_show(struct seq_file *seq)
{
- int cpu;
- int counter = 0;
-
- for_each_possible_cpu(cpu)
- counter += per_cpu(sockets_in_use, cpu);
-
- /* It can be negative, by the way. 8) */
- if (counter < 0)
- counter = 0;
-
- seq_printf(seq, "sockets: used %d\n", counter);
+ seq_printf(seq, "sockets: used %d\n",
+ sock_inuse_get(seq->private));
}
#endif /* CONFIG_PROC_FS */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v7 3/3] sock: Hide unused variable when !CONFIG_PROC_FS.
From: Tonghao Zhang @ 2017-12-14 13:51 UTC (permalink / raw)
To: xiyou.wangcong, davem; +Cc: netdev, Tonghao Zhang, Pavel Emelyanov
In-Reply-To: <1513259519-32332-1-git-send-email-xiangxia.m.yue@gmail.com>
When CONFIG_PROC_FS is disabled, we will not use the prot_inuse
counter. This adds an #ifdef to hide the variable definition in
that case. This is not a bugfix. But we can save bytes when there
are many network namespace.
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Martin Zhang <zhangjunweimartin@didichuxing.com>
Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
---
include/net/netns/core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/netns/core.h b/include/net/netns/core.h
index a5e8a66..36c2d99 100644
--- a/include/net/netns/core.h
+++ b/include/net/netns/core.h
@@ -13,8 +13,8 @@ struct netns_core {
#ifdef CONFIG_PROC_FS
int __percpu *sock_inuse;
-#endif
struct prot_inuse __percpu *prot_inuse;
+#endif
};
#endif
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/3] net: sched: Make qdisc offload uapi uniform
From: Yuval Mintz @ 2017-12-14 13:54 UTC (permalink / raw)
To: davem, netdev; +Cc: mlxsw, Yuval Mintz
Several qdiscs can already be offloaded to hardware, but there's an
inconsistecy in regard to the uapi through which they indicate such
an offload is taking place - indication is passed to the user via
TCA_OPTIONS where each qdisc retains private logic for setting it.
The recent addition of offloading to RED in
602f3baf2218 ("net_sch: red: Add offload ability to RED qdisc") caused
the addition of yet another uapi field for this purpose -
TC_RED_OFFLOADED.
For clarity and prevention of bloat in the uapi we want to eliminate
said added uapi, replacing it with a common mechanism that can be used
to reflect offload status of the various qdiscs.
The first patch introduces TCA_HW_OFFLOAD as the generic message meant
for this purpose. The second changes the current RED implementation into
setting the internal bits necessary for passing it, and the third removes
TC_RED_OFFLOADED as its no longer needed.
Dave,
A bit unorthodox as it's not a fix per-se, but it's the last chance
for killing the unneeded uapi and replacing it with something better
before getting stuck with it forever.
Cheers,
Yuval
Yuval Mintz (3):
net: sched: Add TCA_HW_OFFLOAD
net: sched: Move to new offload indication in RED
pkt_sched: Remove TC_RED_OFFLOADED from uapi
include/net/sch_generic.h | 1 +
include/uapi/linux/pkt_sched.h | 1 -
include/uapi/linux/rtnetlink.h | 1 +
net/sched/sch_api.c | 2 ++
net/sched/sch_red.c | 31 +++++++++++++++----------------
5 files changed, 19 insertions(+), 17 deletions(-)
--
2.4.3
^ permalink raw reply
* [PATCH net 3/3] pkt_sched: Remove TC_RED_OFFLOADED from uapi
From: Yuval Mintz @ 2017-12-14 13:54 UTC (permalink / raw)
To: davem, netdev; +Cc: mlxsw, Yuval Mintz
In-Reply-To: <1513259671-1183-1-git-send-email-yuvalm@mellanox.com>
Following the previous patch, RED is now using the new uniform uapi
for indicating it's offloaded. As a result, TC_RED_OFFLOADED is no
longer utilized by kernel and can be removed [as it's still not
part of any stable release].
Fixes: 602f3baf2218 ("net_sch: red: Add offload ability to RED qdisc")
Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
---
include/uapi/linux/pkt_sched.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index af3cc2f..37b5096 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -256,7 +256,6 @@ struct tc_red_qopt {
#define TC_RED_ECN 1
#define TC_RED_HARDDROP 2
#define TC_RED_ADAPTATIVE 4
-#define TC_RED_OFFLOADED 8
};
struct tc_red_xstats {
--
2.4.3
^ permalink raw reply related
* [PATCH net 1/3] net: sched: Add TCA_HW_OFFLOAD
From: Yuval Mintz @ 2017-12-14 13:54 UTC (permalink / raw)
To: davem, netdev; +Cc: mlxsw, Yuval Mintz
In-Reply-To: <1513259671-1183-1-git-send-email-yuvalm@mellanox.com>
Qdiscs can be offloaded to HW, but current implementation isn't uniform.
Instead, qdiscs either pass information about offload status via their
TCA_OPTIONS or omit it altogether.
Introduce a new attribute - TCA_HW_OFFLOAD that would form a uniform
uAPI for the offloading status of qdiscs.
Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
---
Do Notice this is going to create [easy-to-solve-]conflicts with net-next,
Due to 6b3ba9146fe6 ("net: sched: allow qdiscs to handle locking").
That's also why the numbering here are apparently inconsistent [skipping
0x100].
---
include/net/sch_generic.h | 1 +
include/uapi/linux/rtnetlink.h | 1 +
net/sched/sch_api.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 65d0d25..83a3e47 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -71,6 +71,7 @@ struct Qdisc {
* qdisc_tree_decrease_qlen() should stop.
*/
#define TCQ_F_INVISIBLE 0x80 /* invisible by default in dump */
+#define TCQ_F_OFFLOADED 0x200 /* qdisc is offloaded to HW */
u32 limit;
const struct Qdisc_ops *ops;
struct qdisc_size_table __rcu *stab;
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index d8b5f80..843e29a 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -557,6 +557,7 @@ enum {
TCA_PAD,
TCA_DUMP_INVISIBLE,
TCA_CHAIN,
+ TCA_HW_OFFLOAD,
__TCA_MAX
};
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index b6c4f53..0f1eab9 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -795,6 +795,8 @@ static int tc_fill_qdisc(struct sk_buff *skb, struct Qdisc *q, u32 clid,
tcm->tcm_info = refcount_read(&q->refcnt);
if (nla_put_string(skb, TCA_KIND, q->ops->id))
goto nla_put_failure;
+ if (nla_put_u8(skb, TCA_HW_OFFLOAD, !!(q->flags & TCQ_F_OFFLOADED)))
+ goto nla_put_failure;
if (q->ops->dump && q->ops->dump(q, skb) < 0)
goto nla_put_failure;
qlen = q->q.qlen;
--
2.4.3
^ permalink raw reply related
* [PATCH net 2/3] net: sched: Move to new offload indication in RED
From: Yuval Mintz @ 2017-12-14 13:54 UTC (permalink / raw)
To: davem, netdev; +Cc: mlxsw, Yuval Mintz
In-Reply-To: <1513259671-1183-1-git-send-email-yuvalm@mellanox.com>
Let RED utilize the new internal flag, TCQ_F_OFFLOADED,
to mark a given qdisc as offloaded instead of using a dedicated
indication.
Also, change internal logic into looking at said flag when possible.
Fixes: 602f3baf2218 ("net_sch: red: Add offload ability to RED qdisc")
Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
---
net/sched/sch_red.c | 31 +++++++++++++++----------------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
index 9d874e6..f0747eb 100644
--- a/net/sched/sch_red.c
+++ b/net/sched/sch_red.c
@@ -157,6 +157,7 @@ static int red_offload(struct Qdisc *sch, bool enable)
.handle = sch->handle,
.parent = sch->parent,
};
+ int err;
if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
return -EOPNOTSUPP;
@@ -171,7 +172,14 @@ static int red_offload(struct Qdisc *sch, bool enable)
opt.command = TC_RED_DESTROY;
}
- return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt);
+ err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED, &opt);
+
+ if (!err && enable)
+ sch->flags |= TCQ_F_OFFLOADED;
+ else
+ sch->flags &= ~TCQ_F_OFFLOADED;
+
+ return err;
}
static void red_destroy(struct Qdisc *sch)
@@ -274,7 +282,7 @@ static int red_init(struct Qdisc *sch, struct nlattr *opt)
return red_change(sch, opt);
}
-static int red_dump_offload(struct Qdisc *sch, struct tc_red_qopt *opt)
+static int red_dump_offload_stats(struct Qdisc *sch, struct tc_red_qopt *opt)
{
struct net_device *dev = qdisc_dev(sch);
struct tc_red_qopt_offload hw_stats = {
@@ -286,21 +294,12 @@ static int red_dump_offload(struct Qdisc *sch, struct tc_red_qopt *opt)
.stats.qstats = &sch->qstats,
},
};
- int err;
- opt->flags &= ~TC_RED_OFFLOADED;
- if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
- return 0;
-
- err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED,
- &hw_stats);
- if (err == -EOPNOTSUPP)
+ if (!(sch->flags & TCQ_F_OFFLOADED))
return 0;
- if (!err)
- opt->flags |= TC_RED_OFFLOADED;
-
- return err;
+ return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_RED,
+ &hw_stats);
}
static int red_dump(struct Qdisc *sch, struct sk_buff *skb)
@@ -319,7 +318,7 @@ static int red_dump(struct Qdisc *sch, struct sk_buff *skb)
int err;
sch->qstats.backlog = q->qdisc->qstats.backlog;
- err = red_dump_offload(sch, &opt);
+ err = red_dump_offload_stats(sch, &opt);
if (err)
goto nla_put_failure;
@@ -347,7 +346,7 @@ static int red_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
.marked = q->stats.prob_mark + q->stats.forced_mark,
};
- if (tc_can_offload(dev) && dev->netdev_ops->ndo_setup_tc) {
+ if (sch->flags & TCQ_F_OFFLOADED) {
struct red_stats hw_stats = {0};
struct tc_red_qopt_offload hw_stats_request = {
.command = TC_RED_XSTATS,
--
2.4.3
^ permalink raw reply related
* Re: [PATCH net 1/3] net: sched: Add TCA_HW_OFFLOAD
From: Jiri Pirko @ 2017-12-14 14:04 UTC (permalink / raw)
To: Yuval Mintz; +Cc: davem, netdev, mlxsw
In-Reply-To: <1513259671-1183-2-git-send-email-yuvalm@mellanox.com>
Thu, Dec 14, 2017 at 02:54:29PM CET, yuvalm@mellanox.com wrote:
>Qdiscs can be offloaded to HW, but current implementation isn't uniform.
>Instead, qdiscs either pass information about offload status via their
>TCA_OPTIONS or omit it altogether.
>
>Introduce a new attribute - TCA_HW_OFFLOAD that would form a uniform
>uAPI for the offloading status of qdiscs.
>
>Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net 2/3] net: sched: Move to new offload indication in RED
From: Jiri Pirko @ 2017-12-14 14:07 UTC (permalink / raw)
To: Yuval Mintz; +Cc: davem, netdev, mlxsw
In-Reply-To: <1513259671-1183-3-git-send-email-yuvalm@mellanox.com>
Thu, Dec 14, 2017 at 02:54:30PM CET, yuvalm@mellanox.com wrote:
>Let RED utilize the new internal flag, TCQ_F_OFFLOADED,
>to mark a given qdisc as offloaded instead of using a dedicated
>indication.
>
>Also, change internal logic into looking at said flag when possible.
>
>Fixes: 602f3baf2218 ("net_sch: red: Add offload ability to RED qdisc")
>Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Note that it would be good to add red offload presence in drivers
(mlxsw) and forbid to disable tc offload feature in that case.
^ permalink raw reply
* Re: [PATCH net 3/3] pkt_sched: Remove TC_RED_OFFLOADED from uapi
From: Jiri Pirko @ 2017-12-14 14:07 UTC (permalink / raw)
To: Yuval Mintz; +Cc: davem, netdev, mlxsw
In-Reply-To: <1513259671-1183-4-git-send-email-yuvalm@mellanox.com>
Thu, Dec 14, 2017 at 02:54:31PM CET, yuvalm@mellanox.com wrote:
>Following the previous patch, RED is now using the new uniform uapi
>for indicating it's offloaded. As a result, TC_RED_OFFLOADED is no
>longer utilized by kernel and can be removed [as it's still not
>part of any stable release].
>
>Fixes: 602f3baf2218 ("net_sch: red: Add offload ability to RED qdisc")
>Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH net-next] net: tap: fix POLLOUT condition in tap_poll()
From: yuan linyu @ 2017-12-14 14:22 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, yuan linyu
From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
from logical view, if sock_writeable(&q->sk) return false,
original second condition will return false too,
change it and make second condition can return true.
Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
---
drivers/net/tap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index 0a886fda..72212bf 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -587,8 +587,7 @@ static unsigned int tap_poll(struct file *file, poll_table *wait)
mask |= POLLIN | POLLRDNORM;
if (sock_writeable(&q->sk) ||
- (!test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags) &&
- sock_writeable(&q->sk)))
+ !test_and_set_bit(SOCKWQ_ASYNC_NOSPACE, &q->sock.flags))
mask |= POLLOUT | POLLWRNORM;
out:
--
2.7.4
^ permalink raw reply related
* Re: net-next libbpf broken on prev kernel release
From: Arnaldo Carvalho de Melo @ 2017-12-14 14:28 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Eric Leblond, Martin KaFai Lau, ast, netdev
In-Reply-To: <91dc11ff-0bf8-2db3-a933-27fb60869082@iogearbox.net>
Em Thu, Dec 14, 2017 at 10:52:19AM +0100, Daniel Borkmann escreveu:
> [ +acme, +ast ]
>
> On 12/14/2017 10:16 AM, Eric Leblond wrote:
> > Hello,
> >
> > It seems that the following patch did break libbpf (in net-next
> > version) which is not able to load anymore a program on a 4.14:
> >
> > tree 5096ddd73981e33a2164606461a45b56a189889c
> > parent ad5b177bd73f5107d97c36f56395c4281fb6f089
> > author Martin KaFai Lau <kafai@fb.com> Wed Sep 27 14:37:54 2017 -0700
> > committer David S. Miller <davem@davemloft.net> Fri Sep 29 06:17:05 2017 +0100
> >
> > bpf: libbpf: Provide basic API support to specify BPF obj name
> >
> > The problem comes from
> >
> > -int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
> > - size_t insns_cnt, const char *license,
> > - __u32 kern_version, char *log_buf, size_t log_buf_sz)
> > +int bpf_load_program_name(enum bpf_prog_type type, const char *name,
> > + const struct bpf_insn *insns,
> > + size_t insns_cnt, const char *license,
> > + __u32 kern_version, char *log_buf,
> > + size_t log_buf_sz)
> > {
> > int fd;
> > union bpf_attr attr;
> > + __u32 name_len = name ? strlen(name) : 0;
> >
> > bzero(&attr, sizeof(attr));
> > attr.prog_type = type;
> > @@ -130,6 +151,7 @@ int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
> > attr.log_size = 0;
> > attr.log_level = 0;
> > attr.kern_version = kern_version;
> > + memcpy(attr.prog_name, name, min(name_len, BPF_OBJ_NAME_LEN - 1));
> >
> > If I comment the memcpy then the eBPF program is loading correctly.
> >
> > Is this a wanted behavior to have libbpf that needs to be in sync with
> > kernel ? or should it be fixed ?
> Yeah, this was reported recently here: https://lkml.org/lkml/2017/11/28/1246
> I agree that given the policy of perf tool is to try to use new features
> but if they fail on older kernels, then we should try to fallback whenever
> that is feasible. I think for this specific case, we should in-fact fallback
> and try w/o map/prog name in order to fix this regression for perf (or
> other lib users).
> Also agree that this cannot be done for every possible case like the mentioned
> prog_ifindex field for offloading to NIC in the thread above, but I imho
> the prog_ifindex is a slightly different situation given that a user needs
> to specifically ask to offload via some provided API.
> I think the fix should be: if a user *specifically* calls bpf_load_program_name()
> or bpf_create_map_name() API from the lib, then the intention is very clear
> that the bpf object should be created *with* name and otherwise fail. So a
> fallback for these APIs to load w/o name would be inappropriate! But for the
> existing code that used to load objects before, e.g. bpf_object__create_maps()
> or bpf_program__load() it should try to use either mentioned bpf_*_name() APIs
> and *iff* they fail, fall-back to the normal ones w/o name attribute. Meaning,
> this kind of fall-back should be done, but not on a sys_bpf() layer but from
> a higher PoV in the lib instead. I guess it would make sense to probe the
> underlying kernel at startup and then based on its capabilities use one out
> of the two APIs when we get there, such that we don't need to uselessly retry
> APIs for each prog load.
tools/perf/ has:
static struct {
bool sample_id_all;
bool exclude_guest;
bool mmap2;
bool cloexec;
bool clockid;
bool clockid_wrong;
bool lbr_flags;
bool write_backward;
bool group_read;
} perf_missing_features;
When the user request something that needs some of these features we try
using it, failing it will mark it as missing and then other events will
not needlessly try using it, i.e. we don't do it at program start, we
leave that to when we actually need it, to avoid uselessly probing at
startup.
> Arnaldo, will there be a rework of your fix that we could route to bpf tree?
I'm resuming work on it after I get my current batch tested and
submitted, will reboot with an older kernel and follow your suggestions,
that seems to match Alexei's and Martin's, my patch was just a RFC to
show that we need a fallback for older kernels.
I needed to move on, so I updated my machine to a kernel where interlock
of tools/ with the kernel happens and it worked, so I left this to see
if someone else complained or if I was being too picky. :-)
- Arnaldo
^ permalink raw reply
* Re: [PATCH] Fix handling of verdicts after NF_QUEUE
From: Pablo Neira Ayuso @ 2017-12-14 12:30 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Debabrata Banerjee, David S . Miller, netfilter-devel, coreteam,
netdev, stable
In-Reply-To: <20171213203337.314-1-dbanerje@akamai.com>
Hi Greg,
I'd appreciate if you can take this patch into 4.9-stable. There is no
similar patch in tree, so this is not a backport.
On Wed, Dec 13, 2017 at 03:33:37PM -0500, Debabrata Banerjee wrote:
> A verdict of NF_STOLEN after NF_QUEUE will cause an incorrect return value
> and a potential kernel panic via double free of skb's
>
> This was broken by commit 7034b566a4e7 ("netfilter: fix nf_queue handling")
> and subsequently fixed in v4.10 by commit c63cbc460419 ("netfilter:
> use switch() to handle verdict cases from nf_hook_slow()"). However that
> commit cannot be cleanly cherry-picked to v4.9
>
> Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Thanks a lot!
> ---
>
> This fix is only needed for v4.9 stable since v4.10+ does not have the
> issue
> ---
> net/netfilter/core.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/netfilter/core.c b/net/netfilter/core.c
> index 004af030ef1a..d869ea50623e 100644
> --- a/net/netfilter/core.c
> +++ b/net/netfilter/core.c
> @@ -364,6 +364,11 @@ int nf_hook_slow(struct sk_buff *skb, struct nf_hook_state *state)
> ret = nf_queue(skb, state, &entry, verdict);
> if (ret == 1 && entry)
> goto next_hook;
> + } else {
> + /* Implicit handling for NF_STOLEN, as well as any other
> + * non conventional verdicts.
> + */
> + ret = 0;
> }
> return ret;
> }
> --
> 2.15.1
>
^ permalink raw reply
* Re: [PATCH v2] ARM64: dts: meson-axg: add ethernet mac controller
From: Jerome Brunet @ 2017-12-14 14:52 UTC (permalink / raw)
To: Yixun Lan, devicetree-u79uwXL29TY76Z2rM5mHXA, Kevin Hilman
Cc: Neil Armstrong, Giuseppe Cavallaro, Alexandre Torgue,
Carlo Caione, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171214030242.113152-1-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On Thu, 2017-12-14 at 11:02 +0800, Yixun Lan wrote:
> Add DT info for the stmmac ethernet MAC which found in
> the Amlogic's Meson-AXG SoC, also describe the ethernet
> pinctrl & clock information here.
>
> This is tested in the S400 dev board which use a RTL8211F PHY,
> and the pins connect to the 'eth_rgmii_y_pins' group.
>
> Reviewed-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
I think it would have been better to split this into 2 patches.
One adding the controller for axg, the other using it in the s400, but maybe
Kevin is OK with it...
>
> ---
> Changes in v2 since [1]:
> - rebase to kevin's v4.16/dt64 branch
> - add Neil's Reviewed-by
> - move clock info to board.dts instead of in soc.dtsi
> - drop "meson-axg-dwmac" compatible string, since we didn't use this
> we could re-add it later when we really need.
> - note: to make ethernet work properly,it depend on clock & pinctrl[2],
> to compile the DTS, the patch [3] is required.
> the code part will be taken via clock & pinctrl subsystem tree.
>
> [1]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html
>
> [2]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html
>
> [3]
> http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html
> ---
> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 11 ++++++
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 50 ++++++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 70eca1f8736a..138de3bc7cc8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> @@ -20,3 +20,14 @@
> &uart_AO {
> status = "okay";
> };
> +
> +ðmac {
We try to keep nodes alphabetically ordered.
Please put ethmac before uart_A0
thx
>
>
With all the dependencies sorted out, it works
Tested-by: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [PATCH 1/2] ip_gre: fix potential memory leak in erspan_rcv
From: Haishuang Yan @ 2017-12-14 15:15 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan, William Tu
If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak.
Fixes: 84e54fe0a5ea ("gre: introduce native tunnel support for ERSPAN")
Cc: William Tu <u9012063@gmail.com>
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv4/ip_gre.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index d828821..9253d6f 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -304,8 +304,10 @@ static int erspan_rcv(struct sk_buff *skb, struct tnl_ptk_info *tpi,
return PACKET_REJECT;
md = ip_tunnel_info_opts(&tun_dst->u.tun_info);
- if (!md)
+ if (!md) {
+ dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+ }
md->index = index;
info = &tun_dst->u.tun_info;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] ip6_gre: fix potential memory leak in ip6erspan_rcv
From: Haishuang Yan @ 2017-12-14 15:15 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan, William Tu
In-Reply-To: <1513264507-26199-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
If md is NULL, tun_dst must be freed, otherwise it will cause memory
leak
Fixes: 5a963eb61b7c ("ip6_gre: Add ERSPAN native tunnel support")
Cc: William Tu <u9012063@gmail.com>
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv6/ip6_gre.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 4562579..b8b0e4b 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -542,8 +542,10 @@ static int ip6erspan_rcv(struct sk_buff *skb, int gre_hdr_len,
info = &tun_dst->u.tun_info;
md = ip_tunnel_info_opts(info);
- if (!md)
+ if (!md) {
+ dst_release((struct dst_entry *)tun_dst);
return PACKET_REJECT;
+ }
md->index = index;
info->key.tun_flags |= TUNNEL_ERSPAN_OPT;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v3] ip6_vti: adjust vti mtu according to mtu of output device
From: Alexey Kodanev @ 2017-12-14 15:37 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, David Miller, Petr Vorel, Shannon Nelson,
Alexey Kodanev
LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams that
require fragmentation and the underlying device has MTU <= 1500. This
happens because ip6_vti sets mtu to ETH_DATA_LEN and not updating it
depending on a destination address or link parameter.
Further attempts to send UDP packets may succeed because pmtu gets
updated on ICMPV6_PKT_TOOBIG in vti6_err().
Here is the example when the output device MTU is set to 9000:
# ip a sh ltp_ns_veth2
ltp_ns_veth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ...
inet 10.0.0.2/24 scope global ltp_ns_veth2
inet6 fd00::2/64 scope global
# ip li add vti6 type vti6 local fd00::2 remote fd00::1
# ip li show vti6
vti6@NONE: <POINTOPOINT,NOARP> mtu 1500 ...
link/tunnel6 fd00::2 peer fd00::1
After the patch:
# ip li add vti6 type vti6 local fd00::2 remote fd00::1
# ip li show vti6
vti6@NONE: <POINTOPOINT,NOARP> mtu 8832 ...
link/tunnel6 fd00::2 peer fd00::1
Regarding ip_vti, it already tunes MTU with ip_tunnel_bind_dev().
Reported-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
---
v3: * fix style issue with curly braces around single-statement if block
v2: * cleanup commit message issues (thanks to Shannon)
* handle the case when we don't have route but have device parameter
* cast new MTU to int and then check the maximum (tdev->mtu can be
less than dev->hard_header_len)
net/ipv6/ip6_vti.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index dbb74f3..5404443 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -626,6 +626,7 @@ static void vti6_link_config(struct ip6_tnl *t)
{
struct net_device *dev = t->dev;
struct __ip6_tnl_parm *p = &t->parms;
+ struct net_device *tdev = NULL;
memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr));
memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr));
@@ -638,6 +639,26 @@ static void vti6_link_config(struct ip6_tnl *t)
dev->flags |= IFF_POINTOPOINT;
else
dev->flags &= ~IFF_POINTOPOINT;
+
+ if (p->flags & IP6_TNL_F_CAP_XMIT) {
+ int strict = (ipv6_addr_type(&p->raddr) &
+ (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL));
+
+ struct rt6_info *rt = rt6_lookup(t->net,
+ &p->raddr, &p->laddr,
+ p->link, strict);
+
+ if (rt)
+ tdev = rt->dst.dev;
+ ip6_rt_put(rt);
+ }
+
+ if (!tdev && p->link)
+ tdev = __dev_get_by_index(t->net, p->link);
+
+ if (tdev)
+ dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len,
+ IPV6_MIN_MTU);
}
/**
--
1.7.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