* [PATCH] net: tulip: Remove private "strncmp"
From: Rasmus Villemoes @ 2014-12-04 10:30 UTC (permalink / raw)
To: Grant Grundler; +Cc: Rasmus Villemoes, netdev, linux-kernel
The comment says that the built-in strncmp didn't work. That is not
surprising, as apparently "str" semantics are not really what is
wanted (hint: de4x5_strncmp only stops when two different bytes are
encountered or the end is reached; not if either byte happens to be
0). de4x5_strncmp is actually a memcmp (except for the signature and
that bytes are not necessarily treated as unsigned char); since only
the boolean value of the result is used we can just replace
de4x5_strncmp with memcmp.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
Notes:
I don't know if the comment meant to say 3 bytes, or if the code
compares meaningful chunks of memory (the first three bytes of
&lp->srom span 1.5 fields, and the three bytes from (char*)&lp->srom +
0x10 are &lp->srom.{id_block_crc,reserved2,version} - it seems odd
that these chunks should ever be equal to each other and to the
enet_det[i]). Whether or not the current code works, this patch
shouldn't change the semantics, and I'd like to get rid of
de4x5_strncmp since it is not, in fact, a strncmp.
drivers/net/ethernet/dec/tulip/de4x5.c | 20 +++-----------------
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/de4x5.c b/drivers/net/ethernet/dec/tulip/de4x5.c
index cf8b6ff..badff18 100644
--- a/drivers/net/ethernet/dec/tulip/de4x5.c
+++ b/drivers/net/ethernet/dec/tulip/de4x5.c
@@ -995,7 +995,6 @@ static void de4x5_dbg_mii(struct net_device *dev, int k);
static void de4x5_dbg_media(struct net_device *dev);
static void de4x5_dbg_srom(struct de4x5_srom *p);
static void de4x5_dbg_rx(struct sk_buff *skb, int len);
-static int de4x5_strncmp(char *a, char *b, int n);
static int dc21041_infoleaf(struct net_device *dev);
static int dc21140_infoleaf(struct net_device *dev);
static int dc21142_infoleaf(struct net_device *dev);
@@ -4102,8 +4101,7 @@ get_hw_addr(struct net_device *dev)
}
/*
-** Test for enet addresses in the first 32 bytes. The built-in strncmp
-** didn't seem to work here...?
+** Test for enet addresses in the first 32 bytes.
*/
static int
de4x5_bad_srom(struct de4x5_private *lp)
@@ -4111,8 +4109,8 @@ de4x5_bad_srom(struct de4x5_private *lp)
int i, status = 0;
for (i = 0; i < ARRAY_SIZE(enet_det); i++) {
- if (!de4x5_strncmp((char *)&lp->srom, (char *)&enet_det[i], 3) &&
- !de4x5_strncmp((char *)&lp->srom+0x10, (char *)&enet_det[i], 3)) {
+ if (!memcmp(&lp->srom, &enet_det[i], 3) &&
+ !memcmp((char *)&lp->srom+0x10, &enet_det[i], 3)) {
if (i == 0) {
status = SMC;
} else if (i == 1) {
@@ -4125,18 +4123,6 @@ de4x5_bad_srom(struct de4x5_private *lp)
return status;
}
-static int
-de4x5_strncmp(char *a, char *b, int n)
-{
- int ret=0;
-
- for (;n && !ret; n--) {
- ret = *a++ - *b++;
- }
-
- return ret;
-}
-
static void
srom_repair(struct net_device *dev, int card)
{
--
2.0.4
^ permalink raw reply related
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 10:24 UTC (permalink / raw)
To: Midge Shaojun Tan
Cc: Bjørn Mork, Kevin Zhu, Eli Britstein, Alex Strizhevsky,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <AMSPR06MB6011E001029C251790CB923EE780-MyG0ARRHH/drF+2gGhmTpL9PrO6axcR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4283 bytes --]
Congratulations!
Your modification to the driver work; the disable of padding itself alone did not.
With the modified file version I am able to use the device with no problems.
Congratulations guys.
On Thu, 4 Dec 2014, Midge Shaojun Tan wrote:
> Date: Thu, 4 Dec 2014 11:10:16
> From: Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Hi all,
>
> I test OK with kervel 3.16.4
> Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
> And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
> With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
> Please see the patch and check whether it is correct?
>
>
> -----邮件原件-----
> 发件人: Enrico Mioso [mailto:mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> 发送时间: 2014年12月4日 17:54
> 收件人: Bjørn Mork
> 抄送: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 主题: Re: Is this 32-bit NCM?y
>
> Guys!
> Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now.
> So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here.
>
>
>
>
>
> On Thu, 4 Dec 2014, Bjørn Mork wrote:
>
>> Date: Thu, 4 Dec 2014 10:19:11
>> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>> To: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Subject: Re: Is this 32-bit NCM?y
>>
>> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
>>
>>> Guys,
>>>
>>> After rearranging the padding, putting NCM0 right after NTH, and
>>> disable ARP (FLAG_NOARP) and handling the offset alignment issue, it
>>> seems it begins to work, though there's still problem with DHCP.
>>
>> Great! But it would be good to know if _one_ of these changes is
>> enough to make it work.
>>
>>> The DHCP packet's size becomes a large one after the TX function,
>>> which is 16384, the maximum.
>>
>> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
>> Something like this should do for a simple test:
>>
>> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>>
>>
>> Bjørn
>>
> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>
> If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
>
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Midge Shaojun Tan @ 2014-12-04 10:10 UTC (permalink / raw)
To: Enrico Mioso, Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, youtux@gmail.com,
linux-usb@vger.kernel.org, netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]
Hi all,
I test OK with kervel 3.16.4
Need disable other Ethernet network, just like eth1. (Then the DNS and route is OK)
And also need disable arp, (ifconfig wwan0 -arp up), because China UNICOM don't respond the ARP message.
With new mode switch string: /etc/usb_modeswitch.d/12d1:14fe
Please see the patch and check whether it is correct?
-----邮件原件-----
发件人: Enrico Mioso [mailto:mrkiko.rs@gmail.com]
发送时间: 2014年12月4日 17:54
收件人: Bjørn Mork
抄送: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun Tan; youtux@gmail.com; linux-usb@vger.kernel.org; netdev@vger.kernel.org
主题: Re: Is this 32-bit NCM?y
Guys!
Don't forget I can test it - since I have a remote machine with 3.16 kernel and the device, at least for now.
So - Bjorn: do I need just to disable padding or do I need also to perform some other changes? I am sorry if I ask this a little bit stupidly, but I was alittle bit busy here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 10:19:11
> From: Bjørn Mork <bjorn@mork.no>
> To: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@gmail.com>,
> Eli Britstein <Eli.Britstein@audiocodes.com>,
> Alex Strizhevsky <alexxst@gmail.com>,
> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> "youtux@gmail.com" <youtux@gmail.com>,
> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and
>> disable ARP (FLAG_NOARP) and handling the offset alignment issue, it
>> seems it begins to work, though there's still problem with DHCP.
>
> Great! But it would be good to know if _one_ of these changes is
> enough to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function,
>> which is 16384, the maximum.
>
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
[-- Attachment #2: cdc_ncm.tgz --]
[-- Type: application/x-compressed, Size: 25607 bytes --]
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2 tuntap: Increase the number of queues in tun.
From: Michael S. Tsirkin @ 2014-12-04 10:20 UTC (permalink / raw)
To: Jason Wang
Cc: Pankaj Gupta, linux-kernel, netdev, davem, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen, jiri, sergei.shtylyov
In-Reply-To: <1417661734.16500.0@smtp.corp.redhat.com>
On Thu, Dec 04, 2014 at 03:03:34AM +0008, Jason Wang wrote:
>
>
> On Wed, Dec 3, 2014 at 5:52 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >On Wed, Dec 03, 2014 at 12:49:37PM +0530, Pankaj Gupta wrote:
> >> Networking under kvm works best if we allocate a per-vCPU RX and TX
> >> queue in a virtual NIC. This requires a per-vCPU queue on the host
> >>side.
> >> It is now safe to increase the maximum number of queues.
> >> Preceding patche: 'net: allow large number of rx queues'
> >
> >s/patche/patch/
> >
> >> made sure this won't cause failures due to high order memory
> >> allocations. Increase it to 256: this is the max number of vCPUs
> >> KVM supports.
> >> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> >> Reviewed-by: David Gibson <dgibson@redhat.com>
> >
> >Hmm it's kind of nasty that each tun device is now using x16 memory.
> >Maybe we should look at using a flex array instead, and removing the
> >limitation altogether (e.g. make it INT_MAX)?
>
> But this only happens when IFF_MULTIQUEUE were used.
I refer to this field:
struct tun_file __rcu *tfiles[MAX_TAP_QUEUES];
if we make MAX_TAP_QUEUES 256, this will use 4K bytes,
apparently unconditionally.
> And core has vmalloc() fallback.
> So probably not a big issue?
> >
> >
> >
> >> ---
> >> drivers/net/tun.c | 9 +++++----
> >> 1 file changed, 5 insertions(+), 4 deletions(-)
> >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> >> index e3fa65a..a19dc5f8 100644
> >> --- a/drivers/net/tun.c
> >> +++ b/drivers/net/tun.c
> >> @@ -113,10 +113,11 @@ struct tap_filter {
> >> unsigned char addr[FLT_EXACT_COUNT][ETH_ALEN];
> >> };
> >> -/* DEFAULT_MAX_NUM_RSS_QUEUES were chosen to let the rx/tx queues
> >>allocated for
> >> - * the netdevice to be fit in one page. So we can make sure the
> >>success of
> >> - * memory allocation. TODO: increase the limit. */
> >> -#define MAX_TAP_QUEUES DEFAULT_MAX_NUM_RSS_QUEUES
> >> +/* MAX_TAP_QUEUES 256 is chosen to allow rx/tx queues to be equal
> >> + * to max number of vCPUS in guest. Also, we are making sure here
> >> + * queue memory allocation do not fail.
> >
> >It's not queue memory allocation anymore, is it?
> >I would say "
> >This also helps the tfiles field fit in 4K, so the whole tun
> >device only needs an order-1 allocation.
> >"
> >
> >> + */
> >> +#define MAX_TAP_QUEUES 256
> >> #define MAX_TAP_FLOWS 4096
> >> #define TUN_FLOW_EXPIRE (3 * HZ)
> >> -- 1.8.3.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: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Michael S. Tsirkin @ 2014-12-04 10:17 UTC (permalink / raw)
To: Rick Jones
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Wang,
Du, Fan, fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <547F5CC2.8000908-VXdhtT5mjnY@public.gmane.org>
On Wed, Dec 03, 2014 at 10:56:02AM -0800, Rick Jones wrote:
> Trying to "fake-out" an ICMP message to paper-over "devices" in the "middle"
> of same Layer2 network having different MTUs from the ends goes back to at
> least the days when people started joining FDDI networks to Ethernet
> networks with bridges rather than routers. Perhaps back even further. It
> had problems them (including not all traffic being IP), I doubt today would
> be any different.
>
> All devices in a Layer2 network must have the same MTU. (*)
>
> The only exception to that which does not lead one down a rathole is that
> you can have the MTU at the "edges" of the Layer 2 network be smaller than
> the MTU in the "middle." And then only if the middle "never" tries to talk
> itself to the edges directly.
>
> rick jones
>
> (*) Or at least any communicating device must be kept ignorant of what one
> does to have a smaller MTU in there somewhere.
What I've been pointing out is that just because something is within a VM,
we can't assume it's an edge.
--
MST
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 10:02 UTC (permalink / raw)
To: Enrico Mioso
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412041052310.3861@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> Guys!
> Don't forget I can test it - since I have a remote machine with 3.16
> kernel and the device, at least for now.
> So - Bjorn: do I need just to disable padding or do I need also to
> perform some other changes? I am sorry if I ask this a little bit
> stupidly, but I was alittle bit busy here.
I don't know. I just mentioned it because it is easy to test, although
the method isn't too obvious. Someone should document this somewhere.
Hey, wait... Someone did :-)
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 9:55 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548028A0.5000909@audiocodes.com>
Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
> I will find it out. And I don't have v3.16 and I'm not going to upgrade
> my OS to that. Sorry. So I would just stick to v3.13.
Ouch. well, OK. I certainly hope you are at v3.13.10 or newer at
least. Otherwise we know very well what the problem is...
One of the reasons for the series that went into v3.16 was making this
sort of debugging easier, enabling on-the-fly NCM aggregation parameter
tuning. I'd certainly recommend taking advantage of it instead of
rebulding the driver every time you want to test the effect of some
minor change to the aggregation scheme. And do feel free to add more
knobs if you need them.
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 9:53 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <874mtbojqo.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1529 bytes --]
Guys!
Don't forget I can test it - since I have a remote machine with 3.16 kernel
and the device, at least for now.
So - Bjorn: do I need just to disable padding or do I need also to perform some
other changes? I am sorry if I ask this a little bit stupidly, but I was
alittle bit busy here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 10:19:11
> From: Bjørn Mork <bjorn@mork.no>
> To: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@gmail.com>,
> Eli Britstein <Eli.Britstein@audiocodes.com>,
> Alex Strizhevsky <alexxst@gmail.com>,
> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> "youtux@gmail.com" <youtux@gmail.com>,
> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP.
>
> Great! But it would be good to know if _one_ of these changes is enough
> to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum.
>
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
>
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Jiri Slaby @ 2014-12-04 9:44 UTC (permalink / raw)
To: f.wiessner, netdev, LKML, stable
In-Reply-To: <547F2462.6040405@smart-weblications.de>
On 12/03/2014, 03:55 PM, Smart Weblications GmbH - Florian Wiessner wrote:
> [16623.095403] BUG: unable to handle kernel paging request at 00000000010600d0
> [16623.095445] IP: [<ffffffff81547767>] xfrm_selector_match+0x25/0x2f6
> [16623.095480] PGD aeaea067 PUD 85d95067 PMD 0
> [16623.095513] Oops: 0000 [#1] SMP
> [16623.095543] Modules linked in: netconsole xt_nat xt_multiport veth ip_vs_rr
...
> [16623.096062] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.33 #1
> [16623.096091] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
> 09/28/2011
> [16623.096137] task: ffffffff81804450 ti: ffffffff817f4000 task.ti: ffffffff817f4000
> [16623.096182] RIP: 0010:[<ffffffff81547767>] [<ffffffff81547767>]
> xfrm_selector_match+0x25/0x2f6
> [16623.096233] RSP: 0018:ffff88083fc03900 EFLAGS: 00010246
> [16623.096261] RAX: 0000000000000001 RBX: ffff88083fc03a20 RCX: ffff880787fb1200
> [16623.096292] RDX: 0000000000000002 RSI: ffff88083fc03a20 RDI: 00000000010600a6
> [16623.096323] RBP: 00000000010600a6 R08: 0000000000000000 R09: ffff88083fc039a0
> [16623.096353] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88083fc03a20
> [16623.096383] R13: 0000000000000001 R14: ffffffff818a9700 R15: ffffffffa01c73e0
> [16623.096414] FS: 0000000000000000(0000) GS:ffff88083fc00000(0000)
> knlGS:0000000000000000
> [16623.096469] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [16623.096498] CR2: 00000000010600d0 CR3: 0000000085f0b000 CR4: 00000000000407f0
> [16623.096528] Stack:
> [16623.096550] 0000000000000000 0000000001060002 ffff880787fb1200 ffff88083fc03a20
> [16623.096602] 0000000000000001 ffffffff81547a7c 0000000000000000 ffff8800baad5480
> [16623.096655] ffffffff81804450 ffffffff818a9700 000000003c9041bc ffffffff81547ef7
> [16623.096721] Call Trace:
> [16623.096744] <IRQ>
> [16623.096749] [<ffffffff81547a7c>] ? xfrm_sk_policy_lookup+0x44/0x9b
> [16623.096802] [<ffffffff81547ef7>] ? xfrm_lookup+0x91/0x446
> [16623.096832] [<ffffffff81541316>] ? ip_route_me_harder+0x150/0x1b0
> [16623.096865] [<ffffffffa01b6457>] ? ip_vs_route_me_harder+0x86/0x91 [ip_vs]
> [16623.096899] [<ffffffffa01b797a>] ? ip_vs_out+0x2d3/0x5bc [ip_vs]
> [16623.096930] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
> [16623.096959] [<ffffffff814fc2d3>] ? nf_iterate+0x42/0x80
> [16623.096989] [<ffffffff814fc37a>] ? nf_hook_slow+0x69/0xff
> [16623.097017] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
> [16623.097047] [<ffffffff81501744>] ? ip_local_deliver+0x6f/0x7e
> [16623.097078] [<ffffffff814d82a6>] ? __netif_receive_skb_core+0x5f0/0x66c
> [16623.097108] [<ffffffff814d84b7>] ? process_backlog+0x13e/0x13e
> [16623.097140] [<ffffffffa04b4e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
> [16623.097187] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
> [16623.097218] [<ffffffffa04b4d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
> [16623.097265] [<ffffffffa04b4fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
> [16623.097297] [<ffffffffa048e4aa>] ? bond_handle_frame+0x86/0x1bd [bonding]
> [16623.097328] [<ffffffff814d8155>] ? __netif_receive_skb_core+0x49f/0x66c
> [16623.097358] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
> [16623.097388] [<ffffffff814d9091>] ? napi_gro_receive+0x35/0x76
> [16623.097418] [<ffffffff813eae17>] ? e1000_clean_rx_irq+0x26d/0x2f5
> [16623.097448] [<ffffffff813ef48e>] ? e1000e_poll+0x65/0x23d
> [16623.097477] [<ffffffff814d8709>] ? net_rx_action+0xa2/0x1c0
...
> This happens again and again with 3.12.33
>
>
> see also: http://www.spinics.net/lists/netdev/msg306283.html
>
> is this already fixed somehow?
Hi, I doubt so, as you are the first one letting me know. Could you
check whether 3.12.30 works OK for you?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 9:28 UTC (permalink / raw)
To: Kevin Zhu
Cc: Bjørn Mork, Enrico Mioso, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2567 bytes --]
Ok - but... you can upgrade your OS to that without any effort - simply apt-get-installing the required linux-image-3.16 package plus the -extra package. It's nothing more in case.
thank you kevin, thank you Bjorn.
Enrico
On Thu, 4 Dec 2014, Kevin Zhu wrote:
> Date: Thu, 4 Dec 2014 10:26:20
> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
> To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: Is this 32-bit NCM?y
>
> I will find it out. And I don't have v3.16 and I'm not going to upgrade
> my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size
> is wrong, it should be fixed.
>
> Regards,
> Kevin
>
> On 12/04/2014 05:19 PM, Bjørn Mork wrote:
>> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
>>
>>> Guys,
>>>
>>> After rearranging the padding, putting NCM0 right after NTH, and disable
>>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>>> begins to work, though there's still problem with DHCP.
>> Great! But it would be good to know if _one_ of these changes is enough
>> to make it work.
>>
>>> The DHCP packet's size becomes a large one after the TX function, which
>>> is 16384, the maximum.
>> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
>> Something like this should do for a simple test:
>>
>> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>>
>>
>> Bjørn
> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>
> If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
>
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Thomas Graf @ 2014-12-04 9:26 UTC (permalink / raw)
To: Jesse Gross
Cc: Michael S. Tsirkin, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <CAEP_g=8U_w+dxUHsTH2JQ9dGNHaJp-ai8pdmrfeYBin9NZ46jQ@mail.gmail.com>
On 12/03/14 at 05:51pm, Jesse Gross wrote:
> I think it depends on where you put the PMTU check. If routing is
> happening in OVS where it is decomposed in several discrete actions
> like set MAC and decrement TTL then perhaps there is another explicit
> action to check the MTU. If it is happening in the context of the IP
> stack, then ICMP generation occurs automatically and if you get that
> if you write a flow to send a packet there. In each case, it seems
> like a flow would be steering you by way of an action to do routing so
> you would have fine grained control. I don't see this as conflicting
> with L3 ACLs in an L2 context in the same way that you don't have to
> automatically decrement the TTL.
OK, I was under the impression that you would detect L3 behaviour
desire in OVS without an explicit action. Hence the worry on wrong
classification for L3 ACLs.
Whether we mark the packet and defer the MTU check or we check right
in the action is an implementation detail in the end. I think we
agree on concept level that we need an API to control behaviour.
^ permalink raw reply
* Re: [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Joe Perches @ 2014-12-04 9:26 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Laight, Quentin Lambert, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1417114175.4305.3.camel@perches.com>
On Thu, 2014-11-27 at 10:49 -0800, Joe Perches wrote:
> On Thu, 2014-11-27 at 12:25 +0000, David Laight wrote:
> > Why the change in data?
>
> btw: without gcov and using -O2
>
> $ size arch/x86/net/bpf_jit_comp.o*
> text data bss dec hex filename
> 9671 4 0 9675 25cb arch/x86/net/bpf_jit_comp.o.new
> 10679 4 0 10683 29bb arch/x86/net/bpf_jit_comp.o.old
Alexei?
Is this 10% reduction in size a good reason to change the code?
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 9:26 UTC (permalink / raw)
To: Bjørn Mork
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <874mtbojqo.fsf@nemi.mork.no>
I will find it out. And I don't have v3.16 and I'm not going to upgrade
my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size
is wrong, it should be fixed.
Regards,
Kevin
On 12/04/2014 05:19 PM, Bjørn Mork wrote:
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP.
> Great! But it would be good to know if _one_ of these changes is enough
> to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum.
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 9:19 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548020DD.3030705@audiocodes.com>
Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
> Guys,
>
> After rearranging the padding, putting NCM0 right after NTH, and disable
> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
> begins to work, though there's still problem with DHCP.
Great! But it would be good to know if _one_ of these changes is enough
to make it work.
> The DHCP packet's size becomes a large one after the TX function, which
> is 16384, the maximum.
You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
Something like this should do for a simple test:
echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 9:01 UTC (permalink / raw)
To: Enrico Mioso
Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <alpine.LNX.2.03.1412040955140.3516-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
It looks windows disable it, so I just follow it. Maybe enabling it will
be also OK. I have not tried. I do not find it in hw_cdc_driver.
Regards,
Kevin
On 12/04/2014 04:56 PM, Enrico Mioso wrote:
> Hi Kevin.
> Thank you for your hints and work.
> Only a note - why disabling ARP? I think it could be a good iea... or
> does the hw_cdc_driver do that?
> thank you again,
> Enrico
>
>
>
> On Thu, 4 Dec 2014, Kevin Zhu wrote:
>
>> Date: Thu, 4 Dec 2014 09:52:49
>> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein
>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Subject: Re: Is this 32-bit NCM?y
>>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP. It's able to
>> ping, though my Ubuntu network manage does not notice this network
>> interface. So no DNS.
>>
>> I have to specify the network interface and IP in the ping command.
>>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum. And the dongle does not reply it in time. For
>> now, I just simple rearrange the code to meet Huawei's alignment
>> requirement. I think other devices may be different, regarding the
>> 'offset' definition. We may need to handle it. And also need to double
>> check if the code has bugs.
>>
>> Regards,
>> Kevin
>>
>> On 12/04/2014 02:31 PM, Enrico Mioso wrote:
>>> Hello guys!
>>> I am writing this message to hear if there is any progress,
>>> Enrico
>>>
>>>
>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>
>>>> Date: Wed, 3 Dec 2014 07:05:37
>>>> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>>>> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein
>>>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>>>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>> Subject: Re: Is this 32-bit NCM?
>>>>
>>>> OK. I will. Thank you for everything!
>>>>
>>>> Regards,
>>>> Kevin
>>>>
>>>> On 12/03/2014 02:00 PM, Enrico Mioso wrote:
>>>>> Yes - I think this would be ok. You might try this with the 16-bit
>>>>> river first,
>>>>> and then with the 32-bit one to see how things work.
>>>>> I hope for the best.
>>>>> Let us all know,
>>>>> Enrico
>>>>>
>>>>>
>>>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>>>
>>>>> ==Date: Wed, 3 Dec 2014 06:38:27
>>>>> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>>>>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein
>>>>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>>>>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>>> ==Subject: Re: Is this 32-bit NCM?
>>>>> ==
>>>>> ==My dongle also works with the huawei driver. I think only the 32bit
>>>>> ==format and NDP location matter. We may modify the TX function to
>>>>> put NTH
>>>>> ==and NDP at the beginning of a NTB and see if it will work with the
>>>>> ==driver cdc_ncm.
>>>>> ==
>>>>> ==Regards,
>>>>> ==Kevin
>>>>> ==
>>>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote:
>>>>> ==> ... And what do you think about the source code of their ndis
>>>>> driver?
>>>>> ==> We at least know now the device work with it, so we have
>>>>> something to mimic :D
>>>>> ==> thank you for your work and patience Kevin.
>>>>> ==>
>>>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>>>> ==>
>>>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25
>>>>> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>>>>> ==> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork
>>>>> <bjorn-yOkvZcmFvRU@public.gmane.org>
>>>>> ==> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> ==> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY@public.gmane.orgnel.org>,
>>>>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TaqPxH82wqD4g@public.gmane.orgg>
>>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>>> ==> ==
>>>>> ==> ==I do not understand why the wSequence matters. By the way, I
>>>>> think I see some NDPs are right after NTH headers in the windows
>>>>> capture.
>>>>> ==> ==
>>>>> ==> ==________________________________________
>>>>> ==> ==From: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ==> ==Sent: Tuesday, December 2, 2014 21:53
>>>>> ==> ==To: Bjørn Mork
>>>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun
>>>>> Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>>>>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>>> ==> ==
>>>>> ==> ==Thank you very much Bjorn.
>>>>> ==> ==
>>>>> ==> ==
>>>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote:
>>>>> ==> ==
>>>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03
>>>>> ==> ====From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>>>>> ==> ====To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>,
>>>>> ==> ==== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>>> ==> ==== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> ==== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb@vger.kernel.org>,
>>>>> ==> ==== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY@public.gmane.orgnel.org>
>>>>> ==> ====Subject: Re: Is this 32-bit NCM?
>>>>> ==> ====
>>>>> ==> ====Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> ==> ====
>>>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change
>>>>> order of things in
>>>>> ==> ====> the package or not?
>>>>> ==> ====> This is not to start philosofical falames or something,
>>>>> but to understand
>>>>> ==> ====> better how things work. And, if they do: how much
>>>>> arbitrarily?
>>>>> ==> ====
>>>>> ==> ====Only the NTB header has a fixed location. The rest can be
>>>>> anywhere and
>>>>> ==> ====in any order. Quoting from section 3 Data Transport:
>>>>> ==> ====
>>>>> ==> ==== "Within any given NTB, the NTH always must be first; but
>>>>> the other
>>>>> ==> ==== items may occur in arbitrary order."
>>>>> ==> ====
>>>>> ==> ====
>>>>> ==> ====Bjørn
>>>>> ==> ====
>>>>> ==> ==This email and any files transmitted with it are confidential
>>>>> material. They are intended solely for the use of the designated
>>>>> individual or entity to whom they are addressed. If the reader of
>>>>> this message is not the intended recipient, you are hereby notified
>>>>> that any dissemination, use, distribution or copying of this
>>>>> communication is strictly prohibited and may be unlawful.
>>>>> ==> ==
>>>>> ==> ==If you have received this email in error please immediately
>>>>> notify the sender and delete or destroy any copy of this message
>>>>> ==> ==
>>>>> ==This email and any files transmitted with it are confidential
>>>>> material. They are intended solely for the use of the designated
>>>>> individual or entity to whom they are addressed. If the reader of
>>>>> this message is not the intended recipient, you are hereby notified
>>>>> that any dissemination, use, distribution or copying of this
>>>>> communication is strictly prohibited and may be unlawful.
>>>>> ==
>>>>> ==If you have received this email in error please immediately notify
>>>>> the sender and delete or destroy any copy of this message
>>>>> ==
>>>> This email and any files transmitted with it are confidential
>>>> material. They are intended solely for the use of the designated
>>>> individual or entity to whom they are addressed. If the reader of
>>>> this message is not the intended recipient, you are hereby notified
>>>> that any dissemination, use, distribution or copying of this
>>>> communication is strictly prohibited and may be unlawful.
>>>>
>>>> If you have received this email in error please immediately notify
>>>> the sender and delete or destroy any copy of this message
>>>>
>> This email and any files transmitted with it are confidential
>> material. They are intended solely for the use of the designated
>> individual or entity to whom they are addressed. If the reader of
>> this message is not the intended recipient, you are hereby notified
>> that any dissemination, use, distribution or copying of this
>> communication is strictly prohibited and may be unlawful.
>>
>> If you have received this email in error please immediately notify
>> the sender and delete or destroy any copy of this message
>>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [patch iproute2 6/6] bridge/link: add learning_sync policy flag
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Add 'learned_sync' flag to turn on/off syncing of learned FDB entries from
offload device to bridge's FDB. Flag would be set/cleared in on SELF using
hwmode qualifier 'swdev'. E.g.:
$ sudo bridge link set dev swp1 hwmode swdev learning_sync on
$ bridge -d link show dev swp1
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
hairpin off guard off root_block off fastleave off learning off flood off
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0
learning on learning_sync on hwmode swdev
Adds new IFLA_BRPORT_LEARNING_SYNC attribute for IFLA_PROTINFO on the SELF
brport.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/link.c | 11 +++++++++++
include/linux/if_link.h | 1 +
man/man8/bridge.8 | 6 ++++++
3 files changed, 18 insertions(+)
diff --git a/bridge/link.c b/bridge/link.c
index efe0b8c..0f8649f 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -188,6 +188,9 @@ int print_linkinfo(const struct sockaddr_nl *who,
if (prtb[IFLA_BRPORT_LEARNING])
print_onoff(fp, "learning",
rta_getattr_u8(prtb[IFLA_BRPORT_LEARNING]));
+ if (prtb[IFLA_BRPORT_LEARNING_SYNC])
+ print_onoff(fp, "learning_sync",
+ rta_getattr_u8(prtb[IFLA_BRPORT_LEARNING_SYNC]));
if (prtb[IFLA_BRPORT_UNICAST_FLOOD])
print_onoff(fp, "flood",
rta_getattr_u8(prtb[IFLA_BRPORT_UNICAST_FLOOD]));
@@ -221,6 +224,7 @@ static void usage(void)
fprintf(stderr, " [ fastleave {on | off} ]\n");
fprintf(stderr, " [ root_block {on | off} ]\n");
fprintf(stderr, " [ learning {on | off} ]\n");
+ fprintf(stderr, " [ learning_sync {on | off} ]\n");
fprintf(stderr, " [ flood {on | off} ]\n");
fprintf(stderr, " [ hwmode {vepa | veb} ]\n");
fprintf(stderr, " bridge link show [dev DEV]\n");
@@ -252,6 +256,7 @@ static int brlink_modify(int argc, char **argv)
} req;
char *d = NULL;
__s8 learning = -1;
+ __s8 learning_sync = -1;
__s8 flood = -1;
__s8 hairpin = -1;
__s8 bpdu_guard = -1;
@@ -295,6 +300,10 @@ static int brlink_modify(int argc, char **argv)
NEXT_ARG();
if (!on_off("learning", &learning, *argv))
exit(-1);
+ } else if (strcmp(*argv, "learning_sync") == 0) {
+ NEXT_ARG();
+ if (!on_off("learning_sync", &learning_sync, *argv))
+ exit(-1);
} else if (strcmp(*argv, "flood") == 0) {
NEXT_ARG();
if (!on_off("flood", &flood, *argv))
@@ -359,6 +368,8 @@ static int brlink_modify(int argc, char **argv)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_UNICAST_FLOOD, flood);
if (learning >= 0)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_LEARNING, learning);
+ if (learning_sync >= 0)
+ addattr8(&req.n, sizeof(req), IFLA_BRPORT_LEARNING_SYNC, learning_sync);
if (cost > 0)
addattr32(&req.n, sizeof(req), IFLA_BRPORT_COST, cost);
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 06efa2d..9947f1b 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -243,6 +243,7 @@ enum {
IFLA_BRPORT_LEARNING, /* mac learning */
IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
IFLA_BRPORT_PROXYARP, /* proxy ARP */
+ IFLA_BRPORT_LEARNING_SYNC, /* mac learning sync from device */
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index d3d64d1..83c049a 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -37,6 +37,7 @@ bridge \- show / manipulate bridge addresses and devices
.BR fastleave " { " on " | " off " } ] [ "
.BR root_block " { " on " | " off " } ] [ "
.BR learning " { " on " | " off " } ] [ "
+.BR learning_sync " { " on " | " off " } ] [ "
.BR flood " { " on " | " off " } ] [ "
.BR hwmode " { " vepa " | " veb " | " swdev " } ] "
@@ -242,6 +243,11 @@ not. If learning if off, the bridge will end up flooding any traffic for which
it has no FDB entry. By default this flag is on.
.TP
+.BR "learning_sync on " or " learning_sync off "
+Controls whether a given port will sync MAC addresses learned on device port
+to bridge FDB. This flags applies to device ports in "swdev" hwmode.
+
+.TP
.BR "flooding on " or " flooding off "
Controls whether a given port will flood unicast traffic for which there is no FDB entry. By default this flag is on.
--
1.9.3
^ permalink raw reply related
* [patch iproute2 4/6] bridge/link: add new offload hwmode swdev
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
To support full-featured switch devices offloading bridge funtionality,
add new hwmode 'swdev'. Like 'vepa' and 'veb', 'swdev' indicated bridge
port functionality is being offloaded to hardware.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/link.c | 6 ++++--
include/linux/if_bridge.h | 1 +
man/man8/bridge.8 | 13 ++++++++-----
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index 90d9e7f..efe0b8c 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -65,7 +65,7 @@ static const char *oper_states[] = {
"TESTING", "DORMANT", "UP"
};
-static const char *hw_mode[] = {"VEB", "VEPA"};
+static const char *hw_mode[] = {"VEB", "VEPA", "swdev"};
static void print_operstate(FILE *f, __u8 state)
{
@@ -315,10 +315,12 @@ static int brlink_modify(int argc, char **argv)
mode = BRIDGE_MODE_VEPA;
else if (strcmp(*argv, "veb") == 0)
mode = BRIDGE_MODE_VEB;
+ else if (strcmp(*argv, "swdev") == 0)
+ mode = BRIDGE_MODE_SWDEV;
else {
fprintf(stderr,
"Mode argument must be \"vepa\" or "
- "\"veb\".\n");
+ "\"veb\" or \"swdev\".\n");
exit(-1);
}
} else {
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index ed6868e..6b4eb66 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -105,6 +105,7 @@ struct __fdb_entry {
#define BRIDGE_MODE_VEB 0 /* Default loopback mode */
#define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
+#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
/* Bridge management nested attributes
* [IFLA_AF_SPEC] = {
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index af31d41..d3d64d1 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -38,7 +38,7 @@ bridge \- show / manipulate bridge addresses and devices
.BR root_block " { " on " | " off " } ] [ "
.BR learning " { " on " | " off " } ] [ "
.BR flood " { " on " | " off " } ] [ "
-.BR hwmode " { " vepa " | " veb " } ] "
+.BR hwmode " { " vepa " | " veb " | " swdev " } ] "
.ti -8
.BR "bridge link" " [ " show " ] [ "
@@ -247,15 +247,18 @@ Controls whether a given port will flood unicast traffic for which there is no F
.TP
.BI hwmode
-Some network interface cards support HW bridge functionality and they may be
+Some port devices support HW bridge functionality and they may be
configured in different modes. Currently support modes are:
.B vepa
-- Data sent between HW ports is sent on the wire to the external
-switch.
+- NIC interface supports VEPA: data sent between HW ports is sent on
+the wire to the external switch.
.B veb
-- bridging happens in hardware.
+- NIC interface supports VEB: bridging happens in hardware.
+
+.B swdev
+- Full Ethernet switch offload device: bridging happens in hardware.
.SS bridge link show - list bridge port configuration.
--
1.9.3
^ permalink raw reply related
* [patch iproute2 5/6] link: add missing IFLA_BRPORT_PROXYARP
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/if_link.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index a6e2594..06efa2d 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -242,6 +242,7 @@ enum {
IFLA_BRPORT_FAST_LEAVE, /* multicast fast leave */
IFLA_BRPORT_LEARNING, /* mac learning */
IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
+ IFLA_BRPORT_PROXYARP, /* proxy ARP */
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
--
1.9.3
^ permalink raw reply related
* [patch iproute2 3/6] bridge/fdb: add flag/indication for FDB entry synced from offload device
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Add NTF_EXT_LEARNED flag to neigh flags to indicate FDB entry learned by
device has been learned externally to bridge FDB. For these entries,
add "external" annotation in bridge fdb show output:
00:02:00:00:03:00 dev swp2 used 2/2 master br0 external
00:02:00:00:03:00 dev swp2 self permanent
In the example above, 00:02:00:00:03:00 is shown twice on dev swp2. The
first entry if from the bridge (master) and is marked as "external" by
the offload device. The second entry is from the brport offload device (self),
and was learned by the device.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/fdb.c | 2 ++
include/linux/neighbour.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index d678342..c01a502 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -154,6 +154,8 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
fprintf(fp, "master ");
if (r->ndm_flags & NTF_ROUTER)
fprintf(fp, "router ");
+ if (r->ndm_flags & NTF_EXT_LEARNED)
+ fprintf(fp, "external ");
fprintf(fp, "%s\n", state_n2a(r->ndm_state));
return 0;
diff --git a/include/linux/neighbour.h b/include/linux/neighbour.h
index 4a1d7e9..3a9b0df 100644
--- a/include/linux/neighbour.h
+++ b/include/linux/neighbour.h
@@ -40,6 +40,7 @@ enum {
#define NTF_SELF 0x02
#define NTF_MASTER 0x04
+#define NTF_EXT_LEARNED 0x10
/*
* Neighbor Cache Entry States.
--
1.9.3
^ permalink raw reply related
* [patch iproute2 2/6] bridge/fdb: fix statistics output spacing
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/fdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index a55fac1..d678342 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -142,7 +142,7 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
struct nda_cacheinfo *ci = RTA_DATA(tb[NDA_CACHEINFO]);
int hz = get_user_hz();
- fprintf(fp, " used %d/%d", ci->ndm_used/hz,
+ fprintf(fp, "used %d/%d ", ci->ndm_used/hz,
ci->ndm_updated/hz);
}
if (r->ndm_flags & NTF_SELF)
--
1.9.3
^ permalink raw reply related
* [patch iproute2 1/6] iproute2: ipa: show switch id
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/if_link.h | 1 +
ip/ipaddress.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 4732063..a6e2594 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -145,6 +145,7 @@ enum {
IFLA_CARRIER,
IFLA_PHYS_PORT_ID,
IFLA_CARRIER_CHANGES,
+ IFLA_PHYS_SWITCH_ID,
__IFLA_MAX
};
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 4d99324..bd36a07 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
b1, sizeof(b1)));
}
+ if (tb[IFLA_PHYS_SWITCH_ID]) {
+ SPRINT_BUF(b1);
+ fprintf(fp, "switchid %s ",
+ hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
+ RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
+ b1, sizeof(b1)));
+ }
+
if (tb[IFLA_OPERSTATE])
print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
--
1.9.3
^ permalink raw reply related
* [patch iproute2 0/6] iproute2: add changes for switchdev
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
Jiri Pirko (1):
iproute2: ipa: show switch id
Scott Feldman (5):
bridge/fdb: fix statistics output spacing
bridge/fdb: add flag/indication for FDB entry synced from offload
device
bridge/link: add new offload hwmode swdev
link: add missing IFLA_BRPORT_PROXYARP
bridge/link: add learning_sync policy flag
bridge/fdb.c | 4 +++-
bridge/link.c | 17 +++++++++++++++--
include/linux/if_bridge.h | 1 +
include/linux/if_link.h | 3 +++
include/linux/neighbour.h | 1 +
ip/ipaddress.c | 8 ++++++++
man/man8/bridge.8 | 19 ++++++++++++++-----
7 files changed, 45 insertions(+), 8 deletions(-)
--
1.9.3
^ permalink raw reply
* Re: ipip6 - integer underrun when handlince icmpv4 unreachable messages
From: Steffen Klassert @ 2014-12-04 8:56 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: netdev, roque, kuznet, r.venning, nate
In-Reply-To: <546A6E04.30603@web.de>
On Mon, Nov 17, 2014 at 10:52:04PM +0100, Alexander Wetzel wrote:
> Hello netdev,
>
> the current code to translate icmpv4 "destination unreachable" packets
> to icmpv6 is later generating an integer underrun when calling
> icmpv6_send, by later calling skb_network_header_len and subtracting a
> bigger number from a lower one.
I'd guess the call to skb_network_header_len() in _decode_session6()
is the problematic one, right?
>
> The issue is not visible for vanilla kernels and works correctly from
> a user perspective, but a kernel with the PAX patches and enabled
> "size overflow protection" will panic immediately when it's getting an
> icmpv4 destination unreachable packet back for an encapsulated ipv6
> packet. (Remote tunnel endpoint not reachable.)
>
> I think I've tracked the issue down and can show you the problem with
> the code... as I understand it as non-programmer greping the sources
> and googeling functions. I was even able to find a fix which passes
> the functionality test, but I'm unqualified to rate the correctness of
> it and so are reaching out to you for that.
>
> What happens (output of printk's) with transport_header and
> network_header around "skb_reset_network_header" is described below
> the function.
>
> Near the end of the mail there are two links to the gentoo bug tracker
> and pax forum, suggesting to put this forward to the lkml/netdev for
> review, also including more details on the panics.
>
> So here the function "ipip6_err_gen_icmpv6_unreach" from
> net/ipv6/sit.c with some remarks and one new line which seems to fix
> the problem:
>
> ************************************************************************
> static int ipip6_err_gen_icmpv6_unreach(struct sk_buff *skb)
> {
> int ihl = ((const struct iphdr *)skb->data)->ihl*4;
> struct rt6_info *rt;
> struct sk_buff *skb2;
>
> if (!pskb_may_pull(skb, ihl + sizeof(struct ipv6hdr) + 8))
> return 1;
>
> // we clone the ipv4 skb in skb2 to prepare the icmpv6 packet
> skb2 = skb_clone(skb, GFP_ATOMIC);
>
> if (!skb2)
> return 1;
>
> // we clean up the cloned skb2
> skb_dst_drop(skb2);
> skb_pull(skb2, ihl);
> // The network header is reset
> skb_reset_network_header(skb2);
>
> //THE PROPOSED FIX: The following line is NOT in the current code
> skb_reset_transport_header(skb2);
This will make your panic with PAX go away, but the offset to
the transport header is still wrong. Also, it is not just the
sit tunnel that has this problem. All ipv6 tunnels are affected.
I think the easiest is to fix it in _decode_session6().
Could you please try the patch below?
Subject: [PATCH] xfrm6: Fix transport header offset in _decode_session6.
skb->transport_header might not be valid when we do a reverse
decode because the ipv6 tunnel error handlers don't update it
to the inner transport header. This leads to a wrong offset
calculation and to wrong layer 4 informations. We fix this
by using the size of the ipv6 header as the first offset.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/xfrm6_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index ac49f84..576fc42 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -130,8 +130,8 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
{
struct flowi6 *fl6 = &fl->u.ip6;
int onlyproto = 0;
- u16 offset = skb_network_header_len(skb);
const struct ipv6hdr *hdr = ipv6_hdr(skb);
+ u16 offset = sizeof(*hdr);
struct ipv6_opt_hdr *exthdr;
const unsigned char *nh = skb_network_header(skb);
u8 nexthdr = nh[IP6CB(skb)->nhoff];
--
1.9.1
^ permalink raw reply related
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 8:56 UTC (permalink / raw)
To: Kevin Zhu
Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548020DD.3030705@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 8746 bytes --]
Hi Kevin.
Thank you for your hints and work.
Only a note - why disabling ARP? I think it could be a good iea... or does the hw_cdc_driver do that?
thank you again,
Enrico
On Thu, 4 Dec 2014, Kevin Zhu wrote:
> Date: Thu, 4 Dec 2014 09:52:49
> From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> To: Enrico Mioso <mrkiko.rs@gmail.com>
> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein <Eli.Britstein@audiocodes.com>,
> Alex Strizhevsky <alexxst@gmail.com>,
> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> "youtux@gmail.com" <youtux@gmail.com>,
> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Guys,
>
> After rearranging the padding, putting NCM0 right after NTH, and disable
> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
> begins to work, though there's still problem with DHCP. It's able to
> ping, though my Ubuntu network manage does not notice this network
> interface. So no DNS.
>
> I have to specify the network interface and IP in the ping command.
>
> The DHCP packet's size becomes a large one after the TX function, which
> is 16384, the maximum. And the dongle does not reply it in time. For
> now, I just simple rearrange the code to meet Huawei's alignment
> requirement. I think other devices may be different, regarding the
> 'offset' definition. We may need to handle it. And also need to double
> check if the code has bugs.
>
> Regards,
> Kevin
>
> On 12/04/2014 02:31 PM, Enrico Mioso wrote:
>> Hello guys!
>> I am writing this message to hear if there is any progress,
>> Enrico
>>
>>
>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>
>>> Date: Wed, 3 Dec 2014 07:05:37
>>> From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>> To: Enrico Mioso <mrkiko.rs@gmail.com>
>>> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>>> <Eli.Britstein@audiocodes.com>,
>>> Alex Strizhevsky <alexxst@gmail.com>,
>>> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> "youtux@gmail.com" <youtux@gmail.com>,
>>> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> Subject: Re: Is this 32-bit NCM?
>>>
>>> OK. I will. Thank you for everything!
>>>
>>> Regards,
>>> Kevin
>>>
>>> On 12/03/2014 02:00 PM, Enrico Mioso wrote:
>>>> Yes - I think this would be ok. You might try this with the 16-bit
>>>> river first,
>>>> and then with the 32-bit one to see how things work.
>>>> I hope for the best.
>>>> Let us all know,
>>>> Enrico
>>>>
>>>>
>>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>>
>>>> ==Date: Wed, 3 Dec 2014 06:38:27
>>>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
>>>> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>>>> <Eli.Britstein@audiocodes.com>,
>>>> == Alex Strizhevsky <alexxst@gmail.com>,
>>>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>> == "youtux@gmail.com" <youtux@gmail.com>,
>>>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>>> ==Subject: Re: Is this 32-bit NCM?
>>>> ==
>>>> ==My dongle also works with the huawei driver. I think only the 32bit
>>>> ==format and NDP location matter. We may modify the TX function to
>>>> put NTH
>>>> ==and NDP at the beginning of a NTB and see if it will work with the
>>>> ==driver cdc_ncm.
>>>> ==
>>>> ==Regards,
>>>> ==Kevin
>>>> ==
>>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote:
>>>> ==> ... And what do you think about the source code of their ndis
>>>> driver?
>>>> ==> We at least know now the device work with it, so we have
>>>> something to mimic :D
>>>> ==> thank you for your work and patience Kevin.
>>>> ==>
>>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>>> ==>
>>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25
>>>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>>> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork
>>>> <bjorn@mork.no>
>>>> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>,
>>>> ==> == Alex Strizhevsky <alexxst@gmail.com>,
>>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
>>>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>> ==> ==
>>>> ==> ==I do not understand why the wSequence matters. By the way, I
>>>> think I see some NDPs are right after NTH headers in the windows
>>>> capture.
>>>> ==> ==
>>>> ==> ==________________________________________
>>>> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com>
>>>> ==> ==Sent: Tuesday, December 2, 2014 21:53
>>>> ==> ==To: Bjørn Mork
>>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun
>>>> Tan; youtux@gmail.com; linux-usb@vger.kernel.org;
>>>> netdev@vger.kernel.org
>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>> ==> ==
>>>> ==> ==Thank you very much Bjorn.
>>>> ==> ==
>>>> ==> ==
>>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote:
>>>> ==> ==
>>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03
>>>> ==> ====From: Bjørn Mork <bjorn@mork.no>
>>>> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com>
>>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
>>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>,
>>>> ==> ==== Alex Strizhevsky <alexxst@gmail.com>,
>>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>> ==> ==== "youtux@gmail.com" <youtux@gmail.com>,
>>>> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>>> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>>> ==> ====Subject: Re: Is this 32-bit NCM?
>>>> ==> ====
>>>> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes:
>>>> ==> ====
>>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change
>>>> order of things in
>>>> ==> ====> the package or not?
>>>> ==> ====> This is not to start philosofical falames or something,
>>>> but to understand
>>>> ==> ====> better how things work. And, if they do: how much
>>>> arbitrarily?
>>>> ==> ====
>>>> ==> ====Only the NTB header has a fixed location. The rest can be
>>>> anywhere and
>>>> ==> ====in any order. Quoting from section 3 Data Transport:
>>>> ==> ====
>>>> ==> ==== "Within any given NTB, the NTH always must be first; but
>>>> the other
>>>> ==> ==== items may occur in arbitrary order."
>>>> ==> ====
>>>> ==> ====
>>>> ==> ====Bjørn
>>>> ==> ====
>>>> ==> ==This email and any files transmitted with it are confidential
>>>> material. They are intended solely for the use of the designated
>>>> individual or entity to whom they are addressed. If the reader of
>>>> this message is not the intended recipient, you are hereby notified
>>>> that any dissemination, use, distribution or copying of this
>>>> communication is strictly prohibited and may be unlawful.
>>>> ==> ==
>>>> ==> ==If you have received this email in error please immediately
>>>> notify the sender and delete or destroy any copy of this message
>>>> ==> ==
>>>> ==This email and any files transmitted with it are confidential
>>>> material. They are intended solely for the use of the designated
>>>> individual or entity to whom they are addressed. If the reader of
>>>> this message is not the intended recipient, you are hereby notified
>>>> that any dissemination, use, distribution or copying of this
>>>> communication is strictly prohibited and may be unlawful.
>>>> ==
>>>> ==If you have received this email in error please immediately notify
>>>> the sender and delete or destroy any copy of this message
>>>> ==
>>> This email and any files transmitted with it are confidential
>>> material. They are intended solely for the use of the designated
>>> individual or entity to whom they are addressed. If the reader of
>>> this message is not the intended recipient, you are hereby notified
>>> that any dissemination, use, distribution or copying of this
>>> communication is strictly prohibited and may be unlawful.
>>>
>>> If you have received this email in error please immediately notify
>>> the sender and delete or destroy any copy of this message
>>>
> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>
> If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
>
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 8:52 UTC (permalink / raw)
To: Enrico Mioso
Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412040730480.1320@gmail.com>
Guys,
After rearranging the padding, putting NCM0 right after NTH, and disable
ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
begins to work, though there's still problem with DHCP. It's able to
ping, though my Ubuntu network manage does not notice this network
interface. So no DNS.
I have to specify the network interface and IP in the ping command.
The DHCP packet's size becomes a large one after the TX function, which
is 16384, the maximum. And the dongle does not reply it in time. For
now, I just simple rearrange the code to meet Huawei's alignment
requirement. I think other devices may be different, regarding the
'offset' definition. We may need to handle it. And also need to double
check if the code has bugs.
Regards,
Kevin
On 12/04/2014 02:31 PM, Enrico Mioso wrote:
> Hello guys!
> I am writing this message to hear if there is any progress,
> Enrico
>
>
> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>
>> Date: Wed, 3 Dec 2014 07:05:37
>> From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>> To: Enrico Mioso <mrkiko.rs@gmail.com>
>> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>> <Eli.Britstein@audiocodes.com>,
>> Alex Strizhevsky <alexxst@gmail.com>,
>> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>> "youtux@gmail.com" <youtux@gmail.com>,
>> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>> Subject: Re: Is this 32-bit NCM?
>>
>> OK. I will. Thank you for everything!
>>
>> Regards,
>> Kevin
>>
>> On 12/03/2014 02:00 PM, Enrico Mioso wrote:
>>> Yes - I think this would be ok. You might try this with the 16-bit
>>> river first,
>>> and then with the 32-bit one to see how things work.
>>> I hope for the best.
>>> Let us all know,
>>> Enrico
>>>
>>>
>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>
>>> ==Date: Wed, 3 Dec 2014 06:38:27
>>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
>>> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>>> <Eli.Britstein@audiocodes.com>,
>>> == Alex Strizhevsky <alexxst@gmail.com>,
>>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> == "youtux@gmail.com" <youtux@gmail.com>,
>>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> ==Subject: Re: Is this 32-bit NCM?
>>> ==
>>> ==My dongle also works with the huawei driver. I think only the 32bit
>>> ==format and NDP location matter. We may modify the TX function to
>>> put NTH
>>> ==and NDP at the beginning of a NTB and see if it will work with the
>>> ==driver cdc_ncm.
>>> ==
>>> ==Regards,
>>> ==Kevin
>>> ==
>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote:
>>> ==> ... And what do you think about the source code of their ndis
>>> driver?
>>> ==> We at least know now the device work with it, so we have
>>> something to mimic :D
>>> ==> thank you for your work and patience Kevin.
>>> ==>
>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>> ==>
>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25
>>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork
>>> <bjorn@mork.no>
>>> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>,
>>> ==> == Alex Strizhevsky <alexxst@gmail.com>,
>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
>>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>> ==> ==
>>> ==> ==I do not understand why the wSequence matters. By the way, I
>>> think I see some NDPs are right after NTH headers in the windows
>>> capture.
>>> ==> ==
>>> ==> ==________________________________________
>>> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com>
>>> ==> ==Sent: Tuesday, December 2, 2014 21:53
>>> ==> ==To: Bjørn Mork
>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun
>>> Tan; youtux@gmail.com; linux-usb@vger.kernel.org;
>>> netdev@vger.kernel.org
>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>> ==> ==
>>> ==> ==Thank you very much Bjorn.
>>> ==> ==
>>> ==> ==
>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote:
>>> ==> ==
>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03
>>> ==> ====From: Bjørn Mork <bjorn@mork.no>
>>> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com>
>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>,
>>> ==> ==== Alex Strizhevsky <alexxst@gmail.com>,
>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> ==> ==== "youtux@gmail.com" <youtux@gmail.com>,
>>> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> ==> ====Subject: Re: Is this 32-bit NCM?
>>> ==> ====
>>> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes:
>>> ==> ====
>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change
>>> order of things in
>>> ==> ====> the package or not?
>>> ==> ====> This is not to start philosofical falames or something,
>>> but to understand
>>> ==> ====> better how things work. And, if they do: how much
>>> arbitrarily?
>>> ==> ====
>>> ==> ====Only the NTB header has a fixed location. The rest can be
>>> anywhere and
>>> ==> ====in any order. Quoting from section 3 Data Transport:
>>> ==> ====
>>> ==> ==== "Within any given NTB, the NTH always must be first; but
>>> the other
>>> ==> ==== items may occur in arbitrary order."
>>> ==> ====
>>> ==> ====
>>> ==> ====Bjørn
>>> ==> ====
>>> ==> ==This email and any files transmitted with it are confidential
>>> material. They are intended solely for the use of the designated
>>> individual or entity to whom they are addressed. If the reader of
>>> this message is not the intended recipient, you are hereby notified
>>> that any dissemination, use, distribution or copying of this
>>> communication is strictly prohibited and may be unlawful.
>>> ==> ==
>>> ==> ==If you have received this email in error please immediately
>>> notify the sender and delete or destroy any copy of this message
>>> ==> ==
>>> ==This email and any files transmitted with it are confidential
>>> material. They are intended solely for the use of the designated
>>> individual or entity to whom they are addressed. If the reader of
>>> this message is not the intended recipient, you are hereby notified
>>> that any dissemination, use, distribution or copying of this
>>> communication is strictly prohibited and may be unlawful.
>>> ==
>>> ==If you have received this email in error please immediately notify
>>> the sender and delete or destroy any copy of this message
>>> ==
>> This email and any files transmitted with it are confidential
>> material. They are intended solely for the use of the designated
>> individual or entity to whom they are addressed. If the reader of
>> this message is not the intended recipient, you are hereby notified
>> that any dissemination, use, distribution or copying of this
>> communication is strictly prohibited and may be unlawful.
>>
>> If you have received this email in error please immediately notify
>> the sender and delete or destroy any copy of this message
>>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ 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