* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-27 11:15 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, abrestic@chromium.org
In-Reply-To: <54C612A5.2000208@redhat.com>
Hi Daniel,
On 26/01/15 10:10, Daniel Borkmann wrote:
>> Hello Daniel. Thank you for your feedback.
>> Packet sockets could also be used for the driver interface to
>> user space, however I think that both approaches would require the same
>> amount of maintenance. We need to maintain a protocol consisting of
>> a set of messages or commands that user space can use to communicate
>> with the driver in order to configure the H/W and retrieve results.
>> We could use packet sockets to send those messages too, but I thought
>> netlink already provides a message exchange framework that we could
>> make use of.
>
> When using packet sockets and your driver as a backend feeding them,
> users can see that there's an extra capturing/monitoring netdev present,
> all libpcap-based tools such as tcpdump et al would work out of the box
> w/o adapting any code, and as an admin you can also see what users/tools
> are making of use of the device through packet sockets. I couldn't parse
> the exact motivation from the commit message of why avoiding all this is
> better?
>
> Thanks,
> Daniel
>
>
Just wanted to clarify some implementation details for your approach.
- The driver would need to create and register two net_device instances.
One for sniffing Ethernet TX packets and one for RX.
- Would the control interface for the sniffer in that case need to be
through private socket ioctls (ie SIOCDEVPRIVATE + x ioctl ids)?
- For each ethernet packet that matches the command string the sniffer
returns some data bytes and optionally a timestamp (depending on the
command string). Would a new protocol need to be added in
<linux/if_ether.h> in order to deliver that data to user space through
a packet socket?
Thanks,
Stathis
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Thomas Graf @ 2015-01-27 11:16 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127102420.GA3777@gondor.apana.org.au>
On 01/27/15 at 09:24pm, Herbert Xu wrote:
> The point is that for netfilter as it stands it makes no sense
> to go lockless because its modus operandi is to hold a single
> lock over everything, including walking/dumping.
No objection. I have a patch prepared which allows the user to
provide ht->mutex himself so nfset can provide its own existing
mutex to rhashtable and lock out the resizes from inserts,
removals and dump iterations automatically That would restore the
old behaviour of the nfset API without major surgery.
I was just waiting on your walker as you requested a hold off.
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 11:23 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127111604.GF22262@casper.infradead.org>
On Tue, Jan 27, 2015 at 11:16:04AM +0000, Thomas Graf wrote:
>
> No objection. I have a patch prepared which allows the user to
> provide ht->mutex himself so nfset can provide its own existing
> mutex to rhashtable and lock out the resizes from inserts,
> removals and dump iterations automatically That would restore the
> old behaviour of the nfset API without major surgery.
If you take the mutex you might as well just make it synchronous.
There is zero difference.
Maybe you misunderstood my email. I'm not making it synchronous
for everybody, just those that always take a lock on inserts/removals
and therefore don't need per-bucket locks.
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 1/2] caif: remove wrong dev_net_set() call
From: Nicolas Dichtel @ 2015-01-27 11:34 UTC (permalink / raw)
To: netdev
Cc: davem, dmitry.tarnyagin, arvid.brodin, alex.aring, linux-wpan,
Sjur Brændeland
In-Reply-To: <1422307694-10079-2-git-send-email-nicolas.dichtel@6wind.com>
Le 26/01/2015 22:28, Nicolas Dichtel a écrit :
> src_net points to the netns where the netlink message has been received. This
> netns may be different from the netns where the interface is created (because
> the user may add IFLA_NET_NS_[PID|FD]). In this case, src_net is the link netns.
>
> It seems wrong to override the netns in the newlink() handler because if it
> was not already src_net, it means that the user explicitly asks to create the
> netdevice in another netns.
>
> CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
> CC: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
I got a "Delivery Status Notification (Failure)" for Dmitry Tarnyagin (I took
the email address from the MAINTAINERS file):
Delivery to the following recipient failed permanently:
dmitry.tarnyagin@lockless.no
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for
the recipient domain lockless.no by mail.lockless.no. [46.29.221.38].
The error that the other server returned was:
550 5.1.1 <dmitry.tarnyagin@lockless.no>: Recipient address rejected: User
unknown in virtual mailbox table
Any suggestions?
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Thomas Graf @ 2015-01-27 11:40 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127112304.GA4548@gondor.apana.org.au>
On 01/27/15 at 10:23pm, Herbert Xu wrote:
> On Tue, Jan 27, 2015 at 11:16:04AM +0000, Thomas Graf wrote:
> >
> > No objection. I have a patch prepared which allows the user to
> > provide ht->mutex himself so nfset can provide its own existing
> > mutex to rhashtable and lock out the resizes from inserts,
> > removals and dump iterations automatically That would restore the
> > old behaviour of the nfset API without major surgery.
>
> If you take the mutex you might as well just make it synchronous.
> There is zero difference.
>
> Maybe you misunderstood my email. I'm not making it synchronous
> for everybody, just those that always take a lock on inserts/removals
> and therefore don't need per-bucket locks.
Understood. No objection, happy to review patches. I initially did
keep sync/async separate and it lead to considerable code duplication
and complexity. I figured that if a user needs sync insert they could
provide their own locking. I missed to allow controlling the async
resize though. Again, feel free to give a shot, no objections.
This is unrelated to resize run control though, the reason is that
I'm converting tcp_hashinfo et al and they require a hybrid approach.
The tables may be too big to construct a parallel data structure, we
don't want to hold off inserts or deletes while the expensive dump
is underway. Even though we can't build a shadow structure while
locking everybody else out, we still want to provide a way to somehow
achieve consistent information. I think that NLM_F_INTR with fallback
to restarting the dump is a good option and very easy to implement. In
that case, we want to lock out resize from dumping iterations but
still allow parallel insert/delete.
^ permalink raw reply
* RE: [PATCHv3 ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: David Laight @ 2015-01-27 11:54 UTC (permalink / raw)
To: 'Florian Westphal'
Cc: 'Fan Du', steffen.klassert@secunet.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
netdev@vger.kernel.org, fengyuleidian0615@gmail.com
In-Reply-To: <20150127110413.GF1373@breakpoint.cc>
From: Florian Westphal
> David Laight <David.Laight@ACULAB.COM> wrote:
> > From: Fan Du
> > > structure like xfrm_usersa_info or xfrm_userpolicy_info
> > > has different sizeof when compiled as 32bits and 64bits
> > > due to not appending pack attribute in their definition.
> >
> > Don't 'pack' the structure, just ensure that all the fields
> > are fixed sized and on their natural boundary.
>
> How do you propose to do this without breaking ABI?
You may already have an ABI fubar.
Adding __packed won't make it go away.
IIRC your modified structure did have all its 64bit items
aligned on 8 byte boundaries - so the __packed wouldn't affect
the structure layout.
The problem is that you can't add that field when the ABI
only requires 4 byte alignment for 64bit items.
If you need to access a structure from (eg) an i386 application
within an amd64 kernel then you can add __attribute__((aligned(4)))
to any 64bit member to force that member to have only 4 byte aligment.
On 64bit systems that can't do misaligned transfers (eg sparc64)
that will result in two 32bit accesses for that member.
(You'll need to do it to all 64bit members if the structure
size needs to be an odd multiple of 4.)
> > Possibly add a compile-time check that the structure is
> > of the expected size.
>
> Uh, what?
eg something based on:
typedef foo_check char[sizeof foo == 32 ? 1 : -1];
There will be a standard define for this somewhere
(and for the align attribute).
David
^ permalink raw reply
* Re: ipv6: oops in datagram.c line 260
From: Steffen Klassert @ 2015-01-27 11:58 UTC (permalink / raw)
To: Chris Ruehl; +Cc: Hannes Frederic Sowa, netdev, davem
In-Reply-To: <54C71AFB.40300@gtsys.com.hk>
On Tue, Jan 27, 2015 at 12:58:35PM +0800, Chris Ruehl wrote:
>
> Steffen,
>
> your patch can't apply to the vanilla v3.14.29 can you cross check please.
Sorry, this patch was based on the net tree.
> I'm sorry but we running a productive system and I can't make to much
> noise here!
> Your patch is partly in the 3.14.29 and
> skb->protocol = htons(ETH_P_IP)
> from the xfrm4/6_output_finish() no removed. I do then
>
> --- linux-3.14.x/net/ipv4/xfrm4_output.c.orig 2015-01-27
> 12:50:01.830651344 +0800
> +++ linux-3.14.x/net/ipv4/xfrm4_output.c 2015-01-27 12:51:13.280386355
> +0800
> @@ -82,7 +82,6 @@
> IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
> #endif
>
> - skb->protocol = htons(ETH_P_IP);
> return xfrm_output(skb);
> }
>
> --- linux-3.14.x/net/ipv6/xfrm6_output.c.orig 2015-01-27
> 12:49:39.260735321 +0800
> +++ linux-3.14.x/net/ipv6/xfrm6_output.c 2015-01-27 12:50:47.280482636
> +0800
> @@ -132,7 +132,6 @@
> IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
> #endif
>
> - skb->protocol = htons(ETH_P_IPV6);
> return xfrm_output(skb);
> }
Yes, that should be ok. Here is the complete patch for v3.14.29:
Subject: [PATCH RFC v3.14.29] xfrm: Fix local error reporting crash with interfamily tunnels
We set the outer mode protocol too early. As a result, the
local error handler might dispatch to the wrong address family
and report the error to a wrong socket type. We fix this by
seting the outer protocol to the skb only after we accessed the
inner mode for the last time, right before we do the atcual
encapsulation where we switch finally to the outer mode.
The settings in xfrm{4,6}_output_finish() are removed.
Reported-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv4/xfrm4_output.c | 1 -
net/ipv6/xfrm6_output.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index baa0f63..0cb9606 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -82,7 +82,6 @@ int xfrm4_output_finish(struct sk_buff *skb)
IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
#endif
- skb->protocol = htons(ETH_P_IP);
return xfrm_output(skb);
}
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 6cd625e..98396cf 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -132,7 +132,6 @@ int xfrm6_output_finish(struct sk_buff *skb)
IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
#endif
- skb->protocol = htons(ETH_P_IPV6);
return xfrm_output(skb);
}
--
1.7.2.5
^ permalink raw reply related
* Fw: [Bug 92121] New: acpid cannot connect to netlink socket (bisected)
From: Stephen Hemminger @ 2015-01-27 12:00 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 26 Jan 2015 14:15:55 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 92121] New: acpid cannot connect to netlink socket (bisected)
https://bugzilla.kernel.org/show_bug.cgi?id=92121
Bug ID: 92121
Summary: acpid cannot connect to netlink socket (bisected)
Product: Networking
Version: 2.5
Kernel Version: 3.19.0-rc6
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: ziegler@uni-freiburg.de
Regression: Yes
acpid ouputs the following:
Cannot bind netlink socket: No such file or directory
acpid: cannot open generic netlink socket
acpid: starting up with netlink and the input layer
The commit responsible for that is
5ad6300524c0332ac67e912c20d6e5cf262ba58f
genetlink: disallow subscribing to unknown mcast group
Reverting lets the bug vanish
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Fw: [Bug 92081] New: skb->len=0 and getting "EOF on netlink" with "ip monitor all" (of iproute) when adding a vlan with "bridge vlan add"
From: Stephen Hemminger @ 2015-01-27 12:01 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Mon, 26 Jan 2015 10:15:12 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 92081] New: skb->len=0 and getting "EOF on netlink" with "ip monitor all" (of iproute) when adding a vlan with "bridge vlan add"
https://bugzilla.kernel.org/show_bug.cgi?id=92081
Bug ID: 92081
Summary: skb->len=0 and getting "EOF on netlink" with "ip
monitor all" (of iproute) when adding a vlan with
"bridge vlan add"
Product: Networking
Version: 2.5
Kernel Version: 3.17.6-300
Hardware: All
OS: Linux
Tree: Fedora
Status: NEW
Severity: high
Priority: P1
Component: Other
Assignee: shemminger@linux-foundation.org
Reporter: ramirose@gmail.com
Regression: No
On Fedora 21, with 3.17.6-300.fc21.x86_64, with iproute-3.16.0-3 (installed
from rpm),
ip -V:
ip utility, iproute2-ss140804
Running in one terminal:
ip monitor all
And then running in a second terminal this sequence:
ip link add br0 type bridge
bridge vlan add vid 10 dev br0 self
causes the "ip monitor all" to terminate, with "EOF on netlink".
This happens also on older distros of Fedora (Fedora 20 and downward) with
older kernels.
It seems that the reason is that an skb->len is 0 for the netlink notification
which is sent from
with rtnl_notify() which is invoked from rtnl_bridge_notify(), which in turn
is invoked from rtnl_bridge_setlink().
See:
http://lxr.free-electrons.com/source/net/core/rtnetlink.c#L2773
Rami Rosen
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH net-next 2/2] flow_dissector: add tipc support
From: Erik Hugne @ 2015-01-27 12:08 UTC (permalink / raw)
To: David Miller; +Cc: jon.maloy, eric.dumazet, netdev, tipc-discussion
In-Reply-To: <20150126.165749.913857343835846078.davem@davemloft.net>
On Mon, Jan 26, 2015 at 04:57:49PM -0800, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 22 Jan 2015 09:29:11 -0800
>
> > On Thu, 2015-01-22 at 17:10 +0100, erik.hugne@ericsson.com wrote:
> >> From: Erik Hugne <erik.hugne@ericsson.com>
> >>
> >> The flows are hashed on the sending node address, which allows us
> >> to spread out the TIPC link processing to RPS enabled cores. There
> >> is no point to include the destination address in the hash as that
> >> will always be the same for all inbound links. We have experimented
> >> with a 3-tuple hash over [srcnode, sport, dport], but this showed to
> >> give slightly lower performance because of increased lock contention
> >> when the same link was handled by multiple cores.
> >>
> >> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> >> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> >> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
> >> ---
> >> net/core/flow_dissector.c | 14 ++++++++++++++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
> >> index 4508493..beb83d1 100644
> >> --- a/net/core/flow_dissector.c
> >> +++ b/net/core/flow_dissector.c
> >> @@ -178,6 +178,20 @@ ipv6:
> >> return false;
> >> }
> >> }
> >> + case htons(ETH_P_TIPC): {
> >> + struct {
> >> + __be32 pre[3];
> >> + __be32 srcnode;
> >> + } *hdr, _hdr;
> >
> > Is this header defined somewhere in an include file ?
> >
> > This looks a bit ugly to locally define the format...
>
> I'd like this situation improved but I plan to apply this as-is for
> now.
About time we do something about this.. I'll post a patch with proper header
definitions soon.
//E
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
^ permalink raw reply
* [PATCH 3.16.y-ckt 073/126] xen-netfront: Fix handling packets on compound pages with skb_linearize
From: Luis Henriques @ 2015-01-27 12:16 UTC (permalink / raw)
To: linux-kernel, stable, kernel-team
Cc: Wei Liu, Ian Campbell, Luis Henriques, netdev, Stefan Bader,
Paul Durrant, Zoltan Kiss, xen-devel, David S. Miller
In-Reply-To: <1422361031-19364-1-git-send-email-luis.henriques@canonical.com>
3.16.7-ckt5 -stable review patch. If anyone has any objections, please let me know.
------------------
From: Zoltan Kiss <zoltan.kiss@citrix.com>
commit 97a6d1bb2b658ac85ed88205ccd1ab809899884d upstream.
There is a long known problem with the netfront/netback interface: if the guest
tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
it gets dropped. The reason is that netback maps these slots to a frag in the
frags array, which is limited by size. Having so many slots can occur since
compound pages were introduced, as the ring protocol slice them up into
individual (non-compound) page aligned slots. The theoretical worst case
scenario looks like this (note, skbs are limited to 64 Kb here):
linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
using 2 slots
first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
end and the beginning of a page, therefore they use 3 * 15 = 45 slots
last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
Although I don't think this 51 slots skb can really happen, we need a solution
which can deal with every scenario. In real life there is only a few slots
overdue, but usually it causes the TCP stream to be blocked, as the retry will
most likely have the same buffer layout.
This patch solves this problem by linearizing the packet. This is not the
fastest way, and it can fail much easier as it tries to allocate a big linear
area for the whole packet, but probably easier by an order of magnitude than
anything else. Probably this code path is not touched very frequently anyway.
Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Paul Durrant <paul.durrant@citrix.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
drivers/net/xen-netfront.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 7a4cd11e6a07..3e0019503440 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -623,9 +623,10 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
slots = DIV_ROUND_UP(offset + len, PAGE_SIZE) +
xennet_count_skb_frag_slots(skb);
if (unlikely(slots > MAX_SKB_FRAGS + 1)) {
- net_alert_ratelimited(
- "xennet: skb rides the rocket: %d slots\n", slots);
- goto drop;
+ net_dbg_ratelimited("xennet: skb rides the rocket: %d slots, %d bytes\n",
+ slots, skb->len);
+ if (skb_linearize(skb))
+ goto drop;
}
spin_lock_irqsave(&queue->tx_lock, flags);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Alexander Aring @ 2015-01-27 12:23 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <54C7694C.2060709@6wind.com>
Hi,
(removing the bounced mail address).
On Tue, Jan 27, 2015 at 11:32:44AM +0100, Nicolas Dichtel wrote:
> Le 27/01/2015 10:34, Alexander Aring a écrit :
> >Hi,
> >
> >On Mon, Jan 26, 2015 at 10:28:12PM +0100, Nicolas Dichtel wrote:
> >>
> [snip]
> >>- ieee802154 uses also src_net and does not have NETIF_F_NETNS_LOCAL. Same
> >> question: does this netdevice really supports x-netns?
> >
> >I am not sure if I understand exactly what you mean. First of all, I
> >didn't test anything about net namespaces for the ieee802154 branch.
> >In 802.15.4 branch we have two interfaces: wpan and 6LoWPAN.
> >
> >After running "grep -r "src_net" net" I found this is used in:
> >
> >net/ieee802154/6lowpan/core.c [0]
> Yes, I was talking about this.
>
ok.
> >
> >This file handles the IEEE 802.15.4 6LoWPAN interface to offering a
> >IPv6 interface with an IEEE 802.15.4 6LoWPAN adaption layer.
> >
> >To the codeline "dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));".
> >By calling "ip link add link wpan0 name lowpan0 type lowpan" the
> >lowpan_newlink function will be called and we need to find the wpan interface
> >(returned as real_dev in this case).
> >
> >Namespace setting in wpan interface:
> >
> >Currently we don't use any net namespace settings there, also we don't
> >change the net namespace. The default net namespace for a wpan shoule be
> >"init_net".
> Ok. After grepping for init_net, it seems to be used a lot in net/ieee802154/.
>
Yes, but the code in net/ieee802154 (except net/ieee802154/6lowpan) is only for
the WPAN interface. Currently the WPAN interface is created in mac802154
implementation only [0].
> >
> >So this line could be also written as (I found also some others code which search
> >the wpan interface in &init_net):
> >
> >diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
> >index 9dbe0d69..495c6ad 100644
> >--- a/net/ieee802154/6lowpan/core.c
> >+++ b/net/ieee802154/6lowpan/core.c
> >@@ -151,7 +151,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
> > if (!tb[IFLA_LINK])
> > return -EINVAL;
> > /* find and hold real wpan device */
> >- real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
> >+ real_dev = dev_get_by_index(&init_net, nla_get_u32(tb[IFLA_LINK]));
> > if (!real_dev)
> > return -ENODEV;
> > if (real_dev->type != ARPHRD_IEEE802154) {
> >
> >
> >
> >The above code is for finding the wpan interface (the real 802.15.4 L2 interface).
> >For the IEEE 802.15.4 6LoWPAN interface the whole IPv6 implementation is
> >used. This interface will be created inside function "newlink".
> >
> >Running "grep -r "src_net" net/ipv6" reports me alot uses of "src_net".
> >Don't know if this information is really necessary.
> >
> >Should I set now the NETIF_F_NETNS_LOCAL for both interface types?
> I think yes. If it's not set, a user may do:
> $ ip link add link wpan0 name lowpan0 type lowpan
> $ ip netns add foo
> $ ip link set lowpan0 netns foo
>
We should forbid that for the wpan interface. The code line:
real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
searches for the "wpan0" interface which is given by:
$ ip link add link wpan0 name lowpan0 type lowpan
The returned real_dev netdevice pointer is the wpan interface. The given
"lowpan0" interface is a virtual interface for making IPv6 stuff.
For 6LoWPAN:
This interface is created in 6lowpan/core.c file and is used in the
whole IPv6 stack, because we set the skb->protocol to htons(ETH_P_IPV6). [1]
The IPv6 stack uses alot of "src_net".
> The flag forbids the last command.
>
> Instead of your patch, what about this one:
>
> From d9a9cd22d5e1db1417b3ffb53cc020481dc761b2 Mon Sep 17 00:00:00 2001
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Tue, 27 Jan 2015 11:26:20 +0100
> Subject: [PATCH] ieee802154: forbid to create an iface in a netns != init_net
>
> 6LoWPAN currently doesn't supports netns.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> net/ieee802154/6lowpan/core.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
> index 055fbb71ba6f..fe8fd022042e 100644
> --- a/net/ieee802154/6lowpan/core.c
> +++ b/net/ieee802154/6lowpan/core.c
> @@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
> dev->header_ops = &lowpan_header_ops;
> dev->ml_priv = &lowpan_mlme;
> dev->destructor = free_netdev;
> + dev->features |= NETIF_F_NETNS_LOCAL;
> }
>
> static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
> @@ -148,7 +149,9 @@ static int lowpan_newlink(struct net *src_net, struct
> net_device *dev,
>
> pr_debug("adding new link\n");
>
> - if (!tb[IFLA_LINK])
> + if (!tb[IFLA_LINK] ||
> + !net_eq(src_net, &init_net) ||
> + !net_eq(dev_net(dev), &init_net))
> return -EINVAL;
> /* find and hold real wpan device */
> real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
With the check of "!net_eq(src_net, &init_net)" we need to be sure
that the wpan interface is always in "init_net". This means we need
definitely a dev->features |= NETIF_F_NETNS_LOCAL; somewhere in [0].
To adding "dev->features |= NETIF_F_NETNS_LOCAL;" for a 6LoWPAN interface,
I am not sure about this. I didn't test it yet and it will not break
anything, but we will lost the support for making net namespaces stuff
inside the IPv6/(netfilter) stack.
Summarize:
I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
interface generation and add only the !net_eq(src_net, &init_net) check
above. I suppose that src_net is the net namespace from "underlaying"
interface wpan by calling:
$ ip link add link wpan0 name lowpan0 type lowpan
- Alex
[0] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/mac802154/iface.c#n532
[1] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ieee802154/6lowpan/rx.c#n25
^ permalink raw reply
* Re: [PATCH net-next v1 05/18] net: tx4939: use __ethtool_get_ksettings
From: Sergei Shtylyov @ 2015-01-27 12:32 UTC (permalink / raw)
To: David Decotigny, David S. Miller, Ben Hutchings, Amir Vadai,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: Eric Dumazet, Eugenia Emantayev, Or Gerlitz, Ido Shamay,
Joe Perches, Saeed Mahameed, Govindarajulu Varadarajan,
Venkata Duvvuru, Jeff Kirsher, Eyal Perry, Pravin B Shelar,
Ed Swierk, David Decotigny
In-Reply-To: <1422322574-6188-6-git-send-email-ddecotig-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello.
On 1/27/2015 4:36 AM, David Decotigny wrote:
> From: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
> Signed-off-by: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
> ---
> arch/mips/txx9/generic/setup_tx4939.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
I don't think "net: " prefix applies here.
And you should have CC'ed linux-mips-6z/3iImG2C/i7sgoIIk9UQ@public.gmane.org
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net 1/2] caif: remove wrong dev_net_set() call
From: Bjørn Mork @ 2015-01-27 12:41 UTC (permalink / raw)
To: Nicolas Dichtel
Cc: netdev, davem, dmitry.tarnyagin, arvid.brodin, alex.aring,
linux-wpan, Sjur Brændeland, Dmitry Tarnyagin
In-Reply-To: <54C777D0.6090608@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
>> CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
>> CC: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
>
> I got a "Delivery Status Notification (Failure)" for Dmitry Tarnyagin
> (I took the email address from the MAINTAINERS file):
>
> Delivery to the following recipient failed permanently:
>
> dmitry.tarnyagin@lockless.no
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the server for
> the recipient domain lockless.no by mail.lockless.no. [46.29.221.38].
>
> The error that the other server returned was:
> 550 5.1.1 <dmitry.tarnyagin@lockless.no>: Recipient address rejected: User
> unknown in virtual mailbox table
>
> Any suggestions?
He used a gmail address in commit dd9dfb9f95e2 ("cfg80211: merge in
beacon ies of hidden bss."). Probably by accident, but worth trying
anyway...
I guess the stericsson.com addresses could be failing silently now? Ref
http://stericsson.com/ . Or are they still routed to the named recepients?
Bjørn
^ permalink raw reply
* Re: [PATCH net 1/2] caif: remove wrong dev_net_set() call
From: Nicolas Dichtel @ 2015-01-27 12:50 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev, davem, dmitry.tarnyagin, arvid.brodin, alex.aring,
linux-wpan, Sjur Brændeland, Dmitry Tarnyagin
In-Reply-To: <874mrcwg3q.fsf@nemi.mork.no>
Le 27/01/2015 13:41, Bjørn Mork a écrit :
> Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
>
>>> CC: Sjur Brændeland <sjur.brandeland@stericsson.com>
>>> CC: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
>>
>> I got a "Delivery Status Notification (Failure)" for Dmitry Tarnyagin
>> (I took the email address from the MAINTAINERS file):
>>
>> Delivery to the following recipient failed permanently:
>>
>> dmitry.tarnyagin@lockless.no
>>
>> Technical details of permanent failure:
>> Google tried to deliver your message, but it was rejected by the server for
>> the recipient domain lockless.no by mail.lockless.no. [46.29.221.38].
>>
>> The error that the other server returned was:
>> 550 5.1.1 <dmitry.tarnyagin@lockless.no>: Recipient address rejected: User
>> unknown in virtual mailbox table
>>
>> Any suggestions?
>
>
> He used a gmail address in commit dd9dfb9f95e2 ("cfg80211: merge in
> beacon ies of hidden bss."). Probably by accident, but worth trying
> anyway...
Ok, I will wait a bit before trying this address.
>
> I guess the stericsson.com addresses could be failing silently now? Ref
> http://stericsson.com/ . Or are they still routed to the named recepients?
I got also a delivery failure for sjur.brandeland@stericsson.com
Thank you,
Nicolas
^ permalink raw reply
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Alexander Aring @ 2015-01-27 12:51 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <20150127122340.GA4338@omega>
On Tue, Jan 27, 2015 at 01:23:40PM +0100, Alexander Aring wrote:
...
> Summarize:
>
> I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
> interface generation and add only the !net_eq(src_net, &init_net) check
> above. I suppose that src_net is the net namespace from "underlaying"
> interface wpan by calling:
>
> $ ip link add link wpan0 name lowpan0 type lowpan
>
should look something like:
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index 055fbb7..a44963c 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -148,10 +148,11 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
pr_debug("adding new link\n");
- if (!tb[IFLA_LINK])
+ if (!tb[IFLA_LINK] |
+ !net_eq(src_net, &init_net))
return -EINVAL;
/* find and hold real wpan device */
- real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
+ real_dev = dev_get_by_index(&init_net, nla_get_u32(tb[IFLA_LINK]));
if (!real_dev)
return -ENODEV;
if (real_dev->type != ARPHRD_IEEE802154) {
diff --git a/net/ieee802154/core.c b/net/ieee802154/core.c
index 18bc7e7..161f0e5 100644
--- a/net/ieee802154/core.c
+++ b/net/ieee802154/core.c
@@ -229,6 +229,8 @@ static int cfg802154_netdev_notifier_call(struct notifier_block *nb,
list_add_rcu(&wpan_dev->list, &rdev->wpan_dev_list);
rdev->devlist_generation++;
+ /* can only change netns with wpan_phy */
+ dev->features |= NETIF_F_NETNS_LOCAL;
wpan_dev->netdev = dev;
break;
case NETDEV_DOWN:
--
In ieee802154/core.c we set (like wireless it also does) the
dev->features |= NETIF_F_NETNS_LOCAL; for wpan interface.
In net/ieee802154/6lowpan/core.c, we only check if the wpan interface
belongs to !net_eq(src_net, &init_net).
On 6LoWPAN 802.15.4 interfaces it should be still possible to change
the net namespace.
- Alex
^ permalink raw reply related
* Re: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: Hiroshi Shimamoto @ 2015-01-27 12:53 UTC (permalink / raw)
To: Skidmore, Donald C, Alexander Duyck, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, David Laight,
Hayato Momma
In-Reply-To: <F6FB0E698C9B3143BDF729DF222866469129C3D0@ORSMSX110.amr.corp.intel.com>
> > On 01/22/2015 04:32 PM, Hiroshi Shimamoto wrote:
> > >> Subject: RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast
> > >> promiscuous mode control
> > >>> "Skidmore, Donald C" <donald.c.skidmore@intel.com> writes:
> > >>>
> > >>>> My hang up is more related to: without the nob to enable it (off by
> > >>>> default) we are letting one VF dictate policy for all the other VFs
> > >>>> and the PF. If one VF needs to be in promiscuous multicast so is
> > >>>> everyone else. Their stacks now needs to deal with all the extra
> > >>>> multicast packets. As you point out this might not be a direct
> > >>>> concern for isolation in that the VM could have 'chosen' to join
> > >>>> any Multicast group and seen this traffic. My concern over
> > >>>> isolation is one VF has chosen that all the other VM now have to
> > >>>> see this multicast traffic.
> > >>> Apologies if this question is stupid, but I just have to ask about
> > >>> stuff I don't understand...
> > >>>
> > >>> Looking at the proposed implementation, the promiscous multicast
> > >>> flag seems to be a per-VF flag:
> > >>>
> > >>> +int ixgbe_ndo_set_vf_mc_promisc(struct net_device *netdev, int vf,
> > >>> +bool
> > >>> +setting) {
> > >>> + struct ixgbe_adapter *adapter = netdev_priv(netdev);
> > >>> + struct ixgbe_hw *hw = &adapter->hw;
> > >>> + u32 vmolr;
> > >>> +
> > >>> + if (vf >= adapter->num_vfs)
> > >>> + return -EINVAL;
> > >>> +
> > >>> + adapter->vfinfo[vf].mc_promisc_enabled = setting;
> > >>> +
> > >>> + vmolr = IXGBE_READ_REG(hw, IXGBE_VMOLR(vf));
> > >>> + if (setting) {
> > >>> + e_info(drv, "VF %u: enabling multicast promiscuous\n", vf);
> > >>> + vmolr |= IXGBE_VMOLR_MPE;
> > >>> + } else {
> > >>> + e_info(drv, "VF %u: disabling multicast promiscuous\n", vf);
> > >>> + vmolr &= ~IXGBE_VMOLR_MPE;
> > >>> + }
> > >>> +
> > >>> + IXGBE_WRITE_REG(hw, IXGBE_VMOLR(vf), vmolr);
> > >>> +
> > >>> + return 0;
> > >>> +}
> > >>> +
> > >>>
> > >>> I haven't read the data sheet, but I took a quick look at the
> > >>> excellent high level driver docs:
> > >>> http://www.intel.com/content/dam/doc/design-guide/82599-sr-iov-
> > drive
> > >>> r-
> > >>> companion-guide.pdf
> > >>>
> > >>> It mentions "Multicast Promiscuous Enable" in its "Thoughts for
> > >>> Customization" section:
> > >>>
> > >>> 7.1 Multicast Promiscuous Enable
> > >>>
> > >>> The controller has provisions to allow each VF to be put into
> > >>> Multicast Promiscuous mode. The Intel reference driver does not
> > >>> configure this option .
> > >>>
> > >>> The capability can be enabled/disabled by manipulating the MPE
> > >>> field (bit
> > >>> 28) of the PF VF L2 Control Register (PFVML2FLT – 0x0F000)
> > >>>
> > >>> and showing a section from the data sheet describing the "PF VM L2
> > >>> Control Register - PFVML2FLT[n] (0x0F000 + 4 * n, n=0...63; RW)"
> > >>>
> > >>> To me it looks like enabling Promiscuos Multicast for a VF won't
> > >>> affect any other VF at all. Is this really not the case?
> > >>>
> > >>>
> > >>>
> > >>> Bjørn
> > >> Clearly not a dumb question at all and I'm glad you mentioned that.
> > >> :) I was going off the assumption, been awhile since I read the
> > >> patch, that the patch was using FCTRL.MPE or MANC.MCST_PASS_L2
> > which would turn multicast promiscuous on for everyone. Since the patch is
> > using PFVML2FLT.MPE this lessens my concern over effect on the entire
> > system.
> > > I believe the patches for this VF multicast promiscuous mode is per VF.
> > >
> > >> That said I still would prefer having a way to override this behavior on the
> > PF, although I admit my argument is weaker.
> > >> I'm still concerned about a VF changing the behavior of the PF
> > >> without any way to prevent it. This might be one part philosophical
> > >> (PF sets policy not the VF) but this still could have a noticeable
> > >> effect on the overall system. If any other VFs (or the PF) are
> > >> receiving MC packets these will have to be replicated which will be a
> > >> performance hit. When we use the MC hash this is limited vs. when
> > anyone is in MC promiscuous every MC packet used by another pool would
> > be replicated. I could imagine in some environments (i.e. public clouds)
> > where you don't trust what is running in your VM you might what to block
> > this from happening.
> > > I understand your request and I'm thinking to submit the patches
> > > 1) Add new mbox API between ixgbe/ixgbevf to turn MC promiscuous on,
> > > and enables it when ixgbevf needs over 30 MC addresses.
> > > 2) Add a policy knob to prevent enabling it from the PF.
> > >
> > > Does it seem okay?
> >
> > I would advise that if such a knob is added it should be set to disabled by
> > default. The main problem with supporting that many multicast addresses
> > per VF is that you run the risk for flooding the PCIe interface on the network
> > adapter if too many adapters were to go into such a mode.
> >
>
> This was my understanding as well. Someone would have to "choose" to allow VM to enter this mode, meaning off by default.
I see you'd like to keep it off unless the administrator wants to configure.
>
> > > BTW, I'm bit worried about to use ndo interface for 2) because adding
> > > a new hook makes core code complicated.
> > > Is it really reasonable to do it with ndo?
> > > I haven't find any other suitable method to do it, right now. And
> > > using ndo VF hook looks standard way to control VF functionality.
> > > Then, I think it's the best way to implement this policy in ndo hook.
> >
> > The ndo is probably the only way to go on this. It is how past controls for the
> > VF network functionality have been implemented.
> >
> > >> In some ways it is almost the mirror image of the issue you brought up:
> > >>
> > >> Adding a new hook for this seems over-complicated to me. And it
> > >> still doesn't solve the real problems that
> > >> a) the user has to know about this limit, and
> > >> b) manually configure the feature
> > >>
> > >> My reverse argument might be that if this happens automatically. It
> > >> might take the VM provider a long time to realize performance has
> > >> taken a hit because some VM asked to join 31 multicast groups and
> > entered MC promiscuous. Then only to find that they have no way to block
> > such behavior.
> > >>
> > >> Maybe I wouldn't as concerned if the patch author could provide some
> > >> performance results to show this won't have as a negative effect as I'm
> > afraid it might?
> > > Hm, what kind of test case would you like to have?
> > > The user A who has 30 MC addresses vs the user B who has 31 MC
> > > addresses, which means that MC promiscuous mode, and coming MC
> > packets the user doesn't expect?
> > >
> > > thanks,
> > > Hiroshi
> >
> > The question I would have is how many of these interfaces do you expect to
> > have supporting the expanded multicast mode? As it currently stands
Right now, we're thinking 1 or 2 VFs per PF will be enabled this feature
in our use case. Another representation, 1 or 2 VMs will be used VF device on
one server, each VM has 2 VFs usually.
> > multicast traffic has the potential to flood the adapter, greatly reduce the
> > overall throughput, and add extra workload to the PF and all VFs.
> > For example if several VFs enable this feature, and then someone on the
> > network sends a stream of multicast traffic what happens to the CPU load for
> > the host system?
I'm not sure why all VFs are affected.
I can imagine that PF and VFs which are enabled this feature could receive
flooding packets, but other VFs never receive such packets.
> >
> > Also how many addresses beyond 30 is it you require? An alternative to
> > adding multicast promiscuous might be to consider extending the mailbox
> > API to support sending more than 30 addresses via something such as a
> > multi-part multicast configuration message. The fm10k driver already has
> > logic similar to this as it adds addresses 1 at a time though a separate Switch
> > interface API between the PF and the Switch. You might be able to reuse
> > some of that code to reach beyond the 30 address limit.
>
> I think this would be a much safer approach and probably scale well for small sets. However I don't think it would work
> for Hiroshi's use case. If I remember correctly he wanted 1000's of MC groups per VM. I imagine there would be considerable
> overhead even loading up our 4K hash table 1 address at a time, likewise with that many address wouldn't this just be
> pretty much the same as being in multicast promiscuous. Still this might be an interesting approach to support those
> needing only a few MC groups over the limit.
We would like to use 2000 IPs usually, and would extend to 4k which comes from VLAN limit.
IIRC, mbox API has only 32 words, it doesn't scale, I think.
And there is a single hash table per PF, not per VF. I guess if we set 4k hash entries
from a specific VF, every VF will receive all MC packets.
>
> Alex's point is worth reiterating, this will effect performance. Have you tested this out under load and still see the
> results you can live with?
I don't have any number in MC load.
In general case, we have enough performance in VM, almost wire rate in our scenario.
thanks,
Hiroshi
>
> -Don Skidmore <donald.c.skidmore@intel.com>
>
> >
> > - Alex
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
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 net-next 06/10] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: Jack Morgenstein @ 2015-01-27 13:00 UTC (permalink / raw)
To: David Laight
Cc: 'Amir Vadai', David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Yevgeny Petrilin
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD3B01@AcuExch.aculab.com>
On Tue, 27 Jan 2015 09:43:27 +0000
David Laight <David.Laight@ACULAB.COM> wrote:
> From: Amir Vadai
> > From: Jack Morgenstein <jackm@dev.mellanox.co.il>
> >
> > Struct mlx4_vhcr was implicitly padded by the gcc compiler.
> > This commit makes that padding explicit, to prevent issues with
> > changing compilers. Note that we added the padding dword (rather
> > than simply packing the structure) in order to maintain
> > compatibility with previous kernels.
>
> It isn't a 'compiler' option, but depends on the architecture.
>
> > Reported-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
> > Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> > Signed-off-by: Amir Vadai <amirv@mellanox.com>
> > ---
> > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > b/drivers/net/ethernet/mellanox/mlx4/mlx4.h index 096a81c..595e18a
> > 100644 --- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > @@ -196,13 +196,14 @@ struct mlx4_vhcr {
> > struct mlx4_vhcr_cmd {
> > __be64 in_param;
> > __be32 in_modifier;
> > + u32 reserved1;
>
> Adding a pad here changes the alignment on most 32bit architectures
> (eg i386) where 64bit integers are only aligned to 4 byte boundaries.
> So you are not 'maintaining compatibility with previous kernels'.
You are correct. However, this structure is used ONLY for communication
between a Host and a Guest on that host. In the current code (before
this fix), it was not possible to run a 32-bit Guest over a 64-bit Host,
because of the implicit padding that occurred on the 64-bit Host
and did not occur on the 32-bit Guest.
With this fix, a 32-bit Guest (with the fix) will be able to run over a
64-bit Host (with or without the fix).
The padding dword thus serves to maintain 64-bit Host (old or
new) compatibility with 64-bit Guests (old or new), while allowing
64-bit Hosts to support new 32-bit Guests.
I'll fix the changelog for the next submission.
>
> > __be64 out_param;
> > __be16 token;
> > u16 reserved;
> > u8 status;
> > u8 flags;
> > __be16 opcode;
> > -};
> > +} __packed;
>
> Don't add '__packed' unless you expect the structure to be misaligned
> in memory.
> On systems that fault mis-aligned memory requests you've requested the
> compiler generate code to read/write everything using byte sized
> memory accesses and a lot of shifting and masking.
OK, I'll remove the "packed" in the next submission, since with the
padding dword 64-bit arch and 32-bit arch compilers should produce the
same offsets.
>
> David
>
Thanks for the review!
-Jack
^ permalink raw reply
* A problem about ICMP packet-too-big message handler
From: Yang Yingliang @ 2015-01-27 12:58 UTC (permalink / raw)
To: netdev, David S. Miller
Hi,
My kernel is 3.10 LTS.
I got a problem here about handling ICMP packet-too-big message.
Before sending a packet-too-big packet :
# ip -6 route list table local
local ::1 dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80::1 dev lo metric 0 //It does not have expire value
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:2 dev lo metric 0
local fe80::5054:ff:fe12:3456 dev lo metric 0
After sending a packet-too-big packet
ip -6 route list table local
local ::1 dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80:: dev lo metric 0
local fe80::1 dev lo metric 0 expires _597_ //It has expire value
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:0 dev lo metric 0
local fe80::200:ff:fe00:2 dev lo metric 0
local fe80::5054:ff:fe12:3456 dev lo metric 0
When time is up, I can't ping fe80::1 .
Is it ok or a bug ?
Regards,
Yang
^ permalink raw reply
* [PATCH] net/9p: use memcpy() instead of snprintf() in p9_mount_tag_show()
From: Andrey Ryabinin @ 2015-01-27 13:00 UTC (permalink / raw)
To: linux-kernel
Cc: David Laight, Aneesh Kumar K.V, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, v9fs-developer, netdev,
Andrey Ryabinin
In-Reply-To: <1422290896-25042-1-git-send-email-a.ryabinin@samsung.com>
p9_mount_tag_show() uses '%s' format string to print
non-NULL terminated chan->tag string. This leads
to out of bounds memory read, because format '%s'
implies that string is NULL-terminated.
The length of string is know here, so its simpler and safer
to use memcpy instead of snprintf().
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
---
net/9p/trans_virtio.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index daa749c..9d64145 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -504,7 +504,10 @@ static ssize_t p9_mount_tag_show(struct device *dev,
vdev = dev_to_virtio(dev);
chan = vdev->priv;
- return snprintf(buf, chan->tag_len + 1, "%s", chan->tag);
+ memcpy(buf, chan->tag, chan->tag_len);
+ buf[chan->tag_len] = 0;
+
+ return chan->tag_len + 1;
}
static DEVICE_ATTR(mount_tag, 0444, p9_mount_tag_show, NULL);
--
2.2.2
^ permalink raw reply related
* Re: make allyesconfig i386 build failure with next-20150122 (caused by fb_agm1264k-fl driver)
From: Tilman Schmidt @ 2015-01-27 13:04 UTC (permalink / raw)
To: Guenter Roeck, Greg Kroah-Hartman
Cc: Jim Davis, Stephen Rothwell, linux-next, linux-kernel, devel,
isdn, netdev, Thomas Petazzoni
In-Reply-To: <54C6FB28.3000304@roeck-us.net>
Am 27.01.2015 um 03:42 schrieb Guenter Roeck:
> On 01/26/2015 02:46 PM, Greg Kroah-Hartman wrote:
>> On Mon, Jan 26, 2015 at 01:59:59PM -0800, Guenter Roeck wrote:
>>> On Thu, Jan 22, 2015 at 12:10:33PM -0700, Jim Davis wrote:
>>>> make ARCH=i386 allyesconfig fails with
>>>>
>>>> drivers/staging/built-in.o: In function `reset':
>>>> (.text+0x2ae89d): multiple definition of `reset'
>>>> drivers/isdn/built-in.o:(.text+0x185dc2): first defined here
>>>> make[1]: *** [drivers/built-in.o] Error 1
>>>
>>> Culprit:
>>>
>>> commit b2ebd4be6fa1d2329b63531b044f9e25474981cb
>>> Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>>> Date: Wed Dec 31 10:11:10 2014 +0100
>>>
>>> staging: fbtft: add fb_agm1264k-fl driver
>>>
>>> A global function named 'reset' isn't really a good idea.
>>>
>>> Not that the global function with the same name in the isdn code
>>> is better ;-).
>>
>> Agreed, the fbtft code is now fixed. Patches to fix the isdn code would
>> be gladly accepted as well :)
>>
>
> Did you have a look into the isdn code ? It will need someone
> with a lot of spare time to clean this code up.
Cleaning up the entire isdn code certainly will, but that particular
problem is in fact much more limited. The function in question is
declared, along with several other also much too generically named
ones, in drivers/isdn/sc/card.h which is included nowhere outside
drivers/isdn/sc. So these are really private functions of the
SpellCaster driver which could easily be renamed.
OTOH good old SpellCaster was an ISA card, and the sc driver depends
on the deprecated I4L framework. I wonder if it's worth any effort.
Tilman
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Patrick McHardy @ 2015-01-27 13:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Miller, David.Laight, ying.xue, paulmck,
netdev, netfilter-devel
In-Reply-To: <20150127112304.GA4548@gondor.apana.org.au>
On 27.01, Herbert Xu wrote:
> On Tue, Jan 27, 2015 at 11:16:04AM +0000, Thomas Graf wrote:
> >
> > No objection. I have a patch prepared which allows the user to
> > provide ht->mutex himself so nfset can provide its own existing
> > mutex to rhashtable and lock out the resizes from inserts,
> > removals and dump iterations automatically That would restore the
> > old behaviour of the nfset API without major surgery.
>
> If you take the mutex you might as well just make it synchronous.
> There is zero difference.
>
> Maybe you misunderstood my email. I'm not making it synchronous
> for everybody, just those that always take a lock on inserts/removals
> and therefore don't need per-bucket locks.
Actually I have a patchset queued that adds runtime additions and
removals, both active and timeout based. So netfilter won't have
pure synchronous behaviour anymore.
^ permalink raw reply
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Nicolas Dichtel @ 2015-01-27 13:28 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev, davem, arvid.brodin, linux-wpan
In-Reply-To: <20150127122340.GA4338@omega>
Le 27/01/2015 13:23, Alexander Aring a écrit :
> Hi,
>
> (removing the bounced mail address).
>
> On Tue, Jan 27, 2015 at 11:32:44AM +0100, Nicolas Dichtel wrote:
>> Le 27/01/2015 10:34, Alexander Aring a écrit :
>>> Hi,
>>>
>>> On Mon, Jan 26, 2015 at 10:28:12PM +0100, Nicolas Dichtel wrote:
>>>>
[snip]
>>>
>>> This file handles the IEEE 802.15.4 6LoWPAN interface to offering a
>>> IPv6 interface with an IEEE 802.15.4 6LoWPAN adaption layer.
>>>
>>> To the codeline "dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));".
>>> By calling "ip link add link wpan0 name lowpan0 type lowpan" the
>>> lowpan_newlink function will be called and we need to find the wpan interface
>>> (returned as real_dev in this case).
>>>
>>> Namespace setting in wpan interface:
>>>
>>> Currently we don't use any net namespace settings there, also we don't
>>> change the net namespace. The default net namespace for a wpan shoule be
>>> "init_net".
>> Ok. After grepping for init_net, it seems to be used a lot in net/ieee802154/.
>>
>
> Yes, but the code in net/ieee802154 (except net/ieee802154/6lowpan) is only for
> the WPAN interface. Currently the WPAN interface is created in mac802154
> implementation only [0].
Ok. How is this interface created?
>
>>>
>>> So this line could be also written as (I found also some others code which search
>>> the wpan interface in &init_net):
>>>
>>> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
>>> index 9dbe0d69..495c6ad 100644
>>> --- a/net/ieee802154/6lowpan/core.c
>>> +++ b/net/ieee802154/6lowpan/core.c
>>> @@ -151,7 +151,7 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
>>> if (!tb[IFLA_LINK])
>>> return -EINVAL;
>>> /* find and hold real wpan device */
>>> - real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
>>> + real_dev = dev_get_by_index(&init_net, nla_get_u32(tb[IFLA_LINK]));
>>> if (!real_dev)
>>> return -ENODEV;
>>> if (real_dev->type != ARPHRD_IEEE802154) {
>>>
>>>
>>>
>>> The above code is for finding the wpan interface (the real 802.15.4 L2 interface).
>>> For the IEEE 802.15.4 6LoWPAN interface the whole IPv6 implementation is
>>> used. This interface will be created inside function "newlink".
>>>
>>> Running "grep -r "src_net" net/ipv6" reports me alot uses of "src_net".
>>> Don't know if this information is really necessary.
>>>
>>> Should I set now the NETIF_F_NETNS_LOCAL for both interface types?
>> I think yes. If it's not set, a user may do:
>> $ ip link add link wpan0 name lowpan0 type lowpan
>> $ ip netns add foo
>> $ ip link set lowpan0 netns foo
>>
>
> We should forbid that for the wpan interface. The code line:
>
> real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
>
> searches for the "wpan0" interface which is given by:
> $ ip link add link wpan0 name lowpan0 type lowpan
>
> The returned real_dev netdevice pointer is the wpan interface. The given
> "lowpan0" interface is a virtual interface for making IPv6 stuff.
Yes. But with the current code, it seems that you can also do (not tested):
$ ip link add link wpan0 netns foo name lowpan0 type lowpan
With this cmd, src_net points to the netns where the ip cmd is launched (let's
say init_net in this case) but the interface lowpan0 will be created in the
netns foo. To summarize: wpan0 is in init_net and lowpan0 in foo.
Now, if you use this line:
real_dev = dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
With the same command, dev_net(dev) will point to foo.
>
>
>
> For 6LoWPAN:
>
> This interface is created in 6lowpan/core.c file and is used in the
> whole IPv6 stack, because we set the skb->protocol to htons(ETH_P_IPV6). [1]
>
> The IPv6 stack uses alot of "src_net".
In fact, src_net is used by IP tunnels (sit, ip6gre, ip6_tunnels, ip6_vti). But
these interfaces ignore this parameter.
The IPv6 stack is fully netns aware, thus it will use correctly the netns from
the netdevice and/or from the socket.
>
>> The flag forbids the last command.
>>
>> Instead of your patch, what about this one:
>>
>> From d9a9cd22d5e1db1417b3ffb53cc020481dc761b2 Mon Sep 17 00:00:00 2001
>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Date: Tue, 27 Jan 2015 11:26:20 +0100
>> Subject: [PATCH] ieee802154: forbid to create an iface in a netns != init_net
>>
>> 6LoWPAN currently doesn't supports netns.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>> net/ieee802154/6lowpan/core.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
>> index 055fbb71ba6f..fe8fd022042e 100644
>> --- a/net/ieee802154/6lowpan/core.c
>> +++ b/net/ieee802154/6lowpan/core.c
>> @@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
>> dev->header_ops = &lowpan_header_ops;
>> dev->ml_priv = &lowpan_mlme;
>> dev->destructor = free_netdev;
>> + dev->features |= NETIF_F_NETNS_LOCAL;
>> }
>>
>> static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
>> @@ -148,7 +149,9 @@ static int lowpan_newlink(struct net *src_net, struct
>> net_device *dev,
>>
>> pr_debug("adding new link\n");
>>
>> - if (!tb[IFLA_LINK])
>> + if (!tb[IFLA_LINK] ||
>> + !net_eq(src_net, &init_net) ||
>> + !net_eq(dev_net(dev), &init_net))
>> return -EINVAL;
>> /* find and hold real wpan device */
>> real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
>
> With the check of "!net_eq(src_net, &init_net)" we need to be sure
> that the wpan interface is always in "init_net". This means we need
> definitely a dev->features |= NETIF_F_NETNS_LOCAL; somewhere in [0].
>
> To adding "dev->features |= NETIF_F_NETNS_LOCAL;" for a 6LoWPAN interface,
> I am not sure about this. I didn't test it yet and it will not break
> anything, but we will lost the support for making net namespaces stuff
> inside the IPv6/(netfilter) stack.
Adding NETIF_F_NETNS_LOCAL does not mean that the netdevice can be used only
in init_net, this flag means that the netdevice cannot be moved to another
netns. You can still create a netdevice in another netns (if wpan0 is in netns
foo):
$ ip netns exec foo ip link add link wpan0 name lowpan0 type lowpan
I don't know how wpan0 is created and if this interface can be created directly
in another netns than init_net.
>
>
> Summarize:
>
> I would add the dev->features |= NETIF_F_NETNS_LOCAL; while wpan
> interface generation and add only the !net_eq(src_net, &init_net) check
> above. I suppose that src_net is the net namespace from "underlaying"
> interface wpan by calling:
>
> $ ip link add link wpan0 name lowpan0 type lowpan
No. src_net is the netns where the ip command is launched. With this patch, my
previous cmd (ip link add link wpan0 netns foo name lowpan0 type lowpan) will
still work and lowpan0 will be in netns foo.
Note: I just saw your patch proposal in another reply [0], with it, my sentence
is still true I think ;-)
But:
$ git grep "net_eq.*init_net" net/ieee802154/' | wc -l
7
So I wonder if it's really possible to use lowpan0 in another netns than
init_net (my proposal was based on this).
Maybe this can help you to understand my point.
A virtual interface can be across two netns:
- the link netns (the interface receives and sends packets to/from the link
layer into this netns)
- the netns where the interface is visible (the user receives and sends
packets to/from the interface into this netns)
[0] http://patchwork.ozlabs.org/patch/433467/
Regards,
Nicolas
^ permalink raw reply
* RE: [PATCH net-next 06/10] net/mlx4_core: Fix struct mlx4_vhcr_cmd to make implicit padding explicit
From: David Laight @ 2015-01-27 13:38 UTC (permalink / raw)
To: 'Jack Morgenstein'
Cc: 'Amir Vadai', David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Yevgeny Petrilin
In-Reply-To: <20150127150027.184ba5e8@jpm-OptiPlex-GX620>
From: Jack Morgenstein
> On Tue, 27 Jan 2015 09:43:27 +0000
> David Laight <David.Laight@ACULAB.COM> wrote:
>
> > From: Amir Vadai
> > > From: Jack Morgenstein <jackm@dev.mellanox.co.il>
> > >
> > > Struct mlx4_vhcr was implicitly padded by the gcc compiler.
> > > This commit makes that padding explicit, to prevent issues with
> > > changing compilers. Note that we added the padding dword (rather
> > > than simply packing the structure) in order to maintain
> > > compatibility with previous kernels.
> >
> > It isn't a 'compiler' option, but depends on the architecture.
> >
> > > Reported-by: Alexander Schmidt <alexs@linux.vnet.ibm.com>
> > > Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> > > Signed-off-by: Amir Vadai <amirv@mellanox.com>
> > > ---
> > > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > > b/drivers/net/ethernet/mellanox/mlx4/mlx4.h index 096a81c..595e18a
> > > 100644 --- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > > +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
> > > @@ -196,13 +196,14 @@ struct mlx4_vhcr {
> > > struct mlx4_vhcr_cmd {
> > > __be64 in_param;
> > > __be32 in_modifier;
> > > + u32 reserved1;
> >
> > Adding a pad here changes the alignment on most 32bit architectures
> > (eg i386) where 64bit integers are only aligned to 4 byte boundaries.
> > So you are not 'maintaining compatibility with previous kernels'.
>
> You are correct. However, this structure is used ONLY for communication
> between a Host and a Guest on that host. In the current code (before
> this fix), it was not possible to run a 32-bit Guest over a 64-bit Host,
> because of the implicit padding that occurred on the 64-bit Host
> and did not occur on the 32-bit Guest.
>
> With this fix, a 32-bit Guest (with the fix) will be able to run over a
> 64-bit Host (with or without the fix).
Haven't you broken communication between an old and new
32bit Guests and 32bit hosts (assuming they exist)?
David
^ permalink raw reply
* Re: [PATCH 1/3] ipv6: Select fragment id during UFO/GSO segmentation if not set.
From: Hannes Frederic Sowa @ 2015-01-27 13:47 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ben Hutchings, Vladislav Yasevich, netdev, virtualization,
edumazet, Vladislav Yasevich
In-Reply-To: <20150127084208.GB21584@redhat.com>
On Di, 2015-01-27 at 10:42 +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 27, 2015 at 02:47:54AM +0000, Ben Hutchings wrote:
> > On Mon, 2015-01-26 at 09:37 -0500, Vladislav Yasevich wrote:
> > > If the IPv6 fragment id has not been set and we perform
> > > fragmentation due to UFO, select a new fragment id.
> > > When we store the fragment id into skb_shinfo, set the bit
> > > in the skb so we can re-use the selected id.
> > > This preserves the behavior of UFO packets generated on the
> > > host and solves the issue of id generation for packet sockets
> > > and tap/macvtap devices.
> > >
> > > This patch moves ipv6_select_ident() back in to the header file.
> > > It also provides the helper function that sets skb_shinfo() frag
> > > id and sets the bit.
> > >
> > > It also makes sure that we select the fragment id when doing
> > > just gso validation, since it's possible for the packet to
> > > come from an untrusted source (VM) and be forwarded through
> > > a UFO enabled device which will expect the fragment id.
> > >
> > > CC: Eric Dumazet <edumazet@google.com>
> > > Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > ---
> > > include/linux/skbuff.h | 3 ++-
> > > include/net/ipv6.h | 2 ++
> > > net/ipv6/ip6_output.c | 4 ++--
> > > net/ipv6/output_core.c | 9 ++++++++-
> > > net/ipv6/udp_offload.c | 10 +++++++++-
> > > 5 files changed, 23 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > > index 85ab7d7..3ad5203 100644
> > > --- a/include/linux/skbuff.h
> > > +++ b/include/linux/skbuff.h
> > > @@ -605,7 +605,8 @@ struct sk_buff {
> > > __u8 ipvs_property:1;
> > > __u8 inner_protocol_type:1;
> > > __u8 remcsum_offload:1;
> > > - /* 3 or 5 bit hole */
> > > + __u8 ufo_fragid_set:1;
> > [...]
> >
> > Doesn't the flag belong in struct skb_shared_info, rather than struct
> > sk_buff? Otherwise this looks fine.
> >
> > Ben.
>
> Hmm we seem to be out of tx flags.
> Maybe ip6_frag_id == 0 should mean "not set".
Maybe that is the best idea. Definitely the ufo_fragid_set bit should
move into the skb_shared_info area.
Thanks,
Hannes
^ 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