* [PATCH] kexec: Export kexec_in_progress to modules
From: Florian Fainelli @ 2016-10-21 1:15 UTC (permalink / raw)
To: netdev; +Cc: ebiederm, kexec, linux-kernel, davem, sfr, Florian Fainelli
The bcm_sf2 driver uses kexec_in_progress to know whether it can power
down an integrated PHY during shutdown, and can be built as a module.
Other modules may be using this in the future, so export it.
Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Eric, David, Stephen,
The offending commit is in David's net.git tree, so it would probably make
sense to route the fix through the same tree.
Thanks!
kernel/kexec_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 561675589511..786ab85a5452 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -59,6 +59,7 @@ size_t vmcoreinfo_max_size = sizeof(vmcoreinfo_data);
/* Flag to indicate we are going to kexec a new kernel */
bool kexec_in_progress = false;
+EXPORT_SYMBOL_GPL(kexec_in_progress);
/* Location of the reserved area for the crash kernel */
--
2.7.4
^ permalink raw reply related
* linux-next: manual merge of the staging tree with the net-next tree
From: Stephen Rothwell @ 2016-10-21 1:21 UTC (permalink / raw)
To: Greg KH, David Miller, Networking
Cc: linux-next, linux-kernel, Jarod Wilson, Sergio Paracuellos
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/wlan-ng/p80211netdev.c
between commit:
9c22b4a34edd ("net: use core MTU range checking in wireless drivers")
from the net-next tree and commit:
84ad1efa7d2b ("staging: wlan-ng: fix block comment warnings in p80211netdev.c")
from the staging tree.
I fixed it up (the former removed the code updates by the latter, so I
just did that) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH] kexec: Export kexec_in_progress to modules
From: David Miller @ 2016-10-21 1:54 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, ebiederm, kexec, linux-kernel, sfr
In-Reply-To: <1477012516-20470-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 20 Oct 2016 18:15:16 -0700
> The bcm_sf2 driver uses kexec_in_progress to know whether it can power
> down an integrated PHY during shutdown, and can be built as a module.
> Other modules may be using this in the future, so export it.
>
> Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Eric, David, Stephen,
>
> The offending commit is in David's net.git tree, so it would probably make
> sense to route the fix through the same tree.
Ok, I'll apply this, thanks Florian.
^ permalink raw reply
* Re: [PATCH net] udp: must lock the socket in udp_disconnect()
From: Eric Dumazet @ 2016-10-21 2:09 UTC (permalink / raw)
To: Cong Wang; +Cc: Baozeng Ding, David Miller, network dev
In-Reply-To: <CAM_iQpVG-L=ZCDnOpDjpyDWuyPFY378JbQ5qhu9_bhzOGc9BuQ@mail.gmail.com>
On Thu, 2016-10-20 at 18:12 -0700, Cong Wang wrote:
> If this is the cause of the hashlist corruption (I am still unsure about this),
> then why only UDP? Don't all of those using ip4_datagram_connect()
> as ->connect() and using udp_disconnect() as ->disconnect() need this fix?
>
> For example, after your patch,
>
> .connect = ip4_datagram_connect,
> - .disconnect = udp_disconnect,
> + .disconnect = __udp_disconnect,
>
> Ping socket still doesn't have sock lock for ->disconnect() but has it for
> ->connect()? I must miss something...
ping is less complex, it is protected by a single ping_table.lock
While UDP has to maintain two hash chains with may locks, and has to
handle rehash(), because autobind happens before full 4-tuple is setup.
^ permalink raw reply
* Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers
From: Jarod Wilson @ 2016-10-21 2:37 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Aaron Conole, David Kershner, Wei Liu, VMware, Inc., netdev,
Haiyang Zhang, linux-kernel, virtualization, Paul Durrant,
Shrikrishna Khare
In-Reply-To: <20161020231559-mutt-send-email-mst@kernel.org>
On Thu, Oct 20, 2016 at 11:23:54PM +0300, Michael S. Tsirkin wrote:
> On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote:
...
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index fad84f3..720809f 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
> > .set_settings = virtnet_set_settings,
> > };
> >
> > -#define MIN_MTU 68
> > -#define MAX_MTU 65535
> > -
> > -static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
> > -{
> > - if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
> > - return -EINVAL;
> > - dev->mtu = new_mtu;
> > - return 0;
> > -}
> > -
> > static const struct net_device_ops virtnet_netdev = {
> > .ndo_open = virtnet_open,
> > .ndo_stop = virtnet_close,
> > @@ -1437,7 +1426,6 @@ static const struct net_device_ops virtnet_netdev = {
> > .ndo_validate_addr = eth_validate_addr,
> > .ndo_set_mac_address = virtnet_set_mac_address,
> > .ndo_set_rx_mode = virtnet_set_rx_mode,
> > - .ndo_change_mtu = virtnet_change_mtu,
> > .ndo_get_stats64 = virtnet_stats,
> > .ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
> > .ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
> > @@ -1748,6 +1736,9 @@ static bool virtnet_validate_features(struct virtio_device *vdev)
> > return true;
> > }
> >
> > +#define MIN_MTU ETH_MIN_MTU
> > +#define MAX_MTU ETH_MAX_MTU
> > +
>
> Can we drop these btw?
Bah. Yeah. Should have just used them directly. I didn't add ETH_MAX_MTU
until after doing the virtio_net changes, so I missed that.
> > static int virtnet_probe(struct virtio_device *vdev)
> > {
> > int i, err;
> > @@ -1821,6 +1812,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> >
> > dev->vlan_features = dev->features;
> >
> > + /* MTU range: 68 - 65535 */
> > + dev->min_mtu = MIN_MTU;
> > + dev->max_mtu = MAX_MTU;
> > +
> > /* Configuration may specify what MAC to use. Otherwise random. */
> > if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
> > virtio_cread_bytes(vdev,
> > @@ -1875,8 +1870,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> > mtu = virtio_cread16(vdev,
> > offsetof(struct virtio_net_config,
> > mtu));
> > - if (virtnet_change_mtu(dev, mtu))
> > + if (mtu < dev->min_mtu || mtu > dev->max_mtu)
>
> In fact the > max_mtu branch does not make sense since a 16 bit
> value can't exceed MAX_MTU.
Hm. mtu is declared as an int, not sure if there's any sort of type
promotion to be worried about (not an area I know much/anything about).
Certainly something that could be looked into as a minor optimization,
though it's only in a probe path and shouldn't hurt anything, so ... meh?
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* [PATCH net-next] net: allow to kill a task which waits net_mutex in copy_new_ns
From: Andrei Vagin @ 2016-10-21 2:45 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W . Biederman, Andrey Vagin,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
net_mutex can be locked for a long time. It may be because many
namespaces are being destroyed or many processes decide to create
a network namespace.
Both these operations are heavy, so it is better to have an ability to
kill a process which is waiting net_mutex.
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
---
net/core/net_namespace.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 989434f..b9243b1 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -379,7 +379,14 @@ struct net *copy_net_ns(unsigned long flags,
get_user_ns(user_ns);
- mutex_lock(&net_mutex);
+ rv = mutex_lock_killable(&net_mutex);
+ if (rv < 0) {
+ net_free(net);
+ dec_net_namespaces(ucounts);
+ put_user_ns(user_ns);
+ return ERR_PTR(rv);
+ }
+
net->ucounts = ucounts;
rv = setup_net(net, user_ns);
if (rv == 0) {
--
2.7.4
^ permalink raw reply related
* [PATCH] net: skip genenerating uevents for network namespaces that are exiting
From: Andrei Vagin @ 2016-10-21 2:46 UTC (permalink / raw)
To: David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W . Biederman, Andrei Vagin,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
No one can see these events, because a network namespace can not be
destroyed, if it has sockets.
My experiments shows that net namespaces are destroyed more 30% faster
with this optimization.
Here is a perf output for destroying network namespaces without this
patch.
- 94.76% 0.02% kworker/u48:1 [kernel.kallsyms] [k] cleanup_net
- 94.74% cleanup_net
- 94.64% ops_exit_list.isra.4
- 41.61% default_device_exit_batch
- 41.47% unregister_netdevice_many
- rollback_registered_many
- 40.36% netdev_unregister_kobject
- 14.55% device_del
+ 13.71% kobject_uevent
- 13.04% netdev_queue_update_kobjects
+ 12.96% kobject_put
- 12.72% net_rx_queue_update_kobjects
kobject_put
- kobject_release
+ 12.69% kobject_uevent
+ 0.80% call_netdevice_notifiers_info
+ 19.57% nfsd_exit_net
+ 11.15% tcp_net_metrics_exit
+ 8.25% rpcsec_gss_exit_net
It's very critical to optimize the exit path for network namespaces,
because they are destroyed under net_mutex and many namespaces can be
destroyed for one iteration.
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
---
net/core/net-sysfs.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 6e4f347..c02515e 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -950,10 +950,13 @@ net_rx_queue_update_kobjects(struct net_device *dev, int old_num, int new_num)
}
while (--i >= new_num) {
+ struct kobject *kobj = &dev->_rx[i].kobj;
+
+ if (!list_empty(&dev_net(dev)->exit_list))
+ kobj->uevent_suppress = 1;
if (dev->sysfs_rx_queue_group)
- sysfs_remove_group(&dev->_rx[i].kobj,
- dev->sysfs_rx_queue_group);
- kobject_put(&dev->_rx[i].kobj);
+ sysfs_remove_group(kobj, dev->sysfs_rx_queue_group);
+ kobject_put(kobj);
}
return error;
@@ -1340,6 +1343,8 @@ netdev_queue_update_kobjects(struct net_device *dev, int old_num, int new_num)
while (--i >= new_num) {
struct netdev_queue *queue = dev->_tx + i;
+ if (!list_empty(&dev_net(dev)->exit_list))
+ queue->kobj.uevent_suppress = 1;
#ifdef CONFIG_BQL
sysfs_remove_group(&queue->kobj, &dql_group);
#endif
@@ -1525,6 +1530,9 @@ void netdev_unregister_kobject(struct net_device *ndev)
{
struct device *dev = &(ndev->dev);
+ if (!list_empty(&dev_net(ndev)->exit_list))
+ dev->kobj.uevent_suppress = 1;
+
kobject_get(&dev->kobj);
remove_queue_kobjects(ndev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: skip genenerating uevents for network namespaces that are exiting
From: Cong Wang @ 2016-10-21 3:10 UTC (permalink / raw)
To: Andrei Vagin
Cc: LKML, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Linux Kernel Network Developers, David S. Miller,
Eric W . Biederman
In-Reply-To: <1477017986-18889-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
On Thu, Oct 20, 2016 at 7:46 PM, Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> wrote:
> No one can see these events, because a network namespace can not be
> destroyed, if it has sockets.
>
Are you sure? kobject_uevent_env() seems sending uevents to all
network namespaces.
^ permalink raw reply
* Re: [PATCH] net: l2tp_eth: fix max_mtu
From: Jarod Wilson @ 2016-10-21 3:19 UTC (permalink / raw)
To: Asbjoern Sloth Toennesen
Cc: David S . Miller, linux-kernel, netdev, R Parameswaran
In-Reply-To: <1476998369.10048.1@x201s.roaming.asbjorn.biz>
On Thu, Oct 20, 2016 at 09:19:29PM +0000, Asbjoern Sloth Toennesen wrote:
> On Thu, 20 Oct 2016 20:08:26 +0000 (UTC), ast@asbjorn.biz wrote:
> > diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
> > index 965f7e3..ba82dcc 100644
> > --- a/net/l2tp/l2tp_eth.c
> > +++ b/net/l2tp/l2tp_eth.c
> > @@ -259,6 +259,7 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
> > session->mtu = dev->mtu - session->hdr_len;
> > dev->mtu = session->mtu;
> > dev->needed_headroom += session->hdr_len;
> > + dev->max_mtu = ETH_MAX_MTU - dev->needed_headroom;
>
> I forgot to add that subtracting dev->needed_headroom doesn't
> give the exact maximum MTU, but one that is a bit too high.
> It could also just be set to ETH_MAX_MTU, to indicate that
> the encapsulation is not included.
>
> Calculations like in R. Parameswaran's patch is needed for the
> exact one.
> https://lkml.org/lkml/2016/10/17/3
Argh. So there are a tiny handful of drivers that call ether_setup, but
have no ndo_change_mtu at all, which thus previously, had no mtu range
checks other than mtu < 0, and now have a range check of 68 to 1500...
Since there was no range at all before, feature-parity here should be
min_mtu = 0, max_mtu = ETH_MAX_MTU. I think I see five other cases that
are in a similar situation:
net/atm/br2684.c
net/bluetooth/bnep/netdev.c
net/dsa/slave.c
net/irda/irda_device.c
net/irda/irlan/irlan_eth.c
Honestly, I think dsa is the only one where it likely actually matters,
but I'll send a patch addressing all of those plus l2tp_eth in half a sec.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH 1/4] kconfig: introduce the "imply" keyword
From: Nicolas Pitre @ 2016-10-21 3:24 UTC (permalink / raw)
To: Edward Cree
Cc: John Stultz, Richard Cochran, Yann E MORIN, Thomas Gleixner,
Josh Triplett, netdev, linux-kbuild, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1610201539100.25105@knanqh.ubzr>
On Thu, 20 Oct 2016, Nicolas Pitre wrote:
> On Thu, 20 Oct 2016, Edward Cree wrote:
>
> > I'm interpreting "imply" as being more a way of saying "if you want FOO you
> > probably want BAZ as well". But maybe that should be yet another new
> > keyword if it's so different from what you want "imply" to be. "suggests",
> > perhaps.
>
> Indeed. That's exactly the keyword that came to my mind after I sent my
> previous reply.
So what about the following on top of my previous series:
From: Nicolas Pitre <nicolas.pitre@linaro.org>
Date: Thu, 20 Oct 2016 23:04:46 -0400
Subject: [PATCH] kconfig: introduce the "suggest" keyword
Similar to "imply" but with no added value restrictions on the target
symbol. Useful for providing a default value to another symbol.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index 5ee0dd3c85..b7f4f0ca1d 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -140,6 +140,12 @@ applicable everywhere (see syntax).
ability to hook into a given subsystem while still being able to
configure that subsystem out and keep those drivers selected.
+- even weaker reverse dependencies: "suggest" <symbol> ["if" <expr>]
+ This is similar to "imply" except that this doesn't add any restrictions
+ on the value the suggested symbol may use. In other words this only
+ provides a default for the specified symbol based on the value for the
+ config entry where this is used.
+
- limiting menu display: "visible if" <expr>
This attribute is only applicable to menu blocks, if the condition is
false, the menu block is not displayed to the user (the symbols
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index a73f762c48..eea3aa3c7a 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -86,6 +86,7 @@ struct symbol {
struct expr_value dir_dep;
struct expr_value rev_dep;
struct expr_value implied;
+ struct expr_value suggested;
};
#define for_all_symbols(i, sym) for (i = 0; i < SYMBOL_HASHSIZE; i++) for (sym = symbol_hash[i]; sym; sym = sym->next) if (sym->type != S_OTHER)
@@ -138,6 +139,7 @@ enum prop_type {
P_CHOICE, /* choice value */
P_SELECT, /* select BAR */
P_IMPLY, /* imply BAR */
+ P_SUGGEST, /* suggest BAR */
P_RANGE, /* range 7..100 (for a symbol) */
P_ENV, /* value from environment variable */
P_SYMBOL, /* where a symbol is defined */
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index e9357931b4..3abc5c85ac 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -255,7 +255,9 @@ static void sym_check_prop(struct symbol *sym)
break;
case P_SELECT:
case P_IMPLY:
- use = prop->type == P_SELECT ? "select" : "imply";
+ case P_SUGGEST:
+ use = prop->type == P_SELECT ? "select" :
+ prop->type == P_IMPLY ? "imply" : "suggest";
sym2 = prop_get_symbol(prop);
if (sym->type != S_BOOLEAN && sym->type != S_TRISTATE)
prop_warn(prop,
@@ -341,6 +343,10 @@ void menu_finalize(struct menu *parent)
struct symbol *es = prop_get_symbol(prop);
es->implied.expr = expr_alloc_or(es->implied.expr,
expr_alloc_and(expr_alloc_symbol(menu->sym), expr_copy(dep)));
+ } else if (prop->type == P_SUGGEST) {
+ struct symbol *es = prop_get_symbol(prop);
+ es->suggested.expr = expr_alloc_or(es->suggested.expr,
+ expr_alloc_and(expr_alloc_symbol(menu->sym), expr_copy(dep)));
}
}
}
@@ -687,6 +693,13 @@ static void get_symbol_str(struct gstr *r, struct symbol *sym,
str_append(r, "\n");
}
+ get_symbol_props_str(r, sym, P_SUGGEST, _(" Suggests: "));
+ if (sym->suggested.expr) {
+ str_append(r, _(" Suggested by: "));
+ expr_gstr_print(sym->suggested.expr, r);
+ str_append(r, "\n");
+ }
+
str_append(r, "\n\n");
}
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 074fb66d9a..235f11e3f9 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -267,6 +267,16 @@ static void sym_calc_visibility(struct symbol *sym)
sym->implied.tri = tri;
sym_set_changed(sym);
}
+ tri = no;
+ if (sym->suggested.expr)
+ tri = expr_calc_value(sym->suggested.expr);
+ tri = EXPR_AND(tri, sym->visible);
+ if (tri == mod && sym_get_type(sym) == S_BOOLEAN)
+ tri = yes;
+ if (sym->suggested.tri != tri) {
+ sym->suggested.tri = tri;
+ sym_set_changed(sym);
+ }
}
/*
@@ -406,6 +416,10 @@ void sym_calc_value(struct symbol *sym)
newval.tri = EXPR_AND(expr_calc_value(prop->expr),
prop->visible.tri);
}
+ if (sym->suggested.tri != no) {
+ sym->flags |= SYMBOL_WRITE;
+ newval.tri = EXPR_OR(newval.tri, sym->suggested.tri);
+ }
if (sym->dir_dep.tri != no &&
sym->implied.tri != no) {
/* implied symbols have implied defaults */
@@ -768,7 +782,9 @@ const char *sym_get_string_default(struct symbol *sym)
if (sym->type == S_BOOLEAN && val == mod)
val = yes;
- /* adjust the default value if this symbol is implied by another */
+ /* adjust the default value if this symbol is suggested/implied */
+ if (val < sym->suggested.tri)
+ val = sym->suggested.tri;
if (val < sym->implied.tri)
val = sym->implied.tri;
@@ -1376,6 +1392,8 @@ const char *prop_get_type_name(enum prop_type type)
return "select";
case P_IMPLY:
return "imply";
+ case P_SUGGEST:
+ return "suggest";
case P_RANGE:
return "range";
case P_SYMBOL:
diff --git a/scripts/kconfig/zconf.gperf b/scripts/kconfig/zconf.gperf
index ead02edec9..0c244a8e95 100644
--- a/scripts/kconfig/zconf.gperf
+++ b/scripts/kconfig/zconf.gperf
@@ -39,6 +39,7 @@ hex, T_TYPE, TF_COMMAND, S_HEX
string, T_TYPE, TF_COMMAND, S_STRING
select, T_SELECT, TF_COMMAND
imply, T_IMPLY, TF_COMMAND
+suggest, T_SUGGEST, TF_COMMAND
range, T_RANGE, TF_COMMAND
visible, T_VISIBLE, TF_COMMAND
option, T_OPTION, TF_COMMAND
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 001305fa08..277415540a 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -31,7 +31,7 @@ struct symbol *symbol_hash[SYMBOL_HASHSIZE];
static struct menu *current_menu, *current_entry;
%}
-%expect 32
+%expect 34
%union
{
@@ -63,6 +63,7 @@ static struct menu *current_menu, *current_entry;
%token <id>T_DEFAULT
%token <id>T_SELECT
%token <id>T_IMPLY
+%token <id>T_SUGGEST
%token <id>T_RANGE
%token <id>T_VISIBLE
%token <id>T_OPTION
@@ -125,7 +126,7 @@ stmt_list:
;
option_name:
- T_DEPENDS | T_PROMPT | T_TYPE | T_SELECT | T_IMPLY | T_OPTIONAL | T_RANGE | T_DEFAULT | T_VISIBLE
+ T_DEPENDS | T_PROMPT | T_TYPE | T_SELECT | T_IMPLY | T_SUGGEST | T_OPTIONAL | T_RANGE | T_DEFAULT | T_VISIBLE
;
common_stmt:
@@ -223,6 +224,12 @@ config_option: T_IMPLY T_WORD if_expr T_EOL
printd(DEBUG_PARSE, "%s:%d:imply\n", zconf_curname(), zconf_lineno());
};
+config_option: T_SUGGEST T_WORD if_expr T_EOL
+{
+ menu_add_symbol(P_SUGGEST, sym_lookup($2, 0), $3);
+ printd(DEBUG_PARSE, "%s:%d:suggest\n", zconf_curname(), zconf_lineno());
+};
+
config_option: T_RANGE symbol symbol if_expr T_EOL
{
menu_add_expr(P_RANGE, expr_alloc_comp(E_RANGE,$2, $3), $4);
@@ -676,6 +683,11 @@ static void print_symbol(FILE *out, struct menu *menu)
expr_fprint(prop->expr, out);
fputc('\n', out);
break;
+ case P_SUGGEST:
+ fputs( " suggest ", out);
+ expr_fprint(prop->expr, out);
+ fputc('\n', out);
+ break;
case P_RANGE:
fputs( " range ", out);
expr_fprint(prop->expr, out);
^ permalink raw reply related
* [PATCH net] net: remove MTU limits on a few ether_setup callers
From: Jarod Wilson @ 2016-10-21 3:25 UTC (permalink / raw)
To: linux-kernel
Cc: Jarod Wilson, netdev, Asbjoern Sloth Toennesen, R Parameswaran
These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
were overlooked for changes to MTU range checking behavior. They
previously had no range checks, so for feature-parity, set their min_mtu
to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500
inherited from the ether_setup() changes. Fine-tuning can come after we get
back to full feature-parity here.
CC: netdev@vger.kernel.org
Reported-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
CC: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
CC: R Parameswaran <parameswaran.r7@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
---
net/atm/br2684.c | 4 +++-
net/bluetooth/bnep/netdev.c | 2 ++
net/dsa/slave.c | 2 ++
net/irda/irlan/irlan_eth.c | 3 ++-
net/l2tp/l2tp_eth.c | 2 ++
5 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index c7d82f4..fca84e1 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -649,7 +649,9 @@ static void br2684_setup_routed(struct net_device *netdev)
netdev->hard_header_len = sizeof(llc_oui_ipv4); /* worst case */
netdev->netdev_ops = &br2684_netdev_ops_routed;
netdev->addr_len = 0;
- netdev->mtu = 1500;
+ netdev->mtu = ETH_DATA_LEN;
+ netdev->min_mtu = 0;
+ netdev->max_mtu = ETH_MAX_MTU;
netdev->type = ARPHRD_PPP;
netdev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
netdev->tx_queue_len = 100;
diff --git a/net/bluetooth/bnep/netdev.c b/net/bluetooth/bnep/netdev.c
index 0f25ddc..2b875ed 100644
--- a/net/bluetooth/bnep/netdev.c
+++ b/net/bluetooth/bnep/netdev.c
@@ -221,6 +221,8 @@ void bnep_net_setup(struct net_device *dev)
dev->addr_len = ETH_ALEN;
ether_setup(dev);
+ dev->min_mtu = 0;
+ dev->max_mtu = ETH_MAX_MTU;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->netdev_ops = &bnep_netdev_ops;
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 68714a5..d0c7bce 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1247,6 +1247,8 @@ int dsa_slave_create(struct dsa_switch *ds, struct device *parent,
slave_dev->priv_flags |= IFF_NO_QUEUE;
slave_dev->netdev_ops = &dsa_slave_netdev_ops;
slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
+ slave_dev->min_mtu = 0;
+ slave_dev->max_mtu = ETH_MAX_MTU;
SET_NETDEV_DEVTYPE(slave_dev, &dsa_type);
netdev_for_each_tx_queue(slave_dev, dsa_slave_set_lockdep_class_one,
diff --git a/net/irda/irlan/irlan_eth.c b/net/irda/irlan/irlan_eth.c
index 8192eae..74d09f9 100644
--- a/net/irda/irlan/irlan_eth.c
+++ b/net/irda/irlan/irlan_eth.c
@@ -66,7 +66,8 @@ static void irlan_eth_setup(struct net_device *dev)
dev->netdev_ops = &irlan_eth_netdev_ops;
dev->destructor = free_netdev;
-
+ dev->min_mtu = 0;
+ dev->max_mtu = ETH_MAX_MTU;
/*
* Lets do all queueing in IrTTP instead of this device driver.
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 965f7e3..e2c6ae0 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -259,6 +259,8 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
session->mtu = dev->mtu - session->hdr_len;
dev->mtu = session->mtu;
dev->needed_headroom += session->hdr_len;
+ dev->min_mtu = 0;
+ dev->max_mtu = ETH_MAX_MTU;
priv = netdev_priv(dev);
priv->dev = dev;
--
2.10.0
^ permalink raw reply related
* Re: [PATCH net-next v2 6/9] net: use core MTU range checking in virt drivers
From: Michael S. Tsirkin @ 2016-10-21 3:36 UTC (permalink / raw)
To: Jarod Wilson
Cc: Aaron Conole, David Kershner, Wei Liu, VMware, Inc., netdev,
Haiyang Zhang, linux-kernel, virtualization, Paul Durrant,
Shrikrishna Khare
In-Reply-To: <20161021023720.GA11396@redhat.com>
On Thu, Oct 20, 2016 at 10:37:20PM -0400, Jarod Wilson wrote:
> On Thu, Oct 20, 2016 at 11:23:54PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote:
> ...
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index fad84f3..720809f 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
> > > .set_settings = virtnet_set_settings,
> > > };
> > >
> > > -#define MIN_MTU 68
> > > -#define MAX_MTU 65535
> > > -
> > > -static int virtnet_change_mtu(struct net_device *dev, int new_mtu)
> > > -{
> > > - if (new_mtu < MIN_MTU || new_mtu > MAX_MTU)
> > > - return -EINVAL;
> > > - dev->mtu = new_mtu;
> > > - return 0;
> > > -}
> > > -
> > > static const struct net_device_ops virtnet_netdev = {
> > > .ndo_open = virtnet_open,
> > > .ndo_stop = virtnet_close,
> > > @@ -1437,7 +1426,6 @@ static const struct net_device_ops virtnet_netdev = {
> > > .ndo_validate_addr = eth_validate_addr,
> > > .ndo_set_mac_address = virtnet_set_mac_address,
> > > .ndo_set_rx_mode = virtnet_set_rx_mode,
> > > - .ndo_change_mtu = virtnet_change_mtu,
> > > .ndo_get_stats64 = virtnet_stats,
> > > .ndo_vlan_rx_add_vid = virtnet_vlan_rx_add_vid,
> > > .ndo_vlan_rx_kill_vid = virtnet_vlan_rx_kill_vid,
> > > @@ -1748,6 +1736,9 @@ static bool virtnet_validate_features(struct virtio_device *vdev)
> > > return true;
> > > }
> > >
> > > +#define MIN_MTU ETH_MIN_MTU
> > > +#define MAX_MTU ETH_MAX_MTU
> > > +
> >
> > Can we drop these btw?
>
> Bah. Yeah. Should have just used them directly. I didn't add ETH_MAX_MTU
> until after doing the virtio_net changes, so I missed that.
>
> > > static int virtnet_probe(struct virtio_device *vdev)
> > > {
> > > int i, err;
> > > @@ -1821,6 +1812,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> > >
> > > dev->vlan_features = dev->features;
> > >
> > > + /* MTU range: 68 - 65535 */
> > > + dev->min_mtu = MIN_MTU;
> > > + dev->max_mtu = MAX_MTU;
> > > +
> > > /* Configuration may specify what MAC to use. Otherwise random. */
> > > if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
> > > virtio_cread_bytes(vdev,
> > > @@ -1875,8 +1870,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > mtu = virtio_cread16(vdev,
> > > offsetof(struct virtio_net_config,
> > > mtu));
> > > - if (virtnet_change_mtu(dev, mtu))
> > > + if (mtu < dev->min_mtu || mtu > dev->max_mtu)
> >
> > In fact the > max_mtu branch does not make sense since a 16 bit
> > value can't exceed MAX_MTU.
>
> Hm. mtu is declared as an int, not sure if there's any sort of type
> promotion to be worried about (not an area I know much/anything about).
Not by design, that's for sure.
> Certainly something that could be looked into as a minor optimization,
> though it's only in a probe path and shouldn't hurt anything, so ... meh?
Right. Aaron said he's working on a patch that essentially does
dev->max_mtu = mtu after validation, so this part will look
a bit silly there.
> --
> Jarod Wilson
> jarod@redhat.com
^ permalink raw reply
* Re: [PATCH net] net: remove MTU limits on a few ether_setup callers
From: Florian Fainelli @ 2016-10-21 3:42 UTC (permalink / raw)
To: Jarod Wilson, linux-kernel
Cc: netdev, Asbjoern Sloth Toennesen, R Parameswaran, Andrew Lunn,
Vivien Didelot
In-Reply-To: <20161021032527.12954-1-jarod@redhat.com>
Le 20/10/2016 à 20:25, Jarod Wilson a écrit :
> These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> were overlooked for changes to MTU range checking behavior. They
> previously had no range checks, so for feature-parity, set their min_mtu
> to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500
> inherited from the ether_setup() changes. Fine-tuning can come after we get
> back to full feature-parity here.
>
> CC: netdev@vger.kernel.org
> Reported-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
> CC: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
> CC: R Parameswaran <parameswaran.r7@gmail.com>
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
> ---
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 68714a5..d0c7bce 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1247,6 +1247,8 @@ int dsa_slave_create(struct dsa_switch *ds, struct device *parent,
> slave_dev->priv_flags |= IFF_NO_QUEUE;
> slave_dev->netdev_ops = &dsa_slave_netdev_ops;
> slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
> + slave_dev->min_mtu = 0;
> + slave_dev->max_mtu = ETH_MAX_MTU;
> SET_NETDEV_DEVTYPE(slave_dev, &dsa_type);
Actually for DSA, a reasonable minimum is probably 68 for the following
reasons: ETH_ZLEN of 60 bytes + FCS (4 bytes) + 2/4/8 bytes of Ethernet
switch tag (which is dependent on the tagging protocol used). Such an
Ethernet interface would submit packets through the conduit interface
which is connected to an Ethernet switches, and those typically discard
packets smaller than 64 bytes +/- their custom tag length.
One driver for sure pads the packets to the appropriate length:
bcmsysport, but I don't know about e1000e or e.g: mv643xx_eth which are
also commonly used for the same purposes.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v12 5/9] openvswitch: add processing of L3 packets
From: Pravin Shelar @ 2016-10-21 4:19 UTC (permalink / raw)
To: Jiri Benc
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <a4590d690c169e0021031405463c8629a6e9ecb8.1476708213.git.jbenc@redhat.com>
On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Support receiving, extracting flow key and sending of L3 packets (packets
> without an Ethernet header).
>
> Note that even after this patch, non-Ethernet interfaces are still not
> allowed to be added to bridges. Similarly, netlink interface for sending and
> receiving L3 packets to/from user space is not in place yet.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> net/openvswitch/datapath.c | 17 ++------
> net/openvswitch/flow.c | 101 ++++++++++++++++++++++++++++++++++-----------
> net/openvswitch/vport.c | 16 +++++++
> 3 files changed, 96 insertions(+), 38 deletions(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 4d67ea856067..c5b719fca8d4 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
...
...
> @@ -609,8 +597,10 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, struct genl_info *info)
>
> err = ovs_flow_key_extract_userspace(net, a[OVS_PACKET_ATTR_KEY],
> packet, &flow->key, log);
> - if (err)
> + if (err) {
> + packet = NULL;
> goto err_flow_free;
> + }
>
Why packet is set to NULL? This would leak skb memory in case of error.
> err = ovs_nla_copy_actions(net, a[OVS_PACKET_ATTR_ACTIONS],
> &flow->key, &acts, log);
...
> diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
> index 96c8c4716603..7aee6e273765 100644
> --- a/net/openvswitch/flow.c
> +++ b/net/openvswitch/flow.c
...
> @@ -721,6 +734,20 @@ int ovs_flow_key_update(struct sk_buff *skb, struct sw_flow_key *key)
> return key_extract(skb, key);
> }
>
> +static u8 key_extract_mac_proto(struct sk_buff *skb)
> +{
> + switch (skb->dev->type) {
> + case ARPHRD_ETHER:
> + return MAC_PROTO_ETHERNET;
> + case ARPHRD_NONE:
> + if (skb->protocol == htons(ETH_P_TEB))
> + return MAC_PROTO_ETHERNET;
> + return MAC_PROTO_NONE;
> + }
> + WARN_ON_ONCE(1);
> + return MAC_PROTO_ETHERNET;
This packet should be dropped.
> +}
> +
> int ovs_flow_key_extract(const struct ip_tunnel_info *tun_info,
> struct sk_buff *skb, struct sw_flow_key *key)
> {
....
> diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
> index dc0e2212edfc..8361b62a47c2 100644
> --- a/net/openvswitch/vport.c
> +++ b/net/openvswitch/vport.c
> @@ -502,6 +502,22 @@ void ovs_vport_send(struct vport *vport, struct sk_buff *skb, u8 mac_proto)
> {
> int mtu = vport->dev->mtu;
>
> + switch (vport->dev->type) {
> + case ARPHRD_NONE:
> + if (mac_proto != MAC_PROTO_NONE) {
> + WARN_ON_ONCE(mac_proto != MAC_PROTO_ETHERNET);
> +
It would be easy to read if you check mac_proto for MAC_PROTO_ETHERNET
and then warn otherwise.
another issue is the packet is not dropped if mac_proto is not
MAC_PROTO_ETHERNET
> + skb_reset_network_header(skb);
> + skb_reset_mac_len(skb);
> + skb->protocol = htons(ETH_P_TEB);
> + }
> + break;
> + case ARPHRD_ETHER:
> + if (mac_proto != MAC_PROTO_ETHERNET)
> + goto drop;
> + break;
> + }
> +
> if (unlikely(packet_length(skb, vport->dev) > mtu &&
> !skb_is_gso(skb))) {
> net_warn_ratelimited("%s: dropped over-mtu packet: %d > %d\n",
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net-next v12 6/9] openvswitch: netlink: support L3 packets
From: Pravin Shelar @ 2016-10-21 4:20 UTC (permalink / raw)
To: Jiri Benc
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <8bb825e9a05a96a352dafddccfc49392f4f0813c.1476708213.git.jbenc@redhat.com>
On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Extend the ovs flow netlink protocol to support L3 packets. Packets without
> OVS_KEY_ATTR_ETHERNET attribute specify L3 packets; for those, the
> OVS_KEY_ATTR_ETHERTYPE attribute is mandatory.
>
> Push/pop vlan actions are only supported for Ethernet packets.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
^ permalink raw reply
* Re: [PATCH net-next v12 7/9] openvswitch: add Ethernet push and pop actions
From: Pravin Shelar @ 2016-10-21 4:22 UTC (permalink / raw)
To: Jiri Benc
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <bf8e49c178a2f8ed9adb02e30470be5163d46296.1476708213.git.jbenc@redhat.com>
On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> It's not allowed to push Ethernet header in front of another Ethernet
> header.
>
> It's not allowed to pop Ethernet header if there's a vlan tag. This
> preserves the invariant that L3 packet never has a vlan tag.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> include/uapi/linux/openvswitch.h | 15 ++++++++++++
> net/openvswitch/actions.c | 49 ++++++++++++++++++++++++++++++++++++++++
> net/openvswitch/flow_netlink.c | 18 +++++++++++++++
> 3 files changed, 82 insertions(+)
>
...
...
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 064cbcb7b0c5..a63572fb878e 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -317,6 +317,47 @@ static int set_eth_addr(struct sk_buff *skb, struct sw_flow_key *flow_key,
> return 0;
> }
>
> +/* pop_eth does not support VLAN packets as this action is never called
> + * for them.
> + */
> +static int pop_eth(struct sk_buff *skb, struct sw_flow_key *key)
> +{
> + skb_pull_rcsum(skb, ETH_HLEN);
> + skb_reset_mac_header(skb);
> + skb->mac_len -= ETH_HLEN;
> +
> + /* safe right before invalidate_flow_key */
> + key->mac_proto = MAC_PROTO_NONE;
> + invalidate_flow_key(key);
> + return 0;
> +}
> +
> +static int push_eth(struct sk_buff *skb, struct sw_flow_key *key,
> + const struct ovs_action_push_eth *ethh)
> +{
> + struct ethhdr *hdr;
> +
> + /* Add the new Ethernet header */
> + if (skb_cow_head(skb, ETH_HLEN) < 0)
> + return -ENOMEM;
> +
> + skb_push(skb, ETH_HLEN);
> + skb_reset_mac_header(skb);
> + skb->mac_len = ETH_HLEN;
> +
The eth pop substracts ETH_HLEN but here the length is set. I think it
should be consistent with respect to eth-pop.
^ permalink raw reply
* Re: [PATCH net-next v12 8/9] openvswitch: allow L3 netdev ports
From: Pravin Shelar @ 2016-10-21 4:22 UTC (permalink / raw)
To: Jiri Benc
Cc: Linux Kernel Network Developers, ovs dev, Lorand Jakab,
Simon Horman
In-Reply-To: <4ed33e7c676bdd876a2cc4b5bcbf92851a5727f7.1476708213.git.jbenc@redhat.com>
On Mon, Oct 17, 2016 at 6:02 AM, Jiri Benc <jbenc@redhat.com> wrote:
> Allow ARPHRD_NONE interfaces to be added to ovs bridge.
>
> Based on previous versions by Lorand Jakab and Simon Horman.
>
> Signed-off-by: Lorand Jakab <lojakab@cisco.com>
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Cong Wang @ 2016-10-21 4:47 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, Linux Kernel Network Developers, Elad Raz,
Richard Guy Briggs
In-Reply-To: <CAM_iQpVFWzUm2BJZUs+-LWpKA8kubuKhzyE01_V69TEsrFnm-Q@mail.gmail.com>
On Thu, Oct 20, 2016 at 4:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> Since you want to test SELinux anyway, please test the attached one.
>
Finally my kernel config is friendly to SELinux, and now there are several
tests fails:
Test Summary Report
-------------------
sysctl/test (Wstat: 0 Tests: 4 Failed: 2)
Failed tests: 1-2
mmap/test (Wstat: 0 Tests: 44 Failed: 2)
Failed tests: 20, 26
overlay/test (Wstat: 65280 Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 121 tests but ran 0.
Files=44, Tests=306, 47 wallclock secs ( 0.23 usr 0.30 sys + 1.00
cusr 7.35 csys = 8.88 CPU)
Result: FAIL
Seems not related to my patch?
And, there is a kernel warning which is totally unrelated to my code:
[ 136.788836] ------------[ cut here ]------------
[ 136.793046] WARNING: CPU: 1 PID: 1345 at fs/locks.c:615
locks_unlink_lock_ctx+0xc7/0xcc
[ 136.799829] CPU: 1 PID: 1345 Comm: test_lease Not tainted 4.8.0+ #271
[ 136.803814] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 136.803814] ffffc900036bfd38 ffffffff8152c08e 0000000000000000
0000000000000000
[ 136.803814] ffffc900036bfd78 ffffffff810841c0 00000267036bfc88
ffff8800db2371e8
[ 136.803814] ffff8800db26f4c0 ffffc900036bfe00 ffffc900036bfe00
ffff8800db239240
[ 136.803814] Call Trace:
[ 136.803814] [<ffffffff8152c08e>] dump_stack+0x67/0x90
[ 136.803814] [<ffffffff810841c0>] __warn+0xbd/0xd8
[ 136.803814] [<ffffffff81084297>] warn_slowpath_null+0x1d/0x1f
[ 136.803814] [<ffffffff8121b9cb>] locks_unlink_lock_ctx+0xc7/0xcc
[ 136.803814] [<ffffffff8121bd9e>] locks_delete_lock_ctx+0x17/0x3a
[ 136.803814] [<ffffffff8121be71>] lease_modify+0xb0/0xb9
[ 136.803814] [<ffffffff8121e868>] locks_remove_file+0x93/0xbd
[ 136.803814] [<ffffffff811d903d>] __fput+0xd0/0x19b
[ 136.803814] [<ffffffff811d913e>] ____fput+0xe/0x10
[ 136.803814] [<ffffffff8109ff86>] task_work_run+0x6c/0x97
[ 136.803814] [<ffffffff8100188a>] prepare_exit_to_usermode+0xb0/0xcc
[ 136.803814] [<ffffffff81001a04>] syscall_return_slowpath+0x15e/0x1c2
[ 136.803814] [<ffffffff81001ad7>] do_syscall_64+0x6f/0x76
[ 136.803814] [<ffffffff81b22424>] entry_SYSCALL64_slow_path+0x25/0x25
[ 138.538370] ---[ end trace 90914a16bd3272b8 ]---
^ permalink raw reply
* Re: [PATCH] net: skip genenerating uevents for network namespaces that are exiting
From: Andrey Vagin @ 2016-10-21 5:25 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Linux Containers,
Eric W . Biederman, LKML, David S. Miller
In-Reply-To: <CAM_iQpVA=W3su_a3OUVSD+19A72TMANnCX4dt9UyLOmVoRuBjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Oct 20, 2016 at 8:10 PM, Cong Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Thu, Oct 20, 2016 at 7:46 PM, Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> wrote:
>> No one can see these events, because a network namespace can not be
>> destroyed, if it has sockets.
>>
>
> Are you sure? kobject_uevent_env() seems sending uevents to all
> network namespaces.
kobj_bcast_filter() checks that a kobject namespace is equal to a
socket namespace.
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] kexec: Export kexec_in_progress to modules
From: Eric W. Biederman @ 2016-10-21 5:26 UTC (permalink / raw)
To: David Miller; +Cc: f.fainelli, netdev, kexec, linux-kernel, sfr
In-Reply-To: <20161020.215410.650162338407203719.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Thu, 20 Oct 2016 18:15:16 -0700
>
>> The bcm_sf2 driver uses kexec_in_progress to know whether it can power
>> down an integrated PHY during shutdown, and can be built as a module.
>> Other modules may be using this in the future, so export it.
>>
>> Fixes: 2399d6143f85 ("net: dsa: bcm_sf2: Prevent GPHY shutdown for kexec'd kernels")
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> Eric, David, Stephen,
>>
>> The offending commit is in David's net.git tree, so it would probably make
>> sense to route the fix through the same tree.
>
> Ok, I'll apply this, thanks Florian.
Florian
I am completely confused why any driver would want to do this.
A reboot is semantically identical to a kexec restart. Always has been.
That is pwoering down your hardware during reboot is not safe.
The only thing that might save you is the hardware reset line being
toggled at which point your hardware is powered up again anyway.
So as far as I can tell you are advocating for a change to support a
driver doing something that is completely pointless. So no let's not
export this symbol. Please fix the driver to do something less
pointless instead.
Eric
^ permalink raw reply
* Re: [PATCH v6 0/6] Add eBPF hooks for cgroups
From: David Ahern @ 2016-10-21 5:32 UTC (permalink / raw)
To: Daniel Mack, htejun-b10kYP2dOMg, daniel-FeC+5ew28dpmcu3hnIyYJQ,
ast-b10kYP2dOMg, Pablo Neira Ayuso
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, kafai-b10kYP2dOMg,
fw-HFFVJYpyMKqzQB+pC5nmwQ, pablo-Cap9r6Oaw4JrovVCs/uTlw,
harald-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
sargun-GaZTRHToo+CzQB+pC5nmwQ, cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1474303441-3745-1-git-send-email-daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
On 9/19/16 10:43 AM, Daniel Mack wrote:
> This is v6 of the patch set to allow eBPF programs for network
> filtering and accounting to be attached to cgroups, so that they apply
> to all sockets of all tasks placed in that cgroup. The logic also
> allows to be extendeded for other cgroup based eBPF logic.
>
>
> Changes from v5:
>
> * The eBPF programs now operate on L3 rather than on L2 of the packets,
> and the egress hooks were moved from __dev_queue_xmit() to
> ip*_output().
>
> * For BPF_PROG_TYPE_CGROUP_SOCKET, disallow direct access to the skb
> through BPF_LD_[ABS|IND] instructions, but hook up the
> bpf_skb_load_bytes() access helper instead. Thanks to Daniel Borkmann
> for the help.
It's been a month since the last response or update to this series. Any progress in resolving the resistance to hook locations?
As I mentioned in Tokyo I need a solution for VRF that allows running processes in a VRF context -- meaning a process inherits a default sk_bound_dev_if for any AF_INET{6} sockets opened. Right now we (Cumulus) are using an l3mdev cgroup, something that Tejun pushed back on earlier this year. I strongly believe that cgroups provide the right infrastructure for this feature and looking at options. I'm sure a few people will chuckle about this, but I do have another solution that leverages this patchset -- a bpf program on a cgroup that sets sk_bound_dev_if. So, what's the likelihood of this patchset making 4.10 (or any other release)?
Thanks,
David
^ permalink raw reply
* [PATCH net-next 1/1] driver: tun: Forbid to set IFF_TUN and IFF_TAP at the same time
From: fgao @ 2016-10-21 6:14 UTC (permalink / raw)
To: davem, jasowang, edumazet, pabeni, netdev; +Cc: gfree.wind, Gao Feng
From: Gao Feng <fgao@ikuai8.com>
Current tun driver permits the ifr_flags is set with IFF_TUN and
IFF_TAP at the same time. But actually there is only IFF_TUN flag
works. And it does not make sense these two flags are set, so add
this check.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
drivers/net/tun.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8093e39..c1f89c1 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1752,6 +1752,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (err < 0)
return err;
+ if ((ifr->ifr_flags & (IFF_TUN | IFF_TAP)) == (IFF_TUN | IFF_TAP)) {
+ return -EINVAL;
+ }
+
/* Set dev type */
if (ifr->ifr_flags & IFF_TUN) {
/* TUN device */
--
1.9.1
^ permalink raw reply related
* network packet kernel rate limit
From: YUAN Linyu @ 2016-10-21 6:17 UTC (permalink / raw)
To: netdev@vger.kernel.org
User space application require linux kernel to do rate limit to some type of Ethernet packet(ARP, ICMP, TCP, for example 1000 packet/s) when system run under Ethernet packet flooding test.
Do you know if kernel already exist a feature to implement this requirement?
Thanks
^ permalink raw reply
* Re: [PATCH] net: cpsw: fix obtaining mac address for am3517
From: Tony Lindgren @ 2016-10-21 6:38 UTC (permalink / raw)
To: Jeroen Hofstee
Cc: netdev, Mugunthan V N, Grygorii Strashko, linux-omap,
linux-kernel
In-Reply-To: <1476993351-23065-1-git-send-email-jhofstee@victronenergy.com>
* Jeroen Hofstee <jhofstee@victronenergy.com> [161020 12:57]:
> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
> id to common file") did not only move the code for an am3517, it also
> added the slave parameter, resulting in a invalid (all zero) mac address
> being returned. So change it back to always read from slave zero, so it
> works again.
Hmm doesn't this now break it for cpsw with two instances? We may need
am3517 specific quirk flag instead?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers
From: Rémi Denis-Courmont @ 2016-10-21 6:52 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, netdev, linux-rdma, Stefan Richter, Faisal Latif,
Cliff Whickman, Robin Holt, Jes Sorensen, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sathya Prakash, Chaitra P B,
Suganath Prabu Subramani, MPT-FusionLinux.pdl, Sebastian Reichel,
Felipe Balbi, Arvid Brodin, Remi Denis-Courmont
In-Reply-To: <20161020175524.6184-8-jarod@redhat.com>
Acked-by: Rémi Denis-Courmont <courmisch@gmail.com>
--
Rémi Denis-Courmont
http://www.remlab.net/CV.pdf
^ 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