* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-30 10:31 UTC (permalink / raw)
To: Alex Strizhevsky
Cc: Eli Britstein, linux-usb, youtux@gmail.com, Midge Shaojun Tan,
netdev@vger.kernel.org, Kevin Zhu, Bjørn Mork
In-Reply-To: <CAPChA0czA3vxPZdwk-SgO1Wr83zOV1UoWcL4=05qtBktwq5=TA@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3396 bytes --]
Here are two USB captures.
In m1 - the computer is "silent": and it can listen to ARP traffic coming from
the modem.
In m2, the computer tries to talk, performing DHCP with dhclient from Ubuntu.
Any strange thing?
Is the device really interpreting ndpOffset as Offset in the specs Kevin?
If so we might elaborate on this.
On Sun, 30 Nov 2014, Alex Strizhevsky wrote:
==Date: Sun, 30 Nov 2014 05:22:20
==From: Alex Strizhevsky <alexxst@gmail.com>
==To: Mrkiko Rs <mrkiko.rs@gmail.com>
==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>, linux-usb@vger.kernel.org,
== "youtux@gmail.com" <youtux@gmail.com>,
== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
== "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
== Kevin Zhu <Mingying.Zhu@audiocodes.com>, Bjørn Mork <bjorn@mork.no>
==Subject: Re: Is this 32-bit NCM?
==
==
==Hi Enrico,
==
==Actually I have two dongles with different firmwares (23.128.00.00.00 &
==21.286.03.01.209).
==Probably have sent to you the USB capture with the first one.
==
==In fact we have to make work the second one, this dongle has relevant SW.
==
==On Nov 30, 2014 3:13 AM, "Enrico Mioso" <mrkiko.rs@gmail.com> wrote:
== Hi guys.
== Sorry for the late our but ... I was trying to figure out
== something new about
== this dongle.
== I also searched for it in my city shops without finding it
== actually.
== But then I came back and ... tried to look at some things.
==
== Alex, Kevin: in the Windows USB captures you sent me (and that I
== sent on the
== List), I can notiche something very strange.
== with a shell on a computer connected to a test device I can see
== the following:
== at+gmr
== 21.286.03.01.209
== OK
== and so why in the Windows sniff the dongle answers to the same
== question
== something like
== 23.128.00.00.00
== ?
== Alex - was it the same dongle?
== Kevin or anyone: can you use putty to interact with the dongle
== under Windows
== and type some commands, like:
== at+gmr
== and other similar commands?
== If the dongle reports different firmware versions under Linux
== and Windows, then
== guys... we need to figure out the Windows switch message.
== Overmore - in the device installation sh*t, you can see there is
== a firmware
== updater... Why?
==
== Alex: I used the
== at^reset
== command to get the modem back to normal state once; and so it
== restored the
== nvram to default or something.
== If you reconnect it to windows ... i hope it gets re-setup as
== before.
== But - nothing harmful to the device, only to it's settings,
== sorry.
== I restored the relevant settings and it connects again, but no
== dhcp. But - be
== peaceful: other modems out there seems to not get dhcp anyway.
== this is the state the modem arrives when you buy it, so windows
== should know
== Wwhat To Say To The Modem (TM).
== Another thing - note that:
== [14170.048693] cdc_ncm 1-2:1.2: GET_MAX_DATAGRAM_SIZE failed
==
== Any ideas, comments, suggestions are highly appreciated guys.
== Of any type.
==
== Bjorn - unfortunately it seems this problem is related to E3727
== and E3276
== sticks; they can get IP from DHCP but not go ahead.
==
==
==
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Florian Westphal @ 2014-11-30 10:26 UTC (permalink / raw)
To: Fan Du; +Cc: netdev, davem, fw
In-Reply-To: <1417156385-18276-1-git-send-email-fan.du@intel.com>
Fan Du <fan.du@intel.com> wrote:
> Test scenario: two KVM guests sitting in different
> hosts communicate to each other with a vxlan tunnel.
>
> All interface MTU is default 1500 Bytes, from guest point
> of view, its skb gso_size could be as bigger as 1448Bytes,
> however after guest skb goes through vxlan encapuslation,
> individual segments length of a gso packet could exceed
> physical NIC MTU 1500, which will be lost at recevier side.
>
> So it's possible in virtualized environment, locally created
> skb len after encapslation could be bigger than underlayer
> MTU. In such case, it's reasonable to do GSO first,
> then fragment any packet bigger than MTU as possible.
>
> +---------------+ TX RX +---------------+
> | KVM Guest | -> ... -> | KVM Guest |
> +-+-----------+-+ +-+-----------+-+
> |Qemu/VirtIO| |Qemu/VirtIO|
> +-----------+ +-----------+
> | |
> v tap0 tap0 v
> +-----------+ +-----------+
> | ovs bridge| | ovs bridge|
> +-----------+ +-----------+
> | vxlan vxlan |
> v v
> +-----------+ +-----------+
> | NIC | <------> | NIC |
> +-----------+ +-----------+
>
> Steps to reproduce:
> 1. Using kernel builtin openvswitch module to setup ovs bridge.
> 2. Runing iperf without -M, communication will stuck.
Hmm, do we really want to suport bridges containing interfaces with
different MTUs?
It seems to me to only clean solution is to set tap0 MTU so that it
accounts for the bridge encap overhead.
^ permalink raw reply
* Re: Is this 32-bit NCM?
From: Enrico Mioso @ 2014-11-30 10:18 UTC (permalink / raw)
To: Alex Strizhevsky
Cc: Eli Britstein, linux-usb, youtux@gmail.com, Midge Shaojun Tan,
netdev@vger.kernel.org, Kevin Zhu, Bjørn Mork
In-Reply-To: <CAPChA0czA3vxPZdwk-SgO1Wr83zOV1UoWcL4=05qtBktwq5=TA@mail.gmail.com>
Sorry - by error I did not send the message to all.
Hi everyone, and good Sunday!
The problem is that - between those two firmwares things might change, and so
we don't know what Windows does when it meets this specific branch /version of
the firmware.
I am desperately suspecting that we would not get anything hinting a lot even
looking at the usb capture of this specific firmware, but... in any case it
might be interesting to have it.
(at+gmr returns the firmware revision)
Is the dongles with 23 firmwares working under Linux?
Or, you might upgrade all dongles firmware until all of then are running the 23
version and so workaround the problem differently in case.
Bjorn: I noticed that anyway, as Alex suggested, tcpdump can reveal some
traffic: in particular you can see the gateway asking for us ... but no
traffic can flow out, only flow in.
The system can see traffic coming in, not generate it. Any idea or comment
from anyone is welcome.
^ permalink raw reply
* RE: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Du, Fan @ 2014-11-30 10:08 UTC (permalink / raw)
To: 'Jason Wang'
Cc: netdev@vger.kernel.org, davem@davemloft.net, fw@strlen.de,
Du, Fan
In-Reply-To: <1417158128.3268.2@smtp.corp.redhat.com>
>-----Original Message-----
>From: Jason Wang [mailto:jasowang@redhat.com]
>Sent: Friday, November 28, 2014 3:02 PM
>To: Du, Fan
>Cc: netdev@vger.kernel.org; davem@davemloft.net; fw@strlen.de; Du, Fan
>Subject: Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
>
>
>
>On Fri, Nov 28, 2014 at 2:33 PM, Fan Du <fan.du@intel.com> wrote:
>> Test scenario: two KVM guests sitting in different hosts communicate
>> to each other with a vxlan tunnel.
>>
>> All interface MTU is default 1500 Bytes, from guest point of view, its
>> skb gso_size could be as bigger as 1448Bytes, however after guest skb
>> goes through vxlan encapuslation, individual segments length of a gso
>> packet could exceed physical NIC MTU 1500, which will be lost at
>> recevier side.
>>
>> So it's possible in virtualized environment, locally created skb len
>> after encapslation could be bigger than underlayer MTU. In such case,
>> it's reasonable to do GSO first, then fragment any packet bigger than
>> MTU as possible.
>>
>> +---------------+ TX RX +---------------+
>> | KVM Guest | -> ... -> | KVM Guest |
>> +-+-----------+-+ +-+-----------+-+
>> |Qemu/VirtIO| |Qemu/VirtIO|
>> +-----------+ +-----------+
>> | |
>> v tap0 tap0 v
>> +-----------+ +-----------+
>> | ovs bridge| | ovs bridge|
>> +-----------+ +-----------+
>> | vxlan vxlan |
>> v v
>> +-----------+ +-----------+
>> | NIC | <------> | NIC |
>> +-----------+ +-----------+
>>
>> Steps to reproduce:
>> 1. Using kernel builtin openvswitch module to setup ovs bridge.
>> 2. Runing iperf without -M, communication will stuck.
>
>Is this issue specific to ovs or ipv4? Path MTU discovery should help in this case I
>believe.
Problem here is host stack push local over-sized gso skb down to NIC, and perform GSO there
without any further ip segmentation.
Reasonable behavior is do gso first at ip level, if gso-ed skb is bigger than MTU && df is set,
Then push ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED message back to sender to adjust mtu.
For PMTU to work, that's another issue I will try to address later on.
>>
>>
>> Signed-off-by: Fan Du <fan.du@intel.com>
>> ---
>> net/ipv4/ip_output.c | 7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index
>> bc6471d..558b5f8 100644
>> --- a/net/ipv4/ip_output.c
>> +++ b/net/ipv4/ip_output.c
>> @@ -217,9 +217,10 @@ static int ip_finish_output_gso(struct sk_buff
>> *skb)
>> struct sk_buff *segs;
>> int ret = 0;
>>
>> - /* common case: locally created skb or seglen is <= mtu */
>> - if (((IPCB(skb)->flags & IPSKB_FORWARDED) == 0) ||
>> - skb_gso_network_seglen(skb) <= ip_skb_dst_mtu(skb))
>> + /* Both locally created skb and forwarded skb could exceed
>> + * MTU size, so make a unified rule for them all.
>> + */
>> + if (skb_gso_network_seglen(skb) <= ip_skb_dst_mtu(skb))
>> return ip_finish_output2(skb);
>>
>> /* Slowpath - GSO segment length is exceeding the dst MTU.
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Herbert Xu @ 2014-11-30 10:03 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <20141128235935.GA2178@gondor.apana.org.au>
On Sat, Nov 29, 2014 at 07:59:35AM +0800, Herbert Xu wrote:
> On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
> >
> > I saw there are tun updates on Dave's queue but none seemed to handle this.
> >
> > I can't use current net-next
> > (799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
> > because tun got clogged somehow. Bisected down to:
> >
> > commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
> > Author: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Fri Nov 7 21:22:23 2014 +0800
>
> Does this patch help?
Oops, there was an embarrassing typo in the patch which causes
it to not even build. Here is the corrected version.
-- >8 --
Subject: tun: Fix GSO meta-data handling in tun_get_user
When we write the GSO meta-data in tun_get_user we end up advancing
the IO vector twice, thus exhausting the user buffer before we can
finish writing the packet.
Fixes: f5ff53b4d97c ("{macvtap,tun}_get_user(): switch to iov_iter")
Reported-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4b743c6..6d44da1 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1052,7 +1052,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
if (gso.hdr_len > len)
return -EINVAL;
- iov_iter_advance(from, tun->vnet_hdr_sz);
+ iov_iter_advance(from, tun->vnet_hdr_sz - sizeof(gso));
}
if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) {
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: Question about function. wil_vring_alloc_skb in txrx.c
From: Vladimir Kondratiev @ 2014-11-30 8:39 UTC (permalink / raw)
To: nick
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wil6210-A+ZNKFmMK5xy9aJCnZT0Uw, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <547A5554.3010900-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Saturday, November 29, 2014 06:23:00 PM nick wrote:
> Greetings Vladimr,John and others,
> I am wondering about the TODO in the function in my message at it seems to be no longer needed due to us reserving headroom for the skb packet used in this function. The other reason I can see that this is needed is if we need to
> align the sk_buff for performance or hardware alignment reasons. If that is the case, would someone we willing to
> explain to me how the maintainers would like me to align the sk_buff packet used in the function, wil_vring_alloc_skb.
Hi Nick,
ignore this TODO, I'll remove it. I was not sure what is better for the hardware, now I know there is no hardware
limitation.
Thanks, Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] wil6210: Fix potential memory leaks on error paths
From: Vladimir Kondratiev @ 2014-11-30 8:28 UTC (permalink / raw)
To: John W. Linville
Cc: Lino Sanfilippo, netdev-u79uwXL29TY76Z2rM5mHXA,
ahmedtamrawi-Re5JQEeQqe8AvxtiuMwx3w, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417139239-32602-1-git-send-email-LinoSanfilippo-Mmb7MZpHnFY@public.gmane.org>
On Friday, November 28, 2014 02:47:19 AM Lino Sanfilippo wrote:
> Fix missing memory deallocation on error paths in wil_write_file_wmi()
> and wil_write_file_txmgmt().
>
> Reported-by: Ahmed Tamrawi <ahmedtamrawi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo-Mmb7MZpHnFY@public.gmane.org>
> ---
> drivers/net/wireless/ath/wil6210/debugfs.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c
> index 54a6ddc..4e6e145 100644
> --- a/drivers/net/wireless/ath/wil6210/debugfs.c
> +++ b/drivers/net/wireless/ath/wil6210/debugfs.c
> @@ -573,8 +573,10 @@ static ssize_t wil_write_file_txmgmt(struct file *file, const char __user *buf,
> if (!frame)
> return -ENOMEM;
>
> - if (copy_from_user(frame, buf, len))
> + if (copy_from_user(frame, buf, len)) {
> + kfree(frame);
> return -EIO;
> + }
>
> params.buf = frame;
> params.len = len;
> @@ -614,8 +616,10 @@ static ssize_t wil_write_file_wmi(struct file *file, const char __user *buf,
> return -ENOMEM;
>
> rc = simple_write_to_buffer(wmi, len, ppos, buf, len);
> - if (rc < 0)
> + if (rc < 0) {
> + kfree(wmi);
> return rc;
> + }
>
> cmd = &wmi[1];
> cmdid = le16_to_cpu(wmi->id);
>
Lino and Ahmed: thanks for that. Here is my
Signed-off-by: Vladimir Kondratiev <qca_vkondrat-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
John: please merge
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: tun issue after e0b46d0ee9c: tun: Use iovec iterators
From: Herbert Xu @ 2014-11-30 8:21 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <547954B9.2050804@redhat.com>
On Sat, Nov 29, 2014 at 03:08:09AM -0200, Marcelo Ricardo Leitner wrote:
> On 28-11-2014 21:59, Herbert Xu wrote:
> >On Fri, Nov 28, 2014 at 05:25:27PM -0200, Marcelo Ricardo Leitner wrote:
> >>
> >>I saw there are tun updates on Dave's queue but none seemed to handle this.
> >>
> >>I can't use current net-next
> >>(799d2fff1858004526ad75d66a5dd8a5cce6ad40) on a kvm hypervisor
> >>because tun got clogged somehow. Bisected down to:
> >>
> >>commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
> >>Author: Herbert Xu <herbert@gondor.apana.org.au>
> >>Date: Fri Nov 7 21:22:23 2014 +0800
> >
> >Does this patch help?
>
> Yay, it does! Works for me, thanks Herbert.
> I didn't test performance, but dhcp could get through.
>
> Are you sure about the Fixes tag? Because bisect really pointed to e0b46d0ee9c.
Well according to your report you were having problems with
tun_get_user. The bug I introduced was in tun_put_user and has
already been fixed by Jason Wang.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-next 3/6] samples: bpf: example of stateful socket filtering
From: Alexei Starovoitov @ 2014-11-30 6:24 UTC (permalink / raw)
To: David Miller
Cc: Ingo Molnar, Andy Lutomirski, Daniel Borkmann,
Hannes Frederic Sowa, Eric Dumazet, Linux API,
Network Development, LKML
In-Reply-To: <20141129.210158.2021042941461629799.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sat, Nov 29, 2014 at 9:01 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
> Date: Wed, 26 Nov 2014 21:42:28 -0800
>
>> this socket filter example does:
>> - creates arraymap in kernel with key 4 bytes and value 8 bytes
>>
>> - loads eBPF program:
>> r0 = skb[14 + 9]; // load one byte of ip->proto
> ...
>> + BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
>
> I do not want anything having to do with fixed offsets from
> the skb.
>
> Nothing should know where things are in the SKB structure,
> especially user facing things.
>
> That's why we have explicit BPF operations for fetching
> specific SKB members, so that the layout is completely
> transparent to the entity generating BPF programs.
>
> Besides retaining the flexibility of changing the SKB
> layout arbitrarily without breaking bpf programs, there
> are also security considerations from allowing bpf
> programs to load arbitrary offsets.
>
> Sorry, I do not like this patch series at all.
sigh.
You misunderstood one wrong comment in the whole series.
r0 = skb[14 + 9]; // load one byte of ip->proto
is saying
r0 = skb->data[14 + 9]; // load one byte of ip->proto
it's loading one byte of packet payload and
not one byte of skb structure.
There are plenty of other comments where I mentioned that.
Including cover letter:
"Though native eBPF programs are way more powerful than classic filters
(attachable through similar setsockopt() call), they don't have skb field
accessors yet. Like skb->pkt_type, skb->dev->ifindex are not accessible.
There are sevaral ways to achieve that. That will be in the next set of patches.
So in this set native eBPF programs can only read data from packet and
access maps"
and in patch #2:
+static bool sock_filter_is_valid_access(int off, int size, enum
bpf_access_type type)
+{
+ /* skb fields cannot be accessed yet */
+ return false;
+}
In other words, there is no way to access skb fields yet.
There are several different ways I've implemented to
access skb fields, but they all had their cons and pros, so I
dropped them all to focus on basic things first.
Which is: read packet data and access maps.
Please let me know if you want me to fix this comment
in this patch of sample code.
^ permalink raw reply
* Re: [PATCH v3] sh_eth: Fix skb alloc size and alignment adjust rule.
From: David Miller @ 2014-11-30 5:12 UTC (permalink / raw)
To: ykaneko0929; +Cc: netdev, horms, magnus.damm, linux-sh
In-Reply-To: <1417088040-32144-1-git-send-email-ykaneko0929@gmail.com>
From: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Date: Thu, 27 Nov 2014 20:34:00 +0900
> From: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
>
> In the current driver, allocation size of skb does not care the alignment
> adjust after allocation.
> And also, in the current implementation, buffer alignment method by
> sh_eth_set_receive_align function has a bug that this function displace
> buffer start address forcedly when the alignment is corrected.
> In the result, tail of the skb will exceed allocated area and kernel panic
> will be occurred.
> This patch fix this issue.
>
> Signed-off-by: Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] netpoll: delete defconfig references to obsolete NETPOLL_TRAP
From: David Miller @ 2014-11-30 5:14 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <1417102096-16537-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 27 Nov 2014 10:28:16 -0500
> In commit 9c62a68d13119a1ca9718381d97b0cb415ff4e9d ("netpoll:
> Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") this
> Kconfig option was removed. So remove references to it from
> all defconfigs as well.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH V2] stmmac: platform: Move plat_dat checking earlier
From: David Miller @ 2014-11-30 5:12 UTC (permalink / raw)
To: chenhc; +Cc: peppe.cavallaro, vbridgers2013, netdev
In-Reply-To: <1417093534-21884-1-git-send-email-chenhc@lemote.com>
From: Huacai Chen <chenhc@lemote.com>
Date: Thu, 27 Nov 2014 21:05:34 +0800
> Original code only check/alloc plat_dat for the CONFIG_OF case, this
> patch check/alloc it earlier and unconditionally to avoid kernel build
> warnings:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:275
> stmmac_pltfr_probe() warn: variable dereferenced before check 'plat_dat'
>
> V2: Fix coding style.
>
> Signed-off-by: Huacai Chen <chenhc@lemote.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] vhost: remove unnecessary forward declarations in vhost.h
From: David Miller @ 2014-11-30 5:04 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1417070481-10331-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 27 Nov 2014 14:41:21 +0800
> Signed-off-by: Jason Wang <jasowang@redhat.com>
I don't think generic vhost patches should go via my tree.
If you disagree, let me know why, thanks :)
^ permalink raw reply
* Re: [PATCH net] rtnetlink: release net refcnt on error in do_setlink()
From: David Miller @ 2014-11-30 5:07 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, ebiederm
In-Reply-To: <1417079775-9287-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 27 Nov 2014 10:16:15 +0100
> rtnl_link_get_net() holds a reference on the 'struct net', we need to release
> it in case of error.
>
> CC: Eric W. Biederman <ebiederm@xmission.com>
> Fixes: b51642f6d77b ("net: Enable a userns root rtnl calls that are safe for unprivilged users")
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/6] samples: bpf: example of stateful socket filtering
From: David Miller @ 2014-11-30 5:01 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
dborkman-H+wXaHxf7aLQT0dZR+AlfA,
hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417066951-1999-4-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Wed, 26 Nov 2014 21:42:28 -0800
> this socket filter example does:
> - creates arraymap in kernel with key 4 bytes and value 8 bytes
>
> - loads eBPF program:
> r0 = skb[14 + 9]; // load one byte of ip->proto
...
> + BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
I do not want anything having to do with fixed offsets from
the skb.
Nothing should know where things are in the SKB structure,
especially user facing things.
That's why we have explicit BPF operations for fetching
specific SKB members, so that the layout is completely
transparent to the entity generating BPF programs.
Besides retaining the flexibility of changing the SKB
layout arbitrarily without breaking bpf programs, there
are also security considerations from allowing bpf
programs to load arbitrary offsets.
Sorry, I do not like this patch series at all.
^ permalink raw reply
* Re: [PATCH net-next V3] tun/macvtap: use consume_skb() instead of kfree_skb() when needed
From: David Miller @ 2014-11-30 5:03 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, eric.dumazet
In-Reply-To: <1417070166-7026-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Thu, 27 Nov 2014 14:36:06 +0800
> To be more friendly with drop monitor, we should only call kfree_skb() when
> the packets were dropped and use consume_skb() in other cases.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> Changes from V2:
> - use unlikely() when necessary
> Changes from V1:
> - check the return value of tun/macvtap_put_user()
This does not apply cleanly to net-next and will thus need to
be respun, thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipvlan: ipvlan depends on INET and IPV6
From: David Miller @ 2014-11-30 4:53 UTC (permalink / raw)
To: maheshb; +Cc: netdev, jim.epost
In-Reply-To: <1417065225-784-1-git-send-email-maheshb@google.com>
From: Mahesh Bandewar <maheshb@google.com>
Date: Wed, 26 Nov 2014 21:13:45 -0800
> This driver uses ip_out_local() and ip6_route_output() which are
> defined only if CONFIG_INET and CONFIG_IPV6 are enabled respectively.
>
> Reported-by: Jim Davis <jim.epost@gmail.com>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks for fixing this.
^ permalink raw reply
* Re: [PATCH net] bond: Check length of IFLA_BOND_ARP_IP_TARGET attributes
From: David Miller @ 2014-11-30 4:49 UTC (permalink / raw)
To: tgraf; +Cc: netdev, sfeldma
In-Reply-To: <a7c193909c30dbc19b4f279a3f7ba757107641d3.1417044113.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 27 Nov 2014 00:22:33 +0100
> Fixes: 7f28fa10 ("bonding: add arp_ip_target netlink support")
> Reported-by: John Fastabend <john.fastabend@gmail.com>
> Cc: Scott Feldman <sfeldma@cumulusnetworks.com>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] macvlan: delay the header check for dodgy packets into lower device
From: David Miller @ 2014-11-30 4:45 UTC (permalink / raw)
To: jasowang; +Cc: kaber, netdev, linux-kernel, mst, vyasevic
In-Reply-To: <1416993674-11177-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 26 Nov 2014 17:21:14 +0800
> We do header check twice for a dodgy packet. One is done before
> macvlan_start_xmit(), another is done before lower device's
> ndo_start_xmit(). The first one seems redundant so this patch tries to
> delay header check until a packet reaches its lower device (or macvtap)
> through always enabling NETIF_F_GSO_ROBUST for macvlan device.
>
> Cc: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] xen-netfront: Remove BUGs on paged skb data which crosses a page boundary
From: David Miller @ 2014-11-30 4:43 UTC (permalink / raw)
To: seth.forshee
Cc: konrad.wilk, boris.ostrovsky, david.vrabel, zoltan.kiss,
eric.dumazet, stefan.bader, xen-devel, netdev, linux-kernel
In-Reply-To: <20141127035350.GA10833@ubuntu-mba51>
From: Seth Forshee <seth.forshee@canonical.com>
Date: Wed, 26 Nov 2014 21:53:50 -0600
> On Wed, Nov 26, 2014 at 12:28:12PM -0500, David Miller wrote:
>> From: Seth Forshee <seth.forshee@canonical.com>
>> Date: Tue, 25 Nov 2014 20:28:24 -0600
>>
>> > These BUGs can be erroneously triggered by frags which refer to
>> > tail pages within a compound page. The data in these pages may
>> > overrun the hardware page while still being contained within the
>> > compound page, but since compound_order() evaluates to 0 for tail
>> > pages the assertion fails. The code already iterates through
>> > subsequent pages correctly in this scenario, so the BUGs are
>> > unnecessary and can be removed.
>> >
>> > Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
>> > Cc: <stable@vger.kernel.org> # 3.7+
>> > Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
>>
>> Can I get some Xen developer reviews?
>
> Fwiw this issue was discussed previously and this was the recommended
> fix.
>
> http://article.gmane.org/gmane.linux.kernel/1825381
>
> Since then I got some feedback from a tester that he didn't see any
> problems with the BUGs removed (actually replaced with a WARN so I know
> that he actually saw the condition which triggered the BUG).
That's fine, but I still want a xen-netfront developer to review and
ACK this.
^ permalink raw reply
* Re: Non Explained TODOs in halbtcoutsrc.c
From: Larry Finger @ 2014-11-30 4:31 UTC (permalink / raw)
To: nick; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <547A581A.7040609@gmail.com>
On 11/29/2014 05:34 PM, nick wrote:
> Greetings Larry,
> After reading the code around the TODOS, I can't understand you reasoning for them in this file as they seem to
> unneeded as the logic for the switch statement with them seems to be fine. If there are reasons for them in this
> file, it would be nice to hear from you on why they are needed as TODO as a comment is rather unclear for anybody
> reading this file.
> Nick
I did not write that code. I merely make it available through the git repo, and
modify it so that it will build on all kernel versions. I do not understand the
TODOs any more than you do.
Larry
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-11-30 2:52 UTC (permalink / raw)
To: Wei Yang; +Cc: netdev, davem, gideonn, Eric Dumazet, Amir Vadai
In-Reply-To: <1417315431-16761-1-git-send-email-weiyang@linux.vnet.ibm.com>
BTW, I have one confusion in commit 6a4e812,
if (ring->bf_enabled && desc_size <= MAX_BF && !bounce &&
!vlan_tx_tag_present(skb) && send_doorbell) {
- tx_desc->ctrl.bf_qpn |= cpu_to_be32(ring->doorbell_qpn);
+ tx_desc->ctrl.bf_qpn = ring->doorbell_qpn |
+ cpu_to_be32(real_size);
I am curious about why it adds an | with the real_size?
I see this code pass is invoked in vlan network. I am not farmiliar with
the vlan test. I guess it needs some router with vlan configuration. If you
have some suggestion or link on how to test it, I am happy to have a try.
On Sun, Nov 30, 2014 at 10:43:51AM +0800, Wei Yang wrote:
>In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
>doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
>by iowrite32() instead of iowrite32be().
>
>This works fine on little endian platform, while has some problem on big
>endian platform. Here is the definition in general:
>
> #define iowrite32(v, addr) writel((v), (addr))
> #define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
>
>On little endian platform, the value is not swapped before write. While on big
>endian platform, the value is swapped. This is not expected to happen.
>
>This patch does the swap on big endian platform before it is written.
>
>Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>CC: Eric Dumazet <edumazet@google.com>
>CC: Amir Vadai <amirv@mellanox.com>
>---
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>index 454d9fe..76f028b 100644
>--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
>@@ -954,7 +954,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> tx_desc->ctrl.owner_opcode = op_own;
> if (send_doorbell) {
> wmb();
>- iowrite32(ring->doorbell_qpn,
>+ iowrite32(__cpu_to_le32(ring->doorbell_qpn),
> ring->bf.uar->map + MLX4_SEND_DOORBELL);
> } else {
> ring->xmit_more++;
>--
>1.7.9.5
--
Richard Yang
Help you, Help me
^ permalink raw reply
* [PATCH net] net/mlx4_en: correct the endianness of doorbell_qpn on big endian platform
From: Wei Yang @ 2014-11-30 2:43 UTC (permalink / raw)
To: netdev; +Cc: davem, gideonn, Wei Yang, Eric Dumazet, Amir Vadai
In commit 6a4e812 (net/mlx4_en: Avoid calling bswap in tx fast path), we store
doorbell_qpn in big endian to avoid bswap(). Then we try to write it directly
by iowrite32() instead of iowrite32be().
This works fine on little endian platform, while has some problem on big
endian platform. Here is the definition in general:
#define iowrite32(v, addr) writel((v), (addr))
#define writel(b,addr) __raw_writel(__cpu_to_le32(b),addr)
On little endian platform, the value is not swapped before write. While on big
endian platform, the value is swapped. This is not expected to happen.
This patch does the swap on big endian platform before it is written.
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
CC: Eric Dumazet <edumazet@google.com>
CC: Amir Vadai <amirv@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
index 454d9fe..76f028b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
@@ -954,7 +954,7 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
tx_desc->ctrl.owner_opcode = op_own;
if (send_doorbell) {
wmb();
- iowrite32(ring->doorbell_qpn,
+ iowrite32(__cpu_to_le32(ring->doorbell_qpn),
ring->bf.uar->map + MLX4_SEND_DOORBELL);
} else {
ring->xmit_more++;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] e1000: remove unused variables
From: Ben Hutchings @ 2014-11-30 1:45 UTC (permalink / raw)
To: Hisashi T Fujinaka
Cc: Linux NICS, e1000-devel, Bruce Allan, Jesse Brandeburg,
linux-kernel, John Ronciak, netdev, Sudip Mukherjee
In-Reply-To: <alpine.NEB.2.11.1411262157110.1481@chris.i8u.org>
[-- Attachment #1.1: Type: text/plain, Size: 515 bytes --]
On Wed, 2014-11-26 at 21:59 -0800, Hisashi T Fujinaka wrote:
> I'm pretty sure those double reads are there for a reason, so most of
> this I'm going to have to check on Monday. We have a long holiday
> weekend here in the US.
[...]
If there were double register reads being replaced with single register
reads, I'd agree this was likely to introduce a regression. But all I
see is var = er32(REG) being changed to er32(REG).
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
[-- Attachment #2: Type: text/plain, Size: 441 bytes --]
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH iproute2] ip xfrm: support 64bit kernel and 32bit userspace
From: Ben Hutchings @ 2014-11-30 1:33 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1417157936-5522-1-git-send-email-roy.qing.li@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Fri, 2014-11-28 at 14:58 +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> The size of struct xfrm_userpolicy_info is 168 bytes for 64bit kernel, and
> 164 bytes for 32bit userspace because of the different alignment.
I think it's specific to x86 as other architectures have the same type
alignments for 32- and 64-bit variants.
> and lead to "ip xfrm" be unable to work.
>
> add a pad in struct xfrm_userpolicy_info, and enable it by set
> KERNEL_64_USERSPACE_32 to y
[...]
This doesn't make sense. 32-bit compat needs to work like 32-bit native
- no exceptions, no workarounds in userland. And if you really want to
work around this in userland you'll need a run-time, not compile-time,
check.
Ben.
--
Ben Hutchings
The world is coming to an end. Please log off.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ 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