* 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
* [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-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
* 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
* 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
* 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
* 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: [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: [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: 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 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] 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: [PATCHv3 ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: Florian Westphal @ 2015-01-27 11:04 UTC (permalink / raw)
To: David Laight
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: <063D6719AE5E284EB5DD2968C1650D6D1CAD3B2B@AcuExch.aculab.com>
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?
> Possibly add a compile-time check that the structure is
> of the expected size.
Uh, what?
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Mark Rutland @ 2015-01-27 10:53 UTC (permalink / raw)
To: Stathis Voukelatos
Cc: Stathis Voukelatos, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
abrestic@chromium.org
In-Reply-To: <54C613F2.5090507@linn.co.uk>
On Mon, Jan 26, 2015 at 10:16:18AM +0000, Stathis Voukelatos wrote:
>
> On 23/01/15 10:51, Mark Rutland wrote:
> >
> > diff --git a/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> > new file mode 100644
> > index 0000000..6b6e105
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
> > @@ -0,0 +1,27 @@
> > +* Linn Products Ethernet Packet Sniffer
> > +
> > +Required properties:
> > +- compatible : must be "linn,eth-sniffer"
> > +- reg : physical addresses and sizes of registers. Must contain 3 entries:
> > + first entry: registers memory space
> > + second entry: TX command memory
> > + third entry: RX command memory
> > Just to check: are those memories are part of the packet sniffer device,
> > or are carveouts from other memory?
> Yes, the 3 memory areas are part of the packet sniffer module.
> >> +- fifo-block-words : number of words in one data FIFO entry
> >> +
> >> +Example:
> >> +
> >> +sniffer@1814a000 {
> >> + compatible = "linn,eth-sniffer";
> >> + reg = <0x1814a000 0x100>, <0x1814a400 0x400>, <0x1814a800 0x400>;
> >> + reg-names = "regs", "tx-ram", "rx-ram";
> >> + interrupts = <GIC_SHARED 58 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-names = "eth-sniffer-irq";
> >> + clocks = <&system_clk>;
> >> + clock-names = "sys";
> >> + fifo-block-words = <4>;
> >> + };
> > Surely the relationship between the sniffer, MAC, and PHY should be
> > described, so we know which interface the sniffer is related to?
> >
> The packet sniffer sits between the MAC and the PHY and monitors TX or RX
> packets, or both. Will add a description in the binding doc.
I understood that. However the binding does not explicitly refer to
either of those, so I don't see how you'd associate this sniffer
instance with the relevant PHY+MAC instances.
That should be made explicit in the binding.
Mark.
^ permalink raw reply
* Re: [PATCH] net: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-27 10:51 UTC (permalink / raw)
To: Florian Fainelli, Stathis Voukelatos, netdev, linux-kernel,
devicetree
Cc: abrestic
In-Reply-To: <54C6BFEA.5020101@gmail.com>
Hi Florian,
On 26/01/15 22:30, Florian Fainelli wrote:
> On 23/01/15 02:07, Stathis Voukelatos wrote:
>> This patch adds support the Ethernet Packet Sniffer H/W module
>> developed by Linn Products Ltd and found in the IMG Pistachio SoC.
>> The module allows Ethernet packets to be parsed, matched against
>> a user-defined pattern and timestamped. It sits between a 100M
>> Ethernet MAC and PHY and is completely passive with respect to
>> Ethernet frames.
> Is there any latency penalty involved in capturing (or not) packets as
> opposed to having this capture HW unused?
There is no additional latency introduced by the sniffer at the H/W level,
if that is what you mean. Only the S/W overhead for handling the
sniffer interrupt for each match event.
>> Matched packet bytes and timestamp values are returned through a
>> FIFO. Timestamps are provided to the module through an externally
>> generated Gray-encoded counter.
>>
>> The command pattern for packet matching is stored in module RAM
>> and consists of a sequence of 16-bit entries. Each entry includes
>> an 8-bit command code and and 8-bit data value. Valid command
>> codes are:
>> 0 - Don't care
>> 1 - Match: packet data must match command string byte
>> 2 - Copy: packet data will be copied to FIFO
>> 3 - Match/Stamp: if packet data matches string byte, a timestamp
>> is copied into the FIFO
>> 4 - Copy/Done: packet data will be copied into the FIFO.
>> This command terminates the command string.
>>
>> The driver consists of two modules:
>> - Core: it provides an API to user space using the Generic Netlink
>> framework. Specific backend implementations, like the
>> Ethernet Packet Sniffer, register one or more channels
>> with the Core. For each channel a Genl family is created.
>> User space can access a channel by sending Genl messages
>> to the Genl family associated with the channel. Packet
>> matching events are multicast.
> Instead of having this new generic netlink family to control sniffing,
> could we imagine registering a netdevice which does not nothing but
> still allows for tools like tcpdump, af_packet and other capture tools
> to work transparently and just leverage the HW capture?
Thanks, I will work on that change. It has been suggested by a previous
reviewer too and it makes sense to go down that route.
Stathis
^ permalink raw reply
* Re: [PATCH net 0/2] netns: audit netdevice creation with IFLA_NET_NS_[PID|FD]
From: Nicolas Dichtel @ 2015-01-27 10:32 UTC (permalink / raw)
To: Alexander Aring; +Cc: netdev, davem, dmitry.tarnyagin, arvid.brodin, linux-wpan
In-Reply-To: <20150127093425.GA2698@omega>
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.
>
> 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/.
>
> 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
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]));
--
2.2.2
^ permalink raw reply related
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 10:24 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127101512.GE22262@casper.infradead.org>
On Tue, Jan 27, 2015 at 10:15:12AM +0000, Thomas Graf wrote:
>
> Because libraries like libnl already handle this transparently for
> various user space apps. Those apps are not even aware of the problem
> and always get a consistent dump if the kernel implements INTR.
Did you see Dave's message? He said those that dump need to create
their own data structure so there is no point in proceeding with
any of this work within rhashtable.
> Because making it synchronous does not help the Netlink dump problem
> at all, see below.
>
> Also, a sync resize causes a random inserts/removal to take a lot
> longer. This leads to less predictable insert/removal times. I have
> no objection to offering both sync and async resizing as long as the
> choice of balance is configurable.
So what? They can switch over to lockless mode if they care.
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.
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 1/2] rhashtable: Introduce rhashtable_walk_*
From: Thomas Graf @ 2015-01-27 10:15 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127095454.GA2695@gondor.apana.org.au>
On 01/27/15 at 08:54pm, Herbert Xu wrote:
> On Tue, Jan 27, 2015 at 09:45:41AM +0000, Thomas Graf wrote:
> >
> > OK. I'll wait for your netfilter approach before posting NLM_F_INTR
> > patches.
>
> Why would we still need the INTR stuff given that Dave has asked
> for this to be done outside of rhashtable?
Because libraries like libnl already handle this transparently for
various user space apps. Those apps are not even aware of the problem
and always get a consistent dump if the kernel implements INTR.
> What I'm planning on doing right now is to divide rhashtable users
> into two camps, lockless insert/removal vs. locked insert/removal.
> netfilter will obviously fall into the latter camp.
>
> For those with locked insert/removal I will make resizing/rehashing
> synchronous since there is zero benefit from doing it in a separate
> thread.
Because making it synchronous does not help the Netlink dump problem
at all, see below.
Also, a sync resize causes a random inserts/removal to take a lot
longer. This leads to less predictable insert/removal times. I have
no objection to offering both sync and async resizing as long as the
choice of balance is configurable.
> Once that is done you can then easily walk the table by just holding
> the lock, which is what netfilter does today.
How? Do you want to hold the mutex while the user is reading? I don't
see how to achieve consistency with locking without introducing a ton
of complexity and attackable behaviour like user space being able to
delay inserts. If at all this only seems acceptable for privileged
users.
My vote is to rely on the proven INTR flag and optionally restart the
dump if user space did not indicate that INTR is supported as Patrick
suggested.
^ permalink raw reply
* [PATCH net-next v2] rtnetlink: pass link_net to the newlink handler
From: Nicolas Dichtel @ 2015-01-27 10:13 UTC (permalink / raw)
To: netdev; +Cc: davem, Nicolas Dichtel
In-Reply-To: <54C61ED1.5040501@6wind.com>
When IFLA_LINK_NETNSID is used, the netdevice should be built in this link netns
and moved at the end to another netns (pointed by the socket netns or
IFLA_NET_NS_[PID|FD]).
Existing user of the newlink handler will use the netns argument (src_net) to
find a link netdevice or to check some other information into the link netns.
For example, to find a netdevice, two information are required: an ifindex
(usually from IFLA_LINK) and a netns (this link netns).
Note: when using IFLA_LINK_NETNSID and IFLA_NET_NS_[PID|FD], a user may create a
netdevice that stands in netnsX and with its link part in netnsY, by sending a
rtnl message from netnsZ.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: instead of patching each subsystem, pass the right netns to
the newlink handler
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 07447d1665e6..fedd7ab4085a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2148,7 +2148,7 @@ replay:
dev->ifindex = ifm->ifi_index;
if (ops->newlink) {
- err = ops->newlink(net, dev, tb, data);
+ err = ops->newlink(link_net ? : net, dev, tb, data);
/* Drivers should call free_netdev() in ->destructor
* and unregister it on failure after registration
* so that device could be finally freed in rtnl_unlock.
--
2.2.2
^ permalink raw reply related
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 10:12 UTC (permalink / raw)
To: David Laight
Cc: Thomas Graf, Ying Xue, davem@davemloft.net, kaber@trash.net,
paulmck@linux.vnet.ibm.com, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD3B6C@AcuExch.aculab.com>
On Tue, Jan 27, 2015 at 10:09:18AM +0000, David Laight wrote:
>
> But if err is non-zero you don't hold the mutex.
> Presumably the calling code also errors out immediately,
> so the RCU lock isn't needed at all.
No the calling code expects the RCU lock to be held because it
will always call stop. Look at how seq_file works.
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 1/2] rhashtable: Introduce rhashtable_walk_*
From: David Laight @ 2015-01-27 10:09 UTC (permalink / raw)
To: 'Herbert Xu'
Cc: Thomas Graf, Ying Xue, davem@davemloft.net, kaber@trash.net,
paulmck@linux.vnet.ibm.com, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org
In-Reply-To: <20150126222259.GC30116@gondor.apana.org.au>
From: Herbert Xu
> On Mon, Jan 26, 2015 at 10:09:24AM +0000, David Laight wrote:
> >
> > That doesn't look right to me.
> > Surely you shouldn't be calling rcu_read_lock() when the mutex
> > request is interrupted.
> >
> > So maybe:
> > err = mutex_lock_interruptible(&ht->mutex);
> > if (err)
> > return err;
> > rcu_read_lock();
>
> No, we need to grab the RCU read lock while holding the mutex
> in order to prevent future resizes from happening once we release
> the mutex.
But if err is non-zero you don't hold the mutex.
Presumably the calling code also errors out immediately,
so the RCU lock isn't needed at all.
David
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Herbert Xu @ 2015-01-27 9:54 UTC (permalink / raw)
To: Thomas Graf
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150127094541.GC22262@casper.infradead.org>
On Tue, Jan 27, 2015 at 09:45:41AM +0000, Thomas Graf wrote:
>
> OK. I'll wait for your netfilter approach before posting NLM_F_INTR
> patches.
Why would we still need the INTR stuff given that Dave has asked
for this to be done outside of rhashtable?
What I'm planning on doing right now is to divide rhashtable users
into two camps, lockless insert/removal vs. locked insert/removal.
netfilter will obviously fall into the latter camp.
For those with locked insert/removal I will make resizing/rehashing
synchronous since there is zero benefit from doing it in a separate
thread.
Once that is done you can then easily walk the table by just holding
the lock, which is what netfilter does today.
I'll probably make netlink locked too since it's much simpler that
way. Only really high performance users like TCP/UDP sockets need
lockless insert/removal and the complexity that comes with it.
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: Linn Ethernet Packet Sniffer driver
From: Stathis Voukelatos @ 2015-01-27 9:52 UTC (permalink / raw)
To: Joe Perches
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
abrestic-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <1422301185.18650.4.camel-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On 26/01/15 19:39, Joe Perches wrote:
> This header file is the public API for the driver.
> Should it not live under the 'include' directory?
> Several other drivers seem to follow that convention.
> It depends on how public is public.
>
> If it's _really_ public, it should be in uapi.
> If it's kinda public, then _maybe_ it should be
> in include/linux, but how likely is it another
> driver will use it?
>
>
It is intended for user space code that needs
to use the driver as it defines the netlink messages and
attributes that the driver understands. So I guess
uapi/linux would be the place for it.
Thanks,
Stathis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCHv3 ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: David Laight @ 2015-01-27 9:46 UTC (permalink / raw)
To: 'Fan Du', steffen.klassert@secunet.com
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
netdev@vger.kernel.org, fengyuleidian0615@gmail.com
In-Reply-To: <1422349230-17394-1-git-send-email-fan.du@intel.com>
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.
Possibly add a compile-time check that the structure is
of the expected size.
David
^ permalink raw reply
* Re: [PATCH 1/2] rhashtable: Introduce rhashtable_walk_*
From: Thomas Graf @ 2015-01-27 9:45 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, David.Laight, ying.xue, kaber, paulmck, netdev,
netfilter-devel
In-Reply-To: <20150126233100.GA31108@gondor.apana.org.au>
On 01/27/15 at 10:31am, Herbert Xu wrote:
> On Tue, Jan 27, 2015 at 09:42:16AM +1100, Herbert Xu wrote:
> >
> > As otherwise we'd be looking at fixing the existing users (in
> > particular, nft_hash) properly which might take a lot more time.
>
> I take that back. Looks like my walkers would be no good for
> netfilter anyway since it wants to do nested walks, meaning no
> locks can be taken.
>
> So I think I'll just have to tackle netfilter first in which case
> the walk function would be no use anyway since I could just fix
> netlink by itself.
OK. I'll wait for your netfilter approach before posting NLM_F_INTR
patches.
^ 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