* [PATCH] rsi: fix indentation issue with a code block
From: Colin King @ 2019-02-07 12:11 UTC (permalink / raw)
To: Amitkumar Karwar, Siva Rebbagondla, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a block of code that is indented at the wrong level. Fix this
with extra tabbing.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index aded1ae4fad5..747d96e14bcd 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -810,15 +810,15 @@ static void rsi_mac80211_bss_info_changed(struct ieee80211_hw *hw,
adapter->ps_info.dtim_interval_duration = bss->dtim_period;
adapter->ps_info.listen_interval = conf->listen_interval;
- /* If U-APSD is updated, send ps parameters to firmware */
- if (bss->assoc) {
- if (common->uapsd_bitmap) {
- rsi_dbg(INFO_ZONE, "Configuring UAPSD\n");
- rsi_conf_uapsd(adapter, vif);
+ /* If U-APSD is updated, send ps parameters to firmware */
+ if (bss->assoc) {
+ if (common->uapsd_bitmap) {
+ rsi_dbg(INFO_ZONE, "Configuring UAPSD\n");
+ rsi_conf_uapsd(adapter, vif);
+ }
+ } else {
+ common->uapsd_bitmap = 0;
}
- } else {
- common->uapsd_bitmap = 0;
- }
}
if (changed & BSS_CHANGED_CQM) {
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] net: vxlan: Free a leaked vetoed multicast rdst
From: Petr Machata @ 2019-02-07 12:18 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: davem@davemloft.net, Jiri Pirko
When an rdst is rejected by a driver, the current code removes it from
the remote list, but neglects to free it. This is triggered by
tools/testing/selftests/drivers/net/mlxsw/vxlan_fdb_veto.sh and shows as
the following kmemleak trace:
unreferenced object 0xffff88817fa3d888 (size 96):
comm "softirq", pid 0, jiffies 4372702718 (age 165.252s)
hex dump (first 32 bytes):
02 00 00 00 c6 33 64 03 80 f5 a2 61 81 88 ff ff .....3d....a....
06 df 71 ae ff ff ff ff 0c 00 00 00 04 d2 6a 6b ..q...........jk
backtrace:
[<00000000296b27ac>] kmem_cache_alloc_trace+0x1ae/0x370
[<0000000075c86dc6>] vxlan_fdb_append.part.12+0x62/0x3b0 [vxlan]
[<00000000e0414b63>] vxlan_fdb_update+0xc61/0x1020 [vxlan]
[<00000000f330c4bd>] vxlan_fdb_add+0x2e8/0x3d0 [vxlan]
[<0000000008f81c2c>] rtnl_fdb_add+0x4c2/0xa10
[<00000000bdc4b270>] rtnetlink_rcv_msg+0x6dd/0x970
[<000000006701f2ce>] netlink_rcv_skb+0x290/0x410
[<00000000c08a5487>] rtnetlink_rcv+0x15/0x20
[<00000000d5f54b1e>] netlink_unicast+0x43f/0x5e0
[<00000000db4336bb>] netlink_sendmsg+0x789/0xcd0
[<00000000e1ee26b6>] sock_sendmsg+0xba/0x100
[<00000000ba409802>] ___sys_sendmsg+0x631/0x960
[<000000003c332113>] __sys_sendmsg+0xea/0x180
[<00000000f4139144>] __x64_sys_sendmsg+0x78/0xb0
[<000000006d1ddc59>] do_syscall_64+0x94/0x410
[<00000000c8defa9a>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Move vxlan_dst_free() up and schedule a call thereof to plug this leak.
Fixes: 61f46fe8c646 ("vxlan: Allow vetoing of FDB notifications")
Signed-off-by: Petr Machata <petrm@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/vxlan.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ef45c3c925be..c0cd1c022e77 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -869,6 +869,14 @@ static void vxlan_fdb_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
call_rcu(&f->rcu, vxlan_fdb_free);
}
+static void vxlan_dst_free(struct rcu_head *head)
+{
+ struct vxlan_rdst *rd = container_of(head, struct vxlan_rdst, rcu);
+
+ dst_cache_destroy(&rd->dst_cache);
+ kfree(rd);
+}
+
static int vxlan_fdb_update_existing(struct vxlan_dev *vxlan,
union vxlan_addr *ip,
__u16 state, __u16 flags,
@@ -941,8 +949,10 @@ static int vxlan_fdb_update_existing(struct vxlan_dev *vxlan,
err_notify:
if ((flags & NLM_F_REPLACE) && rc)
*rd = oldrd;
- else if ((flags & NLM_F_APPEND) && rc)
+ else if ((flags & NLM_F_APPEND) && rc) {
list_del_rcu(&rd->list);
+ call_rcu(&rd->rcu, vxlan_dst_free);
+ }
return err;
}
@@ -1013,14 +1023,6 @@ static int vxlan_fdb_update(struct vxlan_dev *vxlan,
}
}
-static void vxlan_dst_free(struct rcu_head *head)
-{
- struct vxlan_rdst *rd = container_of(head, struct vxlan_rdst, rcu);
-
- dst_cache_destroy(&rd->dst_cache);
- kfree(rd);
-}
-
static void vxlan_fdb_dst_destroy(struct vxlan_dev *vxlan, struct vxlan_fdb *f,
struct vxlan_rdst *rd, bool swdev_notify)
{
--
2.4.11
^ permalink raw reply related
* Re: [net-next PATCH] net: rtnetlink: Support alias interfaces with RTM_GETLINK
From: Phil Sutter @ 2019-02-07 12:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20190207102438.21448-1-phil@nwl.cc>
On Thu, Feb 07, 2019 at 11:24:38AM +0100, Phil Sutter wrote:
> Align interface name handling regarding alias interfaces in
> rtnl_getlink() with dev_ioctl() treating SIOCGIFINDEX ioctl calls. The
> latter function strips any colon suffix before doing the interface
> lookup, do the same for RTM_GETLINK requests.
After a second thought, I'll self-NACK this one: Given that netlink API
is completely unrelated to ioctl one, there is no inherent need to do
things the same way. Looking at RTM_NEWLINK handler, it seems possible
to create interface names containing a colon via netlink. Of course
those interfaces are not accessible via ioctl() then, but so are
secondary interface addresses which don't have a properly chosen label.
Sorry for the noise, Phil
^ permalink raw reply
* Re: [net-next PATCH] net: rtnetlink: Support alias interfaces with RTM_GETLINK
From: Michal Kubecek @ 2019-02-07 12:39 UTC (permalink / raw)
To: netdev; +Cc: Phil Sutter, David Miller
In-Reply-To: <20190207122728.GW26388@orbyte.nwl.cc>
On Thu, Feb 07, 2019 at 01:27:28PM +0100, Phil Sutter wrote:
> On Thu, Feb 07, 2019 at 11:24:38AM +0100, Phil Sutter wrote:
> > Align interface name handling regarding alias interfaces in
> > rtnl_getlink() with dev_ioctl() treating SIOCGIFINDEX ioctl calls. The
> > latter function strips any colon suffix before doing the interface
> > lookup, do the same for RTM_GETLINK requests.
>
> After a second thought, I'll self-NACK this one: Given that netlink API
> is completely unrelated to ioctl one, there is no inherent need to do
> things the same way. Looking at RTM_NEWLINK handler, it seems possible
> to create interface names containing a colon via netlink.
Not since commit a4176a939186 ("net: reject creation of netdev names
with colons") which disallowed using such names in general.
But I still don't think it would be a good idea. It's bad enough that
(as I just learned to my surprise) "ip link del dummy1:0" deletes dummy1
without any complaint because ip uses SIOCGIFINDEX ioctl for ifindex
lookup.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH] Using rates in bits when limits are specified in %
From: Marcos Antonio @ 2019-02-07 12:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20190206105126.0d147d72@hermes.lan>
Em 06/02/2019 16:51, Stephen Hemminger escreveu:
> On Wed, 6 Feb 2019 16:09:13 -0200
> Marcos Antonio Moraes <marcos.antonio@digirati.com.br> wrote:
>
>> As /sys/class/net/<iface>/speed indicates a value in Mbits/sec, the
>> transformation is necessary to create the correct limitations.
> Not sure, if this is correct or not could you give an example?
Sure.
With an interface with 1000 Mbits/sec speed, the following commands are
expected to create the same result:
`tc class add dev enp0s3 parent 1:0 classid 1:1 htb rate 500Mbit`
`tc class add dev enp0s3 parent 1:0 classid 1:1 htb rate 50%`
The first command creates the correct class:
class htb 1:1 root prio 0 rate 500Mbit ceil 500Mbit burst 1500b
cburst 1500b
The second one should do the same, instead of creating a class like this:
class htb 1:1 root prio 0 rate 496bit ceil 496bit burst 1599b
cburst 1599b
This happens because after parse_percent_rate(), get_rate() (or
get_rate64()) is called, and it expects to treat the value with the unit
suffix. And the value read from /sys/class/net/<iface>/speed is in
Mbit/sec but does not include the unit. Converting the unity from mbit
to bit would solve the problem.
>
> This patch needs a signed-off-by and a a Fixes tag.
>
> Also please put iproute2 in subject line:
>
> [PATCH iproute2] tc: use bits not mbits/sec in rate percent.
>
> Also, please rebase since I just found a memory leak in this function.
I'll provide a patch with this adjustments.
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] Change tc action identifiers to be more consistent
From: Jamal Hadi Salim @ 2019-02-07 13:00 UTC (permalink / raw)
To: Eli Cohen, xiyou.wangcong, jiri, davem, netdev, linux-kernel
Cc: simon.horman, jakub.kicinski, dirk.vandermerwe, francois.theron,
quentin.monnet, john.hurley, edwin.peer
In-Reply-To: <20190207074549.29861-1-eli@mellanox.com>
On 2019-02-07 2:45 a.m., Eli Cohen wrote:
> This two patch series modifies TC actions identifiers to be more consistent and
> also puts them in one place so new identifiers numbers can be chosen more
> easily.
>
For the series:
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [net-next PATCH] net: rtnetlink: Support alias interfaces with RTM_GETLINK
From: Phil Sutter @ 2019-02-07 13:02 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, David Miller
In-Reply-To: <20190207123939.GE18410@unicorn.suse.cz>
Hi,
On Thu, Feb 07, 2019 at 01:39:39PM +0100, Michal Kubecek wrote:
> On Thu, Feb 07, 2019 at 01:27:28PM +0100, Phil Sutter wrote:
> > On Thu, Feb 07, 2019 at 11:24:38AM +0100, Phil Sutter wrote:
> > > Align interface name handling regarding alias interfaces in
> > > rtnl_getlink() with dev_ioctl() treating SIOCGIFINDEX ioctl calls. The
> > > latter function strips any colon suffix before doing the interface
> > > lookup, do the same for RTM_GETLINK requests.
> >
> > After a second thought, I'll self-NACK this one: Given that netlink API
> > is completely unrelated to ioctl one, there is no inherent need to do
> > things the same way. Looking at RTM_NEWLINK handler, it seems possible
> > to create interface names containing a colon via netlink.
>
> Not since commit a4176a939186 ("net: reject creation of netdev names
> with colons") which disallowed using such names in general.
In my typical afterthought I tried 'ip link add d0:1 type dummy' and was
surprised to get EINVAL from kernel side. Just discovered that line in
dev_valid_name(), too.
> But I still don't think it would be a good idea. It's bad enough that
> (as I just learned to my surprise) "ip link del dummy1:0" deletes dummy1
> without any complaint because ip uses SIOCGIFINDEX ioctl for ifindex
> lookup.
I'm struggling a bit with all this. The original problem is iproute2
commit 50b9950dd9011 ("link dump filter") which changed 'ip link show'
to not use if_indextoname() when given just an interface name. So lookup
happens by name (via RTM_GETLINK) and consequently 'ip link show eth0:1'
doesn't give link stats of eth0 anymore.
Given that iproute2 is supposed to be backwards compatible, the only
valid option I see is to make sure netlink API calls like the above
behave identical to the ioctl ones they replace. Which means allowing
for 'ip link show eth0:42' even if there's no address with that label
assigned to eth0 as well as your example above.
Cheers, Phil
^ permalink raw reply
* [iproute PATCH] ip-link: Fix listing of alias interfaces
From: Phil Sutter @ 2019-02-07 13:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Roopa Prabhu
Commit 50b9950dd9011 ("link dump filter") accidentally broke listing of
links in the old alias interface notation:
| % ip link show eth0:1
| RTNETLINK answers: No such device
| Cannot send link get request: No such device
Prior to the above commit, link lookup was performed via ifindex
returned by if_nametoindex(). The latter uses SIOCGIFINDEX ioctl call
which on kernel side causes the colon-suffix to be dropped before doing
the interface lookup. Netlink API though doesn't care about that at all.
To keep things backward compatible, mimick ioctl API behaviour and drop
the colon-suffix prior to sending the RTM_GETLINK request.
Fixes: 50b9950dd9011 ("link dump filter")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
ip/ipaddress.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 2bc33f3a3b3f2..bc30d326ca0a3 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1974,6 +1974,7 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
* the link device
*/
if (filter_dev && filter.group == -1 && do_link == 1) {
+ *strchrnul(filter_dev, ':') = '\0';
if (iplink_get(filter_dev, RTEXT_FILTER_VF) < 0) {
perror("Cannot send link get request");
delete_json_obj();
--
2.20.1
^ permalink raw reply related
* [PATCH] netfilter: conntrack: fix indentation issue
From: Colin King @ 2019-02-07 13:13 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S . Miller, netfilter-devel, coreteam, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
A statement in an if block is not indented correctly. Fix this.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/netfilter/nf_conntrack_netlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 8071bb04a849..349b42a65c8a 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -2675,7 +2675,7 @@ static int ctnetlink_exp_dump_mask(struct sk_buff *skb,
ret = ctnetlink_dump_tuples_ip(skb, &m);
if (ret >= 0) {
l4proto = nf_ct_l4proto_find(tuple->dst.protonum);
- ret = ctnetlink_dump_tuples_proto(skb, &m, l4proto);
+ ret = ctnetlink_dump_tuples_proto(skb, &m, l4proto);
}
rcu_read_unlock();
--
2.20.1
^ permalink raw reply related
* [PATCH net] vsock: cope with memory allocation failure at socket creation time
From: Paolo Abeni @ 2019-02-07 13:13 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Jorgen Hansen, Stefano Garzarella
In the unlikely event that the kmalloc call in vmci_transport_socket_init()
fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
and oopsing.
This change addresses the above explicitly checking for zero vmci_trans()
at destruction time.
Reported-by: Xiumei Mu <xmu@redhat.com>
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/vmw_vsock/vmci_transport.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index c361ce782412..c3d5ab01fba7 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -1651,6 +1651,10 @@ static void vmci_transport_cleanup(struct work_struct *work)
static void vmci_transport_destruct(struct vsock_sock *vsk)
{
+ /* transport can be NULL if we hit a failure at init() time */
+ if (!vmci_trans(vsk))
+ return;
+
/* Ensure that the detach callback doesn't use the sk/vsk
* we are about to destruct.
*/
--
2.20.1
^ permalink raw reply related
* Re: [net-next PATCH] net: rtnetlink: Support alias interfaces with RTM_GETLINK
From: Michal Kubecek @ 2019-02-07 13:21 UTC (permalink / raw)
To: netdev; +Cc: Phil Sutter, David Miller
In-Reply-To: <20190207130215.GX26388@orbyte.nwl.cc>
On Thu, Feb 07, 2019 at 02:02:15PM +0100, Phil Sutter wrote:
> On Thu, Feb 07, 2019 at 01:39:39PM +0100, Michal Kubecek wrote:
>
> > But I still don't think it would be a good idea. It's bad enough that
> > (as I just learned to my surprise) "ip link del dummy1:0" deletes dummy1
> > without any complaint because ip uses SIOCGIFINDEX ioctl for ifindex
> > lookup.
>
> I'm struggling a bit with all this. The original problem is iproute2
> commit 50b9950dd9011 ("link dump filter") which changed 'ip link show'
> to not use if_indextoname() when given just an interface name. So lookup
> happens by name (via RTM_GETLINK) and consequently 'ip link show eth0:1'
> doesn't give link stats of eth0 anymore.
I would rather consider it a bug that it ever did. It's quite harmless
with "show" but with "set" or "delete", the effect can be quite
disastrous.
We want to preserve backward compatibility in general but iproute2
commit 50b9950dd901 is 4.5 years old and nobody seems to have complained
about the change in behaviour until now.
> Given that iproute2 is supposed to be backwards compatible, the only
> valid option I see is to make sure netlink API calls like the above
> behave identical to the ioctl ones they replace. Which means allowing
> for 'ip link show eth0:42' even if there's no address with that label
> assigned to eth0 as well as your example above.
One reason why I don't like this idea is that iproute2 is not the only
user of rtnetlink interface. There is wicked and glibc for sure, most
likely also NetworkManager (don't remember) and systemd-networkd (didn't
check) and certainly many others I never heard of. Changing the logic
in kernel rtnetlink implementation would affect all of them.
If we want to restore the old behaviour of ip (which I'm not convinced
of), it would make more sense to me to strip the :* suffix in iproute2.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH net] vsock: cope with memory allocation failure at socket creation time
From: Stefano Garzarella @ 2019-02-07 13:37 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, Jorgen Hansen
In-Reply-To: <9ad578fedcc2888319e4ec222d11f6fe51afd613.1549545195.git.pabeni@redhat.com>
On Thu, Feb 07, 2019 at 02:13:18PM +0100, Paolo Abeni wrote:
> In the unlikely event that the kmalloc call in vmci_transport_socket_init()
> fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
> and oopsing.
>
> This change addresses the above explicitly checking for zero vmci_trans()
> at destruction time.
>
> Reported-by: Xiumei Mu <xmu@redhat.com>
> Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/vmw_vsock/vmci_transport.c | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH v2] rhashtable: make walk safe from softirq context
From: Herbert Xu @ 2019-02-07 13:40 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, netdev, Jouni Malinen, Thomas Graf, Johannes Berg
In-Reply-To: <20190206090721.8001-1-johannes@sipsolutions.net>
On Wed, Feb 06, 2019 at 10:07:21AM +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When an rhashtable walk is done from softirq context, we rightfully
> get a lockdep complaint saying that we could get a softirq in the
> middle of a rehash, and thus deadlock on &ht->lock. This happened
> e.g. in mac80211 as it does a walk in softirq context.
>
> Fix this by using spin_lock_bh() wherever we use the &ht->lock.
>
> Initially, I thought it would be sufficient to do this only in the
> rehash (rhashtable_rehash_table), but I changed my mind:
> * the caller doesn't really need to disable softirqs across all
> of the rhashtable_walk_* functions, only those parts that they
> actually do within the lock need it
> * maybe more importantly, it would still lead to massive lockdep
> complaints - false positives, but hard to fix - because lockdep
> wouldn't know about different ht->lock instances, and thus one
> user of the code doing a walk w/o any locking (when it only ever
> uses process context this is fine) vs. another user like in wifi
> where we noticed this problem would still cause it to complain.
>
> Cc: stable@vger.kernel.org
> Reported-by: Jouni Malinen <j@w1.fi>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This interface wasn't designed for use in softirq contexts.
Could you please show me who is doing this so I can review that
to see whether it's a legitimate use of this API?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH bpf-next v7 2/6] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
From: kbuild test robot @ 2019-02-07 13:43 UTC (permalink / raw)
To: Peter Oskolkov
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, netdev,
Peter Oskolkov, David Ahern, Willem de Bruijn, Peter Oskolkov
In-Reply-To: <20190207003720.51096-3-posk@google.com>
[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]
Hi Peter,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Peter-Oskolkov/bpf-add-BPF_LWT_ENCAP_IP-option-to-bpf_lwt_push_encap/20190207-205725
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-randconfig-l1-02071408 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net//core/filter.c: In function 'bpf_push_ip_encap':
>> net//core/filter.c:4808:9: error: implicit declaration of function 'bpf_lwt_push_ip_encap' [-Werror=implicit-function-declaration]
return bpf_lwt_push_ip_encap(skb, hdr, len, ingress);
^
net//core/filter.c: At top level:
net//core/filter.c:4805:12: warning: 'bpf_push_ip_encap' defined but not used [-Wunused-function]
static int bpf_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len,
^
cc1: some warnings being treated as errors
vim +/bpf_lwt_push_ip_encap +4808 net//core/filter.c
4804
4805 static int bpf_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len,
4806 bool ingress)
4807 {
> 4808 return bpf_lwt_push_ip_encap(skb, hdr, len, ingress);
4809 }
4810
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28818 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: phy: Update PHY linkmodes after config_init
From: Andrew Lunn @ 2019-02-07 13:48 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-2-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:30AM +0100, Maxime Chevallier wrote:
> We want to be able to update a PHY's supported list in the config_init
> callback, so move the Pause parameters settings from phydrv->features
> after calling config_init to make sure these parameters aren't
> overwritten.
Hi Maxime
I have a patch which makes some core changes to support PHY doing
runtime feature detection. I would prefer to use them, than this.
Either I or Heiner will post them soon.
Andrew
^ permalink raw reply
* Re: [PATCH v2] rhashtable: make walk safe from softirq context
From: Johannes Berg @ 2019-02-07 13:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-wireless, netdev, Jouni Malinen, Thomas Graf
In-Reply-To: <20190207134006.gmuooqmyc5womcaf@gondor.apana.org.au>
> This interface wasn't designed for use in softirq contexts.
Well, it clearly was used there. You even gave it a gfp_t argument in
rhashtable_walk_init(), so you can't really claim it wasn't designed for
this. I see now that it's ignored, but still?
> Could you please show me who is doing this so I can review that
> to see whether it's a legitimate use of this API?
I'm sure you'll say it's not legitimate, but it still exists ;-)
mesh_plink_broken() gets called from the TX status path, via
ieee80211s_update_metric().
johannes
^ permalink raw reply
* Re: [net-next PATCH] net: rtnetlink: Support alias interfaces with RTM_GETLINK
From: Phil Sutter @ 2019-02-07 13:52 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, David Miller
In-Reply-To: <20190207132156.GF18410@unicorn.suse.cz>
On Thu, Feb 07, 2019 at 02:21:56PM +0100, Michal Kubecek wrote:
> On Thu, Feb 07, 2019 at 02:02:15PM +0100, Phil Sutter wrote:
> > On Thu, Feb 07, 2019 at 01:39:39PM +0100, Michal Kubecek wrote:
> >
> > > But I still don't think it would be a good idea. It's bad enough that
> > > (as I just learned to my surprise) "ip link del dummy1:0" deletes dummy1
> > > without any complaint because ip uses SIOCGIFINDEX ioctl for ifindex
> > > lookup.
> >
> > I'm struggling a bit with all this. The original problem is iproute2
> > commit 50b9950dd9011 ("link dump filter") which changed 'ip link show'
> > to not use if_indextoname() when given just an interface name. So lookup
> > happens by name (via RTM_GETLINK) and consequently 'ip link show eth0:1'
> > doesn't give link stats of eth0 anymore.
>
> I would rather consider it a bug that it ever did. It's quite harmless
> with "show" but with "set" or "delete", the effect can be quite
> disastrous.
Yes, you're right. And unless maintainers care about this compatibility,
I guess these monsters will slowly disappear as things progress towards
netlink.
> We want to preserve backward compatibility in general but iproute2
> commit 50b9950dd901 is 4.5 years old and nobody seems to have complained
> about the change in behaviour until now.
Well, enterprise distributions deliberately try to prevent those changes
from hitting their customers. And (perfect match), these users are the
least tolerating ones. :)
> > Given that iproute2 is supposed to be backwards compatible, the only
> > valid option I see is to make sure netlink API calls like the above
> > behave identical to the ioctl ones they replace. Which means allowing
> > for 'ip link show eth0:42' even if there's no address with that label
> > assigned to eth0 as well as your example above.
>
> One reason why I don't like this idea is that iproute2 is not the only
> user of rtnetlink interface. There is wicked and glibc for sure, most
> likely also NetworkManager (don't remember) and systemd-networkd (didn't
> check) and certainly many others I never heard of. Changing the logic
> in kernel rtnetlink implementation would affect all of them.
>
> If we want to restore the old behaviour of ip (which I'm not convinced
> of), it would make more sense to me to strip the :* suffix in iproute2.
I just sent a patch, let's see what userspace has to say about it.
Thanks, Phil
^ permalink raw reply
* [PATCH net 1/1] net/smc: fix byte_order for rx_curs_confirmed
From: Ursula Braun @ 2019-02-07 13:52 UTC (permalink / raw)
To: davem
Cc: netdev, linux-s390, linux-rdma, schwidefsky, heiko.carstens,
raspl, ubraun
The recent change in the rx_curs_confirmed assignment disregards
byte order, which causes problems on little endian architectures.
This patch fixes it.
Fixes: b8649efad879 ("net/smc: fix sender_free computation") (net-tree)
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/smc_cdc.c | 4 +---
net/smc/smc_cdc.h | 19 ++++++++++---------
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/net/smc/smc_cdc.c b/net/smc/smc_cdc.c
index a712c9f8699b..fb07ad8d69a6 100644
--- a/net/smc/smc_cdc.c
+++ b/net/smc/smc_cdc.c
@@ -101,9 +101,7 @@ int smc_cdc_msg_send(struct smc_connection *conn,
conn->tx_cdc_seq++;
conn->local_tx_ctrl.seqno = conn->tx_cdc_seq;
- smc_host_msg_to_cdc((struct smc_cdc_msg *)wr_buf,
- &conn->local_tx_ctrl, conn);
- smc_curs_copy(&cfed, &((struct smc_host_cdc_msg *)wr_buf)->cons, conn);
+ smc_host_msg_to_cdc((struct smc_cdc_msg *)wr_buf, conn, &cfed);
rc = smc_wr_tx_send(link, (struct smc_wr_tx_pend_priv *)pend);
if (!rc)
smc_curs_copy(&conn->rx_curs_confirmed, &cfed, conn);
diff --git a/net/smc/smc_cdc.h b/net/smc/smc_cdc.h
index 271e2524dc8f..f1cdde9d4b89 100644
--- a/net/smc/smc_cdc.h
+++ b/net/smc/smc_cdc.h
@@ -211,26 +211,27 @@ static inline int smc_curs_diff_large(unsigned int size,
static inline void smc_host_cursor_to_cdc(union smc_cdc_cursor *peer,
union smc_host_cursor *local,
+ union smc_host_cursor *save,
struct smc_connection *conn)
{
- union smc_host_cursor temp;
-
- smc_curs_copy(&temp, local, conn);
- peer->count = htonl(temp.count);
- peer->wrap = htons(temp.wrap);
+ smc_curs_copy(save, local, conn);
+ peer->count = htonl(save->count);
+ peer->wrap = htons(save->wrap);
/* peer->reserved = htons(0); must be ensured by caller */
}
static inline void smc_host_msg_to_cdc(struct smc_cdc_msg *peer,
- struct smc_host_cdc_msg *local,
- struct smc_connection *conn)
+ struct smc_connection *conn,
+ union smc_host_cursor *save)
{
+ struct smc_host_cdc_msg *local = &conn->local_tx_ctrl;
+
peer->common.type = local->common.type;
peer->len = local->len;
peer->seqno = htons(local->seqno);
peer->token = htonl(local->token);
- smc_host_cursor_to_cdc(&peer->prod, &local->prod, conn);
- smc_host_cursor_to_cdc(&peer->cons, &local->cons, conn);
+ smc_host_cursor_to_cdc(&peer->prod, &local->prod, save, conn);
+ smc_host_cursor_to_cdc(&peer->cons, &local->cons, save, conn);
peer->prod_flags = local->prod_flags;
peer->conn_state_flags = local->conn_state_flags;
}
--
2.16.4
^ permalink raw reply related
* Re: Compiler warning
From: Koen Vandeputte @ 2019-02-07 13:55 UTC (permalink / raw)
To: David Ahern, netdev
In-Reply-To: <e5d6fb7f-715c-2959-8a1b-24629a2bb2a1@gmail.com>
On 05.02.19 03:55, David Ahern wrote:
> On 2/4/19 3:43 AM, Koen Vandeputte wrote:
>> Hi All,
>>
>> I'm seeing following compiler warning during kernel compilation
>> (5.0-rc5 and 4.14.96):
>>
>>
>> net/core/dev.c: In function 'validate_xmit_skb_list':
>> net/core/dev.c:3405:15: warning: 'tail' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
>> tail->next = skb;
>> ~~~~~~~~~~~^~~~~
>>
>>
>> Source shows this:
>>
>> https://elixir.bootlin.com/linux/v5.0-rc5/source/net/core/dev.c#L3387
>>
>> Looks like "tail" can get deferenced while it indeed doesn't get
>> initialized? Kind regards, Koen
>>
> same with this one - false positive. head is initialized to NULL. tail
> is set on the first pass through the loop.
>
> What compiler / version is this?
Thanks for confirming David. (for both of the warnings)
This is seen using GCC 7.4.0
I don't know the policy upstream regarding compiler warnings .. so
thought I should report these. :)
Regards,
Koen
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] net: phy: Update PHY linkmodes after config_init
From: Maxime Chevallier @ 2019-02-07 13:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207134807.GD23970@lunn.ch>
Hello Andrew,
On Thu, 7 Feb 2019 14:48:07 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
>On Thu, Feb 07, 2019 at 10:49:30AM +0100, Maxime Chevallier wrote:
>> We want to be able to update a PHY's supported list in the config_init
>> callback, so move the Pause parameters settings from phydrv->features
>> after calling config_init to make sure these parameters aren't
>> overwritten.
>
>Hi Maxime
>
>I have a patch which makes some core changes to support PHY doing
>runtime feature detection. I would prefer to use them, than this.
>
>Either I or Heiner will post them soon.
Sure, no problem, thanks for doing this. I'll be happy to review and
test that on my side.
As I said, I lack the big picture view on that part so my approach was
pretty naive, I'm glad you can take care of this :)
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH net-next v2 02/10] net: phy: Mask-out non-compatible modes when setting the max-speed
From: Andrew Lunn @ 2019-02-07 13:59 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-3-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:31AM +0100, Maxime Chevallier wrote:
> When setting a PHY's max speed using either the max-speed DT property
> or ethtool, we should mask-out all non-compatible modes according to the
> settings table, instead of just the 10/100BASET modes.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Suggested-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* RE: [PATCH net] vsock: cope with memory allocation failure at socket creation time
From: Jorgen S. Hansen @ 2019-02-07 14:00 UTC (permalink / raw)
To: 'Paolo Abeni', netdev@vger.kernel.org
Cc: David S. Miller, Stefano Garzarella
In-Reply-To: <9ad578fedcc2888319e4ec222d11f6fe51afd613.1549545195.git.pabeni@redhat.com>
> In the unlikely event that the kmalloc call in vmci_transport_socket_init()
> fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
> and oopsing.
>
> This change addresses the above explicitly checking for zero vmci_trans() at
> destruction time.
>
> Reported-by: Xiumei Mu <xmu@redhat.com>
> Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/vmw_vsock/vmci_transport.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/vmw_vsock/vmci_transport.c
> b/net/vmw_vsock/vmci_transport.c index c361ce782412..c3d5ab01fba7
> 100644
> --- a/net/vmw_vsock/vmci_transport.c
> +++ b/net/vmw_vsock/vmci_transport.c
> @@ -1651,6 +1651,10 @@ static void vmci_transport_cleanup(struct
> work_struct *work)
>
> static void vmci_transport_destruct(struct vsock_sock *vsk) {
> + /* transport can be NULL if we hit a failure at init() time */
> + if (!vmci_trans(vsk))
> + return;
> +
> /* Ensure that the detach callback doesn't use the sk/vsk
> * we are about to destruct.
> */
> --
> 2.20.1
Reviewed-by: Jorgen Hansen <jhansen@vmware.com>
Thanks for fixing this,
Jorgen
^ permalink raw reply
* Re: [PATCH net-next v2 03/10] net: phy: Move of_set_phy_eee_broken to phy-core.c
From: Andrew Lunn @ 2019-02-07 14:01 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-4-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:32AM +0100, Maxime Chevallier wrote:
> Since of_set_phy_supported was moved to phy-core.c, we can also move
> of_set_phy_eee_broken to the same location, so that we have all OF
> functions in the same place.
>
> This patch doesn't intend to introduce any change in behaviour.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next v7 2/6] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
From: kbuild test robot @ 2019-02-07 14:04 UTC (permalink / raw)
To: Peter Oskolkov
Cc: kbuild-all, Alexei Starovoitov, Daniel Borkmann, netdev,
Peter Oskolkov, David Ahern, Willem de Bruijn, Peter Oskolkov
In-Reply-To: <20190207003720.51096-3-posk@google.com>
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Hi Peter,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Peter-Oskolkov/bpf-add-BPF_LWT_ENCAP_IP-option-to-bpf_lwt_push_encap/20190207-205725
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-defconfig (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net//core/filter.c: In function 'bpf_push_ip_encap':
>> net//core/filter.c:4808:9: error: implicit declaration of function 'bpf_lwt_push_ip_encap'; did you mean 'bpf_push_ip_encap'? [-Werror=implicit-function-declaration]
return bpf_lwt_push_ip_encap(skb, hdr, len, ingress);
^~~~~~~~~~~~~~~~~~~~~
bpf_push_ip_encap
At top level:
net//core/filter.c:4805:12: warning: 'bpf_push_ip_encap' defined but not used [-Wunused-function]
static int bpf_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len,
^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +4808 net//core/filter.c
4804
4805 static int bpf_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len,
4806 bool ingress)
4807 {
> 4808 return bpf_lwt_push_ip_encap(skb, hdr, len, ingress);
4809 }
4810
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26942 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 04/10] net: phy: Automatically fill the generic TP, FIBRE and Backplane modes
From: Andrew Lunn @ 2019-02-07 14:09 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Florian Fainelli, Heiner Kallweit,
Russell King, linux-arm-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw
In-Reply-To: <20190207094939.27369-5-maxime.chevallier@bootlin.com>
On Thu, Feb 07, 2019 at 10:49:33AM +0100, Maxime Chevallier wrote:
> PHY advertised and supported linkmodes contain both specific modes such
> as 1000BASET Half/Full and generic ones such as TP that represent a
> class of modes.
>
> Since some modes such as Fibre, TP or Backplane match a wide range of
> specific modes, we can automatically set these bits if one of the
> specific modes it corresponds to is present in the list.
>
> The 'TP' bit is set whenever there's a BaseT linkmode in
> phydev->supported.
>
> The 'FIBRE' bit is set for BaseL, BaseS and BaseE linkmodes.
>
> Finally, the 'Backplane' is set whenever a BaseK mode is supported.
Hi Maxime
Interesting idea.
But what exactly are we supposed to be representing here? That PHY
can do these modes, or that the port exists on the device? The
marvell10g can do fibre, but do all boards have an SFP/SFF, or do some
only have an RJ-45 for TP? Are there boards without TP and just
SFP/SFF?
Is there documentation in ethtool which gives a clue as to what is
expected?
Thanks
Andrew
^ 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