* Re: [PATCH V2 2/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used()
From: Jason Wang @ 2013-09-02 6:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20130902055048.GA19838@redhat.com>
On 09/02/2013 01:50 PM, Michael S. Tsirkin wrote:
> On Fri, Aug 30, 2013 at 12:29:18PM +0800, Jason Wang wrote:
>> > We tend to batch the used adding and signaling in vhost_zerocopy_callback()
>> > which may result more than 100 used buffers to be updated in
>> > vhost_zerocopy_signal_used() in some cases. So wwitch to use
> switch
Ok.
>> > vhost_add_used_and_signal_n() to avoid multiple calls to
>> > vhost_add_used_and_signal(). Which means much more less times of used index
>> > updating and memory barriers.
> pls put info on perf gain in commit log too
>
Sure.
^ permalink raw reply
* [PATCH v4] ipv6:introduce function to find route for redirect
From: Duan Jiong @ 2013-09-02 6:14 UTC (permalink / raw)
To: davem; +Cc: duanj.fnst, netdev, hannes
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
RFC 4861 says that the IP source address of the Redirect is the
same as the current first-hop router for the specified ICMP
Destination Address, so the gateway should be taken into
consideration when we find the route for redirect.
There was once a check in commit
a6279458c534d01ccc39498aba61c93083ee0372 ("NDISC: Search over
all possible rules on receipt of redirect.") and the check
went away in commit b94f1c0904da9b8bf031667afc48080ba7c3e8c9
("ipv6: Use icmpv6_notify() to propagate redirect, instead of
rt6_redirect()").
The bug is only "exploitable" on layer-2 because the source
address of the redirect is checked to be a valid link-local
address but it makes spoofing a lot easier in the same L2
domain nonetheless.
Thanks very much for Hannes's help.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
Changes for v4:
1.Fix the intended problems
2.Change the ordering of the arguments in function
ip6_route_redirect
3.Drop the unnecessary flag RT6_LOOKUP_F_IFACE
4.Check the dst.error when look up route for redirect
net/ipv6/ah6.c | 2 +-
net/ipv6/esp6.c | 2 +-
net/ipv6/icmp.c | 2 +-
net/ipv6/ipcomp6.c | 2 +-
net/ipv6/ndisc.c | 3 ++-
net/ipv6/route.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++-----
6 files changed, 77 insertions(+), 11 deletions(-)
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index bb02e17..73784c3 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -628,7 +628,7 @@ static void ah6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
return;
if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, 0, 0);
+ ip6_redirect(skb, net, skb->dev->ifindex, 0);
else
ip6_update_pmtu(skb, net, info, 0, 0);
xfrm_state_put(x);
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index aeac0dc..d3618a7 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -447,7 +447,7 @@ static void esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
return;
if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, 0, 0);
+ ip6_redirect(skb, net, skb->dev->ifindex, 0);
else
ip6_update_pmtu(skb, net, info, 0, 0);
xfrm_state_put(x);
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 7cfc8d2..73681c2 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -92,7 +92,7 @@ static void icmpv6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
if (type == ICMPV6_PKT_TOOBIG)
ip6_update_pmtu(skb, net, info, 0, 0);
else if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, 0, 0);
+ ip6_redirect(skb, net, skb->dev->ifindex, 0);
if (!(type & ICMPV6_INFOMSG_MASK))
if (icmp6->icmp6_type == ICMPV6_ECHO_REQUEST)
diff --git a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c
index 7af5aee..5636a91 100644
--- a/net/ipv6/ipcomp6.c
+++ b/net/ipv6/ipcomp6.c
@@ -76,7 +76,7 @@ static void ipcomp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
return;
if (type == NDISC_REDIRECT)
- ip6_redirect(skb, net, 0, 0);
+ ip6_redirect(skb, net, skb->dev->ifindex, 0);
else
ip6_update_pmtu(skb, net, info, 0, 0);
xfrm_state_put(x);
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 04d31c2..70abece 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1370,7 +1370,8 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
return;
if (!ndopts.nd_opts_rh) {
- ip6_redirect_no_header(skb, dev_net(skb->dev), 0, 0);
+ ip6_redirect_no_header(skb, dev_net(skb->dev),
+ skb->dev->ifindex, 0);
return;
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 8d9a93e..a01337f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1157,6 +1157,73 @@ void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
}
EXPORT_SYMBOL_GPL(ip6_sk_update_pmtu);
+/* Handle redirects */
+struct ip6rd_flowi {
+ struct flowi6 fl6;
+ struct in6_addr gateway;
+};
+
+static struct rt6_info *__ip6_route_redirect(struct net *net,
+ struct fib6_table *table,
+ struct flowi6 *fl6,
+ int flags)
+{
+ struct ip6rd_flowi *rdfl = (struct ip6rd_flowi *)fl6;
+ struct rt6_info *rt;
+ struct fib6_node *fn;
+
+ /* Get the "current" route for this destination and
+ * check if the redirect has come from approriate router.
+ *
+ * RFC 4861 specifies that redirects should only be
+ * accepted if they come from the nexthop to the target.
+ * Due to the way the routes are chosen, this notion
+ * is a bit fuzzy and one might need to check all possible
+ * routes.
+ */
+
+ read_lock_bh(&table->tb6_lock);
+ fn = fib6_lookup(&table->tb6_root, &fl6->daddr, &fl6->saddr);
+restart:
+ for (rt = fn->leaf; rt; rt = rt->dst.rt6_next) {
+ if (rt6_check_expired(rt))
+ continue;
+ if (rt->dst.error)
+ continue;
+ if (!(rt->rt6i_flags & RTF_GATEWAY))
+ continue;
+ if (fl6->flowi6_oif != rt->dst.dev->ifindex)
+ continue;
+ if (!ipv6_addr_equal(&rdfl->gateway, &rt->rt6i_gateway))
+ continue;
+ break;
+ }
+
+ if (!rt)
+ rt = net->ipv6.ip6_null_entry;
+ BACKTRACK(net, &fl6->saddr);
+out:
+ dst_hold(&rt->dst);
+
+ read_unlock_bh(&table->tb6_lock);
+
+ return rt;
+};
+
+static struct dst_entry *ip6_route_redirect(struct net *net,
+ const struct flowi6 *fl6,
+ const struct in6_addr *gateway)
+{
+ int flags = RT6_LOOKUP_F_HAS_SADDR;
+ struct ip6rd_flowi rdfl;
+
+ rdfl.fl6 = *fl6;
+ rdfl.gateway = *gateway;
+
+ return fib6_rule_lookup(net, &rdfl.fl6,
+ flags, __ip6_route_redirect);
+}
+
void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
{
const struct ipv6hdr *iph = (struct ipv6hdr *) skb->data;
@@ -1171,9 +1238,8 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
fl6.saddr = iph->saddr;
fl6.flowlabel = ip6_flowinfo(iph);
- dst = ip6_route_output(net, NULL, &fl6);
- if (!dst->error)
- rt6_do_redirect(dst, NULL, skb);
+ dst = ip6_route_redirect(net, &fl6, &ipv6_hdr(skb)->saddr);
+ rt6_do_redirect(dst, NULL, skb);
dst_release(dst);
}
EXPORT_SYMBOL_GPL(ip6_redirect);
@@ -1193,9 +1259,8 @@ void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif,
fl6.daddr = msg->dest;
fl6.saddr = iph->daddr;
- dst = ip6_route_output(net, NULL, &fl6);
- if (!dst->error)
- rt6_do_redirect(dst, NULL, skb);
+ dst = ip6_route_redirect(net, &fl6, &iph->saddr);
+ rt6_do_redirect(dst, NULL, skb);
dst_release(dst);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3] ipv6:introduce function to find route for redirect
From: Duan Jiong @ 2013-09-02 6:07 UTC (permalink / raw)
To: hannes; +Cc: davem, netdev
In-Reply-To: <5223FA1C.5020501@cn.fujitsu.com>
于 2013年09月02日 10:38, Duan Jiong 写道:
>>> void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>>
>> Maybe we should rename oif to iif now?
> Yes, that looks no ambiguity.
I'm sorry about that.
I finally think that there is no need to rename oif to iif, because
the argument oif will be assigned to fl6.flowi6_oif, and if we
rename it, others will be confused by this.
Thanks,
Duan
^ permalink raw reply
* Re: 3.11-rc7:BUG: soft lockup
From: Baoquan He @ 2013-09-02 6:06 UTC (permalink / raw)
To: Hillf Danton; +Cc: Cong Wang, LKML, Linux Kernel Network Developers
In-Reply-To: <CAJd=RBCT6dbLwX6z+1LxCvJ9-NOYQRe0zzBkEQosFgLvNgg4bg@mail.gmail.com>
Hi both,
Thanks for your patches. I tried to test your patches, first the 2nd
one, namely Hillf's patch, it's OK. Then when I wanted to reproduce and
test Cong's patch, it failed to happen again.
I remember this bug happened randomly at the very beginning,
just after kernel compiling it always happened one day.
So maybe when it happened again, I will test your patch separately.
Baoquan
Thanks
On 08/31/2013 11:25 AM, Hillf Danton wrote:
> On Fri, Aug 30, 2013 at 8:18 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> Cc'ing netdev
>>
>> On Fri, Aug 30, 2013 at 4:20 PM, Baoquan He <baoquan.he@gmail.com> wrote:
>>> Hi,
>>>
>>> I tried the 3.11.0-rc7+ on x86_64, and after bootup, the soft lockup bug
>>> happened.
>>>
>>> [ 48.895000] BUG: soft lockup - CPU#1 stuck for 22s! [ebtables:444]
>>> [ 48.901191] Modules linked in: bnep(F) bluetooth(F) ebtables(F)
>>> ip6table_filter(F) ip6_tables(F) rfkill(F) snd_hda_intel(F+)
>>> snd_hda_codec(F) snd_hwdep(F) snd_seq(F) sn)
>>> [ 48.950034] CPU: 1 PID: 444 Comm: ebtables Tainted: GF D
>>> 3.11.0-rc7+ #1
>>> [ 48.957433] Hardware name: Hewlett-Packard HP Z420 Workstation/1589,
>>> BIOS J61 v01.02 03/09/2012
>>> [ 48.966131] task: ffff88040c2dc650 ti: ffff8804187d2000 task.ti:
>>> ffff8804187d2000
>>> [ 48.973610] RIP: 0010:[<ffffffff812e57a7>] [<ffffffff812e57a7>]
>>> strcmp+0x27/0x40
>>> [ 48.981119] RSP: 0018:ffff8804187d3db8 EFLAGS: 00000246
>>> [ 48.986430] RAX: 0000000000000000 RBX: 00007fffda942730 RCX:
>>> ffff8804187d3fd8
>>> [ 48.993566] RDX: 0000000000000000 RSI: ffff8804187d3e01 RDI:
>>> ffffffff81cb8a39
>>> [ 49.000707] RBP: ffff8804187d3db8 R08: 00000000fffffff2 R09:
>>> 0000000000000000
>>> [ 49.007841] R10: 0000000000000163 R11: 0000000000000000 R12:
>>> ffffffff8128300c
>>> [ 49.014972] R13: ffff8804187d3d98 R14: ffff8804187d3ef4 R15:
>>> 0000000000000004
>>> [ 49.022112] FS: 00007faab6589740(0000) GS:ffff88042fc80000(0000)
>>> knlGS:0000000000000000
>>> [ 49.030194] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 49.035942] CR2: 0000003f0d810414 CR3: 000000040d2cc000 CR4:
>>> 00000000000407e0
>>> [ 49.043077] Stack:
>>> [ 49.045096] ffff8804187d3de8 ffffffffa0249674 0000000000000080
>>> ffffffff81cb8180
>>> [ 49.052559] 00007fffda942730 ffff8804187d3ef4 ffff8804187d3ea0
>>> ffffffffa02497a9
>>> [ 49.060020] 0000000000000000 00007265746c6966 0000003f0d7b92c0
>>> 00007fffda942850
>>> [ 49.067487] Call Trace:
>>> [ 49.069949] [<ffffffffa0249674>]
>>> find_inlist_lock.constprop.16+0x54/0x100 [ebtables]
>>> [ 49.077779] [<ffffffffa02497a9>] do_ebt_get_ctl+0x89/0x1d0 [ebtables]
>>> [ 49.084306] [<ffffffff81551ca8>] nf_getsockopt+0x68/0x90
>>> [ 49.089717] [<ffffffff81560d40>] ip_getsockopt+0x80/0xa0
>>> [ 49.095113] [<ffffffff815835c5>] raw_getsockopt+0x25/0x50
>>> [ 49.100588] [<ffffffff8150ddd4>] sock_common_getsockopt+0x14/0x20
>>> [ 49.106766] [<ffffffff8150d208>] SyS_getsockopt+0x68/0xd0
>>> [ 49.112257] [<ffffffff8162c682>] system_call_fastpath+0x16/0x1b
>>> [ 49.118260] Code: 00 00 00 00 55 48 89 e5 eb 0e 66 2e 0f 1f 84 00 00
>>> 00 00 00 84 c0 74 1c 48 83 c7 01 0f b6 47 ff 48 83 c6 01 3a 46 ff 74 eb
>>> 19 c0 <83> c8 01 5d c3 0f 1
>>> [ 76.925880] BUG: soft lockup - CPU#1 stuck for 22s! [ebtables:444]
>>> [ 76.932069] Modules linked in: bnep(F) bluetooth(F) ebtables(F)
>>> ip6table_filter(F) ip6_tables(F) rfkill(F) snd_hda_intel(F+)
>>> snd_hda_codec(F) snd_hwdep(F) snd_seq(F) sn)
>>> [ 76.980847] CPU: 1 PID: 444 Comm: ebtables Tainted: GF D
>>> 3.11.0-rc7+ #1
>>> [ 76.988245] Hardware name: Hewlett-Packard HP Z420 Workstation/1589,
>>> BIOS J61 v01.02 03/09/2012
>>> [ 76.996940] task: ffff88040c2dc650 ti: ffff8804187d2000 task.ti:
>>> ffff8804187d2000
>>> [ 77.004426] RIP: 0010:[<ffffffff812e5784>] [<ffffffff812e5784>]
>>> strcmp+0x4/0x40
>>> [ 77.011849] RSP: 0018:ffff8804187d3db8 EFLAGS: 00000212
>>> [ 77.017163] RAX: 0000000000000001 RBX: 00007fffda942730 RCX:
>>> ffff8804187d3fd8
>>> [ 77.024304] RDX: 0000000000000000 RSI: ffff8804187d3e00 RDI:
>>> ffffffff81cb8a38
>>> [ 77.031434] RBP: ffff8804187d3db8 R08: 00000000fffffff2 R09:
>>> 0000000000000000
>>> [ 77.038566] R10: 0000000000000163 R11: 0000000000000000 R12:
>>> ffffffff8128300c
>>> [ 77.045699] R13: ffff8804187d3d98 R14: ffff8804187d3ef4 R15:
>>> 0000000000000004
>>> [ 77.052842] FS: 00007faab6589740(0000) GS:ffff88042fc80000(0000)
>>> knlGS:0000000000000000
>>> [ 77.060934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [ 77.066668] CR2: 0000003f0d810414 CR3: 000000040d2cc000 CR4:
>>> 00000000000407e0
>>> [ 77.073799] Stack:
>>> [ 77.075818] ffff8804187d3de8 ffffffffa0249674 0000000000000080
>>> ffffffff81cb8180
>>> [ 77.083287] 00007fffda942730 ffff8804187d3ef4 ffff8804187d3ea0
>>> ffffffffa02497a9
>>> [ 77.090749] 0000000000000000 00007265746c6966 0000003f0d7b92c0
>>> 00007fffda942850
>>> [ 77.098215] Call Trace:
>>> [ 77.100668] [<ffffffffa0249674>]
>>> find_inlist_lock.constprop.16+0x54/0x100 [ebtables]
>>> [ 77.108500] [<ffffffffa02497a9>] do_ebt_get_ctl+0x89/0x1d0 [ebtables]
>>> [ 77.115035] [<ffffffff81551ca8>] nf_getsockopt+0x68/0x90
>>> [ 77.120438] [<ffffffff81560d40>] ip_getsockopt+0x80/0xa0
>>> [ 77.125845] [<ffffffff815835c5>] raw_getsockopt+0x25/0x50
>>> [ 77.131328] [<ffffffff8150ddd4>] sock_common_getsockopt+0x14/0x20
>>> [ 77.137515] [<ffffffff8150d208>] SyS_getsockopt+0x68/0xd0
>>> [ 77.143011] [<ffffffff8162c682>] system_call_fastpath+0x16/0x1b
>>> [ 77.149019] Code: 0f 1f 80 00 00 00 00 48 83 c6 01 0f b6 4e ff 48 83
>>> c2 01 84 c9 88 4a ff 75 ed 5d c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48
>>> 89 e5 <eb> 0e 66 2e 0f 1f 8
>>
>> Does the following patch help?
>>
>>
>> diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
>> index ac78024..4a0ec8f 100644
>> --- a/net/bridge/netfilter/ebtables.c
>> +++ b/net/bridge/netfilter/ebtables.c
>> @@ -1503,6 +1503,10 @@ static int do_ebt_get_ctl(struct sock *sk, int
>> cmd, void __user *user, int *len)
>> if (copy_from_user(&tmp, user, sizeof(tmp)))
>> return -EFAULT;
>>
>> + if (memscan(tmp.name, '\0', EBT_TABLE_MAXNAMELEN) ==
>> + (tmp.name + EBT_TABLE_MAXNAMELEN))
>> + return -EINVAL;
>> +
>> t = find_table_lock(net, tmp.name, &ret, &ebt_mutex);
>> if (!t)
>> return ret;
>> --
>>
> release lock!!
>
> --- a/net/bridge/netfilter/ebtables.c Sat Aug 31 11:12:54 2013
> +++ b/net/bridge/netfilter/ebtables.c Sat Aug 31 11:15:24 2013
> @@ -332,8 +332,10 @@ find_inlist_lock_noload(struct list_head
> return NULL;
>
> list_for_each_entry(e, head, list) {
> - if (strcmp(e->name, name) == 0)
> + if (strcmp(e->name, name) == 0) {
> + mutex_unlock(mutex);
> return e;
> + }
> }
> *error = -ENOENT;
> mutex_unlock(mutex);
> --
^ permalink raw reply
* Re: [PATCH] batman: Remove reference to compare_ether_addr
From: Antonio Quartulli @ 2013-09-02 5:54 UTC (permalink / raw)
To: Joe Perches
Cc: Marek Lindner, Simon Wunderlich, David S. Miller, b.a.t.m.a.n,
netdev, LKML
In-Reply-To: <1378075508.1953.27.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
On Sun, Sep 01, 2013 at 03:45:08PM -0700, Joe Perches wrote:
> This function is being removed, rename the reference.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Thanks a lot Joe
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V2 6/6] vhost_net: correctly limit the max pending buffers
From: Michael S. Tsirkin @ 2013-09-02 5:56 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <1377836962-49780-7-git-send-email-jasowang@redhat.com>
On Fri, Aug 30, 2013 at 12:29:22PM +0800, Jason Wang wrote:
> As Michael point out, We used to limit the max pending DMAs to get better cache
> utilization. But it was not done correctly since it was one done when there's no
> new buffers submitted from guest. Guest can easily exceeds the limitation by
> keeping sending packets.
>
> So this patch moves the check into main loop. Tests shows about 5%-10%
> improvement on per cpu throughput for guest tx. But a 5% drop on per cpu
> transaction rate for a single session TCP_RR.
Any explanation for the drop? single session TCP_RR is unlikely to
exceed VHOST_MAX_PEND, correct?
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/net.c | 15 ++++-----------
> 1 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index d09c17c..592e1f2 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -363,6 +363,10 @@ static void handle_tx(struct vhost_net *net)
> if (zcopy)
> vhost_zerocopy_signal_used(net, vq);
>
> + if ((nvq->upend_idx + vq->num - VHOST_MAX_PEND) % UIO_MAXIOV ==
> + nvq->done_idx)
> + break;
> +
> head = vhost_get_vq_desc(&net->dev, vq, vq->iov,
> ARRAY_SIZE(vq->iov),
> &out, &in,
> @@ -372,17 +376,6 @@ static void handle_tx(struct vhost_net *net)
> break;
> /* Nothing new? Wait for eventfd to tell us they refilled. */
> if (head == vq->num) {
> - int num_pends;
> -
> - /* If more outstanding DMAs, queue the work.
> - * Handle upend_idx wrap around
> - */
> - num_pends = likely(nvq->upend_idx >= nvq->done_idx) ?
> - (nvq->upend_idx - nvq->done_idx) :
> - (nvq->upend_idx + UIO_MAXIOV -
> - nvq->done_idx);
> - if (unlikely(num_pends > VHOST_MAX_PEND))
> - break;
> if (unlikely(vhost_enable_notify(&net->dev, vq))) {
> vhost_disable_notify(&net->dev, vq);
> continue;
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH V2 1/6] vhost_net: make vhost_zerocopy_signal_used() returns void
From: Michael S. Tsirkin @ 2013-09-02 5:51 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <1377836962-49780-2-git-send-email-jasowang@redhat.com>
tweak subj s/returns/return/
On Fri, Aug 30, 2013 at 12:29:17PM +0800, Jason Wang wrote:
> None of its caller use its return value, so let it return void.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/net.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 969a859..280ee66 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -276,8 +276,8 @@ static void copy_iovec_hdr(const struct iovec *from, struct iovec *to,
> * of used idx. Once lower device DMA done contiguously, we will signal KVM
> * guest used idx.
> */
> -static int vhost_zerocopy_signal_used(struct vhost_net *net,
> - struct vhost_virtqueue *vq)
> +static void vhost_zerocopy_signal_used(struct vhost_net *net,
> + struct vhost_virtqueue *vq)
> {
> struct vhost_net_virtqueue *nvq =
> container_of(vq, struct vhost_net_virtqueue, vq);
> @@ -297,7 +297,6 @@ static int vhost_zerocopy_signal_used(struct vhost_net *net,
> }
> if (j)
> nvq->done_idx = i;
> - return j;
> }
>
> static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH V2 2/6] vhost_net: use vhost_add_used_and_signal_n() in vhost_zerocopy_signal_used()
From: Michael S. Tsirkin @ 2013-09-02 5:50 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <1377836962-49780-3-git-send-email-jasowang@redhat.com>
On Fri, Aug 30, 2013 at 12:29:18PM +0800, Jason Wang wrote:
> We tend to batch the used adding and signaling in vhost_zerocopy_callback()
> which may result more than 100 used buffers to be updated in
> vhost_zerocopy_signal_used() in some cases. So wwitch to use
switch
> vhost_add_used_and_signal_n() to avoid multiple calls to
> vhost_add_used_and_signal(). Which means much more less times of used index
> updating and memory barriers.
pls put info on perf gain in commit log too
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/net.c | 13 ++++++++-----
> 1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 280ee66..8a6dd0d 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -281,7 +281,7 @@ static void vhost_zerocopy_signal_used(struct vhost_net *net,
> {
> struct vhost_net_virtqueue *nvq =
> container_of(vq, struct vhost_net_virtqueue, vq);
> - int i;
> + int i, add;
> int j = 0;
>
> for (i = nvq->done_idx; i != nvq->upend_idx; i = (i + 1) % UIO_MAXIOV) {
> @@ -289,14 +289,17 @@ static void vhost_zerocopy_signal_used(struct vhost_net *net,
> vhost_net_tx_err(net);
> if (VHOST_DMA_IS_DONE(vq->heads[i].len)) {
> vq->heads[i].len = VHOST_DMA_CLEAR_LEN;
> - vhost_add_used_and_signal(vq->dev, vq,
> - vq->heads[i].id, 0);
> ++j;
> } else
> break;
> }
> - if (j)
> - nvq->done_idx = i;
> + while (j) {
> + add = min(UIO_MAXIOV - nvq->done_idx, j);
> + vhost_add_used_and_signal_n(vq->dev, vq,
> + &vq->heads[nvq->done_idx], add);
> + nvq->done_idx = (nvq->done_idx + add) % UIO_MAXIOV;
> + j -= add;
> + }
> }
>
> static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
> --
> 1.7.1
^ permalink raw reply
* Re: [PATCH] rtl8187: fix use after free on failure path in rtl8187_init_urbs()
From: Alexey Khoroshilov @ 2013-09-02 4:06 UTC (permalink / raw)
To: htl10
Cc: larry.finger, linville, linux-wireless, netdev, linux-kernel,
ldv-project, Greg Kroah-Hartman
In-Reply-To: <1378021881.73447.YahooMailBasic@web172302.mail.ir2.yahoo.com>
On 01.09.2013 10:51, Hin-Tak Leung wrote:
> ------------------------------
> On Sat, Aug 31, 2013 22:18 BST Alexey Khoroshilov wrote:
>
>> In case of __dev_alloc_skb() failure rtl8187_init_urbs()
>> calls usb_free_urb(entry) where 'entry' can points to urb
>> allocated at the previous iteration. That means refcnt will be
>> decremented incorrectly and the urb can be used after memory
>> deallocation.
>>
>> The patch fixes the issue and implements error handling of init_urbs
>> in rtl8187_start().
>>
>> Found by Linux Driver Verification project (linuxtesting.org).
>>
>> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
>> ---
>> drivers/net/wireless/rtl818x/rtl8187/dev.c | 15 ++++++++++-----
>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtl818x/rtl8187/dev.c b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> index f49220e..e83d53c 100644
>> --- a/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> +++ b/drivers/net/wireless/rtl818x/rtl8187/dev.c
>> @@ -438,17 +438,16 @@ static int rtl8187_init_urbs(struct ieee80211_hw *dev)
>> skb_queue_tail(&priv->rx_queue, skb);
>> usb_anchor_urb(entry, &priv->anchored);
>> ret = usb_submit_urb(entry, GFP_KERNEL);
>> + usb_free_urb(entry);
>> if (ret) {
>> skb_unlink(skb, &priv->rx_queue);
>> usb_unanchor_urb(entry);
>> goto err;
>> }
>> - usb_free_urb(entry);
>> }
>> return ret;
>>
>> err:
>> - usb_free_urb(entry);
>> kfree_skb(skb);
>> usb_kill_anchored_urbs(&priv->anchored);
>> return ret;
> This part looks wrong - you free_urb(entry) then unanchor_urb(entry).
I do not see any problems here.
usb_free_urb() just decrements refcnt of the urb.
While usb_anchor_urb() and usb_unanchor_urb() increment and decrement it
as well.
So actual memory deallocation will happen in usb_unanchor_urb().
>
>> @@ -956,8 +955,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
>> (RETRY_COUNT < 8 /* short retry limit */) |
>> (RETRY_COUNT < 0 /* long retry limit */) |
>> (7 < 21 /* MAX TX DMA */));
>> - rtl8187_init_urbs(dev);
>> - rtl8187b_init_status_urb(dev);
>> + ret = rtl8187_init_urbs(dev);
>> + if (ret)
>> + goto rtl8187_start_exit;
>> + ret = rtl8187b_init_status_urb(dev);
>> + if (ret)
>> + usb_kill_anchored_urbs(&priv->anchored);
>> goto rtl8187_start_exit;
>> }
>>
>> @@ -966,7 +969,9 @@ static int rtl8187_start(struct ieee80211_hw *dev)
>> rtl818x_iowrite32(priv, &priv->map->MAR[0], ~0);
>> rtl818x_iowrite32(priv, &priv->map->MAR[1], ~0);
>>
>> - rtl8187_init_urbs(dev);
>> + ret = rtl8187_init_urbs(dev);
>> + if (ret)
>> + goto rtl8187_start_exit;
>>
>> reg = RTL818X_RX_CONF_ONLYERLPKT |
>> RTL818X_RX_CONF_RX_AUTORESETPHY |
>> --
>> 1.8.1.2
>>
>
>
^ permalink raw reply
* confusion about tkey_extract_bits, please help.
From: ke wang @ 2013-09-02 3:46 UTC (permalink / raw)
To: netdev; +Cc: hacklinux66
hi:
i had a question about ipv6 routing in 2.6.39. what the algorithm of
the function tkey_extract_bits. can anyone give me some advice on it,
thank u indeed .
static inline t_key tkey_extract_bits(t_key a, unsigned int offset,
unsigned int bits)
{
if (offset < KEYLENGTH)
return ((t_key)(a << offset)) >> (KEYLENGTH - bits);
else
return 0;
}
^ permalink raw reply
* Re: Is fallback vhost_net to qemu for live migrate available？
From: Jason Wang @ 2013-09-02 3:19 UTC (permalink / raw)
To: Qin Chuanyu
Cc: Anthony Liguori, Michael S. Tsirkin, KVM list, netdev, qianhuibin,
xen-devel@lists.xen.org, wangfuhai, likunyun, liuyongan,
liuyingdong
In-Reply-To: <522174D7.6080903@huawei.com>
On 08/31/2013 12:45 PM, Qin Chuanyu wrote:
> On 2013/8/30 0:08, Anthony Liguori wrote:
>> Hi Qin,
>
>>> By change the memory copy and notify mechanism ，currently
>>> virtio-net with
>>> vhost_net could run on Xen with good performance。
>>
>> I think the key in doing this would be to implement a property
>> ioeventfd and irqfd interface in the driver domain kernel. Just
>> hacking vhost_net with Xen specific knowledge would be pretty nasty
>> IMHO.
>>
> Yes, I add a kernel module which persist virtio-net pio_addr and msix
> address as what kvm module did. Guest wake up vhost thread by adding a
> hook func in evtchn_interrupt.
>
>> Did you modify the front end driver to do grant table mapping or is
>> this all being done by mapping the domain's memory?
>>
> There is nothing changed in front end driver. Currently I use
> alloc_vm_area to get address space， and map the domain's memory as
> what what qemu did.
>
>> KVM and Xen represent memory in a very different way. KVM can only
>> track when guest mode code dirties memory. It relies on QEMU to track
>> when guest memory is dirtied by QEMU. Since vhost is running outside
>> of QEMU, vhost also needs to tell QEMU when it has dirtied memory.
>>
>> I don't think this is a problem with Xen though. I believe (although
>> could be wrong) that Xen is able to track when either the domain or
>> dom0 dirties memory.
>>
>> So I think you can simply ignore the dirty logging with vhost and it
>> should Just Work.
>>
> Thanks for your advice, I have tried it, without ping, it could
> migrate successfully, but if there has skb been received, domU would
> crash. I guess that because though Xen track domU memory, but it could
> only track memory that changed in DomU. memory changed by Dom0 is out
> of control.
>
>>
>> No, we don't have a mechanism to fallback to QEMU for the datapath.
>> It would be possible but I think it's a bad idea to mix and match the
>> two.
>>
> Next I would try to fallback datapath to qemu for three reason:
> 1: memory translate mechanism has been changed for vhost_net on
> Xen，so there would be some necessary changed needed for vhost_log in
> kernel.
>
> 2: I also maped IOREQ_PFN page(which is used for communication between
> qemu and Xen) in kernel notify module, so it also needed been marked
> as dirty when tx/rx exist in migrate period.
>
> 3: Most important of all， Michael S. Tsirkin said that he hadn't
> considered about vhost_net migrate on Xen，so there would be some
> changed needed in vhost_log for qemu.
>
> fallback to qemu seems to much easier, isn't it.
Maybe we can just stop vhost_net in pre_save() and enable it in
post_load()? Then no need to use enable the dirty logging of vhost_net.
>
>
> Regards
> Qin chuanyu
>
>
^ permalink raw reply
* Re: [PATCH V2 4/6] vhost_net: determine whether or not to use zerocopy at one time
From: Jason Wang @ 2013-09-02 3:15 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <5220E606.8010008@cogentembedded.com>
On 08/31/2013 02:35 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 08/30/2013 08:29 AM, Jason Wang wrote:
>
>> Currently, even if the packet length is smaller than
>> VHOST_GOODCOPY_LEN, if
>> upend_idx != done_idx we still set zcopy_used to true and rollback
>> this choice
>> later. This could be avoided by determine zerocopy once by checking all
>> conditions at one time before.
>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/vhost/net.c | 46
>> +++++++++++++++++++---------------------------
>> 1 files changed, 19 insertions(+), 27 deletions(-)
>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 8a6dd0d..ff60c2a 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -404,43 +404,35 @@ static void handle_tx(struct vhost_net *net)
>> iov_length(nvq->hdr, s), hdr_size);
>> break;
>> }
>> - zcopy_used = zcopy && (len >= VHOST_GOODCOPY_LEN ||
>> - nvq->upend_idx != nvq->done_idx);
>> +
>> + zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN
>> + && (nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx
>> + && vhost_net_tx_select_zcopy(net);
>
> Could you leave && on a first of two lines, matching the previous
> style?
>
ok.
>>
>> /* use msg_control to pass vhost zerocopy ubuf info to skb */
>> if (zcopy_used) {
>> + struct ubuf_info *ubuf;
>> + ubuf = nvq->ubuf_info + nvq->upend_idx;
>> +
>> vq->heads[nvq->upend_idx].id = head;
> [...]
>> + vq->heads[nvq->upend_idx].len = VHOST_DMA_IN_PROGRESS;
>> + ubuf->callback = vhost_zerocopy_callback;
>> + ubuf->ctx = nvq->ubufs;
>> + ubuf->desc = nvq->upend_idx;
>> + msg.msg_control = ubuf;
>> + msg.msg_controllen = sizeof(ubuf);
>
> 'sizeof(ubuf)' where 'ubuf' is a pointer? Are you sure it shouldn't
> be 'sizeof(*ubuf)'?
Yes, pointer is sufficiet. Vhost allocate an arrays of ubuf and
tun/macvtap just need a reference of it.
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: manual merge of the net-next tree with Linus' tree
From: Stephen Rothwell @ 2013-09-02 3:12 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Byungho An, Sonic Zhang
[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c between commit
64c3b252e9fc ("net: stmmac: fixed the pbl setting with DT") from the
tree and commit e2a240c7d3bc ("driver:net:stmmac: Disable DMA store and
forward mode if platform data force_thresh_dma_mode is set") from the
net-next tree.
I fixed it up (I think - see below) and can carry the fix as necessary (no
action is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1c83a44,623ebc5..0000000
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@@ -71,18 -71,19 +71,23 @@@ static int stmmac_probe_config_dt(struc
plat->force_sf_dma_mode = 1;
}
- dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*dma_cfg), GFP_KERNEL);
- if (!dma_cfg)
- return -ENOMEM;
-
- plat->dma_cfg = dma_cfg;
- of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
- dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst");
- dma_cfg->mixed_burst = of_property_read_bool(np, "snps,mixed-burst");
+ if (of_find_property(np, "snps,pbl", NULL)) {
+ dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*dma_cfg),
+ GFP_KERNEL);
+ if (!dma_cfg)
+ return -ENOMEM;
+ plat->dma_cfg = dma_cfg;
+ of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
+ dma_cfg->fixed_burst =
+ of_property_read_bool(np, "snps,fixed-burst");
+ dma_cfg->mixed_burst =
+ of_property_read_bool(np, "snps,mixed-burst");
+ }
+ plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
+ if (plat->force_thresh_dma_mode) {
+ plat->force_sf_dma_mode = 0;
+ pr_warn("force_sf_dma_mode is ignored if force_thresh_dma_mode is set.");
+ }
return 0;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V2 5/6] vhost_net: poll vhost queue after marking DMA is done
From: Jason Wang @ 2013-09-02 3:06 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1377881073.2065.10.camel@bwh-desktop.uk.level5networks.com>
On 08/31/2013 12:44 AM, Ben Hutchings wrote:
> On Fri, 2013-08-30 at 12:29 +0800, Jason Wang wrote:
>> We used to poll vhost queue before making DMA is done, this is racy if vhost
>> thread were waked up before marking DMA is done which can result the signal to
>> be missed. Fix this by always poll the vhost thread before DMA is done.
> Does this bug only exist in net-next or is it older? Should the fix go
> to net and stable branches?
This should go for the stable branches too (3.4 above).
Thanks for the checking.
>
> Ben.
>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>> drivers/vhost/net.c | 9 +++++----
>> 1 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index ff60c2a..d09c17c 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -308,6 +308,11 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
>> struct vhost_virtqueue *vq = ubufs->vq;
>> int cnt = atomic_read(&ubufs->kref.refcount);
>>
>> + /* set len to mark this desc buffers done DMA */
>> + vq->heads[ubuf->desc].len = success ?
>> + VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN;
>> + vhost_net_ubuf_put(ubufs);
>> +
>> /*
>> * Trigger polling thread if guest stopped submitting new buffers:
>> * in this case, the refcount after decrement will eventually reach 1
>> @@ -318,10 +323,6 @@ static void vhost_zerocopy_callback(struct ubuf_info *ubuf, bool success)
>> */
>> if (cnt <= 2 || !(cnt % 16))
>> vhost_poll_queue(&vq->poll);
>> - /* set len to mark this desc buffers done DMA */
>> - vq->heads[ubuf->desc].len = success ?
>> - VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN;
>> - vhost_net_ubuf_put(ubufs);
>> }
>>
>> /* Expects to be always run from workqueue - which acts as
^ permalink raw reply
* Re: [PATCH] drivers: net: ethernet: 8390: Kconfig: add H8300H_AKI3068NET and H8300H_H8MAX dependancy for NE_H8300
From: Chen Gang @ 2013-09-02 2:39 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Yoshinori Sato, Kees Cook, David Miller, netdev
In-Reply-To: <5223EE80.8000305@asianux.com>
On 09/02/2013 09:48 AM, Chen Gang wrote:
> On 08/30/2013 10:36 PM, Paul Gortmaker wrote:
>> [[PATCH] drivers: net: ethernet: 8390: Kconfig: add H8300H_AKI3068NET and H8300H_H8MAX dependancy for NE_H8300] On 30/08/2013 (Fri 11:29) Chen Gang wrote:
>>
>>> Only H8300H_AKI3068NET and H8300H_H8MAX can support NE_H8300 (or it
>>> will no related irq and base address).
>>
>> Do you have an H83000 and really know that is true? I'm guessing no.
Oh, sorry, forgot reply this item.
And I have no related hardware (I am just cross compiling).
Hmm... according to the implementation, we can assume original author
though: "currently only H8300H_AKI3068NET and H8300H_H8MAX can/need
support NE_H8300" (may better use "need" instead of "can").
Thanks.
>>
>> Looking at the driver, it is kind of broken that it only assigns I/O and
>> irq for two platforms, but the H8300 arch Kconfig.cpu only allows building
>> a single platform in a given kernel anyway, so a dependency fix is
>> probably acceptable here.
>>
>
> OK, thanks.
>
>> Given that, what you really want to indicate is something like:
>>
>> Currently only H8300H_AKI3068NET and H8300H_H8MAX define default
>> I/O base and IRQ values for the NE_H8300 driver. Hence builds
>> for other H8300H platforms will fail as per below. Since H8300H
>> does not support multi platform builds, we simply limit building
>> the driver to those two platforms specifically.
>>
>
> Hmm... that sounds good to me.
>
>>>
>>> The release error:
>>>
>>> CC [M] drivers/net/hamradio/bpqether.o
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> This file has nothing to do with the problem in question. [If you are
>> going to do a "make -j30" in testing, then at least restart with -j1 to
>> properly capture the error message.]
>>
>
> Oh, it is a waste, which I should remove, thanks.
>
>
>> Please update the commit log appropriately and resubmit.
>>
>
> OK, I will send patch v2.
>
>> Paul.
>> --
>>
>>> drivers/net/ethernet/8390/ne-h8300.c: In function 'init_dev':
>>> drivers/net/ethernet/8390/ne-h8300.c:117:23: error: 'h8300_ne_base' undeclared (first use in this function)
>>> drivers/net/ethernet/8390/ne-h8300.c:117:23: note: each undeclared identifier is reported only once for each function it appears in
>>> drivers/net/ethernet/8390/ne-h8300.c:117:23: error: bit-field '<anonymous>' width not an integer constant
>>> drivers/net/ethernet/8390/ne-h8300.c:119:20: error: 'h8300_ne_irq' undeclared (first use in this function)
>>> drivers/net/ethernet/8390/ne-h8300.c: In function 'init_module':
>>> drivers/net/ethernet/8390/ne-h8300.c:647:21: error: 'h8300_ne_base' undeclared (first use in this function)
>>> drivers/net/ethernet/8390/ne-h8300.c:648:15: error: 'h8300_ne_irq' undeclared (first use in this function)
>>> drivers/net/ethernet/8390/ne-h8300.c:661:4: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]
>>>
>>>
>>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>>> ---
>>> drivers/net/ethernet/8390/Kconfig | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
>>> index a5f91e1..becef25 100644
>>> --- a/drivers/net/ethernet/8390/Kconfig
>>> +++ b/drivers/net/ethernet/8390/Kconfig
>>> @@ -148,7 +148,7 @@ config PCMCIA_PCNET
>>>
>>> config NE_H8300
>>> tristate "NE2000 compatible support for H8/300"
>>> - depends on H8300
>>> + depends on H8300H_AKI3068NET || H8300H_H8MAX
>>> ---help---
>>> Say Y here if you want to use the NE2000 compatible
>>> controller on the Renesas H8/300 processor.
>>> --
>>> 1.7.7.6
>>
>>
>
> Thanks.
>
--
Chen Gang
^ permalink raw reply
* Re: [PATCH v3] ipv6:introduce function to find route for redirect
From: Duan Jiong @ 2013-09-02 2:38 UTC (permalink / raw)
To: hannes; +Cc: davem, netdev
In-Reply-To: <20130901210825.GD19455@order.stressinduktion.org>
于 2013年09月02日 05:08, Hannes Frederic Sowa 写道:
> On Sat, Aug 31, 2013 at 01:09:33PM +0800, Duan Jiong wrote:
>> RFC 4861 says that the IP source address of the Redirect is the
>> same as the current first-hop router for the specified ICMP
>> Destination Address, so the gateway should be taken into
>> consideration when we find the route for redirect.
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> This patch looks good!
>
> Maybe you could also point to commit
> a6279458c534d01ccc39498aba61c93083ee0372 ("NDISC: Search over all possible
> rules on receipt of redirect.") and where the check went away?
>
> The bug is only "exploitable" on layer-2 because the source address of the
> redirect is checked to be a valid link-local address but it makes spoofing a
> lot easier in the same L2 domain nonetheless.
>
> Nice work!
>
> Some smaller comments inline:
>
Thanks very much for you comments， and i will correct those problems.
>> ---
>> Changes for v3:
>> 1.Fix the comments style problems
>>
>> net/ipv6/ah6.c | 2 +-
>> net/ipv6/esp6.c | 2 +-
>> net/ipv6/icmp.c | 2 +-
>> net/ipv6/ipcomp6.c | 2 +-
>> net/ipv6/ndisc.c | 3 ++-
>> net/ipv6/route.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++-----
>> 6 files changed, 78 insertions(+), 11 deletions(-)
>>
>> diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
>> index bb02e17..73784c3 100644
>> --- a/net/ipv6/ah6.c
>> +++ b/net/ipv6/ah6.c
>> @@ -628,7 +628,7 @@ static void ah6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>> return;
>>
>> if (type == NDISC_REDIRECT)
>> - ip6_redirect(skb, net, 0, 0);
>> + ip6_redirect(skb, net, skb->dev->ifindex, 0);
>> else
>> ip6_update_pmtu(skb, net, info, 0, 0);
>> xfrm_state_put(x);
>> diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
>> index aeac0dc..d3618a7 100644
>> --- a/net/ipv6/esp6.c
>> +++ b/net/ipv6/esp6.c
>> @@ -447,7 +447,7 @@ static void esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>> return;
>>
>> if (type == NDISC_REDIRECT)
>> - ip6_redirect(skb, net, 0, 0);
>> + ip6_redirect(skb, net, skb->dev->ifindex, 0);
>> else
>> ip6_update_pmtu(skb, net, info, 0, 0);
>> xfrm_state_put(x);
>> diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
>> index 7cfc8d2..73681c2 100644
>> --- a/net/ipv6/icmp.c
>> +++ b/net/ipv6/icmp.c
>> @@ -92,7 +92,7 @@ static void icmpv6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>> if (type == ICMPV6_PKT_TOOBIG)
>> ip6_update_pmtu(skb, net, info, 0, 0);
>> else if (type == NDISC_REDIRECT)
>> - ip6_redirect(skb, net, 0, 0);
>> + ip6_redirect(skb, net, skb->dev->ifindex, 0);
>>
>> if (!(type & ICMPV6_INFOMSG_MASK))
>> if (icmp6->icmp6_type == ICMPV6_ECHO_REQUEST)
>> diff --git a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c
>> index 7af5aee..5636a91 100644
>> --- a/net/ipv6/ipcomp6.c
>> +++ b/net/ipv6/ipcomp6.c
>> @@ -76,7 +76,7 @@ static void ipcomp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>> return;
>>
>> if (type == NDISC_REDIRECT)
>> - ip6_redirect(skb, net, 0, 0);
>> + ip6_redirect(skb, net, skb->dev->ifindex, 0);
>> else
>> ip6_update_pmtu(skb, net, info, 0, 0);
>> xfrm_state_put(x);
>> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
>> index 04d31c2..90f474b 100644
>> --- a/net/ipv6/ndisc.c
>> +++ b/net/ipv6/ndisc.c
>> @@ -1370,7 +1370,8 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
>> return;
>>
>> if (!ndopts.nd_opts_rh) {
>> - ip6_redirect_no_header(skb, dev_net(skb->dev), 0, 0);
>> + ip6_redirect_no_header(skb, dev_net(skb->dev),
>> + skb->dev->ifindex, 0);
>
> This is not indented correctly. skb->dev->ifindex should be placed right below
> the upper skb variable.
>
>> return;
>> }
>>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 8d9a93e..2e1d378 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1157,6 +1157,74 @@ void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk, __be32 mtu)
>> }
>> EXPORT_SYMBOL_GPL(ip6_sk_update_pmtu);
>>
>> +/* Handle redirects */
>> +struct ip6rd_flowi {
>> + struct flowi6 fl6;
>> + struct in6_addr gateway;
>> +};
>> +
>> +static struct rt6_info *__ip6_route_redirect(struct net *net,
>> + struct fib6_table *table,
>> + struct flowi6 *fl6,
>> + int flags)
>> +{
>> + struct ip6rd_flowi *rdfl = (struct ip6rd_flowi *)fl6;
>> + struct rt6_info *rt;
>> + struct fib6_node *fn;
>> +
>> + /* Get the "current" route for this destination and
>> + * check if the redirect has come from approriate router.
>> + *
>> + * RFC 4861 specifies that redirects should only be
>> + * accepted if they come from the nexthop to the target.
>> + * Due to the way the routes are chosen, this notion
>> + * is a bit fuzzy and one might need to check all possible
>> + * routes.
>> + */
>> +
>> + read_lock_bh(&table->tb6_lock);
>> + fn = fib6_lookup(&table->tb6_root, &fl6->daddr, &fl6->saddr);
>> +restart:
>> + for (rt = fn->leaf; rt; rt = rt->dst.rt6_next) {
>> + if (rt6_check_expired(rt))
>> + continue;
>
> [1] (backreference for a comment below)
>
>> + if (!(rt->rt6i_flags & RTF_GATEWAY))
>> + continue;
>> + if (fl6->flowi6_oif != rt->dst.dev->ifindex)
>> + continue;
>> + if (!ipv6_addr_equal(&rdfl->gateway, &rt->rt6i_gateway))
>> + continue;
>> + break;
>> + }
>> +
>> + if (!rt)
>> + rt = net->ipv6.ip6_null_entry;
>> + BACKTRACK(net, &fl6->saddr);
>> +out:
>> + dst_hold(&rt->dst);
>> +
>> + read_unlock_bh(&table->tb6_lock);
>> +
>> + return rt;
>> +};
>> +
>> +static struct dst_entry *ip6_route_redirect(const struct flowi6 *fl6,
>> + const struct in6_addr *gateway,
>> + struct net *net)
>
> The ordering of the arguments could be in the same style as the other
> ip6_route_* functions (net, flow, gateway). But that is not that important.
>
>> +{
>> + int flags = RT6_LOOKUP_F_HAS_SADDR;
>> + struct ip6rd_flowi rdfl;
>> +
>> + rdfl.fl6 = *fl6;
>> + rdfl.gateway = *gateway;
>> +
>> + if (rt6_need_strict(&fl6->daddr))
>> + flags |= RT6_LOOKUP_F_IFACE;
>
> This is not needed because you do the matching on interfaces yourself
> in __ip6_route_redirect. The flag should currently not be checked on
> this code path down in fib6_rule_lookup.
>
>> +
>> + return fib6_rule_lookup(net, &rdfl.fl6,
>> + flags, __ip6_route_redirect);
>
> This line jumped a bit too far to the right, too. ;)
>
>> +}
>> +
>> void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>
> Maybe we should rename oif to iif now?
Yes, that looks no ambiguity.
>
>> {
>> const struct ipv6hdr *iph = (struct ipv6hdr *) skb->data;
>> @@ -1171,9 +1239,8 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>> fl6.saddr = iph->saddr;
>> fl6.flowlabel = ip6_flowinfo(iph);
>>
>> - dst = ip6_route_output(net, NULL, &fl6);
>> - if (!dst->error)
>> - rt6_do_redirect(dst, NULL, skb);
>> + dst = ip6_route_redirect(&fl6, &ipv6_hdr(skb)->saddr, net);
>> + rt6_do_redirect(dst, NULL, skb);
>
> What is the reason you left out the dst.error check? E.g. if a system had a
> prohbit rule it is possible to circumvent this with a redirect packet now.
>
That's my fault. i just understand the meaning of dst.error incorrectly, and
i will modify the patch according to your comment below.
> I would think about placing this check at [1] and fail the lookup
> early. rt6_do_redirect does check for null-entry, so you could omit the
> check here, then.
>
Thanks,
Duan
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-09-02 2:25 UTC (permalink / raw)
To: Duan Fugang-B38611, David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
l.stach@pengutronix.de
In-Reply-To: <9848F2DB572E5649BA045B288BE08FBE0167E411@039-SN2MPN1-021.039d.mgd.msft.net>
> > > Due to get tx & rx previous description use the same function
> > > fec_enet_get_prevdesc(). If put the logic into
> > > fec_enet_get_prevdesc(), I think it is better to split the function
> > > to fec_enet_get_tx_prevdesc(),fec_enet_get_rx_prevdesc().
> > >
> > > If you agree it, I will submit one patch to do it.
> >
> > It doesn't looks good to split to two functions.
> > Can we use if (p == fep->tx_base || p == fep->rx_base) to check if get
> > first entry of queue?
>
> Yes, this check can get the first entry of queue, but the ring size is
> different for rx and tx ring.
> In current driver, there have no tx/rx ring size variable define in struct
> fec_enet_private.
>
> And, if change fec_enet_get_prevdesc(), the fec_enet_get_nextdesc() may need
> to do related logic change for nicety code.
Yes, it should be better handle this logical in get_prevdesc and get_nextdesc.
So we have unified place to handle wrap.
>
> > Best regards
> > Frank Li
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Duan Fugang-B38611 @ 2013-09-02 2:23 UTC (permalink / raw)
To: Li Frank-B20596, David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
l.stach@pengutronix.de
In-Reply-To: <1F990F8245A4214A8CC4BFFBD9F790F908B40731@039-SN1MPN1-001.039d.mgd.msft.net>
From: Li Frank-B20596
Data: Monday, September 02, 2013 10:10 AM + 800
> To: Duan Fugang-B38611; David Miller
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com;
> l.stach@pengutronix.de
> Subject: RE: [PATCH] net: fec: fix the error to get the previous BD entry
>
> >
> > Due to get tx & rx previous description use the same function
> > fec_enet_get_prevdesc(). If put the logic into
> > fec_enet_get_prevdesc(), I think it is better to split the function to
> > fec_enet_get_tx_prevdesc(),fec_enet_get_rx_prevdesc().
> >
> > If you agree it, I will submit one patch to do it.
>
> It doesn't looks good to split to two functions.
> Can we use if (p == fep->tx_base || p == fep->rx_base) to check if get
> first entry of queue?
Yes, this check can get the first entry of queue, but the ring size is different for rx and tx ring.
In current driver, there have no tx/rx ring size variable define in struct fec_enet_private.
And, if change fec_enet_get_prevdesc(), the fec_enet_get_nextdesc() may need to do related logic change for nicety code.
> Best regards
> Frank Li
^ permalink raw reply
* [PATCH v2] drivers: net: ethernet: 8390: Kconfig: add H8300H_AKI3068NET and H8300H_H8MAX dependancy for NE_H8300
From: Chen Gang @ 2013-09-02 2:20 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Yoshinori Sato, Kees Cook, David Miller, netdev
In-Reply-To: <20130830143639.GA16269@windriver.com>
Currently only H8300H_AKI3068NET and H8300H_H8MAX define default
I/O base and IRQ values for the NE_H8300 driver. Hence builds
for other H8300H platforms will fail as per below. Since H8300H
does not support multi platform builds, we simply limit building
the driver to those two platforms specifically.
The release error:
drivers/net/ethernet/8390/ne-h8300.c: In function 'init_dev':
drivers/net/ethernet/8390/ne-h8300.c:117:23: error: 'h8300_ne_base' undeclared (first use in this function)
drivers/net/ethernet/8390/ne-h8300.c:117:23: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/8390/ne-h8300.c:117:23: error: bit-field '<anonymous>' width not an integer constant
drivers/net/ethernet/8390/ne-h8300.c:119:20: error: 'h8300_ne_irq' undeclared (first use in this function)
drivers/net/ethernet/8390/ne-h8300.c: In function 'init_module':
drivers/net/ethernet/8390/ne-h8300.c:647:21: error: 'h8300_ne_base' undeclared (first use in this function)
drivers/net/ethernet/8390/ne-h8300.c:648:15: error: 'h8300_ne_irq' undeclared (first use in this function)
drivers/net/ethernet/8390/ne-h8300.c:661:4: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
drivers/net/ethernet/8390/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
index a5f91e1..becef25 100644
--- a/drivers/net/ethernet/8390/Kconfig
+++ b/drivers/net/ethernet/8390/Kconfig
@@ -148,7 +148,7 @@ config PCMCIA_PCNET
config NE_H8300
tristate "NE2000 compatible support for H8/300"
- depends on H8300
+ depends on H8300H_AKI3068NET || H8300H_H8MAX
---help---
Say Y here if you want to use the NE2000 compatible
controller on the Renesas H8/300 processor.
--
1.7.7.6
^ permalink raw reply related
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-09-02 2:09 UTC (permalink / raw)
To: Duan Fugang-B38611, David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
l.stach@pengutronix.de
In-Reply-To: <9848F2DB572E5649BA045B288BE08FBE0167B047@039-SN2MPN1-021.039d.mgd.msft.net>
>
> Due to get tx & rx previous description use the same function
> fec_enet_get_prevdesc(). If put the logic into fec_enet_get_prevdesc(), I
> think it is better to split the function to
> fec_enet_get_tx_prevdesc(),fec_enet_get_rx_prevdesc().
>
> If you agree it, I will submit one patch to do it.
It doesn't looks good to split to two functions.
Can we use if (p == fep->tx_base || p == fep->rx_base) to check if get first entry of queue?
Best regards
Frank Li
>
> Thanks,
> Andy
^ permalink raw reply
* [PATCH net-next] net: make snmp_mib_free static inline
From: Cong Wang @ 2013-09-02 2:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Cong Wang
In-Reply-To: <1378087613-15279-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Fengguang reported:
net/built-in.o: In function `in6_dev_finish_destroy':
(.text+0x4ca7d): undefined reference to `snmp_mib_free'
this is due to snmp_mib_free() is defined when CONFIG_INET is enabled,
but in6_dev_finish_destroy() is now moved to core kernel.
I think snmp_mib_free() is small enough to be inlined, so just make it
static inline.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
include/net/ip.h | 12 +++++++++++-
net/ipv4/af_inet.c | 12 ------------
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index a68f838..48f5597 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -194,7 +194,17 @@ static inline u64 snmp_fold_field64(void __percpu *mib[], int offt, size_t syncp
}
#endif
extern int snmp_mib_init(void __percpu *ptr[2], size_t mibsize, size_t align);
-extern void snmp_mib_free(void __percpu *ptr[2]);
+
+static inline void snmp_mib_free(void __percpu *ptr[SNMP_ARRAY_SZ])
+{
+ int i;
+
+ BUG_ON(ptr == NULL);
+ for (i = 0; i < SNMP_ARRAY_SZ; i++) {
+ free_percpu(ptr[i]);
+ ptr[i] = NULL;
+ }
+}
extern struct local_ports {
seqlock_t lock;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index b4d0be2..7a1874b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1532,18 +1532,6 @@ int snmp_mib_init(void __percpu *ptr[2], size_t mibsize, size_t align)
}
EXPORT_SYMBOL_GPL(snmp_mib_init);
-void snmp_mib_free(void __percpu *ptr[SNMP_ARRAY_SZ])
-{
- int i;
-
- BUG_ON(ptr == NULL);
- for (i = 0; i < SNMP_ARRAY_SZ; i++) {
- free_percpu(ptr[i]);
- ptr[i] = NULL;
- }
-}
-EXPORT_SYMBOL_GPL(snmp_mib_free);
-
#ifdef CONFIG_IP_MULTICAST
static const struct net_protocol igmp_protocol = {
.handler = igmp_rcv,
--
1.7.7.6
^ permalink raw reply related
* [PATCH net-next] vxlan: include net/ip6_checksum.h for csum_ipv6_magic()
From: Cong Wang @ 2013-09-02 2:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Cong Wang
In-Reply-To: <1378087613-15279-1-git-send-email-amwang@redhat.com>
From: Cong Wang <amwang@redhat.com>
Fengguang reported a compile warning:
drivers/net/vxlan.c: In function 'vxlan6_xmit_skb':
drivers/net/vxlan.c:1352:3: error: implicit declaration of function 'csum_ipv6_magic' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
this patch fixes it.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
drivers/net/vxlan.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 0fcf3f7..6b560f3 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -44,6 +44,7 @@
#include <net/ipv6.h>
#include <net/addrconf.h>
#include <net/ip6_tunnel.h>
+#include <net/ip6_checksum.h>
#endif
#define VXLAN_VERSION "0.1"
--
1.7.7.6
^ permalink raw reply related
* [PATCH net-next] vxlan: fix flowi6_proto value
From: Cong Wang @ 2013-09-02 2:06 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Cong Wang
From: Cong Wang <amwang@redhat.com>
It should be IPPROTO_UDP.
Signed-off-by: Cong Wang <amwang@redhat.com>
---
drivers/net/vxlan.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 3ffb22d..0fcf3f7 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1671,7 +1671,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
fl6.flowi6_oif = rdst->remote_ifindex;
fl6.daddr = dst->sin6.sin6_addr;
fl6.saddr = vxlan->saddr.sin6.sin6_addr;
- fl6.flowi6_proto = skb->protocol;
+ fl6.flowi6_proto = IPPROTO_UDP;
if (ipv6_stub->ipv6_dst_lookup(sk, &ndst, &fl6)) {
netdev_dbg(dev, "no route to %pI6\n",
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] drivers: net: ethernet: 8390: Kconfig: add H8300H_AKI3068NET and H8300H_H8MAX dependancy for NE_H8300
From: Chen Gang @ 2013-09-02 1:48 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Yoshinori Sato, Kees Cook, David Miller, netdev
In-Reply-To: <20130830143639.GA16269@windriver.com>
On 08/30/2013 10:36 PM, Paul Gortmaker wrote:
> [[PATCH] drivers: net: ethernet: 8390: Kconfig: add H8300H_AKI3068NET and H8300H_H8MAX dependancy for NE_H8300] On 30/08/2013 (Fri 11:29) Chen Gang wrote:
>
>> Only H8300H_AKI3068NET and H8300H_H8MAX can support NE_H8300 (or it
>> will no related irq and base address).
>
> Do you have an H83000 and really know that is true? I'm guessing no.
>
> Looking at the driver, it is kind of broken that it only assigns I/O and
> irq for two platforms, but the H8300 arch Kconfig.cpu only allows building
> a single platform in a given kernel anyway, so a dependency fix is
> probably acceptable here.
>
OK, thanks.
> Given that, what you really want to indicate is something like:
>
> Currently only H8300H_AKI3068NET and H8300H_H8MAX define default
> I/O base and IRQ values for the NE_H8300 driver. Hence builds
> for other H8300H platforms will fail as per below. Since H8300H
> does not support multi platform builds, we simply limit building
> the driver to those two platforms specifically.
>
Hmm... that sounds good to me.
>>
>> The release error:
>>
>> CC [M] drivers/net/hamradio/bpqether.o
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This file has nothing to do with the problem in question. [If you are
> going to do a "make -j30" in testing, then at least restart with -j1 to
> properly capture the error message.]
>
Oh, it is a waste, which I should remove, thanks.
> Please update the commit log appropriately and resubmit.
>
OK, I will send patch v2.
> Paul.
> --
>
>> drivers/net/ethernet/8390/ne-h8300.c: In function 'init_dev':
>> drivers/net/ethernet/8390/ne-h8300.c:117:23: error: 'h8300_ne_base' undeclared (first use in this function)
>> drivers/net/ethernet/8390/ne-h8300.c:117:23: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/net/ethernet/8390/ne-h8300.c:117:23: error: bit-field '<anonymous>' width not an integer constant
>> drivers/net/ethernet/8390/ne-h8300.c:119:20: error: 'h8300_ne_irq' undeclared (first use in this function)
>> drivers/net/ethernet/8390/ne-h8300.c: In function 'init_module':
>> drivers/net/ethernet/8390/ne-h8300.c:647:21: error: 'h8300_ne_base' undeclared (first use in this function)
>> drivers/net/ethernet/8390/ne-h8300.c:648:15: error: 'h8300_ne_irq' undeclared (first use in this function)
>> drivers/net/ethernet/8390/ne-h8300.c:661:4: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]
>>
>>
>> Signed-off-by: Chen Gang <gang.chen@asianux.com>
>> ---
>> drivers/net/ethernet/8390/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/8390/Kconfig b/drivers/net/ethernet/8390/Kconfig
>> index a5f91e1..becef25 100644
>> --- a/drivers/net/ethernet/8390/Kconfig
>> +++ b/drivers/net/ethernet/8390/Kconfig
>> @@ -148,7 +148,7 @@ config PCMCIA_PCNET
>>
>> config NE_H8300
>> tristate "NE2000 compatible support for H8/300"
>> - depends on H8300
>> + depends on H8300H_AKI3068NET || H8300H_H8MAX
>> ---help---
>> Say Y here if you want to use the NE2000 compatible
>> controller on the Renesas H8/300 processor.
>> --
>> 1.7.7.6
>
>
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH] virtio-net: Set RXCSUM feature if GUEST_CSUM is available
From: Rusty Russell @ 2013-09-02 1:47 UTC (permalink / raw)
To: David Miller, thuth; +Cc: netdev, mst, virtualization
In-Reply-To: <20130829.155704.248095796202059854.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Thomas Huth <thuth@linux.vnet.ibm.com>
> Date: Tue, 27 Aug 2013 17:09:02 +0200
>
>> If the VIRTIO_NET_F_GUEST_CSUM virtio feature is available, the guest
>> does not have to calculate the checksums on all received packets. This
>> is pretty much the same feature as RX checksum offloading on real
>> network cards, so the virtio-net driver should report this by setting
>> the NETIF_F_RXCSUM flag. When the user now runs "ethtool -k", he or she
>> can see whether the virtio-net interface has to calculate RX checksums
>> or not.
>>
>> Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
>
> Can one of the virtio_net folks please review this?
Hmm, so NETIF_F_RXCSUM only exists for ethtool's benefit. Weird.
But this patch is correct:
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks,
Rusty.
^ 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