* Re: [PATCH net-next v2 05/10] drivers: base: Add device_find_class()
From: David Miller @ 2017-01-12 21:21 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, jason, andrew, sebastian.hesselbarth, gregory.clement,
linux, vivien.didelot, linux-arm-kernel, linux-kernel, gregkh
In-Reply-To: <20170112034121.27697-6-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 11 Jan 2017 19:41:16 -0800
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/base/core.c | 19 +++++++++++++++++++
> include/linux/device.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 020ea7f05520..3dd6047c10d8 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2065,6 +2065,25 @@ struct device *device_find_child(struct device *parent, void *data,
> }
> EXPORT_SYMBOL_GPL(device_find_child);
>
> +static int dev_is_class(struct device *dev, void *class)
I know you are just moving code, but this class argumnet is a string
and thus should be "char *" or even "const char *".
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-12 21:18 UTC (permalink / raw)
To: shannon.nelson
Cc: eric.dumazet, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <131ec7b7-5b74-2545-8bf7-92812443a876@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 12 Jan 2017 12:56:08 -0800
>
>
> On 1/12/2017 12:41 PM, David Miller wrote:
>> From: Shannon Nelson <shannon.nelson@oracle.com>
>> Date: Thu, 12 Jan 2017 12:30:38 -0800
>>
>>> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
>>>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>>>>
>>>>>
>>>>> I suspect that someplace, somebody is casting val to an int * or
>>>>> something like that.
>>>>
>>>> Then that would be the bug. Can we root cause this please ?
>>>>
>>>>
>>>
>>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>>>
>>> struct in6_addr *buf = (struct in6_addr *) tmp.val;
>>
>> Oh yeah, that's it. I didn't notice that at all.
>>
>
> It looked to me like swapping the data fields would be the easiest and
> least impactive way to fix this. I didn't want to mess with the
> logic. I'm certainly open to other suggestions.
Given the nature of the problem, your fix is probably fine.
Eric, any objections?
^ permalink raw reply
* Re: [iproute PATCH] tc: m_xt: Fix segfault with iptables-1.6.0
From: Phil Sutter @ 2017-01-12 21:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170112113449.581e2219@xeon-e3>
On Thu, Jan 12, 2017 at 11:34:49AM -0800, Stephen Hemminger wrote:
> On Thu, 12 Jan 2017 15:22:49 +0100
> Phil Sutter <phil@nwl.cc> wrote:
>
> > Said iptables version introduced struct xtables_globals field
> > 'compat_rev', a function pointer. Initializing it is mandatory as
> > libxtables calls it without existence check.
> >
> > Without this, tc segfaults when using the xt action like so:
> >
> > | tc filter add dev d0 parent ffff: u32 match u32 0 0 \
> > | action xt -j MARK --set-mark 20
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> > tc/m_xt.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/tc/m_xt.c b/tc/m_xt.c
> > index dbb54981462ee..57ed40d7aa3a8 100644
> > --- a/tc/m_xt.c
> > +++ b/tc/m_xt.c
> > @@ -77,6 +77,9 @@ static struct xtables_globals tcipt_globals = {
> > .orig_opts = original_opts,
> > .opts = original_opts,
> > .exit_err = NULL,
> > +#if (XTABLES_VERSION_CODE >= 11)
> > + .compat_rev = xtables_compatible_revision,
> > +#endif
> > };
> >
> > /*
>
> Ah the xtables API is not really an application friendly API by
> any stretch of the imagination
Yeah, this could have really been handled by the lib, especially since
it provides the callback to assign to it. But whatever, looking at the
git log shows it's not happening for the first time so at least it's
consistent. :)
> Parenthesis not really necessary there.
Oh, indeed! I just stuck to how the other XTABLES_VERSION_CODE checks
are made. Are you going to apply this patch either way? I'll then
follow-up dropping the parentheses at all places at once.
Thanks, Phil
^ permalink raw reply
* Re: [PATCH 2/6 net-next] inet: drop ->bind_conflict
From: Josef Bacik @ 2017-01-12 21:04 UTC (permalink / raw)
To: David Miller; +Cc: hannes, kraigatgoog, eric.dumazet, tom, netdev, kernel-team
In-Reply-To: <20170112.145640.2151487482259137455.davem@davemloft.net>
On Thu, Jan 12, 2017 at 2:56 PM, David Miller <davem@davemloft.net>
wrote:
> From: Josef Bacik <jbacik@fb.com>
> Date: Wed, 11 Jan 2017 15:22:40 -0500
>
>> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
>> index 56d756e..dc07734 100644
>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -63,6 +63,7 @@
>> #include <linux/times.h>
>> #include <linux/slab.h>
>>
>> +#include <net/addrconf.h>
>> #include <net/net_namespace.h>
>> #include <net/icmp.h>
>> #include <net/inet_hashtables.h>
>
> I don't see what this has to do with this change.
Ugh sorry, that's a left over from when I had the protocol specific
callback for the saddr_equal stuff, I'll fix that up. Thanks,
Josef
^ permalink raw reply
* [PATCH net] net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
From: Florian Fainelli @ 2017-01-12 20:09 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli
The __bcm_sysport_tx_reclaim() function is used to reclaim transmit
resources in different places within the driver. Most of them should
not affect the state of the transit flow control.
Introduce bcm_sysport_tx_clean() which cleans the ring, but does not
re-enable flow control towards the networking stack, and make
bcm_sysport_tx_reclaim() do the actual transmit queue flow control.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 7e8cf213fd81..744ed6ddaf37 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -710,11 +710,8 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
unsigned int pkts_compl = 0, bytes_compl = 0;
struct bcm_sysport_cb *cb;
- struct netdev_queue *txq;
u32 hw_ind;
- txq = netdev_get_tx_queue(ndev, ring->index);
-
/* Compute how many descriptors have been processed since last call */
hw_ind = tdma_readl(priv, TDMA_DESC_RING_PROD_CONS_INDEX(ring->index));
c_index = (hw_ind >> RING_CONS_INDEX_SHIFT) & RING_CONS_INDEX_MASK;
@@ -745,9 +742,6 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
ring->c_index = c_index;
- if (netif_tx_queue_stopped(txq) && pkts_compl)
- netif_tx_wake_queue(txq);
-
netif_dbg(priv, tx_done, ndev,
"ring=%d c_index=%d pkts_compl=%d, bytes_compl=%d\n",
ring->index, ring->c_index, pkts_compl, bytes_compl);
@@ -759,16 +753,33 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
static unsigned int bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
struct bcm_sysport_tx_ring *ring)
{
+ struct netdev_queue *txq;
unsigned int released;
unsigned long flags;
+ txq = netdev_get_tx_queue(priv->netdev, ring->index);
+
spin_lock_irqsave(&ring->lock, flags);
released = __bcm_sysport_tx_reclaim(priv, ring);
+ if (released)
+ netif_tx_wake_queue(txq);
+
spin_unlock_irqrestore(&ring->lock, flags);
return released;
}
+/* Locked version of the per-ring TX reclaim, but does not wake the queue */
+static void bcm_sysport_tx_clean(struct bcm_sysport_priv *priv,
+ struct bcm_sysport_tx_ring *ring)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&ring->lock, flags);
+ __bcm_sysport_tx_reclaim(priv, ring);
+ spin_unlock_irqrestore(&ring->lock, flags);
+}
+
static int bcm_sysport_tx_poll(struct napi_struct *napi, int budget)
{
struct bcm_sysport_tx_ring *ring =
@@ -1252,7 +1263,7 @@ static void bcm_sysport_fini_tx_ring(struct bcm_sysport_priv *priv,
napi_disable(&ring->napi);
netif_napi_del(&ring->napi);
- bcm_sysport_tx_reclaim(priv, ring);
+ bcm_sysport_tx_clean(priv, ring);
kfree(ring->cbs);
ring->cbs = NULL;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next] liquidio VF: reduce load time of module
From: David Miller @ 2017-01-12 20:53 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20170112014027.GA9704@felix.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 11 Jan 2017 17:40:27 -0800
> From: Prasad Kanneganti <prasad.kanneganti@cavium.com>
>
> Reduce the load time of the VF driver by decreasing the wait time between
> iterations of the loop that polls for a mailbox response from the PF. Also
> change the wait time units from jiffies to milliseconds.
>
> Signed-off-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] secure_seq: fix sparse errors
From: David Miller @ 2017-01-12 20:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, Jason
In-Reply-To: <1484187037.15816.21.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 11 Jan 2017 18:10:37 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Fixes following warnings :
>
> net/core/secure_seq.c:125:28: warning: incorrect type in argument 1
> (different base types)
> net/core/secure_seq.c:125:28: expected unsigned int const [unsigned]
> [usertype] a
> net/core/secure_seq.c:125:28: got restricted __be32 [usertype] saddr
> net/core/secure_seq.c:125:35: warning: incorrect type in argument 2
> (different base types)
> net/core/secure_seq.c:125:35: expected unsigned int const [unsigned]
> [usertype] b
> net/core/secure_seq.c:125:35: got restricted __be32 [usertype] daddr
> net/core/secure_seq.c:125:43: warning: cast from restricted __be16
> net/core/secure_seq.c:125:61: warning: restricted __be16 degrades to
> integer
>
>
> Fixes: 7cd23e5300c1 ("secure_seq: use SipHash in place of MD5")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Shannon Nelson @ 2017-01-12 20:56 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <20170112.154143.1940764507974590907.davem@davemloft.net>
On 1/12/2017 12:41 PM, David Miller wrote:
> From: Shannon Nelson <shannon.nelson@oracle.com>
> Date: Thu, 12 Jan 2017 12:30:38 -0800
>
>> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
>>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>>>
>>>>
>>>> I suspect that someplace, somebody is casting val to an int * or
>>>> something like that.
>>>
>>> Then that would be the bug. Can we root cause this please ?
>>>
>>>
>>
>> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>>
>> struct in6_addr *buf = (struct in6_addr *) tmp.val;
>
> Oh yeah, that's it. I didn't notice that at all.
>
It looked to me like swapping the data fields would be the easiest and
least impactive way to fix this. I didn't want to mess with the logic.
I'm certainly open to other suggestions.
sln
^ permalink raw reply
* Re: [PATCH] [net] net/mlx5e: fix another -Wmaybe-uninitialized warning
From: Or Gerlitz @ 2017-01-12 20:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Or Gerlitz, Saeed Mahameed, Hadar Hen Zion, David S . Miller,
Linux Netdev List, Linux Kernel
In-Reply-To: <2981112.7jTLlX72ae@wuerfel>
On Thu, Jan 12, 2017 at 6:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, January 12, 2017 5:21:49 PM CET Or Gerlitz wrote:
>> When I build here without CONFIG_INET in my system, the build goes fine
>> with this approach. However, we're pretty sure that in the past we got
>> 0-day report from the kbuild test robot where he was unhappy that we
>> make the ip_route_output_key call without being wrapped with that #if
>> IS_ENABLED(CONFIG_INET) -- so, we don't want to go there again... thoughts?
> I went back and forth between the two versions, either leaving the #if
> in place, or using the if(IS_ENABLED()) check to be really sure that
> we can't get compile error here.
> I did check that ip_route_output_key() is always declared, but now
> I see that net/route.h might not always be included from en_tc.c
> if CONFIG_INET is disabled (I don't see how it gets included, but
> it obviously is when CONFIG_INET is turned on).
> Adding an explicit include of that file should probably avoid the
> case you ran into earlier, but for I agree it's safer to not rely
> on that here for a bugfix, and just leave the #ifdef. Do you want to
> modify it yourself, or should I spin a new version with that?
I can do that next week, thanks
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-12 20:41 UTC (permalink / raw)
To: shannon.nelson
Cc: eric.dumazet, rob.gardner, netdev, sparclinux, linux-kernel
In-Reply-To: <1c39bf41-4ebf-643a-c6a0-caf98a17a89c@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu, 12 Jan 2017 12:30:38 -0800
> On 1/12/2017 12:25 PM, Eric Dumazet wrote:
>> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>>
>>>
>>> I suspect that someplace, somebody is casting val to an int * or
>>> something like that.
>>
>> Then that would be the bug. Can we root cause this please ?
>>
>>
>
> Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
>
> struct in6_addr *buf = (struct in6_addr *) tmp.val;
Oh yeah, that's it. I didn't notice that at all.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: David Miller @ 2017-01-12 20:39 UTC (permalink / raw)
To: eric.dumazet
Cc: rob.gardner, shannon.nelson, netdev, sparclinux, linux-kernel
In-Reply-To: <1484252733.13165.1.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 12 Jan 2017 12:25:33 -0800
> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>
>>
>> I suspect that someplace, somebody is casting val to an int * or
>> something like that.
>
> Then that would be the bug. Can we root cause this please ?
The three accesses to foc->val are via function calls, at least when I
try to build it, one via memcmp(), one via memcpy() (for the structure
assignment at the end of the function) and one via a call into the
crypto layer when we do tcp_fastopen_cookie_gen).
So if the PC is inside of tcp_try_fastopen() it has to be something
else, or something specific to your gcc and build.
^ permalink raw reply
* Re: [iproute PATCH] tc: m_xt: Fix segfault with iptables-1.6.0
From: Stephen Hemminger @ 2017-01-12 19:34 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20170112142249.13041-1-phil@nwl.cc>
On Thu, 12 Jan 2017 15:22:49 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Said iptables version introduced struct xtables_globals field
> 'compat_rev', a function pointer. Initializing it is mandatory as
> libxtables calls it without existence check.
>
> Without this, tc segfaults when using the xt action like so:
>
> | tc filter add dev d0 parent ffff: u32 match u32 0 0 \
> | action xt -j MARK --set-mark 20
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> tc/m_xt.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tc/m_xt.c b/tc/m_xt.c
> index dbb54981462ee..57ed40d7aa3a8 100644
> --- a/tc/m_xt.c
> +++ b/tc/m_xt.c
> @@ -77,6 +77,9 @@ static struct xtables_globals tcipt_globals = {
> .orig_opts = original_opts,
> .opts = original_opts,
> .exit_err = NULL,
> +#if (XTABLES_VERSION_CODE >= 11)
> + .compat_rev = xtables_compatible_revision,
> +#endif
> };
>
> /*
Ah the xtables API is not really an application friendly API by
any stretch of the imagination
Parenthesis not really necessary there.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Shannon Nelson @ 2017-01-12 20:30 UTC (permalink / raw)
To: Eric Dumazet, Rob Gardner; +Cc: netdev, davem, sparclinux, linux-kernel
In-Reply-To: <1484252733.13165.1.camel@edumazet-glaptop3.roam.corp.google.com>
On 1/12/2017 12:25 PM, Eric Dumazet wrote:
> On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>
>>
>> I suspect that someplace, somebody is casting val to an int * or
>> something like that.
>
> Then that would be the bug. Can we root cause this please ?
>
>
Look in net/ipv4/tcp_fastopen.c:tcp_fastopen_cookie_gen() for the line
struct in6_addr *buf = (struct in6_addr *) tmp.val;
sln
^ permalink raw reply
* [PATCH net v3] ipv6: sr: fix several BUGs when preemption is enabled
From: David Lebrun @ 2017-01-12 20:30 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
seg6_hmac_init() is called during the initialization of the ipv6 module.
This causes a subsequent call to smp_processor_id() with preemption
enabled, resulting in the following trace.
[ 20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
[ 20.452556] caller is debug_smp_processor_id+0x17/0x19
[ 20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
[ 20.454406] ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
[ 20.455528] ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
[ 20.456539] ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
[ 20.456539] Call Trace:
[ 20.456539] [<ffffffff813607b2>] dump_stack+0x63/0x7f
[ 20.456539] [<ffffffff813778dc>] check_preemption_disabled+0xd1/0xe3
[ 20.456539] [<ffffffff81377905>] debug_smp_processor_id+0x17/0x19
[ 20.460260] [<ffffffffa0061f3b>] seg6_hmac_init+0xfa/0x192 [ipv6]
[ 20.460260] [<ffffffffa0061ccc>] seg6_init+0x39/0x6f [ipv6]
[ 20.460260] [<ffffffffa006121a>] inet6_init+0x21a/0x321 [ipv6]
[ 20.460260] [<ffffffffa0061000>] ? 0xffffffffa0061000
[ 20.460260] [<ffffffff81000457>] do_one_initcall+0x8b/0x115
[ 20.460260] [<ffffffff811328a3>] do_init_module+0x53/0x1c4
[ 20.460260] [<ffffffff8110650a>] load_module+0x1153/0x14ec
[ 20.460260] [<ffffffff81106a7b>] SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106a7b>] ? SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106abc>] SyS_finit_module+0x9/0xb
[ 20.460260] [<ffffffff810014d1>] do_syscall_64+0x62/0x75
[ 20.460260] [<ffffffff816834f0>] entry_SYSCALL64_slow_path+0x25/0x25
Moreover, dst_cache_* functions also call smp_processor_id(), generating
a similar trace.
This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
and disable preemption when using dst_cache_* functions.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6_hmac.c | 2 +-
net/ipv6/seg6_iptunnel.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index ef1c8a4..03a0648 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -400,7 +400,7 @@ static int seg6_hmac_init_algo(void)
*p_tfm = tfm;
}
- p_tfm = this_cpu_ptr(algo->tfms);
+ p_tfm = raw_cpu_ptr(algo->tfms);
tfm = *p_tfm;
shsize = sizeof(*shash) + crypto_shash_descsize(tfm);
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index bbfca22..1d60cb1 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -265,7 +265,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
slwt = seg6_lwt_lwtunnel(orig_dst->lwtstate);
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst = dst_cache_get(&slwt->cache);
+ preempt_enable();
#endif
if (unlikely(!dst)) {
@@ -286,7 +288,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
}
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst_cache_set_ip6(&slwt->cache, dst, &fl6.saddr);
+ preempt_enable();
#endif
}
--
2.7.3
^ permalink raw reply related
* Re: [Patch] Fixing order of trinary operator when assigning the ifindex in XFRM Decode Session
From: David Ahern @ 2017-01-12 20:28 UTC (permalink / raw)
To: Chacon, Carlos A, netdev@vger.kernel.org; +Cc: steffen.klassert@secunet.com
In-Reply-To: <BY1PR0701MB12228231F8BCD74FC473284A9A790@BY1PR0701MB1222.namprd07.prod.outlook.com>
Hi Carlos:
patches sent to netdev should be plain text only. Using git send-email would be best.
Also, the Subject line should start with the area affected (e.g., net: xfrm:) and really should be a bit shorter. e.g., something like this:
[PATCH] net: xfrm: fix flow oif in decode_session
On 1/12/17 1:01 PM, Chacon, Carlos A wrote:
>
> Author: Carlos Chacon <carlos.chacon@gatech.edu>
> Date: Thu Jan 12 11:42:32 2017 -0800
>
> Fixing order of trinary operator when assigning the ifindex in XFRM Decode Session
>
> For xfrm4_policy.c:_decode_session4 and xfrm6_policy.c:_decode_session6 the line
> fl4->flowi4_oif = reverse ? skb->skb_iif : oif;
> fl6->flowi6_oif = reverse ? skb->skb_iif : oif;
> is assigning the incorrect oif to the flow_oif. It should read:
> reverse ? oif : skb->skb_iif;
> The "reverse" variable is defined in net/xfrm/xfrm_policy.c:__xfrm_policy_check
> when it checks if the dir is above the XFRM_POLICY_MASK if this returns false
> it reverses the ifindex, but it should only reverse if it returns true.
The above explanation suggests the reverse flag in __xfrm_policy_check should be fixed. Can you check that and maybe __xfrm_policy_check2 as well?
^ permalink raw reply
* Re: To netlink or not to netlink, that is the question
From: David Miller @ 2017-01-12 20:27 UTC (permalink / raw)
To: Jason; +Cc: dcbw, stephen, netdev
In-Reply-To: <CAHmME9oYtxL=sBpOquOjcqtQnYY=AFHC+OqMdeQD6X8HNoY4zw@mail.gmail.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Thu, 12 Jan 2017 21:07:43 +0100
> David - you concur with Stephen that ioctl is really not okay and I
> should absolutely do netlink?
Yes.
^ permalink raw reply
* Re: [PATCH net v2] ipv6: sr: fix several BUGs when preemption is enabled
From: David Lebrun @ 2017-01-12 20:28 UTC (permalink / raw)
To: netdev; +Cc: Vivien Didelot
In-Reply-To: <1484252809-29192-1-git-send-email-david.lebrun@uclouvain.be>
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
On 01/12/2017 09:26 PM, David Lebrun wrote:
> From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
No idea where does that come from, resending patch. Sorry about that Vivien.
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
^ permalink raw reply
* [PATCH net v2] ipv6: sr: fix several BUGs when preemption is enabled
From: David Lebrun @ 2017-01-12 20:26 UTC (permalink / raw)
To: netdev; +Cc: Vivien Didelot, David Lebrun
From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
seg6_hmac_init() is called during the initialization of the ipv6 module.
This causes a subsequent call to smp_processor_id() with preemption
enabled, resulting in the following trace.
[ 20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
[ 20.452556] caller is debug_smp_processor_id+0x17/0x19
[ 20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
[ 20.454406] ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
[ 20.455528] ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
[ 20.456539] ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
[ 20.456539] Call Trace:
[ 20.456539] [<ffffffff813607b2>] dump_stack+0x63/0x7f
[ 20.456539] [<ffffffff813778dc>] check_preemption_disabled+0xd1/0xe3
[ 20.456539] [<ffffffff81377905>] debug_smp_processor_id+0x17/0x19
[ 20.460260] [<ffffffffa0061f3b>] seg6_hmac_init+0xfa/0x192 [ipv6]
[ 20.460260] [<ffffffffa0061ccc>] seg6_init+0x39/0x6f [ipv6]
[ 20.460260] [<ffffffffa006121a>] inet6_init+0x21a/0x321 [ipv6]
[ 20.460260] [<ffffffffa0061000>] ? 0xffffffffa0061000
[ 20.460260] [<ffffffff81000457>] do_one_initcall+0x8b/0x115
[ 20.460260] [<ffffffff811328a3>] do_init_module+0x53/0x1c4
[ 20.460260] [<ffffffff8110650a>] load_module+0x1153/0x14ec
[ 20.460260] [<ffffffff81106a7b>] SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106a7b>] ? SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106abc>] SyS_finit_module+0x9/0xb
[ 20.460260] [<ffffffff810014d1>] do_syscall_64+0x62/0x75
[ 20.460260] [<ffffffff816834f0>] entry_SYSCALL64_slow_path+0x25/0x25
Moreover, dst_cache_* functions also call smp_processor_id(), generating
a similar trace.
This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
and disable preemption when using dst_cache_* functions.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
net/ipv6/seg6_hmac.c | 2 +-
net/ipv6/seg6_iptunnel.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index ef1c8a4..03a0648 100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -400,7 +400,7 @@ static int seg6_hmac_init_algo(void)
*p_tfm = tfm;
}
- p_tfm = this_cpu_ptr(algo->tfms);
+ p_tfm = raw_cpu_ptr(algo->tfms);
tfm = *p_tfm;
shsize = sizeof(*shash) + crypto_shash_descsize(tfm);
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index bbfca22..1d60cb1 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -265,7 +265,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
slwt = seg6_lwt_lwtunnel(orig_dst->lwtstate);
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst = dst_cache_get(&slwt->cache);
+ preempt_enable();
#endif
if (unlikely(!dst)) {
@@ -286,7 +288,9 @@ int seg6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
}
#ifdef CONFIG_DST_CACHE
+ preempt_disable();
dst_cache_set_ip6(&slwt->cache, dst, &fl6.saddr);
+ preempt_enable();
#endif
}
--
2.7.3
^ permalink raw reply related
* Re: [PATCH net-next] liquidio: remove unnecessary code
From: David Miller @ 2017-01-12 20:25 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20170112010902.GA9597@felix.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 11 Jan 2017 17:09:02 -0800
> Remove code that's no longer needed. It used to serve a purpose, which was
> to fix a link-related bug. For a while now, the NIC firmware has had a
> more elegant fix for that bug.
>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Eric Dumazet @ 2017-01-12 20:25 UTC (permalink / raw)
To: Rob Gardner; +Cc: Shannon Nelson, netdev, davem, sparclinux, linux-kernel
In-Reply-To: <cd152a9f-4855-a552-2b45-bd619436a628@oracle.com>
On Thu, 2017-01-12 at 13:15 -0700, Rob Gardner wrote:
>
> I suspect that someplace, somebody is casting val to an int * or
> something like that.
Then that would be the bug. Can we root cause this please ?
^ permalink raw reply
* Re: [PATCH] net: ipv4: fix table id in getroute response
From: David Miller @ 2017-01-12 20:18 UTC (permalink / raw)
To: dsa; +Cc: netdev
In-Reply-To: <1484178137-23735-1-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Wed, 11 Jan 2017 15:42:17 -0800
> rtm_table is an 8-bit field while table ids are allowed up to u32. Commit
> 709772e6e065 ("net: Fix routing tables with id > 255 for legacy software")
> added the preference to set rtm_table in dumps to RT_TABLE_COMPAT if the
> table id is > 255. The table id returned on get route requests should do
> the same.
>
> Fixes: c36ba6603a11 ("net: Allow user to get table id from route lookup")
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Good catch, applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH] xen-netfront: Fix Rx stall during network stress and OOM
From: David Miller @ 2017-01-12 20:17 UTC (permalink / raw)
To: vineethp
Cc: boris.ostrovsky, jgross, xen-devel, netdev, linux-kernel, kamatam,
aliguori
In-Reply-To: <1484176637-2869-1-git-send-email-vineethp@amazon.com>
From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Wed, 11 Jan 2017 23:17:17 +0000
> @@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int budget)
> napi_complete(napi);
>
> RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
> - if (more_to_do)
> +
> + /* If there is more work to do or could not allocate
> + * rx buffers, re-enable polling.
> + */
> + if (more_to_do || err != 0)
> napi_schedule(napi);
Just polling endlessly in a loop retrying the SKB allocation over and over
again until it succeeds is not very nice behavior.
You already have that refill timer, so please use that to retry instead
of wasting cpu cycles looping in NAPI poll.
Thanks.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_fastopen unaligned access complaints on sparc
From: Rob Gardner @ 2017-01-12 20:15 UTC (permalink / raw)
To: Eric Dumazet, Shannon Nelson; +Cc: netdev, davem, sparclinux, linux-kernel
In-Reply-To: <1484252011.13165.0.camel@edumazet-glaptop3.roam.corp.google.com>
On 01/12/2017 01:13 PM, Eric Dumazet wrote:
> On Thu, 2017-01-12 at 11:59 -0800, Shannon Nelson wrote:
>> Fix up a data alignment issue on sparc by swapping the order
>> of the cookie byte array field with the length field in
>> struct tcp_fastopen_cookie
>>
>> This addresses log complaints like these:
>> log_unaligned: 113 callbacks suppressed
>> Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
>> Kernel unaligned access at TPC[9764ac] tcp_try_fastopen+0x2ec/0x360
>> Kernel unaligned access at TPC[9764c8] tcp_try_fastopen+0x308/0x360
>> Kernel unaligned access at TPC[9764e4] tcp_try_fastopen+0x324/0x360
>> Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
>>
>> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
>> ---
>> include/linux/tcp.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
>> index fc5848d..95cda75 100644
>> --- a/include/linux/tcp.h
>> +++ b/include/linux/tcp.h
>> @@ -62,8 +62,8 @@ static inline unsigned int tcp_optlen(const struct sk_buff *skb)
>>
>> /* TCP Fast Open Cookie as stored in memory */
>> struct tcp_fastopen_cookie {
>> - s8 len;
>> u8 val[TCP_FASTOPEN_COOKIE_MAX];
>> + s8 len;
>> bool exp; /* In RFC6994 experimental option format */
>> };
>>
> Strange... Do you have an explanation of why this patch would be
> needed ? A compiler issue ?
>
>
> s8 and u8 are bytes after all.
>
>
I suspect that someplace, somebody is casting val to an int * or
something like that.
^ permalink raw reply
* Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
From: Boris Ostrovsky @ 2017-01-12 20:14 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: Vlastimil Babka, David Rientjes, Mel Gorman, Johannes Weiner,
Al Viro, linux-mm, LKML, Michal Hocko, Martin Schwidefsky,
Heiko Carstens, Herbert Xu, Anton Vorontsov, Colin Cross,
Kees Cook, Tony Luck, Rafael J. Wysocki, Ben Skeggs,
Kent Overstreet, Santosh Raspatur, Hariprasad S, Tariq Toukan,
Yishai
In-Reply-To: <20170112153717.28943-6-mhocko@kernel.org>
> diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
> index 6890897a6f30..10f1ef582659 100644
> --- a/drivers/xen/evtchn.c
> +++ b/drivers/xen/evtchn.c
> @@ -87,18 +87,6 @@ struct user_evtchn {
> bool enabled;
> };
>
> -static evtchn_port_t *evtchn_alloc_ring(unsigned int size)
> -{
> - evtchn_port_t *ring;
> - size_t s = size * sizeof(*ring);
> -
> - ring = kmalloc(s, GFP_KERNEL);
> - if (!ring)
> - ring = vmalloc(s);
> -
> - return ring;
> -}
> -
> static void evtchn_free_ring(evtchn_port_t *ring)
> {
> kvfree(ring);
> @@ -334,7 +322,7 @@ static int evtchn_resize_ring(struct per_user_data *u)
> else
> new_size = 2 * u->ring_size;
>
> - new_ring = evtchn_alloc_ring(new_size);
> + new_ring = kvmalloc(new_size * sizeof(*new_ring), GFP_KERNEL);
> if (!new_ring)
> return -ENOMEM;
>
Xen bits:
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] [v2] net: qcom/emac: grab a reference to the phydev on ACPI systems
From: David Miller @ 2017-01-12 20:14 UTC (permalink / raw)
To: timur; +Cc: netdev, johan
In-Reply-To: <1484174751-19036-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 11 Jan 2017 16:45:51 -0600
> Commit 6ffe1c4cd0a7 ("net: qcom/emac: fix of_node and phydev leaks")
> fixed the problem with reference leaks on phydev, but the fix is
> device-tree specific. When the driver unloads, the reference is
> dropped only on DT systems.
>
> Instead, it's cleaner if up grab an reference on ACPI systems.
> When the driver unloads, we can drop the reference without having
> to check whether we're on a DT system.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
Applied.
^ permalink raw reply
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