* Re: request to queue patches for stable
From: David Miller @ 2012-12-14 20:38 UTC (permalink / raw)
To: caiqian; +Cc: netdev
In-Reply-To: <1907800187.6214689.1355191395335.JavaMail.root@redhat.com>
From: CAI Qian <caiqian@redhat.com>
Date: Mon, 10 Dec 2012 21:03:15 -0500 (EST)
>
>
> ----- Original Message -----
>> From: "David Miller" <davem@davemloft.net>
>> To: caiqian@redhat.com
>> Cc: greg@kroah.com, stable@vger.kernel.org, mbizon@freebox.fr, ja@ssi.bg
>> Sent: Friday, December 7, 2012 11:23:21 AM
>> Subject: Re: [PATCH] ipv4: do not cache looped multicasts
>>
>> From: CAI Qian <caiqian@redhat.com>
>> Date: Thu, 6 Dec 2012 21:56:35 -0500 (EST)
>>
>> > OK, I have a few network patches in the queue that looks applicable
>> > to
>> > the stable as well. I think I'll send them out here too to seek
>> > their
>> > ACKs. David, please let me know if I should stop doing this.
>>
>> Please stop doing this.
>>
>> If you want networking patches to reach stable, first
>> consult:
>>
>> http://patchwork.ozlabs.org/bundle/davem/stable/
>>
>> to see if the patch you want isn't queued up already.
>>
>> If it is not, ask me to queue it up on netdev@vger.kernel.org
>>
>> But note that I like to let networking patches "cook" upstream
>> in Linus's tree for a certain amount of time before I submit
>> them to -stable. There can be up to even a week or two.
> Dave, the following patches looks applicable for the stable
> releases. Please queue them up if you agree.
>
> 0e376bd0b791ac6ac6bdb051492df0769c840848 (for 3.0.x, 3.4.x and 3.6.x)
> e196c0e579902f42cf72414461fb034e5a1ffbf7 (for 3.0.x, 3.4.x and 3.6.x)
> 6e51fe7572590d8d86e93b547fab6693d305fd0d (for 3.0.x, 3.4.x and 3.6.x)
> e1a676424c290b1c8d757e3860170ac7ecd89af4 (for 3.6.x)
> 636174219b52b5a8bc51bc23bbcba97cd30a65e3 (for 3.6.x)
What is the point of my publishing the pending networking -stable
queue if you're not even going to check it? Those last two patches
were already queued up.
Furthermore, it is erroneous to suggest the -ENOMEM SCTP fix without
the memory leak fix that happens in the commit right before it.
I've queued things up appropriately, but I really don't appreciate
how you've handled this at all. It makes a lot more work for me than
necessary.
^ permalink raw reply
* Re: [PATCH] sctp: Change defaults on cookie hmac selection
From: Vlad Yasevich @ 2012-12-14 20:01 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David Miller, Linus Torvalds, linux-sctp
In-Reply-To: <1355511060-27320-1-git-send-email-nhorman@tuxdriver.com>
On 12/14/2012 01:51 PM, Neil Horman wrote:
> Recently I posted commit 3c68198e75 which made selection of the cookie hmac
> algorithm selectable. This is all well and good, but Linus noted that it
> changes the default config:
> http://marc.info/?l=linux-netdev&m=135536629004808&w=2
>
> I've modified the sctp Kconfig file to reflect the recommended way of making
> this choice, using the thermal driver example specified, and brought the
> defaults back into line with the way they were prior to my origional patch
>
> Tested by myself (allbeit fairly quickly). All configuration combinations seems
> to work soundly.
>
Just tried it and like how it looks.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: David Miller <davem@davemloft.net>
> CC: Linus Torvalds <torvalds@linux-foundation.org>
> CC: Vlad Yasevich <vyasevich@gmail.com>
> CC: linux-sctp@vger.kernel.org
> ---
> net/sctp/Kconfig | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
> index a9edd2e..7cd47be 100644
> --- a/net/sctp/Kconfig
> +++ b/net/sctp/Kconfig
> @@ -66,12 +66,31 @@ config SCTP_DBG_OBJCNT
> 'cat /proc/net/sctp/sctp_dbg_objcnt'
>
> If unsure, say N
> +choice
> + prompt "Default SCTP cookie HMAC encoding"
> + default SCTP_COOKIE_HMAC_MD5
> + help
> + This option sets the default sctp cookie hmac algorithm
> + when in doubt select 'md5'
> +
> +config SCTP_DEFAULT_COOKIE_HMAC_MD5
> + bool "Enable optional MD5 hmac cookie generation"
> + help
> + Enable optional MD5 hmac based SCTP cookie generation
> + select SCTP_COOKIE_HMAC_MD5
> +
> +config SCTP_DEFAULT_COOKIE_HMAC_SHA1
> + bool "Enable optional SHA1 hmac cookie generation"
> + help
> + Enable optional SHA1 hmac based SCTP cookie generation
> + select SCTP_COOKIE_HMAC_SHA1
> +
> +endchoice
>
> config SCTP_COOKIE_HMAC_MD5
> bool "Enable optional MD5 hmac cookie generation"
> help
> Enable optional MD5 hmac based SCTP cookie generation
> - default y
> select CRYPTO_HMAC if SCTP_COOKIE_HMAC_MD5
> select CRYPTO_MD5 if SCTP_COOKIE_HMAC_MD5
>
> @@ -79,7 +98,6 @@ config SCTP_COOKIE_HMAC_SHA1
> bool "Enable optional SHA1 hmac cookie generation"
> help
> Enable optional SHA1 hmac based SCTP cookie generation
> - default y
> select CRYPTO_HMAC if SCTP_COOKIE_HMAC_SHA1
> select CRYPTO_SHA1 if SCTP_COOKIE_HMAC_SHA1
>
>
^ permalink raw reply
* [PATCH] sctp: Change defaults on cookie hmac selection
From: Neil Horman @ 2012-12-14 18:51 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David Miller, Linus Torvalds, Vlad Yasevich,
linux-sctp
Recently I posted commit 3c68198e75 which made selection of the cookie hmac
algorithm selectable. This is all well and good, but Linus noted that it
changes the default config:
http://marc.info/?l=linux-netdev&m=135536629004808&w=2
I've modified the sctp Kconfig file to reflect the recommended way of making
this choice, using the thermal driver example specified, and brought the
defaults back into line with the way they were prior to my origional patch
Tested by myself (allbeit fairly quickly). All configuration combinations seems
to work soundly.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: David Miller <davem@davemloft.net>
CC: Linus Torvalds <torvalds@linux-foundation.org>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: linux-sctp@vger.kernel.org
---
net/sctp/Kconfig | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index a9edd2e..7cd47be 100644
--- a/net/sctp/Kconfig
+++ b/net/sctp/Kconfig
@@ -66,12 +66,31 @@ config SCTP_DBG_OBJCNT
'cat /proc/net/sctp/sctp_dbg_objcnt'
If unsure, say N
+choice
+ prompt "Default SCTP cookie HMAC encoding"
+ default SCTP_COOKIE_HMAC_MD5
+ help
+ This option sets the default sctp cookie hmac algorithm
+ when in doubt select 'md5'
+
+config SCTP_DEFAULT_COOKIE_HMAC_MD5
+ bool "Enable optional MD5 hmac cookie generation"
+ help
+ Enable optional MD5 hmac based SCTP cookie generation
+ select SCTP_COOKIE_HMAC_MD5
+
+config SCTP_DEFAULT_COOKIE_HMAC_SHA1
+ bool "Enable optional SHA1 hmac cookie generation"
+ help
+ Enable optional SHA1 hmac based SCTP cookie generation
+ select SCTP_COOKIE_HMAC_SHA1
+
+endchoice
config SCTP_COOKIE_HMAC_MD5
bool "Enable optional MD5 hmac cookie generation"
help
Enable optional MD5 hmac based SCTP cookie generation
- default y
select CRYPTO_HMAC if SCTP_COOKIE_HMAC_MD5
select CRYPTO_MD5 if SCTP_COOKIE_HMAC_MD5
@@ -79,7 +98,6 @@ config SCTP_COOKIE_HMAC_SHA1
bool "Enable optional SHA1 hmac cookie generation"
help
Enable optional SHA1 hmac based SCTP cookie generation
- default y
select CRYPTO_HMAC if SCTP_COOKIE_HMAC_SHA1
select CRYPTO_SHA1 if SCTP_COOKIE_HMAC_SHA1
--
1.7.11.7
^ permalink raw reply related
* Re: cpts: Fix build error caused by include of plat/clock.h
From: David Miller @ 2012-12-14 18:18 UTC (permalink / raw)
To: richardcochran; +Cc: koen, tony, linux-arm-kernel, linux-omap, netdev
In-Reply-To: <20121214110918.GA7982@netboy.at.omicron.at>
From: Richard Cochran <richardcochran@gmail.com>
Date: Fri, 14 Dec 2012 12:09:18 +0100
> On Fri, Dec 14, 2012 at 10:55:56AM +0100, Koen Kooi wrote:
>>
>> Op 14 dec. 2012, om 08:13 heeft Richard Cochran <richardcochran@gmail.com> het volgende geschreven:
>>
>> > On Thu, Dec 13, 2012 at 01:36:41PM -0800, Tony Lindgren wrote:
>> >> Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock)
>> >> mistakenly included plat/clock.h that should not be included by drivers
>> >> even if it exists.
>> >
>> > Hasn't this already been fixed?
>> >
>> > https://patchwork.kernel.org/patch/1810481/
>> > http://www.spinics.net/lists/linux-omap/msg83132.html
>>
>> That patch didn't get applied, so it's still broken in Linus' tree :(
>
> In netdev's patchwork, this was marked "Not Applicable." Dave, can you
> possibly take this patch? If not, who should I ask next?
That's strange, when I look at that patch it's marked "Accepted" ;-)
^ permalink raw reply
* Re: [PATCH v2] inet: Fix kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: christoph.paasch
Cc: gerrit, kuznet, jmorris, yoshfuji, kaber, netdev, dccp,
eric.dumazet
In-Reply-To: <1355494078-7880-1-git-send-email-christoph.paasch@uclouvain.be>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Fri, 14 Dec 2012 15:07:58 +0100
> If in either of the above functions inet_csk_route_child_sock() or
> __inet_inherit_port() fails, the newsk will not be freed:
...
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v3] ipv6: Change skb->data before using icmpv6_notify() to propagate redirect
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: djduanjiong; +Cc: steffen.klassert, netdev
In-Reply-To: <50CB22CF.9010505@gmail.com>
From: Duan Jiong <djduanjiong@gmail.com>
Date: Fri, 14 Dec 2012 20:59:59 +0800
>
> In function ndisc_redirect_rcv(), the skb->data points to the transport
> header, but function icmpv6_notify() need the skb->data points to the
> inner IP packet. So before using icmpv6_notify() to propagate redirect,
> change skb->data to point the inner IP packet that triggered the sending
> of the Redirect, and introduce struct rd_msg to make it easy.
>
> Signed-off-by: Duan Jiong <djduanjiong@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 07/12] stmmac: fix platform driver unregistering
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: khlebnikov; +Cc: linux-kernel, peppe.cavallaro, netdev
In-Reply-To: <20121214110251.11019.9914.stgit@zurg>
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Fri, 14 Dec 2012 15:02:51 +0400
> This patch fixes platform device drivers unregistering and adds proper error
> handing on module loading.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 08/12] bonding: do not cancel works in bond_uninit()
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: khlebnikov; +Cc: linux-kernel, nikolay, netdev, fubar, andy
In-Reply-To: <20121214110255.11019.14759.stgit@zurg>
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Fri, 14 Dec 2012 15:02:55 +0400
> Bonding initializes these works in bond_open() and cancels in bond_close(),
> thus in bond_uninit() they are already canceled but may be unitialized yet.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 10/12] mac802154: fix destructon ordering for ieee802154 devices
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: khlebnikov-GEFAQzZX7r8dnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20121214110303.11019.41133.stgit@zurg>
From: Konstantin Khlebnikov <khlebnikov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Date: Fri, 14 Dec 2012 15:03:03 +0400
> mutex_destroy() must be called before wpan_phy_free(), because it puts the last
> reference and frees memory. Catched as overwritten poison in kmalloc-2048.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Applied.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
^ permalink raw reply
* Re: [PATCH 03/12] mISDN: fix race in timer canceling on module unloading
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: khlebnikov; +Cc: linux-kernel, netdev, isdn
In-Reply-To: <20121214110236.11019.98301.stgit@zurg>
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Fri, 14 Dec 2012 15:02:36 +0400
> Using timer_pending() without additional syncronization is racy,
> del_timer_sync() must be used here for waiting in-flight handler.
> Bug caught with help from "debug-objects" during random insmod/rmmod.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH] tuntap: fix ambigious multiqueue API
From: David Miller @ 2012-12-14 18:16 UTC (permalink / raw)
To: jasowang; +Cc: mst, netdev, linux-kernel, pmoore, mprivozn, wkevils
In-Reply-To: <1355478810-10144-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 14 Dec 2012 17:53:30 +0800
> The current multiqueue API is ambigious which may confuse both user and LSM to
> do things correctly:
>
> - Both TUNSETIFF and TUNSETQUEUE could be used to create the queues of a tuntap
> device.
> - TUNSETQUEUE were used to disable and enable a specific queue of the
> device. But since the state of tuntap were completely removed from the queue,
> it could be used to attach to another device (there's no such kind of
> requirement currently, and it needs new kind of LSM policy.
> - TUNSETQUEUE could be used to attach to a persistent device without any
> queues. This kind of attching bypass the necessary checking during TUNSETIFF
> and may lead unexpected result.
>
> So this patch tries to make a cleaner and simpler API by:
>
> - Only allow TUNSETIFF to create queues.
> - TUNSETQUEUE could be only used to disable and enabled the queues of a device,
> and the state of the tuntap device were not detachd from the queues when it
> was disabled, so TUNSETQUEUE could be only used after TUNSETIFF and with the
> same device.
>
> This is done by introducing a list which keeps track of all queues which were
> disabled. The queue would be moved between this list and tfiles[] array when it
> was enabled/disabled. A pointer of the tun_struct were also introdued to track
> the device it belongs to when it was disabled.
>
> After the change, the isolation between management and application could be done
> through: TUNSETIFF were only called by management software and TUNSETQUEUE were
> only called by application.For LSM/SELinux, the things left is to do proper
> check during tun_set_queue() if needed.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: remove temporary variable for MLDv2 maximum response code computation
From: David Miller @ 2012-12-14 18:15 UTC (permalink / raw)
To: wcang; +Cc: netdev, shemminger
In-Reply-To: <50CAEC97.2090609@sfc.wide.ad.jp>
From: Ang Way Chuang <wcang@sfc.wide.ad.jp>
Date: Fri, 14 Dec 2012 17:08:39 +0800
> As suggested by Stephen Hemminger, this remove the temporary
> variable introduced in commit
> eca2a43bb0d2c6ebd528be6acb30a88435abe307
>
> Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
Applied.
In the future, please provide the commit message header line when
referencing commits by ID, this allows to avoid ambiguity when a
commit exists in multiple trees.
I added it this time for you.
Thanks.
^ permalink raw reply
* Re: [PATCH iproute2 v2] ip: use rtnelink to manage mroute
From: Stephen Hemminger @ 2012-12-14 18:10 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
In-Reply-To: <1355390202-6868-1-git-send-email-nicolas.dichtel@6wind.com>
On Thu, 13 Dec 2012 10:16:42 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> mroute was using /proc/net/ip_mr_[vif|cache] to display mroute entries. Hence,
> only RT_TABLE_DEFAULT was displayed and only IPv4.
> With rtnetlink, it is possible to display all tables for IPv4 and IPv6. The output
> format is kept. Also, like before the patch, statistics are displayed when user specify
> the '-s' argument.
>
> The patch also adds the support of 'ip monitor mroute', which is now possible.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied. I had to clean up some merge conflicts because of applying your
patches out of order. It would help if you would recheck the version
that I just pushed to git.
^ permalink raw reply
* Re: [PATCH iproute2 6/6] ip/link_iptnl: fix indentation
From: Stephen Hemminger @ 2012-12-14 18:02 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev
In-Reply-To: <1355406174-10586-6-git-send-email-nicolas.dichtel@6wind.com>
On Thu, 13 Dec 2012 14:42:54 +0100
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> Use tabs instead of space when possible.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Thanks applied all these.
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Jiri Pirko @ 2012-12-14 17:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Flavio Leitner, John Fastabend, netdev, davem, edumazet,
bhutchings, mirqus, greearb
In-Reply-To: <20121214092343.76356a2c@nehalam.linuxnetplumber.net>
Fri, Dec 14, 2012 at 06:23:43PM CET, shemminger@vyatta.com wrote:
>On Fri, 14 Dec 2012 18:13:45 +0100
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Fri, Dec 14, 2012 at 05:59:18PM CET, shemminger@vyatta.com wrote:
>> >On Fri, 14 Dec 2012 17:35:32 +0100
>> >Jiri Pirko <jiri@resnulli.us> wrote:
>> >
>> >> Fri, Dec 14, 2012 at 05:12:01PM CET, shemminger@vyatta.com wrote:
>> >> >On Fri, 14 Dec 2012 15:41:34 +0100
>> >> >Jiri Pirko <jiri@resnulli.us> wrote:
>> >> >
>> >> >> Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:
>> >> >> >On Thu, 13 Dec 2012 16:17:33 -0200
>> >> >> >Flavio Leitner <fbl@redhat.com> wrote:
>> >> >> >
>> >> >> >> On Thu, 13 Dec 2012 10:09:33 -0800
>> >> >> >> Stephen Hemminger <shemminger@vyatta.com> wrote:
>> >> >> >>
>> >> >> >> > On Thu, 13 Dec 2012 15:54:23 -0200
>> >> >> >> > Flavio Leitner <fbl@redhat.com> wrote:
>> >> >> >> >
>> >> >> >> > > I am saying this because people are used to and there are scripts out
>> >> >> >> > > there using something like:
>> >> >> >> > > # ethtool <iface> | grep 'Link'
>> >> >> >> > > to react an interface failure.
>> >> >> >> >
>> >> >> >> > Then the script is broken. It is asking about hardware state.
>> >> >> >>
>> >> >> >> I was talking about the team master interface, so it makes sense
>> >> >> >> to check its 'hardware' state. Just think on 'bond0' interface
>> >> >> >> with no slaves. It should report Link detected: no.
>> >> >> >>
>> >> >> >> See bond_release(), what happens if bond->slave_cnt == 0, for instance.
>> >> >> >>
>> >> >> >
>> >> >> >I was thinking more that ethtool operation for reporting link on
>> >> >> >the team device should use the proper check rather than just using netif_carrier_ok(),
>> >> >> >the team ethtool operation for get_link should be check IFF_RUNNING flag
>> >> >> >in dev->flags which is controlled by operstate transistions.
>> >> >>
>> >> >> I admit I'm bit confused now.
>> >> >>
>> >> >> For example in bridge code:
>> >> >> in br_add_if() - netif_carrier_ok() is checked and by the value it is
>> >> >> decided if br_stp_enable_port() is called or not. Wouldn't it make more
>> >> >> sense to check IFF_RUNNING (or netif_oper_up()) here?
>> >> >>
>> >> >> The reason I'm asing is that if team device is in bridge, carrier is
>> >> >> always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
>> >> >> userspace, in current code, bridge wouldn't know the difference...
>> >> >>
>> >> >> There are more exmaples of similar usage of netif_carrier_ok() in
>> >> >> bridge (called on ports), bonding (called on slaves), team code (called on ports).
>> >> >
>> >> >Yes the bridge should be fixed to work with user controlled devices.
>> >>
>> >> Okay. I'll try to figure out some patchset over the weekend.
>> >>
>> >> Thanks.
>> >>
>> >
>> >Something like this seems needed.
>> >
>> >--- a/net/bridge/br_if.c 2012-10-25 09:11:15.627272524 -0700
>> >+++ b/net/bridge/br_if.c 2012-12-14 08:58:14.329847361 -0800
>> >@@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
>> > struct net_device *dev = p->dev;
>> > struct net_bridge *br = p->br;
>> >
>> >- if (netif_running(dev) && netif_carrier_ok(dev))
>> >+ if (netif_running(dev) && netif_oper_up(dev))
>> > p->path_cost = port_cost(dev);
>> >
>> > if (!netif_running(br->dev))
>> > return;
>> >
>> > spin_lock_bh(&br->lock);
>> >- if (netif_running(dev) && netif_carrier_ok(dev)) {
>> >+ if (netif_running(dev) && netif_oper_up(dev))
>> > if (p->state == BR_STATE_DISABLED)
>> > br_stp_enable_port(p);
>> > } else {
>> >--- a/net/bridge/br_notify.c 2012-10-25 09:11:15.631272484 -0700
>> >+++ b/net/bridge/br_notify.c 2012-12-14 08:57:36.954222724 -0800
>> >@@ -82,7 +82,7 @@ static int br_device_event(struct notifi
>> > break;
>> >
>> > case NETDEV_UP:
>> >- if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
>> >+ if (netif_running(br->dev) && netif_oper_up(dev)) {
>> > spin_lock_bh(&br->lock);
>> > br_stp_enable_port(p);
>> > spin_unlock_bh(&br->lock);
>>
>>
>> Yes. I have this already in my queue. I just spotted a problem though.
>>
>> Lets say teamd sets operstate of the team device by values IF_OPER_UP
>> and IF_OPER_DORMANT depending on teamd states of ports.
>> What if one would like to use 802.1X supplicant on the same device?
>> That would not be possible.
>>
>> This proves that the layering would not be correct. It look like the
>> carrier userspace set would be the correct thing to do after all...
>>
>> What do you think?
>
>That is tough, you have two applications conflicting over control of
>the same state on the same device.
I do not think so. The thing is, they both do something different. Teamd
should care of the low level link and set that up accordingly.
802.1X supplicant is higher. This implies they should not use the same
interface, ergo IMHO Teamd should be able to set carrier directly.
And that is what is provided by this patchset.
ps: I think that the use of 802.1X supplicant over team device is legit
setup.
>
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Stephen Hemminger @ 2012-12-14 17:23 UTC (permalink / raw)
To: Jiri Pirko
Cc: Flavio Leitner, John Fastabend, netdev, davem, edumazet,
bhutchings, mirqus, greearb
In-Reply-To: <20121214171345.GC1652@minipsycho.brq.redhat.com>
On Fri, 14 Dec 2012 18:13:45 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Dec 14, 2012 at 05:59:18PM CET, shemminger@vyatta.com wrote:
> >On Fri, 14 Dec 2012 17:35:32 +0100
> >Jiri Pirko <jiri@resnulli.us> wrote:
> >
> >> Fri, Dec 14, 2012 at 05:12:01PM CET, shemminger@vyatta.com wrote:
> >> >On Fri, 14 Dec 2012 15:41:34 +0100
> >> >Jiri Pirko <jiri@resnulli.us> wrote:
> >> >
> >> >> Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:
> >> >> >On Thu, 13 Dec 2012 16:17:33 -0200
> >> >> >Flavio Leitner <fbl@redhat.com> wrote:
> >> >> >
> >> >> >> On Thu, 13 Dec 2012 10:09:33 -0800
> >> >> >> Stephen Hemminger <shemminger@vyatta.com> wrote:
> >> >> >>
> >> >> >> > On Thu, 13 Dec 2012 15:54:23 -0200
> >> >> >> > Flavio Leitner <fbl@redhat.com> wrote:
> >> >> >> >
> >> >> >> > > I am saying this because people are used to and there are scripts out
> >> >> >> > > there using something like:
> >> >> >> > > # ethtool <iface> | grep 'Link'
> >> >> >> > > to react an interface failure.
> >> >> >> >
> >> >> >> > Then the script is broken. It is asking about hardware state.
> >> >> >>
> >> >> >> I was talking about the team master interface, so it makes sense
> >> >> >> to check its 'hardware' state. Just think on 'bond0' interface
> >> >> >> with no slaves. It should report Link detected: no.
> >> >> >>
> >> >> >> See bond_release(), what happens if bond->slave_cnt == 0, for instance.
> >> >> >>
> >> >> >
> >> >> >I was thinking more that ethtool operation for reporting link on
> >> >> >the team device should use the proper check rather than just using netif_carrier_ok(),
> >> >> >the team ethtool operation for get_link should be check IFF_RUNNING flag
> >> >> >in dev->flags which is controlled by operstate transistions.
> >> >>
> >> >> I admit I'm bit confused now.
> >> >>
> >> >> For example in bridge code:
> >> >> in br_add_if() - netif_carrier_ok() is checked and by the value it is
> >> >> decided if br_stp_enable_port() is called or not. Wouldn't it make more
> >> >> sense to check IFF_RUNNING (or netif_oper_up()) here?
> >> >>
> >> >> The reason I'm asing is that if team device is in bridge, carrier is
> >> >> always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
> >> >> userspace, in current code, bridge wouldn't know the difference...
> >> >>
> >> >> There are more exmaples of similar usage of netif_carrier_ok() in
> >> >> bridge (called on ports), bonding (called on slaves), team code (called on ports).
> >> >
> >> >Yes the bridge should be fixed to work with user controlled devices.
> >>
> >> Okay. I'll try to figure out some patchset over the weekend.
> >>
> >> Thanks.
> >>
> >
> >Something like this seems needed.
> >
> >--- a/net/bridge/br_if.c 2012-10-25 09:11:15.627272524 -0700
> >+++ b/net/bridge/br_if.c 2012-12-14 08:58:14.329847361 -0800
> >@@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
> > struct net_device *dev = p->dev;
> > struct net_bridge *br = p->br;
> >
> >- if (netif_running(dev) && netif_carrier_ok(dev))
> >+ if (netif_running(dev) && netif_oper_up(dev))
> > p->path_cost = port_cost(dev);
> >
> > if (!netif_running(br->dev))
> > return;
> >
> > spin_lock_bh(&br->lock);
> >- if (netif_running(dev) && netif_carrier_ok(dev)) {
> >+ if (netif_running(dev) && netif_oper_up(dev))
> > if (p->state == BR_STATE_DISABLED)
> > br_stp_enable_port(p);
> > } else {
> >--- a/net/bridge/br_notify.c 2012-10-25 09:11:15.631272484 -0700
> >+++ b/net/bridge/br_notify.c 2012-12-14 08:57:36.954222724 -0800
> >@@ -82,7 +82,7 @@ static int br_device_event(struct notifi
> > break;
> >
> > case NETDEV_UP:
> >- if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
> >+ if (netif_running(br->dev) && netif_oper_up(dev)) {
> > spin_lock_bh(&br->lock);
> > br_stp_enable_port(p);
> > spin_unlock_bh(&br->lock);
>
>
> Yes. I have this already in my queue. I just spotted a problem though.
>
> Lets say teamd sets operstate of the team device by values IF_OPER_UP
> and IF_OPER_DORMANT depending on teamd states of ports.
> What if one would like to use 802.1X supplicant on the same device?
> That would not be possible.
>
> This proves that the layering would not be correct. It look like the
> carrier userspace set would be the correct thing to do after all...
>
> What do you think?
That is tough, you have two applications conflicting over control of
the same state on the same device.
^ permalink raw reply
* Re: [Patch] iproute2: clean up genl/genl.c::usage()
From: Stephen Hemminger @ 2012-12-14 17:15 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
In-Reply-To: <1355465438-20586-1-git-send-email-amwang@redhat.com>
On Fri, 14 Dec 2012 14:10:38 +0800
Cong Wang <amwang@redhat.com> wrote:
> gcc attribute can be used in definition, no need to
> redeclare it.
>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> ---
> diff --git a/genl/genl.c b/genl/genl.c
> index 49b6596..a1e55e0 100644
> --- a/genl/genl.c
> +++ b/genl/genl.c
> @@ -97,9 +97,7 @@ noexist:
> return f;
> }
>
> -static void usage(void) __attribute__((noreturn));
> -
> -static void usage(void)
> +static void __attribute__((noreturn)) usage(void)
> {
> fprintf(stderr, "Usage: genl [ OPTIONS ] OBJECT | help }\n"
> "where OBJECT := { ctrl etc }\n"
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Why bother, all the other older code uses the prototype version,
besides the optimizing of usage() function is ridiculous anyway.
I am just going to remove all the
static void usage(void) __attribute__((noreturn));
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Jiri Pirko @ 2012-12-14 17:13 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Flavio Leitner, John Fastabend, netdev, davem, edumazet,
bhutchings, mirqus, greearb
In-Reply-To: <20121214085918.6a2f3535@nehalam.linuxnetplumber.net>
Fri, Dec 14, 2012 at 05:59:18PM CET, shemminger@vyatta.com wrote:
>On Fri, 14 Dec 2012 17:35:32 +0100
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Fri, Dec 14, 2012 at 05:12:01PM CET, shemminger@vyatta.com wrote:
>> >On Fri, 14 Dec 2012 15:41:34 +0100
>> >Jiri Pirko <jiri@resnulli.us> wrote:
>> >
>> >> Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:
>> >> >On Thu, 13 Dec 2012 16:17:33 -0200
>> >> >Flavio Leitner <fbl@redhat.com> wrote:
>> >> >
>> >> >> On Thu, 13 Dec 2012 10:09:33 -0800
>> >> >> Stephen Hemminger <shemminger@vyatta.com> wrote:
>> >> >>
>> >> >> > On Thu, 13 Dec 2012 15:54:23 -0200
>> >> >> > Flavio Leitner <fbl@redhat.com> wrote:
>> >> >> >
>> >> >> > > I am saying this because people are used to and there are scripts out
>> >> >> > > there using something like:
>> >> >> > > # ethtool <iface> | grep 'Link'
>> >> >> > > to react an interface failure.
>> >> >> >
>> >> >> > Then the script is broken. It is asking about hardware state.
>> >> >>
>> >> >> I was talking about the team master interface, so it makes sense
>> >> >> to check its 'hardware' state. Just think on 'bond0' interface
>> >> >> with no slaves. It should report Link detected: no.
>> >> >>
>> >> >> See bond_release(), what happens if bond->slave_cnt == 0, for instance.
>> >> >>
>> >> >
>> >> >I was thinking more that ethtool operation for reporting link on
>> >> >the team device should use the proper check rather than just using netif_carrier_ok(),
>> >> >the team ethtool operation for get_link should be check IFF_RUNNING flag
>> >> >in dev->flags which is controlled by operstate transistions.
>> >>
>> >> I admit I'm bit confused now.
>> >>
>> >> For example in bridge code:
>> >> in br_add_if() - netif_carrier_ok() is checked and by the value it is
>> >> decided if br_stp_enable_port() is called or not. Wouldn't it make more
>> >> sense to check IFF_RUNNING (or netif_oper_up()) here?
>> >>
>> >> The reason I'm asing is that if team device is in bridge, carrier is
>> >> always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
>> >> userspace, in current code, bridge wouldn't know the difference...
>> >>
>> >> There are more exmaples of similar usage of netif_carrier_ok() in
>> >> bridge (called on ports), bonding (called on slaves), team code (called on ports).
>> >
>> >Yes the bridge should be fixed to work with user controlled devices.
>>
>> Okay. I'll try to figure out some patchset over the weekend.
>>
>> Thanks.
>>
>
>Something like this seems needed.
>
>--- a/net/bridge/br_if.c 2012-10-25 09:11:15.627272524 -0700
>+++ b/net/bridge/br_if.c 2012-12-14 08:58:14.329847361 -0800
>@@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
> struct net_device *dev = p->dev;
> struct net_bridge *br = p->br;
>
>- if (netif_running(dev) && netif_carrier_ok(dev))
>+ if (netif_running(dev) && netif_oper_up(dev))
> p->path_cost = port_cost(dev);
>
> if (!netif_running(br->dev))
> return;
>
> spin_lock_bh(&br->lock);
>- if (netif_running(dev) && netif_carrier_ok(dev)) {
>+ if (netif_running(dev) && netif_oper_up(dev))
> if (p->state == BR_STATE_DISABLED)
> br_stp_enable_port(p);
> } else {
>--- a/net/bridge/br_notify.c 2012-10-25 09:11:15.631272484 -0700
>+++ b/net/bridge/br_notify.c 2012-12-14 08:57:36.954222724 -0800
>@@ -82,7 +82,7 @@ static int br_device_event(struct notifi
> break;
>
> case NETDEV_UP:
>- if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
>+ if (netif_running(br->dev) && netif_oper_up(dev)) {
> spin_lock_bh(&br->lock);
> br_stp_enable_port(p);
> spin_unlock_bh(&br->lock);
Yes. I have this already in my queue. I just spotted a problem though.
Lets say teamd sets operstate of the team device by values IF_OPER_UP
and IF_OPER_DORMANT depending on teamd states of ports.
What if one would like to use 802.1X supplicant on the same device?
That would not be possible.
This proves that the layering would not be correct. It look like the
carrier userspace set would be the correct thing to do after all...
What do you think?
Jiri
^ permalink raw reply
* Re: [PATCH] iproute2: update usage info of bridge monitor
From: Stephen Hemminger @ 2012-12-14 17:11 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, bridge
In-Reply-To: <1355464772-17712-1-git-send-email-amwang@redhat.com>
On Fri, 14 Dec 2012 13:59:32 +0800
Cong Wang <amwang@redhat.com> wrote:
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> ---
> diff --git a/bridge/monitor.c b/bridge/monitor.c
> index 44e14d8..29bb931 100644
> --- a/bridge/monitor.c
> +++ b/bridge/monitor.c
> @@ -31,7 +31,7 @@ int prefix_banner;
>
> static void usage(void)
> {
> - fprintf(stderr, "Usage: bridge monitor\n");
> + fprintf(stderr, "Usage: bridge monitor [file | link | fdb | mdb | all]\n");
> exit(-1);
> }
>
Applied.
^ permalink raw reply
* Re: [PATCH] add a `make dist` helper
From: Stephen Hemminger @ 2012-12-14 17:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Mike Frysinger, netdev
In-Reply-To: <drbl5w8utpw8p960mxvy37j1.1355469370120@email.android.com>
On Thu, 13 Dec 2012 23:16:10 -0800
Stephen Hemminger <stephen.hemminger@vyatta.com> wrote:
>
> I appreciate the effort but there are a number of more steps to doing a release and I need to script them all together.
The tarball's have been rebased, and I built a iproute2-release script for next time.
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Stephen Hemminger @ 2012-12-14 16:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: Flavio Leitner, John Fastabend, netdev, davem, edumazet,
bhutchings, mirqus, greearb
In-Reply-To: <20121214163532.GB1652@minipsycho.brq.redhat.com>
On Fri, 14 Dec 2012 17:35:32 +0100
Jiri Pirko <jiri@resnulli.us> wrote:
> Fri, Dec 14, 2012 at 05:12:01PM CET, shemminger@vyatta.com wrote:
> >On Fri, 14 Dec 2012 15:41:34 +0100
> >Jiri Pirko <jiri@resnulli.us> wrote:
> >
> >> Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:
> >> >On Thu, 13 Dec 2012 16:17:33 -0200
> >> >Flavio Leitner <fbl@redhat.com> wrote:
> >> >
> >> >> On Thu, 13 Dec 2012 10:09:33 -0800
> >> >> Stephen Hemminger <shemminger@vyatta.com> wrote:
> >> >>
> >> >> > On Thu, 13 Dec 2012 15:54:23 -0200
> >> >> > Flavio Leitner <fbl@redhat.com> wrote:
> >> >> >
> >> >> > > I am saying this because people are used to and there are scripts out
> >> >> > > there using something like:
> >> >> > > # ethtool <iface> | grep 'Link'
> >> >> > > to react an interface failure.
> >> >> >
> >> >> > Then the script is broken. It is asking about hardware state.
> >> >>
> >> >> I was talking about the team master interface, so it makes sense
> >> >> to check its 'hardware' state. Just think on 'bond0' interface
> >> >> with no slaves. It should report Link detected: no.
> >> >>
> >> >> See bond_release(), what happens if bond->slave_cnt == 0, for instance.
> >> >>
> >> >
> >> >I was thinking more that ethtool operation for reporting link on
> >> >the team device should use the proper check rather than just using netif_carrier_ok(),
> >> >the team ethtool operation for get_link should be check IFF_RUNNING flag
> >> >in dev->flags which is controlled by operstate transistions.
> >>
> >> I admit I'm bit confused now.
> >>
> >> For example in bridge code:
> >> in br_add_if() - netif_carrier_ok() is checked and by the value it is
> >> decided if br_stp_enable_port() is called or not. Wouldn't it make more
> >> sense to check IFF_RUNNING (or netif_oper_up()) here?
> >>
> >> The reason I'm asing is that if team device is in bridge, carrier is
> >> always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
> >> userspace, in current code, bridge wouldn't know the difference...
> >>
> >> There are more exmaples of similar usage of netif_carrier_ok() in
> >> bridge (called on ports), bonding (called on slaves), team code (called on ports).
> >
> >Yes the bridge should be fixed to work with user controlled devices.
>
> Okay. I'll try to figure out some patchset over the weekend.
>
> Thanks.
>
Something like this seems needed.
--- a/net/bridge/br_if.c 2012-10-25 09:11:15.627272524 -0700
+++ b/net/bridge/br_if.c 2012-12-14 08:58:14.329847361 -0800
@@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
struct net_device *dev = p->dev;
struct net_bridge *br = p->br;
- if (netif_running(dev) && netif_carrier_ok(dev))
+ if (netif_running(dev) && netif_oper_up(dev))
p->path_cost = port_cost(dev);
if (!netif_running(br->dev))
return;
spin_lock_bh(&br->lock);
- if (netif_running(dev) && netif_carrier_ok(dev)) {
+ if (netif_running(dev) && netif_oper_up(dev))
if (p->state == BR_STATE_DISABLED)
br_stp_enable_port(p);
} else {
--- a/net/bridge/br_notify.c 2012-10-25 09:11:15.631272484 -0700
+++ b/net/bridge/br_notify.c 2012-12-14 08:57:36.954222724 -0800
@@ -82,7 +82,7 @@ static int br_device_event(struct notifi
break;
case NETDEV_UP:
- if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
+ if (netif_running(br->dev) && netif_oper_up(dev)) {
spin_lock_bh(&br->lock);
br_stp_enable_port(p);
spin_unlock_bh(&br->lock);
^ permalink raw reply
* Re: [PATCH net] sctp: jsctp_sf_eat_sack: fix kernel NULL ptr dereference
From: Daniel Borkmann @ 2012-12-14 16:57 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: David Miller, netdev
In-Reply-To: <50CB41F2.7040403@gmail.com>
On 12/14/2012 04:12 PM, Vlad Yasevich wrote:
> On 12/14/2012 09:27 AM, Daniel Borkmann wrote:
>> During debugging a sctp problem, I hit a kernel NULL pointer
>> dereference in the jprobes callback jsctp_sf_eat_sack(). This
>> small patch fixes the panic.
>>
>> Cc: Vlad Yasevich <vyasevich@gmail.com>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> ---
>> net/sctp/probe.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/sctp/probe.c b/net/sctp/probe.c
>> index bc6cd75..0a4e9d6 100644
>> --- a/net/sctp/probe.c
>> +++ b/net/sctp/probe.c
>> @@ -134,7 +134,7 @@ sctp_disposition_t jsctp_sf_eat_sack(const struct sctp_endpoint *ep,
>>
>> sp = asoc->peer.primary_path;
>>
>> - if ((full || sp->cwnd != lcwnd) &&
>> + if (sp && (full || sp->cwnd != lcwnd) &&
>> (!port || asoc->peer.port == port ||
>> ep->base.bind_addr.port == port)) {
>> lcwnd = sp->cwnd;
>
> Sorry, but this patch isn't making much sense. @sp points to the primary path of the association and that can not be null if we receiving
> SACKs on this association.
>
> sctp_sf_eat_sack_6_2(), which we are probing, is only called while the association is valid and all the transports still exist. It is also called under lock, so the transports can not go away while processing of the SACK. So unless there is some kind of jprobe issue, the pointer
> you are looking at should always be valid.
Okay, I'll dig a bit deeper into that over the weekend.
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Vlad Yasevich @ 2012-12-14 16:50 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Stephen Hemminger, David Miller, or.gerlitz, netdev, mst,
john.r.fastabend
In-Reply-To: <50CA5D39.5060003@mojatatu.com>
On 12/13/2012 05:56 PM, Jamal Hadi Salim wrote:
> On 12-12-13 05:37 PM, Stephen Hemminger wrote:
>
>>
>> You can, run any action before it hits the bridge.
>
> I think you and I have had this discussion before ;->
> It works just fine on ingress.
>
>
> #Add ingress qdisc on br0
> tc qdisc add dev br0 ingress
> #Add a filter to accept all and count
> tc filter add dev br0 parent ffff: protocol ip prio 6 u32 match ip dst
> 0/0 flowid 1:16 action ok
> #show the stats
> root@jhs12:~# tc -s filter show parent ffff: dev br0
> filter protocol ip pref 6 u32
> filter protocol ip pref 6 u32 fh 800: ht divisor 1
> filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid 1:16
> match 00000000/00000000 at 16
> action order 1: gact action pass
> random type none pass val 0
> index 2 ref 1 bind 1 installed 269 sec used 74 sec
> Action statistics:
> Sent 1210 bytes 15 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> ------
>
> Look at those packets ...
Interesting. But, but how complex would be be to configure a vlan
filter for say 10 different vlans, each one of them only permitted
to be forwarded to their respective VM. Oh, and Vlan tags should
be stripped when they are being forwarded.
config:
+- eth0
|
br0-+- vnet0 (vlan10) - VM1
|
+- vnet1 (vlan20) - VM2
|
+- vnet3 (vlan30) - VM3
... etc...
-vlad
>
> cheers,
> jamal
>
> cheers,
> jamal
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH net-next 0/5] Ease netns management for userland
From: Eric W. Biederman @ 2012-12-14 16:50 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, davem, aatteka
In-Reply-To: <50CB5047.8060804@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 13/12/2012 20:08, Eric W. Biederman a écrit :
>> No. The difficulty monitoring which network namespaces are being used
>> is an unintended side effect.
> Why is netlink a bad idea? Having a way to know all existing netns is a start
> point to monitor netns, isn't it?
In the same way that having a neighbour table that contains all existing
ip address to mac addresses mappings is a starting point to monitor all
existing hosts.
All does not scale.
All removes a lot of perfectly valid use cases like checkpoint-restart,
and nesting containers.
All as different from what is already implemented requires implementing
yet another namespace to put the names of all into it. We have enough
namespaces now thank you very much.
An unfiltered global list is about as interesting to use as putting
all files in /. Sure you know which directory you put your file in but
which file is it?
What has already been implemented should be roughly as good for
monitoring as what is available with lsof.
And of course there is the fact that a global list of anything that is
the same from every perspective violates the principle of relativity,
and is in contradiction with the phsical reality in which we exist.
So there is no way that having a global all inclusive list of network
namespaces makes the least lick of sense and I really don't want to
think about it.
Eric
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Jiri Pirko @ 2012-12-14 16:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Flavio Leitner, John Fastabend, netdev, davem, edumazet,
bhutchings, mirqus, greearb
In-Reply-To: <20121214081201.1205b613@nehalam.linuxnetplumber.net>
Fri, Dec 14, 2012 at 05:12:01PM CET, shemminger@vyatta.com wrote:
>On Fri, 14 Dec 2012 15:41:34 +0100
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Thu, Dec 13, 2012 at 07:20:51PM CET, shemminger@vyatta.com wrote:
>> >On Thu, 13 Dec 2012 16:17:33 -0200
>> >Flavio Leitner <fbl@redhat.com> wrote:
>> >
>> >> On Thu, 13 Dec 2012 10:09:33 -0800
>> >> Stephen Hemminger <shemminger@vyatta.com> wrote:
>> >>
>> >> > On Thu, 13 Dec 2012 15:54:23 -0200
>> >> > Flavio Leitner <fbl@redhat.com> wrote:
>> >> >
>> >> > > I am saying this because people are used to and there are scripts out
>> >> > > there using something like:
>> >> > > # ethtool <iface> | grep 'Link'
>> >> > > to react an interface failure.
>> >> >
>> >> > Then the script is broken. It is asking about hardware state.
>> >>
>> >> I was talking about the team master interface, so it makes sense
>> >> to check its 'hardware' state. Just think on 'bond0' interface
>> >> with no slaves. It should report Link detected: no.
>> >>
>> >> See bond_release(), what happens if bond->slave_cnt == 0, for instance.
>> >>
>> >
>> >I was thinking more that ethtool operation for reporting link on
>> >the team device should use the proper check rather than just using netif_carrier_ok(),
>> >the team ethtool operation for get_link should be check IFF_RUNNING flag
>> >in dev->flags which is controlled by operstate transistions.
>>
>> I admit I'm bit confused now.
>>
>> For example in bridge code:
>> in br_add_if() - netif_carrier_ok() is checked and by the value it is
>> decided if br_stp_enable_port() is called or not. Wouldn't it make more
>> sense to check IFF_RUNNING (or netif_oper_up()) here?
>>
>> The reason I'm asing is that if team device is in bridge, carrier is
>> always ON and I'm fiddling with IF_OPER_UP and IF_OPER_DORMANT from
>> userspace, in current code, bridge wouldn't know the difference...
>>
>> There are more exmaples of similar usage of netif_carrier_ok() in
>> bridge (called on ports), bonding (called on slaves), team code (called on ports).
>
>Yes the bridge should be fixed to work with user controlled devices.
Okay. I'll try to figure out some patchset over the weekend.
Thanks.
^ 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