* [PATCH 0/5] Allwinner H6 Ethernet support
From: Icenowy Zheng @ 2018-07-22 5:39 UTC (permalink / raw)
To: Rob Herring, Maxime Ripard, Chen-Yu Tsai, David S. Miller,
Corentin Labbe
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
This patchset introduces Allwinner H6 Ethernet support with code already
available for A64.
As the system controller and EMAC on H6 are all similar to A64 ones,
support for them are directly reused, by using fallback compatible
strings.
Icenowy Zheng (5):
dt-binding: dwmac-sun8i: add H6 compatible string (w/ A64 fallback)
dt-bindings: sunxi-sram: add binding for Allwinner H6 SRAM C
arm64: allwinner: h6: add system controller device tree node
arm64: allwinner: h6: add EMAC device nodes
arm64: allwinner: h6: add support for the Ethernet on Pine H64
.../devicetree/bindings/net/dwmac-sun8i.txt | 1 +
.../devicetree/bindings/sram/sunxi-sram.txt | 4 ++
.../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 29 ++++++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 53 +++++++++++++++++++
4 files changed, 87 insertions(+)
--
2.18.0
^ permalink raw reply
* Re: hard-coded limit on unresolved multicast route cache in ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy networks
From: David Miller @ 2018-07-22 5:03 UTC (permalink / raw)
To: karn; +Cc: kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <147f730b-8cbf-b76d-f693-b3fdaf72a89c@ka9q.net>
From: Phil Karn <karn@ka9q.net>
Date: Sat, 21 Jul 2018 18:31:22 -0700
> I'm running pimd (protocol independent multicast routing) and found that
> on busy networks with lots of unresolved multicast routing entries, the
> creation of new multicast group routes can be extremely slow and
> unreliable, especially when the group in question has little traffic.
>
> A google search revealed the following conversation about the problem
> from the fall of 2015:
>
> https://github.com/troglobit/pimd/issues/58
>
> Note especially the comment by kopren on Sep 13, 2016.
>
> The writer traced the problem to function ipmr_cache_unresolved() in
> file net/ipmr.c, in the following block of code:
>
> /* Create a new entry if allowable */
> if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
> (c = ipmr_cache_alloc_unres()) == NULL) {
> spin_unlock_bh(&mfc_unres_lock);
>
> kfree_skb(skb);
> return -ENOBUFS;
> }
...
> Does this hard-coded limit serve any purpose? Can it be safely increased
> to a much larger value, or better yet, removed altogether? If it can't
> be removed, can it at least be made configurable through a /proc entry?
Yeah that limit is bogus for several reasons.
One, it's too low.
Two, it's not configurable.
There does have to be some limit, because we are depending upon a user
process (mrouted or whatever) to receive the netlink message, resolve
the cache entry, and update the kernel.
If the user process gets stuck, or processes entries very slowly, the
backlog could grow infinitely. So we do indeed need some kind of limit.
But, we essentially already do have such a limit, and that's the
socket receive queue limits of the mrouted socket. And indeed, we
fail the cache creation if we cannot queue up the netlink message to
the user process successfully.
Therefore, it probably is safe and correct to remove this
cache_resolve_queue_len altogether.
Something like this:
diff --git a/include/linux/mroute_base.h b/include/linux/mroute_base.h
index d633f737b3c6..b166465d7c05 100644
--- a/include/linux/mroute_base.h
+++ b/include/linux/mroute_base.h
@@ -234,7 +234,6 @@ struct mr_table_ops {
* @mfc_hash: Hash table of all resolved routes for easy lookup
* @mfc_cache_list: list of resovled routes for possible traversal
* @maxvif: Identifier of highest value vif currently in use
- * @cache_resolve_queue_len: current size of unresolved queue
* @mroute_do_assert: Whether to inform userspace on wrong ingress
* @mroute_do_pim: Whether to receive IGMP PIMv1
* @mroute_reg_vif_num: PIM-device vif index
@@ -251,7 +250,6 @@ struct mr_table {
struct rhltable mfc_hash;
struct list_head mfc_cache_list;
int maxvif;
- atomic_t cache_resolve_queue_len;
bool mroute_do_assert;
bool mroute_do_pim;
int mroute_reg_vif_num;
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 9f79b9803a16..c007cf9bfe82 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -747,8 +747,6 @@ static void ipmr_destroy_unres(struct mr_table *mrt, struct mfc_cache *c)
struct sk_buff *skb;
struct nlmsgerr *e;
- atomic_dec(&mrt->cache_resolve_queue_len);
-
while ((skb = skb_dequeue(&c->_c.mfc_un.unres.unresolved))) {
if (ip_hdr(skb)->version == 0) {
struct nlmsghdr *nlh = skb_pull(skb,
@@ -1135,9 +1133,11 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
}
if (!found) {
+ bool was_empty;
+
/* Create a new entry if allowable */
- if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
- (c = ipmr_cache_alloc_unres()) == NULL) {
+ c = ipmr_cache_alloc_unres();
+ if (!c) {
spin_unlock_bh(&mfc_unres_lock);
kfree_skb(skb);
@@ -1163,11 +1163,11 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, vifi_t vifi,
return err;
}
- atomic_inc(&mrt->cache_resolve_queue_len);
+ was_empty = list_empty(&mrt->mfc_unres_queue);
list_add(&c->_c.list, &mrt->mfc_unres_queue);
mroute_netlink_event(mrt, c, RTM_NEWROUTE);
- if (atomic_read(&mrt->cache_resolve_queue_len) == 1)
+ if (was_empty)
mod_timer(&mrt->ipmr_expire_timer,
c->_c.mfc_un.unres.expires);
}
@@ -1274,7 +1274,6 @@ static int ipmr_mfc_add(struct net *net, struct mr_table *mrt,
if (uc->mfc_origin == c->mfc_origin &&
uc->mfc_mcastgrp == c->mfc_mcastgrp) {
list_del(&_uc->list);
- atomic_dec(&mrt->cache_resolve_queue_len);
found = true;
break;
}
@@ -1322,7 +1321,7 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
mr_cache_put(c);
}
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ if (!list_empty(&mrt->mfc_unres_queue)) {
spin_lock_bh(&mfc_unres_lock);
list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
list_del(&c->list);
@@ -2648,9 +2647,19 @@ static int ipmr_rtm_route(struct sk_buff *skb, struct nlmsghdr *nlh,
return ipmr_mfc_delete(tbl, &mfcc, parent);
}
+static int queue_count(struct mr_table *mrt)
+{
+ struct list_head *pos;
+ int count = 0;
+
+ list_for_each(pos, &mrt->mfc_unres_queue)
+ count++;
+ return count;
+}
+
static bool ipmr_fill_table(struct mr_table *mrt, struct sk_buff *skb)
{
- u32 queue_len = atomic_read(&mrt->cache_resolve_queue_len);
+ u32 queue_len = queue_count(mrt);
if (nla_put_u32(skb, IPMRA_TABLE_ID, mrt->id) ||
nla_put_u32(skb, IPMRA_TABLE_CACHE_RES_QUEUE_LEN, queue_len) ||
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 0d0f0053bb11..75e9c5a3e7ea 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -759,8 +759,6 @@ static void ip6mr_destroy_unres(struct mr_table *mrt, struct mfc6_cache *c)
struct net *net = read_pnet(&mrt->net);
struct sk_buff *skb;
- atomic_dec(&mrt->cache_resolve_queue_len);
-
while ((skb = skb_dequeue(&c->_c.mfc_un.unres.unresolved)) != NULL) {
if (ipv6_hdr(skb)->version == 0) {
struct nlmsghdr *nlh = skb_pull(skb,
@@ -1139,8 +1137,8 @@ static int ip6mr_cache_unresolved(struct mr_table *mrt, mifi_t mifi,
* Create a new entry if allowable
*/
- if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
- (c = ip6mr_cache_alloc_unres()) == NULL) {
+ c = ip6mr_cache_alloc_unres();
+ if (!c) {
spin_unlock_bh(&mfc_unres_lock);
kfree_skb(skb);
@@ -1167,7 +1165,6 @@ static int ip6mr_cache_unresolved(struct mr_table *mrt, mifi_t mifi,
return err;
}
- atomic_inc(&mrt->cache_resolve_queue_len);
list_add(&c->_c.list, &mrt->mfc_unres_queue);
mr6_netlink_event(mrt, c, RTM_NEWROUTE);
@@ -1455,7 +1452,6 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
if (ipv6_addr_equal(&uc->mf6c_origin, &c->mf6c_origin) &&
ipv6_addr_equal(&uc->mf6c_mcastgrp, &c->mf6c_mcastgrp)) {
list_del(&_uc->list);
- atomic_dec(&mrt->cache_resolve_queue_len);
found = true;
break;
}
@@ -1502,7 +1498,7 @@ static void mroute_clean_tables(struct mr_table *mrt, bool all)
mr_cache_put(c);
}
- if (atomic_read(&mrt->cache_resolve_queue_len) != 0) {
+ if (!list_empty(&mrt->mfc_unres_queue)) {
spin_lock_bh(&mfc_unres_lock);
list_for_each_entry_safe(c, tmp, &mrt->mfc_unres_queue, list) {
list_del(&c->list);
^ permalink raw reply related
* Re: [PATCH] netlink: fix memory leak
From: Jason A. Donenfeld @ 2018-07-22 5:00 UTC (permalink / raw)
To: cscnull
Cc: Pablo Neira Ayuso, kadlec, Florian Westphal, David Miller,
Berg, Johannes, Philippe Ombredanne, kstewart, Greg Kroah-Hartman,
dsahern, lucien.xin, ktkhai, Cong Wang, LKML, netfilter-devel,
coreteam, Netdev
In-Reply-To: <20180722024925.3176-1-cscnull@gmail.com>
On Sun, Jul 22, 2018 at 4:51 AM Shaochun Chen <cscnull@gmail.com> wrote:
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 393573a99a5a..7b85176cf9bb 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -2275,6 +2275,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
> struct netlink_callback *cb;
> struct sock *sk;
> struct netlink_sock *nlk;
> + bool cb_running = false;
> int ret;
>
> refcount_inc(&skb->users);
> @@ -2317,6 +2318,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
>
> nlk->cb_running = true;
> nlk->dump_done_errno = INT_MAX;
> + cb_running = true;
>
> mutex_unlock(nlk->cb_mutex);
>
> @@ -2339,6 +2341,8 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
> mutex_unlock(nlk->cb_mutex);
> error_free:
> kfree_skb(skb);
> + if (cb_running)
> + netlink_dump_start_fail(control);
cb_running is never true here, since nothing jumps to error_free after
you set it to be true. Pasting more code for context:
nlk->cb_running = true;
nlk->dump_done_errno = INT_MAX;
1) ----> cb_runnning = true;
mutex_unlock(nlk->cb_mutex);
ret = netlink_dump(sk);
sock_put(sk);
if (ret)
A) return ret;
/* We successfully started a dump, by returning -EINTR we
* signal not to send ACK even if it was requested.
*/
B) return -EINTR;
error_put:
module_put(control->module);
error_unlock:
sock_put(sk);
mutex_unlock(nlk->cb_mutex);
error_free:
kfree_skb(skb);
2) ----> if (cb_running) netlink_dump_start_fail(control);
return ret;
After (1) is set, the function exits via (A) or (B), and so (2) is never hit.
But even if you moved it somehow to the if(ret), I'm still not sure
it'd be correct; start cbs should either succeed, or they should error
out and cleanup entirely after themselves.
> return ret;
> }
> EXPORT_SYMBOL(__netlink_dump_start);
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH net] ipv6: use fib6_info_hold_safe() when necessary
From: Wei Wang @ 2018-07-22 3:56 UTC (permalink / raw)
To: David Miller, netdev
Cc: Eric Dumazet, David Ahern, Martin KaFai Lau, Wei Wang
From: Wei Wang <weiwan@google.com>
In the code path where only rcu read lock is held, e.g. in the route
lookup code path, it is not safe to directly call fib6_info_hold()
because the fib6_info may already have been deleted but still exists
in the rcu grace period. Holding reference to it could cause double
free and crash the kernel.
This patch adds a new function fib6_info_hold_safe() and replace
fib6_info_hold() in all necessary places.
Syzbot reported 3 crash traces because of this. One of them is:
8021q: adding VLAN 0 to HW filter on device team0
IPv6: ADDRCONF(NETDEV_CHANGE): team0: link becomes ready
dst_release: dst:(____ptrval____) refcnt:-1
dst_release: dst:(____ptrval____) refcnt:-2
WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 dst_hold include/net/dst.h:239 [inline]
WARNING: CPU: 1 PID: 4845 at include/net/dst.h:239 ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
dst_release: dst:(____ptrval____) refcnt:-1
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 4845 Comm: syz-executor493 Not tainted 4.18.0-rc3+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
dst_release: dst:(____ptrval____) refcnt:-2
dst_release: dst:(____ptrval____) refcnt:-3
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
dst_release: dst:(____ptrval____) refcnt:-4
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
dst_release: dst:(____ptrval____) refcnt:-5
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:dst_hold include/net/dst.h:239 [inline]
RIP: 0010:ip6_setup_cork+0xd66/0x1830 net/ipv6/ip6_output.c:1204
Code: c1 ed 03 89 9d 18 ff ff ff 48 b8 00 00 00 00 00 fc ff df 41 c6 44 05 00 f8 e9 2d 01 00 00 4c 8b a5 c8 fe ff ff e8 1a f6 e6 fa <0f> 0b e9 6a fc ff ff e8 0e f6 e6 fa 48 8b 85 d0 fe ff ff 48 8d 78
RSP: 0018:ffff8801a8fcf178 EFLAGS: 00010293
RAX: ffff8801a8eba5c0 RBX: 0000000000000000 RCX: ffffffff869511e6
RDX: 0000000000000000 RSI: ffffffff869515b6 RDI: 0000000000000005
RBP: ffff8801a8fcf2c8 R08: ffff8801a8eba5c0 R09: ffffed0035ac8338
R10: ffffed0035ac8338 R11: ffff8801ad6419c3 R12: ffff8801a8fcf720
R13: ffff8801a8fcf6a0 R14: ffff8801ad6419c0 R15: ffff8801ad641980
ip6_make_skb+0x2c8/0x600 net/ipv6/ip6_output.c:1768
udpv6_sendmsg+0x2c90/0x35f0 net/ipv6/udp.c:1376
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:641 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:651
___sys_sendmsg+0x51d/0x930 net/socket.c:2125
__sys_sendmmsg+0x240/0x6f0 net/socket.c:2220
__do_sys_sendmmsg net/socket.c:2249 [inline]
__se_sys_sendmmsg net/socket.c:2246 [inline]
__x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2246
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446ba9
Code: e8 cc bb 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fb39a469da8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00000000006dcc54 RCX: 0000000000446ba9
RDX: 00000000000000b8 RSI: 0000000020001b00 RDI: 0000000000000003
RBP: 00000000006dcc50 R08: 00007fb39a46a700 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 45c828efc7a64843
R13: e6eeb815b9d8a477 R14: 5068caf6f713c6fc R15: 0000000000000001
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
Fixes: 93531c674315 (net/ipv6: separate handling of FIB entries from dst based routes)
Reported-by: syzbot+902e2a1bcd4f7808cef5@syzkaller.appspotmail.com
Reported-by: syzbot+8ae62d67f647abeeceb9@syzkaller.appspotmail.com
Reported-by: syzbot+3f08feb14086930677d0@syzkaller.appspotmail.com
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
---
include/net/ip6_fib.h | 5 +++++
net/ipv6/addrconf.c | 3 ++-
net/ipv6/route.c | 41 +++++++++++++++++++++++++++++++----------
3 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/include/net/ip6_fib.h b/include/net/ip6_fib.h
index 71b9043aa0e7..3d4930528db0 100644
--- a/include/net/ip6_fib.h
+++ b/include/net/ip6_fib.h
@@ -281,6 +281,11 @@ static inline void fib6_info_hold(struct fib6_info *f6i)
atomic_inc(&f6i->fib6_ref);
}
+static inline bool fib6_info_hold_safe(struct fib6_info *f6i)
+{
+ return atomic_inc_not_zero(&f6i->fib6_ref);
+}
+
static inline void fib6_info_release(struct fib6_info *f6i)
{
if (f6i && atomic_dec_and_test(&f6i->fib6_ref))
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 91580c62bb86..f66a1cae3366 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2374,7 +2374,8 @@ static struct fib6_info *addrconf_get_prefix_route(const struct in6_addr *pfx,
continue;
if ((rt->fib6_flags & noflags) != 0)
continue;
- fib6_info_hold(rt);
+ if (!fib6_info_hold_safe(rt))
+ continue;
break;
}
out:
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 2ce0bd17de4f..ec18b3ce8b6d 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -972,10 +972,10 @@ static void ip6_rt_init_dst(struct rt6_info *rt, struct fib6_info *ort)
rt->dst.lastuse = jiffies;
}
+/* Caller must already hold reference to @from */
static void rt6_set_from(struct rt6_info *rt, struct fib6_info *from)
{
rt->rt6i_flags &= ~RTF_EXPIRES;
- fib6_info_hold(from);
rcu_assign_pointer(rt->from, from);
dst_init_metrics(&rt->dst, from->fib6_metrics->metrics, true);
if (from->fib6_metrics != &dst_default_metrics) {
@@ -984,6 +984,7 @@ static void rt6_set_from(struct rt6_info *rt, struct fib6_info *from)
}
}
+/* Caller must already hold reference to @ort */
static void ip6_rt_copy_init(struct rt6_info *rt, struct fib6_info *ort)
{
struct net_device *dev = fib6_info_nh_dev(ort);
@@ -1044,9 +1045,14 @@ static struct rt6_info *ip6_create_rt_rcu(struct fib6_info *rt)
struct net_device *dev = rt->fib6_nh.nh_dev;
struct rt6_info *nrt;
+ if (!fib6_info_hold_safe(rt))
+ return NULL;
+
nrt = ip6_dst_alloc(dev_net(dev), dev, flags);
if (nrt)
ip6_rt_copy_init(nrt, rt);
+ else
+ fib6_info_release(rt);
return nrt;
}
@@ -1178,10 +1184,15 @@ static struct rt6_info *ip6_rt_cache_alloc(struct fib6_info *ort,
* Clone the route.
*/
+ if (!fib6_info_hold_safe(ort))
+ return NULL;
+
dev = ip6_rt_get_dev_rcu(ort);
rt = ip6_dst_alloc(dev_net(dev), dev, 0);
- if (!rt)
+ if (!rt) {
+ fib6_info_release(ort);
return NULL;
+ }
ip6_rt_copy_init(rt, ort);
rt->rt6i_flags |= RTF_CACHE;
@@ -1210,12 +1221,17 @@ static struct rt6_info *ip6_rt_pcpu_alloc(struct fib6_info *rt)
struct net_device *dev;
struct rt6_info *pcpu_rt;
+ if (!fib6_info_hold_safe(rt))
+ return NULL;
+
rcu_read_lock();
dev = ip6_rt_get_dev_rcu(rt);
pcpu_rt = ip6_dst_alloc(dev_net(dev), dev, flags);
rcu_read_unlock();
- if (!pcpu_rt)
+ if (!pcpu_rt) {
+ fib6_info_release(rt);
return NULL;
+ }
ip6_rt_copy_init(pcpu_rt, rt);
pcpu_rt->rt6i_flags |= RTF_PCPU;
return pcpu_rt;
@@ -2486,7 +2502,7 @@ static struct rt6_info *__ip6_route_redirect(struct net *net,
out:
if (ret)
- dst_hold(&ret->dst);
+ ip6_hold_safe(net, &ret, true);
else
ret = ip6_create_rt_rcu(rt);
@@ -3303,7 +3319,8 @@ static int ip6_route_del(struct fib6_config *cfg,
continue;
if (cfg->fc_protocol && cfg->fc_protocol != rt->fib6_protocol)
continue;
- fib6_info_hold(rt);
+ if (!fib6_info_hold_safe(rt))
+ continue;
rcu_read_unlock();
/* if gateway was specified only delete the one hop */
@@ -3409,6 +3426,9 @@ static void rt6_do_redirect(struct dst_entry *dst, struct sock *sk, struct sk_bu
rcu_read_lock();
from = rcu_dereference(rt->from);
+ /* This fib6_info_hold() is safe here because we hold reference to rt
+ * and rt already holds reference to fib6_info.
+ */
fib6_info_hold(from);
rcu_read_unlock();
@@ -3470,7 +3490,8 @@ static struct fib6_info *rt6_get_route_info(struct net *net,
continue;
if (!ipv6_addr_equal(&rt->fib6_nh.nh_gw, gwaddr))
continue;
- fib6_info_hold(rt);
+ if (!fib6_info_hold_safe(rt))
+ continue;
break;
}
out:
@@ -3530,8 +3551,8 @@ struct fib6_info *rt6_get_dflt_router(struct net *net,
ipv6_addr_equal(&rt->fib6_nh.nh_gw, addr))
break;
}
- if (rt)
- fib6_info_hold(rt);
+ if (rt && !fib6_info_hold_safe(rt))
+ rt = NULL;
rcu_read_unlock();
return rt;
}
@@ -3579,8 +3600,8 @@ static void __rt6_purge_dflt_routers(struct net *net,
struct inet6_dev *idev = dev ? __in6_dev_get(dev) : NULL;
if (rt->fib6_flags & (RTF_DEFAULT | RTF_ADDRCONF) &&
- (!idev || idev->cnf.accept_ra != 2)) {
- fib6_info_hold(rt);
+ (!idev || idev->cnf.accept_ra != 2) &&
+ fib6_info_hold_safe(rt)) {
rcu_read_unlock();
ip6_del_rt(net, rt);
goto restart;
--
2.18.0.233.g985f88cf7e-goog
^ permalink raw reply related
* Re: [PATCH net-next 0/9] TX used ring batched updating for vhost
From: David Miller @ 2018-07-22 4:44 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1532045721-4958-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 20 Jul 2018 08:15:12 +0800
> This series implement batch updating of used ring for TX. This help to
> reduce the cache contention on used ring. The idea is first split
> datacopy path from zerocopy, and do only batching for datacopy. This
> is because zercopy had already supported its own batching.
>
> TX PPS was increased 25.8% and Netperf TCP does not show obvious
> differences.
>
> The split of datapath will also be helpful for future implementation
> like in order completion.
>
> Please review.
Jason, I really like the way you composed this patch series, it was
very easy to read and understand. :-)
Michael, please review.
^ permalink raw reply
* Re: [PATCH 4/4] net: dsa: Add Lantiq / Intel DSA driver for vrx200
From: David Miller @ 2018-07-22 3:17 UTC (permalink / raw)
To: hauke
Cc: netdev, andrew, vivien.didelot, f.fainelli, john, linux-mips, dev,
hauke.mehrtens
In-Reply-To: <20180721191358.13952-5-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sat, 21 Jul 2018 21:13:58 +0200
> + // start the table access:
Please stick to C-style comments, except perhaps in the SPDX
identifiers.
Thank you.
^ permalink raw reply
* Re: [PATCH net] net: skb_segment() should not return NULL
From: David Miller @ 2018-07-22 2:35 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, alexander.h.duyck
In-Reply-To: <20180719230438.190659-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Thu, 19 Jul 2018 16:04:38 -0700
> syzbot caught a NULL deref [1], caused by skb_segment()
>
> skb_segment() has many "goto err;" that assume the @err variable
> contains -ENOMEM.
>
> A successful call to __skb_linearize() should not clear @err,
> otherwise a subsequent memory allocation error could return NULL.
Ugh, good catch.
> While we are at it, we might use -EINVAL instead of -ENOMEM when
> MAX_SKB_FRAGS limit is reached.
...
> Fixes: ddff00d42043 ("net: Move skb_has_shared_frag check out of GRE code and into segmentation")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net/ipv6: Fix linklocal to global address with VRF
From: David Miller @ 2018-07-22 2:32 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20180719194118.25346-1-dsahern@kernel.org>
From: dsahern@kernel.org
Date: Thu, 19 Jul 2018 12:41:18 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Example setup:
> host: ip -6 addr add dev eth1 2001:db8:104::4
> where eth1 is enslaved to a VRF
>
> switch: ip -6 ro add 2001:db8:104::4/128 dev br1
> where br1 only has an LLA
>
> ping6 2001:db8:104::4
> ssh 2001:db8:104::4
>
> (NOTE: UDP works fine if the PKTINFO has the address set to the global
> address and ifindex is set to the index of eth1 with a destination an
> LLA).
>
> For ICMP, icmp6_iif needs to be updated to check if skb->dev is an
> L3 master. If it is then return the ifindex from rt6i_idev similar
> to what is done for loopback.
>
> For TCP, restore the original tcp_v6_iif definition which is needed in
> most places and add a new tcp_v6_iif_l3_slave that considers the
> l3_slave variability. This latter check is only needed for socket
> lookups.
>
> Fixes: 9ff74384600a ("net: vrf: Handle ipv6 multicast and link-local addresses")
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied and queued up for -stable.
> Dave: I can look at the backports to stable if needed.
Please do, that will help me a lot.
^ permalink raw reply
* Re: [PATCH] net: phy: sfp: Do not use "imply HWMON"
From: David Miller @ 2018-07-22 2:27 UTC (permalink / raw)
To: linux; +Cc: andrew, f.fainelli, netdev, linux-kernel
In-Reply-To: <1532018499-16490-1-git-send-email-linux@roeck-us.net>
From: Guenter Roeck <linux@roeck-us.net>
Date: Thu, 19 Jul 2018 09:41:39 -0700
> "imply HWMON" was supposed to ensure that the SFP phy code can be built
> with HWMON enabled or disabled while at the same time ensuring that
> HWMON is not built as module if SFP is built into the kernel.
> Unfortunately, that does not work as intended. With "allmodconfig", it
> results in several unrelated HWMON drivers to be disabled instead of
> being built as module as expected.
>
> Let's use the old "depends on HWMON || HWMON=n" instead. This is slightly
> different (it enforces SFP to be built as module if HWMON is built as
> module), but it is better than the alternative of using "IS_REACHABLE()"
> in the driver since that would disable sensor support if HWMON is built
> as module and SFP is built into the kernel.
>
> Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
> Cc: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Applied, thanks.
^ permalink raw reply
* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: David Miller @ 2018-07-22 2:25 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson
In-Reply-To: <20180719162613.27184-4-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Thu, 19 Jul 2018 21:56:13 +0530
> In function decrypt_skb(), array allocation in case when sgout is NULL
> is unnecessary. Instead, local variable sgin_arr[] can be used.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Hmmm...
Dave, can you take a look at this? Do you think there might have
been a reason you felt that you needed to dynamically allocate
the scatterlists when you COW and skb and do in-place decryption?
I guess this change is ok, nsg can only get smaller when the SKB
is COW'd.
^ permalink raw reply
* [PATCH] netlink: fix memory leak
From: Shaochun Chen @ 2018-07-22 2:49 UTC (permalink / raw)
To: pablo
Cc: kadlec, fw, davem, johannes.berg, pombredanne, kstewart, cscnull,
gregkh, Jason, dsahern, lucien.xin, ktkhai, xiyou.wangcong,
linux-kernel, netfilter-devel, coreteam, netdev
when netlink_dump start failed, netlink_callback will not be called,
and the memory which pointed by control->data will leak. so if netlink_dump
start fail, call control->done to free the memory.
Signed-off-by: Shaochun Chen <cscnull@gmail.com>
---
include/linux/netlink.h | 10 ++++++++++
net/netfilter/nf_tables_api.c | 4 +++-
net/netlink/af_netlink.c | 4 ++++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index f3075d6c7e82..9d6b3edc5a5b 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -214,6 +214,16 @@ static inline int netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
return __netlink_dump_start(ssk, skb, nlh, control);
}
+static inline void netlink_dump_start_fail(struct netlink_dump_control *control)
+{
+ struct netlink_callback cb = {
+ .data = control->data,
+ };
+
+ if (control->done)
+ control->done(&cb);
+}
+
struct netlink_tap {
struct net_device *dev;
struct module *module;
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 896d4a36081d..dc30a329f785 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -588,8 +588,10 @@ static int nft_netlink_dump_start_rcu(struct sock *nlsk, struct sk_buff *skb,
{
int err;
- if (!try_module_get(THIS_MODULE))
+ if (!try_module_get(THIS_MODULE)) {
+ netlink_dump_start_fail(c);
return -EINVAL;
+ }
rcu_read_unlock();
err = netlink_dump_start(nlsk, skb, nlh, c);
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 393573a99a5a..7b85176cf9bb 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2275,6 +2275,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
struct netlink_callback *cb;
struct sock *sk;
struct netlink_sock *nlk;
+ bool cb_running = false;
int ret;
refcount_inc(&skb->users);
@@ -2317,6 +2318,7 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
nlk->cb_running = true;
nlk->dump_done_errno = INT_MAX;
+ cb_running = true;
mutex_unlock(nlk->cb_mutex);
@@ -2339,6 +2341,8 @@ int __netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
mutex_unlock(nlk->cb_mutex);
error_free:
kfree_skb(skb);
+ if (cb_running)
+ netlink_dump_start_fail(control);
return ret;
}
EXPORT_SYMBOL(__netlink_dump_start);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net: wimax: stack: fixed multi line comment issue
From: David Miller @ 2018-07-22 2:36 UTC (permalink / raw)
To: mark; +Cc: inaky.perez-gonzalez, linux-wimax, netdev, linux-kernel
In-Reply-To: <20180719231146.24532-1-mark@markrailton.com>
From: Mark Railton <mark@markrailton.com>
Date: Fri, 20 Jul 2018 00:11:46 +0100
> Moved end of comment to it's own line per guide
>
> Signed-off-by: Mark Railton <mark@markrailton.com>
Applied, thanks.
^ permalink raw reply
* hard-coded limit on unresolved multicast route cache in ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy networks
From: Phil Karn @ 2018-07-22 1:31 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev,
linux-kernel
I'm running pimd (protocol independent multicast routing) and found that
on busy networks with lots of unresolved multicast routing entries, the
creation of new multicast group routes can be extremely slow and
unreliable, especially when the group in question has little traffic.
A google search revealed the following conversation about the problem
from the fall of 2015:
https://github.com/troglobit/pimd/issues/58
Note especially the comment by kopren on Sep 13, 2016.
The writer traced the problem to function ipmr_cache_unresolved() in
file net/ipmr.c, in the following block of code:
/* Create a new entry if allowable */
if (atomic_read(&mrt->cache_resolve_queue_len) >= 10 ||
(c = ipmr_cache_alloc_unres()) == NULL) {
spin_unlock_bh(&mfc_unres_lock);
kfree_skb(skb);
return -ENOBUFS;
}
This imposes a hard-wired limit of 10 multicast route entries with
unresolved source addresses and upstream interfaces. My problem system
sits on a busy subnet at UC San Diego, and when I run the command 'ip
mroute show' there are almost always exactly 10 unresolved multicast
routes. The authors reported that removing this limit solved their
problem, but I still see the test in the just-released kernel version
4.17.8.
I don't have this problem on my home network or on a small network at a
local high school, both networks having fewer active multicast groups.
The problem only shows up at UCSD.
The problem is most acute with a multicast group that generates only one
packet (decoded ham radio location tracking packets) every 10 seconds or
so. The multicast route *never* resolves and traffic never gets through.
The problem is also severe with a multicast group generating
intermittent bursts of traffic with seconds of idle time between bursts
(audio PCM from a software defined FM receiver with a squelch that stops
the traffic when there's no signal). However, when the receiver is tuned
to NOAA Weather Radio (which generates a continuous stream of traffic)
multicast routing generally worked.
The *only* difference between these three cases was the intensity of
traffic in the multicast groups.
Does this hard-coded limit serve any purpose? Can it be safely increased
to a much larger value, or better yet, removed altogether? If it can't
be removed, can it at least be made configurable through a /proc entry?
Thanks,
Phil Karn, KA9Q
^ permalink raw reply
* Re: [PATCH net-next 4/4] act_mirred: use ACT_MIRRED when possible
From: David Miller @ 2018-07-21 23:29 UTC (permalink / raw)
To: pabeni
Cc: netdev, jhs, xiyou.wangcong, jiri, daniel, marcelo.leitner,
eyal.birger
In-Reply-To: <f8a7309955a6e634c318741606756435920d6cc4.1531941678.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Thu, 19 Jul 2018 15:02:29 +0200
> kernel openswitch datapath.
^^^^^^^^^^
"openvswitch"
^ permalink raw reply
* Re: [PATCH net] net: phy: consider PHY_IGNORE_INTERRUPT in phy_start_aneg_priv
From: David Miller @ 2018-07-21 23:21 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <e6770015-4b52-d0ff-fc98-9e0b8f34be6b@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 19 Jul 2018 08:15:16 +0200
> The situation described in the comment can occur also with
> PHY_IGNORE_INTERRUPT, therefore change the condition to include it.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net 0/3] qed: Fix series II.
From: David Miller @ 2018-07-21 23:19 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Michal.Kalderon, ariel.elior
In-Reply-To: <20180719055004.23556-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed, 18 Jul 2018 22:50:01 -0700
> The patch series fixes few issues in the qed driver.
>
> Please consider applying it to 'net' branch.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver
From: Hauke Mehrtens @ 2018-07-21 23:18 UTC (permalink / raw)
To: John Crispin
Cc: davem, netdev, andrew, vivien.didelot, f.fainelli, linux-mips,
dev, hauke.mehrtens
In-Reply-To: <4f39ca41-bcad-4b04-65dd-3570cb3ce804@phrozen.org>
On 07/21/2018 10:25 PM, John Crispin wrote:
>
>
> On 21/07/18 21:13, Hauke Mehrtens wrote:
>> + * Copyright (C) 2012 John Crispin<blogic@openwrt.org>
> that is not my mail addr :-)
> John
Thanks for the information, I fixed your mail address.
Hauke
^ permalink raw reply
* Re: [PATCH net-next] libcxgb: replace vmalloc and memset with vzalloc
From: David Miller @ 2018-07-21 23:33 UTC (permalink / raw)
To: yuehaibing; +Cc: linux-kernel, netdev
In-Reply-To: <20180719141827.7776-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 19 Jul 2018 22:18:27 +0800
> Use vzalloc instead of the vmalloc, memset combo
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: hix5hd2_gmac: use dma_zalloc_coherent instead of allocator/memset
From: David Miller @ 2018-07-21 23:31 UTC (permalink / raw)
To: yuehaibing; +Cc: yisen.zhuang, salil.mehta, linux-kernel, netdev
In-Reply-To: <20180719135711.5656-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 19 Jul 2018 21:57:11 +0800
> Use dma_zalloc_coherent instead of dma_alloc_coherent
> followed by memset 0.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tipc: make some functions static
From: David Miller @ 2018-07-21 23:23 UTC (permalink / raw)
To: yuehaibing; +Cc: jon.maloy, ying.xue, linux-kernel, netdev, tipc-discussion
In-Reply-To: <20180719091659.20248-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 19 Jul 2018 17:16:59 +0800
> Fixes the following sparse warnings:
>
> net/tipc/link.c:376:5: warning: symbol 'link_bc_rcv_gap' was not declared. Should it be static?
> net/tipc/link.c:823:6: warning: symbol 'link_prepare_wakeup' was not declared. Should it be static?
> net/tipc/link.c:959:6: warning: symbol 'tipc_link_advance_backlog' was not declared. Should it be static?
> net/tipc/link.c:1009:5: warning: symbol 'tipc_link_retrans' was not declared. Should it be static?
> net/tipc/monitor.c:687:5: warning: symbol '__tipc_nl_add_monitor_peer' was not declared. Should it be static?
> net/tipc/group.c:230:20: warning: symbol 'tipc_group_find_member' was not declared. Should it be static?
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 bpf-next] bpfilter: Fix mismatch in function argument types
From: David Miller @ 2018-07-21 23:21 UTC (permalink / raw)
To: daniel; +Cc: kafai, yuehaibing, ast, linux-kernel, netdev
In-Reply-To: <9c9f981b-7d1e-1bb2-6771-727fc762c7c5@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Thu, 19 Jul 2018 17:51:41 +0200
> On 07/19/2018 05:48 PM, Martin KaFai Lau wrote:
>> On Thu, Jul 19, 2018 at 03:56:59PM +0800, YueHaibing wrote:
>>> Fix following warning:
>>> net/ipv4/bpfilter/sockopt.c:28:5: error: symbol 'bpfilter_ip_set_sockopt' redeclared with different type
>>> net/ipv4/bpfilter/sockopt.c:34:5: error: symbol 'bpfilter_ip_get_sockopt' redeclared with different type
>>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> LGTM. Missing a Fixes tag though.
>>
>> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
>> Acked-by: Martin KaFai Lau <kafai@fb.com>
>
> (Should go to -net tree.)
>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Applied.
^ permalink raw reply
* Re: [PATCH] net: sched: use PTR_ERR_OR_ZERO macro in tcf_block_cb_register
From: David Miller @ 2018-07-21 23:17 UTC (permalink / raw)
To: gustavo; +Cc: jhs, xiyou.wangcong, jiri, netdev, linux-kernel
In-Reply-To: <20180719041417.GA21061@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Wed, 18 Jul 2018 23:14:17 -0500
> This line makes up what macro PTR_ERR_OR_ZERO already does. So,
> make use of PTR_ERR_OR_ZERO rather than an open-code version.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: caif: Add a missing rcu_read_unlock() in caif_flow_cb
From: David Miller @ 2018-07-21 23:16 UTC (permalink / raw)
To: yuehaibing; +Cc: dmitry.tarnyagin, linux-kernel, netdev
In-Reply-To: <20180719022713.17324-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 19 Jul 2018 10:27:13 +0800
> Add a missing rcu_read_unlock in the error path
>
> Fixes: c95567c80352 ("caif: added check for potential null return")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] net: lantiq: Add Lantiq / Intel vrx200 Ethernet driver
From: John Crispin @ 2018-07-21 20:25 UTC (permalink / raw)
To: Hauke Mehrtens, davem
Cc: netdev, andrew, vivien.didelot, f.fainelli, linux-mips, dev,
hauke.mehrtens
In-Reply-To: <20180721191358.13952-4-hauke@hauke-m.de>
On 21/07/18 21:13, Hauke Mehrtens wrote:
> + * Copyright (C) 2012 John Crispin<blogic@openwrt.org>
that is not my mail addr :-)
John
^ permalink raw reply
* [PATCH] net: prevent ISA drivers from building on PPC32
From: Randy Dunlap @ 2018-07-21 19:59 UTC (permalink / raw)
To: PowerPC, Michael Ellerman, netdev@vger.kernel.org, David Miller
From: Randy Dunlap <rdunlap@infradead.org>
Prevent drivers from building on PPC32 if they use isa_bus_to_virt(),
isa_virt_to_bus(), or isa_page_to_bus(), which are not available and
thus cause build errors.
../drivers/net/ethernet/3com/3c515.c: In function 'corkscrew_open':
../drivers/net/ethernet/3com/3c515.c:824:9: error: implicit declaration of function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? [-Werror=implicit-function-declaration]
../drivers/net/ethernet/amd/lance.c: In function 'lance_rx':
../drivers/net/ethernet/amd/lance.c:1203:23: error: implicit declaration of function 'isa_bus_to_virt'; did you mean 'bus_to_virt'? [-Werror=implicit-function-declaration]
../drivers/net/ethernet/amd/ni65.c: In function 'ni65_init_lance':
../drivers/net/ethernet/amd/ni65.c:585:20: error: implicit declaration of function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? [-Werror=implicit-function-declaration]
../drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open':
../drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? [-Werror=implicit-function-declaration]
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
---
in cirrus/Kconfig, CS89x0 should probably also depend on ISA_DMA_API.
drivers/net/ethernet/3com/Kconfig | 2 +-
drivers/net/ethernet/amd/Kconfig | 4 ++--
drivers/net/ethernet/cirrus/Kconfig | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
--- linux-next-20180720.orig/drivers/net/ethernet/3com/Kconfig
+++ linux-next-20180720/drivers/net/ethernet/3com/Kconfig
@@ -32,7 +32,7 @@ config EL3
config 3C515
tristate "3c515 ISA \"Fast EtherLink\""
- depends on ISA && ISA_DMA_API
+ depends on ISA && ISA_DMA_API && !PPC32
---help---
If you have a 3Com ISA EtherLink XL "Corkscrew" 3c515 Fast Ethernet
network card, say Y here.
--- linux-next-20180720.orig/drivers/net/ethernet/amd/Kconfig
+++ linux-next-20180720/drivers/net/ethernet/amd/Kconfig
@@ -44,7 +44,7 @@ config AMD8111_ETH
config LANCE
tristate "AMD LANCE and PCnet (AT1500 and NE2100) support"
- depends on ISA && ISA_DMA_API && !ARM
+ depends on ISA && ISA_DMA_API && !ARM && !PPC32
---help---
If you have a network (Ethernet) card of this type, say Y here.
Some LinkSys cards are of this type.
@@ -138,7 +138,7 @@ config PCMCIA_NMCLAN
config NI65
tristate "NI6510 support"
- depends on ISA && ISA_DMA_API && !ARM
+ depends on ISA && ISA_DMA_API && !ARM && !PPC32
---help---
If you have a network (Ethernet) card of this type, say Y here.
--- linux-next-20180720.orig/drivers/net/ethernet/cirrus/Kconfig
+++ linux-next-20180720/drivers/net/ethernet/cirrus/Kconfig
@@ -19,6 +19,7 @@ if NET_VENDOR_CIRRUS
config CS89x0
tristate "CS89x0 support"
depends on ISA || EISA || ARM
+ depends on !PPC32
---help---
Support for CS89x0 chipset based Ethernet cards. If you have a
network (Ethernet) card of this type, say Y and read the file
^ 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