* Re: [PATCH net-next v5 0/4] netns: allow to identify peer netns
From: David Miller @ 2015-01-19 19:16 UTC (permalink / raw)
To: nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
luto-kltTT9wpgjJwATOyAt5JVQ, cwang-xCSkyg8dI+0RB7SZvlqPiA
In-Reply-To: <1421331078-21622-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
From: Nicolas Dichtel <nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
Date: Thu, 15 Jan 2015 15:11:14 +0100
> The goal of this serie is to be able to multicast netlink messages with an
> attribute that identify a peer netns.
> This is needed by the userland to interpret some information contained in
> netlink messages (like IFLA_LINK value, but also some other attributes in case
> of x-netns netdevice (see also
> http://thread.gmane.org/gmane.linux.network/315933/focus=316064 and
> http://thread.gmane.org/gmane.linux.kernel.containers/28301/focus=4239)).
>
> Ids of peer netns can be set by userland via a new rtnl cmd RTM_NEWNSID. When
> the kernel needs an id for a peer (for example when advertising a new x-netns
> interface via netlink), if the user didn't allocate an id, one will be
> automatically allocated.
> These ids are stored per netns and are local (ie only valid in the netns where
> they are set). To avoid allocating an int for each peer netns, I use
> idr_for_each() to retrieve the id of a peer netns. Note that it will be possible
> to add a table (struct net -> id) later to optimize this lookup if needed.
>
> Patch 1/4 introduces the rtnetlink API mechanism to set and get these ids.
> Patch 2/4 and 3/4 implements an example of how to use these ids when advertising
> information about a x-netns interface.
> And patch 4/4 shows that the netlink messages can be symetric between a GET and
> a SET.
...
Seires applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/5] bonding: fix incorrect lacp mux state when agg not active
From: Nikolay Aleksandrov @ 2015-01-19 19:26 UTC (permalink / raw)
To: Jonathan Toppins, netdev; +Cc: Andy Gospodarek, Wilson Kok
In-Reply-To: <1421423848-414-4-git-send-email-jtoppins@cumulusnetworks.com>
On 01/16/2015 04:57 PM, Jonathan Toppins wrote:
> From: Wilson Kok <wkok@cumulusnetworks.com>
>
> This patch attempts to fix the following problems when an actor or
> partner's aggregator is not active:
> 1. a slave's lacp port state is marked as AD_STATE_SYNCHRONIZATION
> even if it is attached to an inactive aggregator. LACP advertises
> this state to the partner, making the partner think he can move
> into COLLECTING_DISTRIBUTING state even though this link will not
> pass traffic on the local side
>
> 2. a slave goes into COLLECTING_DISTRIBUTING state without checking
> if the aggregator is actually active
>
> 3. when in COLLECTING_DISTRIBUTING state, the partner parameters may
> change, e.g. the partner_oper_port_state.SYNCHRONIZATION. The
> local mux machine is not reacting to the change and continue to
> keep the slave and bond up
>
> 4. When bond slave leaves an inactive aggregator and joins an active
> aggregator, the actor oper port state need to update to SYNC state.
>
> Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
> Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
> Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
> ---
> drivers/net/bonding/bond_3ad.c | 44 ++++++++++++++++++++++++++++++++--------
> 1 file changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index e9b706f..52a8772 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -471,10 +471,13 @@ static void __record_pdu(struct lacpdu *lacpdu, struct port *port)
> * and the port is matched
> */
> if ((port->sm_vars & AD_PORT_MATCHED)
> - && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION))
> + && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION)) {
In net/ it's preferred to have the logical operators at the end of the
previous line. It'd be nice if we start fixing these in bond_3ad.c since
they're being touched by the patch anyhow.
> partner->port_state |= AD_STATE_SYNCHRONIZATION;
> - else
> + pr_debug("%s partner sync=1\n", port->slave->dev->name);
> + } else {
> partner->port_state &= ~AD_STATE_SYNCHRONIZATION;
> + pr_debug("%s partner sync=0\n", port->slave->dev->name);
> + }
> }
> }
>
> @@ -729,6 +732,8 @@ static inline void __update_lacpdu_from_port(struct port *port)
> lacpdu->actor_port_priority = htons(port->actor_port_priority);
> lacpdu->actor_port = htons(port->actor_port_number);
> lacpdu->actor_state = port->actor_oper_port_state;
> + pr_debug("update lacpdu: %s, actor port state %x\n",
> + port->slave->dev->name, port->actor_oper_port_state);
>
> /* lacpdu->reserved_3_1 initialized
> * lacpdu->tlv_type_partner_info initialized
> @@ -901,7 +906,9 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> if ((port->sm_vars & AD_PORT_SELECTED) &&
> (port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION) &&
> !__check_agg_selection_timer(port)) {
> - port->sm_mux_state = AD_MUX_COLLECTING_DISTRIBUTING;
> + if (port->aggregator->is_active)
> + port->sm_mux_state =
> + AD_MUX_COLLECTING_DISTRIBUTING;
> } else if (!(port->sm_vars & AD_PORT_SELECTED) ||
> (port->sm_vars & AD_PORT_STANDBY)) {
> /* if UNSELECTED or STANDBY */
> @@ -913,12 +920,18 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> */
> __set_agg_ports_ready(port->aggregator, __agg_ports_are_ready(port->aggregator));
> port->sm_mux_state = AD_MUX_DETACHED;
> + } else if (port->aggregator->is_active) {
> + port->actor_oper_port_state |=
> + AD_STATE_SYNCHRONIZATION;
> }
> break;
> case AD_MUX_COLLECTING_DISTRIBUTING:
> if (!(port->sm_vars & AD_PORT_SELECTED) ||
> (port->sm_vars & AD_PORT_STANDBY) ||
> - !(port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION)) {
> + !(port->partner_oper.port_state &
> + AD_STATE_SYNCHRONIZATION) ||
> + !(port->actor_oper_port_state &
> + AD_STATE_SYNCHRONIZATION)) {
IMO this one looks a bit confusing when broken up like that.
> port->sm_mux_state = AD_MUX_ATTACHED;
> } else {
> /* if port state hasn't changed make
> @@ -940,8 +953,10 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
>
> /* check if the state machine was changed */
> if (port->sm_mux_state != last_state) {
> - pr_debug("Mux Machine: Port=%d, Last State=%d, Curr State=%d\n",
> - port->actor_port_number, last_state,
> + pr_debug("Mux Machine: Port=%d (%s), Last State=%d, Curr State=%d\n",
> + port->actor_port_number,
> + port->slave->dev->name,
> + last_state,
> port->sm_mux_state);
> switch (port->sm_mux_state) {
> case AD_MUX_DETACHED:
> @@ -956,7 +971,12 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> port->sm_mux_timer_counter = __ad_timer_to_ticks(AD_WAIT_WHILE_TIMER, 0);
> break;
> case AD_MUX_ATTACHED:
> - port->actor_oper_port_state |= AD_STATE_SYNCHRONIZATION;
> + if (port->aggregator->is_active)
> + port->actor_oper_port_state |=
> + AD_STATE_SYNCHRONIZATION;
> + else
> + port->actor_oper_port_state &=
> + ~AD_STATE_SYNCHRONIZATION;
> port->actor_oper_port_state &= ~AD_STATE_COLLECTING;
> port->actor_oper_port_state &= ~AD_STATE_DISTRIBUTING;
> ad_disable_collecting_distributing(port,
> @@ -966,6 +986,7 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> case AD_MUX_COLLECTING_DISTRIBUTING:
> port->actor_oper_port_state |= AD_STATE_COLLECTING;
> port->actor_oper_port_state |= AD_STATE_DISTRIBUTING;
> + port->actor_oper_port_state |= AD_STATE_SYNCHRONIZATION;
> ad_enable_collecting_distributing(port,
> update_slave_arr);
> port->ntt = true;
> @@ -1047,8 +1068,10 @@ static void ad_rx_machine(struct lacpdu *lacpdu, struct port *port)
>
> /* check if the State machine was changed or new lacpdu arrived */
> if ((port->sm_rx_state != last_state) || (lacpdu)) {
> - pr_debug("Rx Machine: Port=%d, Last State=%d, Curr State=%d\n",
> - port->actor_port_number, last_state,
> + pr_debug("Rx Machine: Port=%d (%s), Last State=%d, Curr State=%d\n",
> + port->actor_port_number,
> + port->slave->dev->name,
> + last_state,
> port->sm_rx_state);
> switch (port->sm_rx_state) {
> case AD_RX_INITIALIZE:
> @@ -1397,6 +1420,9 @@ static void ad_port_selection_logic(struct port *port, bool *update_slave_arr)
>
> aggregator = __get_first_agg(port);
> ad_agg_selection_logic(aggregator, update_slave_arr);
> +
> + if (!port->aggregator->is_active)
> + port->actor_oper_port_state &= ~AD_STATE_SYNCHRONIZATION;
> }
>
> /* Decide if "agg" is a better choice for the new active aggregator that
>
^ permalink raw reply
* Re: [PATCH net-next 1/5] bonding: keep bond interface carrier off until at least one active member
From: Nikolay Aleksandrov @ 2015-01-19 19:27 UTC (permalink / raw)
To: Jonathan Toppins, netdev; +Cc: Scott Feldman, Andy Gospodarek
In-Reply-To: <1421423848-414-2-git-send-email-jtoppins@cumulusnetworks.com>
On 01/16/2015 04:57 PM, Jonathan Toppins wrote:
> From: Scott Feldman <sfeldma@cumulusnetworks.com>
>
> Bonding driver parameter min_links is now used to signal upper-level
> protocols of bond status. The way it works is if the total number of
> active members in slaves drops below min_links, the bond link carrier
> will go down, signaling upper levels that bond is inactive. When active
> members returns to >= min_links, bond link carrier will go up (RUNNING),
> and protocols can resume. When bond is carrier down, member ports are
> in stp fwd state blocked (rather than normal disabled state), so
> low-level ctrl protocols (LACP) can still get in and be processed by
> bonding driver.
>
> LACP will still do it's job while bond is carrier off, and if bond members
> become active, bond carrier will be turned back on, signaling higher-level
> protocols that bond is viable.
>
> Suggested setting of min_links is 1, rather than the default of zero.
> Using min_links=1 says that at least 1 slave must be active within bond
> for bond to be carrier on.
>
> Finally, when min_links bonding option is changed update carrier status.
>
> Cc: Scott Feldman <sfeldma@gmail.com>
> Cc: Andy Gospodarek <gospo@cumulusnetworks.com>
> Signed-off-by: Jonathan Toppins <jtoppins@cumulusnetworks.com>
> ---
> drivers/net/bonding/bond_3ad.c | 18 ++++++++++++++----
> drivers/net/bonding/bond_main.c | 2 +-
> drivers/net/bonding/bond_options.c | 1 +
> include/net/bonding.h | 1 +
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index 8baa87d..e9b706f 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -189,6 +189,7 @@ static inline int __agg_has_partner(struct aggregator *agg)
> static inline void __disable_port(struct port *port)
> {
> bond_set_slave_inactive_flags(port->slave, BOND_SLAVE_NOTIFY_LATER);
> + bond_3ad_set_carrier(port->slave->bond);
> }
>
> /**
> @@ -199,8 +200,10 @@ static inline void __enable_port(struct port *port)
> {
> struct slave *slave = port->slave;
>
> - if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave))
> + if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave)) {
While at it please remove the extra ( ) around slave->link == BOND_LINK_UP.
> bond_set_slave_active_flags(slave, BOND_SLAVE_NOTIFY_LATER);
> + bond_3ad_set_carrier(slave->bond);
> + }
> }
>
> /**
> @@ -2372,8 +2375,10 @@ void bond_3ad_handle_link_change(struct slave *slave, char link)
> int bond_3ad_set_carrier(struct bonding *bond)
> {
> struct aggregator *active;
> - struct slave *first_slave;
> + struct slave *first_slave, *slave;
> + struct list_head *iter;
> int ret = 1;
> + int active_slaves = 0;
>
> rcu_read_lock();
> first_slave = bond_first_slave_rcu(bond);
> @@ -2381,10 +2386,15 @@ int bond_3ad_set_carrier(struct bonding *bond)
> ret = 0;
> goto out;
> }
> +
> + bond_for_each_slave_rcu(bond, slave, iter)
> + if (SLAVE_AD_INFO(slave)->aggregator.is_active)
> + active_slaves++;
> +
> active = __get_active_agg(&(SLAVE_AD_INFO(first_slave)->aggregator));
> - if (active) {
> + if (active && __agg_has_partner(active)) {
> /* are enough slaves available to consider link up? */
> - if (active->num_of_ports < bond->params.min_links) {
> + if (active_slaves < bond->params.min_links) {
> if (netif_carrier_ok(bond->dev)) {
> netif_carrier_off(bond->dev);
> goto out;
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 0dceba1..02ffedb 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -334,7 +334,7 @@ static int bond_vlan_rx_kill_vid(struct net_device *bond_dev,
> *
> * Returns zero if carrier state does not change, nonzero if it does.
> */
> -static int bond_set_carrier(struct bonding *bond)
> +int bond_set_carrier(struct bonding *bond)
> {
> struct list_head *iter;
> struct slave *slave;
> diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
> index 9bd538d4..4df2894 100644
> --- a/drivers/net/bonding/bond_options.c
> +++ b/drivers/net/bonding/bond_options.c
> @@ -1181,6 +1181,7 @@ static int bond_option_min_links_set(struct bonding *bond,
> netdev_info(bond->dev, "Setting min links value to %llu\n",
> newval->value);
> bond->params.min_links = newval->value;
> + bond_set_carrier(bond);
>
> return 0;
> }
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index 983a94b..29f53ea 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -525,6 +525,7 @@ void bond_sysfs_slave_del(struct slave *slave);
> int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev);
> int bond_release(struct net_device *bond_dev, struct net_device *slave_dev);
> u32 bond_xmit_hash(struct bonding *bond, struct sk_buff *skb);
> +int bond_set_carrier(struct bonding *bond);
> void bond_select_active_slave(struct bonding *bond);
> void bond_change_active_slave(struct bonding *bond, struct slave *new_active);
> void bond_create_debugfs(void);
>
^ permalink raw reply
* Re: [PATCH net-next 0/5] bonding: various 802.3ad fixes
From: Nikolay Aleksandrov @ 2015-01-19 19:29 UTC (permalink / raw)
To: Jonathan Toppins, netdev; +Cc: Veaceslav Falico, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <1421423848-414-1-git-send-email-jtoppins@cumulusnetworks.com>
On 01/16/2015 04:57 PM, Jonathan Toppins wrote:
> This patch series is a forward porting of patches we (Cumulus) are shipping
> in our 3.2 series kernels. These fixes attempt to make 802.3ad bonding mode
> more predictable in certian state machine transtions in addition to enhancing
> 802.3ad bond carrier determination based on acutal number of peered ports plus
> if the bond has an active aggregrator. Specific notes are contained within each
> patch.
>
> For this patch series there are no userspace facing changes, a diff between
> the modinfo output showed no difference. However, there are behavioral
> facing changes, primarily in the bond carrier state. Please make sure to
> review carefully.
>
> Jonathan Toppins (1):
> bonding: cleanup and remove dead code
>
> Satish Ashok (1):
> bonding: fix LACP PDU not sent on slave port sometimes
>
> Scott Feldman (1):
> bonding: keep bond interface carrier off until at least one active
> member
>
> Wilson Kok (2):
> bonding: fix bond_open() don't always set slave active flag
> bonding: fix incorrect lacp mux state when agg not active
>
> drivers/net/bonding/bond_3ad.c | 73 ++++++++++++++++++++++++++++--------
> drivers/net/bonding/bond_main.c | 6 +--
> drivers/net/bonding/bond_options.c | 1 +
> include/net/bond_3ad.h | 1 -
> include/net/bonding.h | 1 +
> 5 files changed, 62 insertions(+), 20 deletions(-)
>
Hi Jonathan,
For all patches you should also CC the other maintainers of the bonding -
Jay and Veaceslav, I'm adding them now just in case they've missed them.
I have a few cosmetic nits which I don't have a strong feeling about i.e.
if the others are okay with them - then ignore them, I've replied to the
patches directly, but other than that you can add for the set my:
Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
^ permalink raw reply
* [patch] s2io: use snprintf() as a safety feature
From: Dan Carpenter @ 2015-01-19 19:34 UTC (permalink / raw)
To: Jon Mason; +Cc: netdev, kernel-janitors
"sp->desc[i]" has 25 characters. "dev->name" has 15 characters. If we
used all 15 characters then the sprintf() would overflow.
I changed the "sprintf(sp->name, "%s Neterion %s"" to snprintf(), as
well, even though it can't overflow just to be consistent.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
This driver is quite old.
diff --git a/drivers/net/ethernet/neterion/s2io.c b/drivers/net/ethernet/neterion/s2io.c
0529cad..a4cdf2f 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -6987,7 +6987,9 @@ static int s2io_add_isr(struct s2io_nic *sp)
if (sp->s2io_entries[i].in_use == MSIX_FLG) {
if (sp->s2io_entries[i].type ==
MSIX_RING_TYPE) {
- sprintf(sp->desc[i], "%s:MSI-X-%d-RX",
+ snprintf(sp->desc[i],
+ sizeof(sp->desc[i]),
+ "%s:MSI-X-%d-RX",
dev->name, i);
err = request_irq(sp->entries[i].vector,
s2io_msix_ring_handle,
@@ -6996,7 +6998,9 @@ static int s2io_add_isr(struct s2io_nic *sp)
sp->s2io_entries[i].arg);
} else if (sp->s2io_entries[i].type ==
MSIX_ALARM_TYPE) {
- sprintf(sp->desc[i], "%s:MSI-X-%d-TX",
+ snprintf(sp->desc[i],
+ sizeof(sp->desc[i]),
+ "%s:MSI-X-%d-TX",
dev->name, i);
err = request_irq(sp->entries[i].vector,
s2io_msix_fifo_handle,
@@ -8154,7 +8158,8 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
"%s: UDP Fragmentation Offload(UFO) enabled\n",
dev->name);
/* Initialize device name */
- sprintf(sp->name, "%s Neterion %s", dev->name, sp->product_name);
+ snprintf(sp->name, sizeof(sp->name), "%s Neterion %s", dev->name,
+ sp->product_name);
if (vlan_tag_strip)
sp->vlan_strip_flag = 1;
^ permalink raw reply
* Re: [patch-net-next v3] net: ethernet: ti: cpsw: fix buld break when NET_POLL_CONTROLLER
From: David Miller @ 2015-01-19 19:45 UTC (permalink / raw)
To: balbi; +Cc: tony, linux-omap, mugunthanvnm, netdev
In-Reply-To: <1421689956-14369-1-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Mon, 19 Jan 2015 11:52:36 -0600
> Commit c03abd84634d (net: ethernet: cpsw: don't requests IRQs we don't
> use) left one build breakage when NET_POLL_CONTROLLER is enabled.
>
> Fix this build break by referring to the correct irqs_table array.
>
> Fixes: c03abd84634d (net: ethernet: cpsw: don't requests IRQs we don't use)
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: David Miller @ 2015-01-19 19:50 UTC (permalink / raw)
To: hagen; +Cc: hannes, netdev, stable, fgont
In-Reply-To: <CAPh34mc3T7W81J_NjMkHvQpjad1gTM3j99gnX8x8jnKvh2TBDg@mail.gmail.com>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Mon, 19 Jan 2015 15:00:21 +0100
> On 19 January 2015 at 14:55, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
>>
>> I think this is the correct way forward on how to deal with atomic
>> fragments.
>>
>> Hagen, do you submit patches to remove dst_allfrag/RTAX_FEATURE_ALLFRAG,
>> IPCORK_ALLFRAG, etc. for net-next, too?
>
> Yes, patch sits already in the pipe. I wanted to wait for davem's pull.
It's one thing to change policy about how we might or might not
automatically set this bit in the kernel, but at a minimum you cannot
just remove RTAX_FEATURE_ALLFRAG, it's in a userspace header and
you'll break application builds.
Second of all, there is absolutely no reason to prevent the user from
setting this bit. If someone wants to set RTAX_FEATURE_ALLFRAG on a
route on their own system, that is their business.
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: David Miller @ 2015-01-19 19:51 UTC (permalink / raw)
To: hagen; +Cc: netdev, hannes, stable, fgont
In-Reply-To: <1421357665-2804-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Thu, 15 Jan 2015 22:34:25 +0100
> Reduce the attack vector and stop generating IPv6 Fragment Header for
> paths with an MTU smaller than the minimum required IPv6 MTU
> size (1280 byte) - called atomic fragments.
>
> See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1]
> for more information and how this "feature" can be misused.
>
> [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Fernando Gont <fgont@si6networks.com>
> Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Applied, thanks.
But any follow-ups to get rid of RTAX_FEATURE_ALLFRAG altogether are
not to be seriously considered in my opinion.
^ permalink raw reply
* Re: [PATCH net] ipv6: stop sending PTB packets for MTU < 1280
From: Hannes Frederic Sowa @ 2015-01-19 20:05 UTC (permalink / raw)
To: David Miller; +Cc: hagen, netdev, stable, fgont
In-Reply-To: <20150119.145058.954790496532942109.davem@davemloft.net>
On Mo, 2015-01-19 at 14:50 -0500, David Miller wrote:
> From: Hagen Paul Pfeifer <hagen@jauu.net>
> Date: Mon, 19 Jan 2015 15:00:21 +0100
>
> > On 19 January 2015 at 14:55, Hannes Frederic Sowa
> > <hannes@stressinduktion.org> wrote:
> >> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> >>
> >> I think this is the correct way forward on how to deal with atomic
> >> fragments.
> >>
> >> Hagen, do you submit patches to remove dst_allfrag/RTAX_FEATURE_ALLFRAG,
> >> IPCORK_ALLFRAG, etc. for net-next, too?
> >
> > Yes, patch sits already in the pipe. I wanted to wait for davem's pull.
>
> It's one thing to change policy about how we might or might not
> automatically set this bit in the kernel, but at a minimum you cannot
> just remove RTAX_FEATURE_ALLFRAG, it's in a userspace header and
> you'll break application builds.
Sure, the define would need to be left alone.
> Second of all, there is absolutely no reason to prevent the user from
> setting this bit. If someone wants to set RTAX_FEATURE_ALLFRAG on a
> route on their own system, that is their business.
Oh yes, although we never exposed an ip route knob for that, it is still
possible users did set manually, so we cannot get rid of that, agreed.
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v8 0/4] net: Add Keystone NetCP ethernet driver support
From: David Miller @ 2015-01-19 20:11 UTC (permalink / raw)
To: m-karicheri2-l0cyMroinI0
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1421367007-19744-1-git-send-email-m-karicheri2-l0cyMroinI0@public.gmane.org>
From: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
Date: Thu, 15 Jan 2015 19:10:03 -0500
> The Network Coprocessor (NetCP) is a hardware accelerator that processes
> Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
> switch sub-module to send and receive packets. NetCP also includes a packet
> accelerator (PA) module to perform packet classification operations such as
> header matching, and packet modification operations such as checksum
> generation. NetCP can also optionally include a Security Accelerator(SA)
> capable of performing IPSec operations on ingress/egress packets.
>
> Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
> includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
> 1Gb/s rates per Ethernet port.
>
> Both GBE and XGBE network processors supported using common driver. It
> is also designed to handle future variants of NetCP.
Series applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 3/4] net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator
From: Heiko Stübner @ 2015-01-19 20:12 UTC (permalink / raw)
To: Romain Perier
Cc: peppe.cavallaro-qxv4g6HH51o, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
roger.chen-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1421690889-11901-4-git-send-email-romain.perier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Am Montag, 19. Januar 2015, 18:08:08 schrieb Romain Perier:
> Currently, dwmac-rk uses a custom propety "phy_regulator" to get the name of
> the right regulator to use to power on or power off the phy. This commit
> converts the driver to use phy-supply devicetree property and the
> corresponding API, it cleans the code a bit and make it simpler to
> maintain.
>
> Signed-off-by: Romain Perier <romain.perier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
I don't see updated binding documentation in here.
Secondly I think patch4 which changes the property in the evb-rk808 could be
in here. The change is simple enough and would keep it bisectable without
needing transistional patches.
And there is the one warning down below.
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 61
> ++++++++------------------ 1 file changed, 19 insertions(+), 42
> deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c index 06e1637..8a8091c
> 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -32,7 +32,7 @@
> struct rk_priv_data {
> struct platform_device *pdev;
> int phy_iface;
> - char regulator[32];
> + struct regulator *regulator;
>
> bool clk_enabled;
> bool clock_input;
> @@ -287,46 +287,25 @@ static int gmac_clk_enable(struct rk_priv_data
> *bsp_priv, bool enable)
>
> static int phy_power_on(struct rk_priv_data *bsp_priv, bool enable)
> {
> - struct regulator *ldo;
> - char *ldostr = bsp_priv->regulator;
> + struct regulator *ldo = bsp_priv->regulator;
> int ret;
> struct device *dev = &bsp_priv->pdev->dev;
>
> - if (!ldostr) {
> - dev_err(dev, "%s: no ldo found\n", __func__);
> + if (!ldo) {
> + dev_err(dev, "%s: no regulator found\n", __func__);
> return -1;
> }
>
> - ldo = regulator_get(NULL, ldostr);
> - if (!ldo) {
> - dev_err(dev, "\n%s get ldo %s failed\n", __func__, ldostr);
> + if (enable) {
> + ret = regulator_enable(ldo);
> + if (ret)
> + dev_err(dev, "%s: fail to enable phy-supply\n",
> + __func__);
> } else {
> - if (enable) {
> - if (!regulator_is_enabled(ldo)) {
> - ret = regulator_enable(ldo);
> - if (ret != 0)
> - dev_err(dev, "%s: fail to enable %s\n",
> - __func__, ldostr);
> - else
> - dev_info(dev, "turn on ldo done.\n");
> - } else {
> - dev_warn(dev, "%s is enabled before enable",
> - ldostr);
> - }
> - } else {
> - if (regulator_is_enabled(ldo)) {
> - ret = regulator_disable(ldo);
> - if (ret != 0)
> - dev_err(dev, "%s: fail to disable %s\n",
> - __func__, ldostr);
> - else
> - dev_info(dev, "turn off ldo done.\n");
> - } else {
> - dev_warn(dev, "%s is disabled before disable",
> - ldostr);
> - }
> - }
> - regulator_put(ldo);
> + ret = regulator_disable(ldo);
> + if (ret)
> + dev_err(dev, "%s: fail to disable phy-supply\n",
> + __func__);
> }
>
> return 0;
> @@ -346,14 +325,12 @@ static void *rk_gmac_setup(struct platform_device
> *pdev)
>
> bsp_priv->phy_iface = of_get_phy_mode(dev->of_node);
>
> - ret = of_property_read_string(dev->of_node, "phy_regulator", &strings);
> - if (ret) {
> - dev_warn(dev, "%s: Can not read property: phy_regulator.\n",
> - __func__);
> - } else {
> - dev_info(dev, "%s: PHY power controlled by regulator(%s).\n",
> - __func__, strings);
> - strcpy(bsp_priv->regulator, strings);
> + bsp_priv->regulator = devm_regulator_get_optional(dev, "phy");
> + if (IS_ERR(bsp_priv->regulator)) {
> + if (PTR_ERR(bsp_priv->regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
this should be return ERR_PTR(-EPROBE_DEFER) and produces a warning in its
current state
> + dev_err(dev, "no regulator found\n");
> + bsp_priv->regulator = NULL;
> }
>
> ret = of_property_read_string(dev->of_node, "clock_in_out", &strings);
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] phonet netlink: allow multiple messages per skb in route dump
From: Johannes Berg @ 2015-01-19 20:14 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: netdev, Sakari Ailus, Remi Denis-Courmont
In-Reply-To: <45863435.BJJN05sX3K@philogene>
On Mon, 2015-01-19 at 22:11 +0200, Rémi Denis-Courmont wrote:
> Le lundi 19 janvier 2015, 12:15:24 Johannes Berg a écrit :
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > My previous patch to this file changed the code to be bug-compatible
> > towards userspace. Unless userspace (which I wasn't able to find)
> > implements the dump reader by hand in a wrong way, this isn't needed.
>
> The canonical userspace is there (specifically src/pnroute.c):
> https://gitorious.org/meego-cellular/phonet-utils/
Ah, cool.
> AFAICT, it should work either way. By now, I expect what's left of the
> Maemo/Meego/Mer/whatever community has forked or rewritten it though.
The loop
for (struct nlmsghdr *nlh = (struct nlmsghdr *)&req;
NLMSG_OK (nlh, (size_t)ret); nlh = NLMSG_NEXT (nlh, ret))
should make it do the right thing, I agree.
johannes
^ permalink raw reply
* Re: [PATCH] phonet netlink: allow multiple messages per skb in route dump
From: Rémi Denis-Courmont @ 2015-01-19 20:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Sakari Ailus, Remi Denis-Courmont, Johannes Berg
In-Reply-To: <1421666124-16055-1-git-send-email-johannes@sipsolutions.net>
Le lundi 19 janvier 2015, 12:15:24 Johannes Berg a écrit :
> From: Johannes Berg <johannes.berg@intel.com>
>
> My previous patch to this file changed the code to be bug-compatible
> towards userspace. Unless userspace (which I wasn't able to find)
> implements the dump reader by hand in a wrong way, this isn't needed.
The canonical userspace is there (specifically src/pnroute.c):
https://gitorious.org/meego-cellular/phonet-utils/
AFAICT, it should work either way. By now, I expect what's left of the
Maemo/Meego/Mer/whatever community has forked or rewritten it though.
> If it uses libnl or similar code putting multiple messages into a
> single SKB is far more efficient.
>
> Change the code to do this. While at it, also clean it up and don't
> use so many variables - just store the address in the callback args
> directly.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/phonet/pn_netlink.c | 22 +++++++---------------
> 1 file changed, 7 insertions(+), 15 deletions(-)
>
> diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
> index 54d766842c2b..bc5ee5fbe6ae 100644
> --- a/net/phonet/pn_netlink.c
> +++ b/net/phonet/pn_netlink.c
> @@ -272,31 +272,23 @@ static int route_doit(struct sk_buff *skb, struct
> nlmsghdr *nlh) static int route_dumpit(struct sk_buff *skb, struct
> netlink_callback *cb) {
> struct net *net = sock_net(skb->sk);
> - u8 addr, addr_idx = 0, addr_start_idx = cb->args[0];
> + u8 addr;
>
> rcu_read_lock();
> - for (addr = 0; addr < 64; addr++) {
> - struct net_device *dev;
> + for (addr = cb->args[0]; addr < 64; addr++) {
> + struct net_device *dev = phonet_route_get_rcu(net, addr << 2);
>
> - dev = phonet_route_get_rcu(net, addr << 2);
> if (!dev)
> continue;
>
> - if (addr_idx++ < addr_start_idx)
> - continue;
> - fill_route(skb, dev, addr << 2, NETLINK_CB(cb->skb).portid,
> - cb->nlh->nlmsg_seq, RTM_NEWROUTE);
> - /* fill_route() used to return > 0 (or negative errors) but
> - * never 0 - ignore the return value and just go out to
> - * call dumpit again from outside to preserve the behavior
> - */
> - goto out;
> + if (fill_route(skb, dev, addr << 2, NETLINK_CB(cb->skb).portid,
> + cb->nlh->nlmsg_seq, RTM_NEWROUTE) < 0)
> + goto out;
> }
>
> out:
> rcu_read_unlock();
> - cb->args[0] = addr_idx;
> - cb->args[1] = 0;
> + cb->args[0] = addr;
>
> return skb->len;
> }
--
Rémi
^ permalink raw reply
* Re: [PATCH v1 0/4] net: stmmac: dwmac-rk: Fix phy regulator issues
From: Heiko Stübner @ 2015-01-19 20:19 UTC (permalink / raw)
To: Romain Perier, David Miller
Cc: peppe.cavallaro, netdev, linux-kernel, linux-rockchip,
linux-arm-kernel, devicetree, roger.chen
In-Reply-To: <1421690889-11901-1-git-send-email-romain.perier@gmail.com>
Hi Romain
Am Montag, 19. Januar 2015, 18:08:05 schrieb Romain Perier:
> This series fixes few issues in dwmac-rk:
>
> 1. Voltage settings was hardcoded into the driver for the phy regulator.
> The driver now uses the default voltage settings found in the devicetree,
> which are applied throught the regulator framework.
> 2. The regulator name used to power on or power off the phy was put in the
> devicetree variable "phy_regulator", which is not standard and added a lot
> of code for nothing. The driver now uses the devicetree property
> "phy-supply" and the corresponding functions to manipulate this regulator.
>
> The corresponding devicetree files are also updated. As, dwmac-rk was
> recently pushed in the development tree, I don't care about devicetree
> backward compatibility issues.
This last sentence is slightly misleading :-) .
The actual fact is, that these new bindings for the rk3288 gmac have not been
released with any official kernel release yet ... i.e. the will be released with
3.20 in whatever form, so we don't _need_ to care about keeping compatibility
still for the next 2.5 weeks or so.
@Dave: it would be good if this series (when fixed) could still go into the
3.20 material so we don't get stuck with the non-standard regulator property.
As we'll probably need a v2 due to at the issue in patch3, could you also
switch places of patch1 and 2, which would keep bisecatbility (i.e. regulator
property before removing the voltage setting from the driver).
Otherwise this series:
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH net-next 0/5] bonding: various 802.3ad fixes
From: David Miller @ 2015-01-19 20:19 UTC (permalink / raw)
To: jtoppins; +Cc: netdev
In-Reply-To: <1421423848-414-1-git-send-email-jtoppins@cumulusnetworks.com>
From: Jonathan Toppins <jtoppins@cumulusnetworks.com>
Date: Fri, 16 Jan 2015 10:57:23 -0500
> This patch series is a forward porting of patches we (Cumulus) are shipping
> in our 3.2 series kernels. These fixes attempt to make 802.3ad bonding mode
> more predictable in certian state machine transtions in addition to enhancing
> 802.3ad bond carrier determination based on acutal number of peered ports plus
> if the bond has an active aggregrator. Specific notes are contained within each
> patch.
>
> For this patch series there are no userspace facing changes, a diff between
> the modinfo output showed no difference. However, there are behavioral
> facing changes, primarily in the bond carrier state. Please make sure to
> review carefully.
There was some minor feedback given to you for this series, please address
it and repost the set.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] csiostor:Remove T4 FCoE support
From: David Miller @ 2015-01-19 20:30 UTC (permalink / raw)
To: praveenm; +Cc: netdev, linux-scsi, JBottomley, hch, hariprasad, varun
In-Reply-To: <cover.1421423434.git.praveenm@chelsio.com>
From: Praveen Madhavan <praveenm@chelsio.com>
Date: Fri, 16 Jan 2015 21:30:18 +0530
> We found a subtle issue with FCoE on T4 very late in the game
> and decided not to productize FCoE on T4 and therefore there
> are no customers that will be impacted by this change. FCoE is
> supported on T5 cards.
>
> Please apply on net-next since depends on previous commits.
>
> Changes in v2:
> - Make the commit message more clearer.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v13 3/3] net: hisilicon: new hip04 ethernet driver
From: Arnd Bergmann @ 2015-01-19 20:34 UTC (permalink / raw)
To: Alexander Graf
Cc: Ding Tianhong, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, grant.likely-QSEj5FYQhm4dnm+yROfE0A,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-lFZ/pmaqli7XmaaqVzeoHQ
In-Reply-To: <54BD48BF.3050707-l3A5Bk7waGM@public.gmane.org>
On Monday 19 January 2015 19:11:11 Alexander Graf wrote:
>
> After hammering on the box a bit again, I'm in a situation where I get
> lots of
>
> [302398.232603] hip04-ether e28b0000.ethernet eth0: rx drop
> [302398.377309] hip04-ether e28b0000.ethernet eth0: rx drop
> [302398.395198] hip04-ether e28b0000.ethernet eth0: rx drop
> [302398.466118] hip04-ether e28b0000.ethernet eth0: rx drop
> [302398.659009] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.053389] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.122067] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.268192] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.286081] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.594201] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.683416] hip04-ether e28b0000.ethernet eth0: rx drop
> [302399.701307] hip04-ether e28b0000.ethernet eth0: rx drop
>
> and I really am getting a lot of drops - I can't even ping the machine
> anymore.
>
> However, as it is there's a good chance the machine is simply
> unreachable because it's busy writing to the UART, and even if not all
> useful messages indicating anything have scrolled out. I really don't
> think you should emit any message over and over again to the user. Once
> or twice is enough.
>
> Please make sure to rate limit it.
I would argue that packet loss is not an error condition at all
and you should not print this at netdev_err() level. You could make
this a netdev_dbg(), or just make it silent because it's already
counted in the statistics.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net 0/2] sh_eth fixes
From: David Miller @ 2015-01-19 20:38 UTC (permalink / raw)
To: ben.hutchings
Cc: netdev, linux-kernel, nobuhiro.iwamatsu.yj, mitsuhiro.kimura.kc,
hisashi.nakamura.ak, ykaneko0929
In-Reply-To: <1421430592.1222.190.camel@xylophone.i.decadent.org.uk>
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date: Fri, 16 Jan 2015 17:49:52 +0000
> I'm currently looking at Ethernet support on the R-Car H2 chip,
> reviewing and testing the sh_eth driver. Here are fixes for two fairly
> obvious bugs in the driver; I will probably have some more later.
>
> These are not tested on any of the other supported chips.
Series applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next 0/5] bonding: various 802.3ad fixes
From: Jonathan Toppins @ 2015-01-19 20:39 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: Veaceslav Falico, Jay Vosburgh, Andy Gospodarek
In-Reply-To: <54BD5B0B.5030507@redhat.com>
On 1/19/15 2:29 PM, Nikolay Aleksandrov wrote:
> On 01/16/2015 04:57 PM, Jonathan Toppins wrote:
>> This patch series is a forward porting of patches we (Cumulus) are shipping
>> in our 3.2 series kernels. These fixes attempt to make 802.3ad bonding mode
>> more predictable in certian state machine transtions in addition to enhancing
>> 802.3ad bond carrier determination based on acutal number of peered ports plus
>> if the bond has an active aggregrator. Specific notes are contained within each
>> patch.
>>
>> For this patch series there are no userspace facing changes, a diff between
>> the modinfo output showed no difference. However, there are behavioral
>> facing changes, primarily in the bond carrier state. Please make sure to
>> review carefully.
>>
>> Jonathan Toppins (1):
>> bonding: cleanup and remove dead code
>>
>> Satish Ashok (1):
>> bonding: fix LACP PDU not sent on slave port sometimes
>>
>> Scott Feldman (1):
>> bonding: keep bond interface carrier off until at least one active
>> member
>>
>> Wilson Kok (2):
>> bonding: fix bond_open() don't always set slave active flag
>> bonding: fix incorrect lacp mux state when agg not active
>>
>> drivers/net/bonding/bond_3ad.c | 73 ++++++++++++++++++++++++++++--------
>> drivers/net/bonding/bond_main.c | 6 +--
>> drivers/net/bonding/bond_options.c | 1 +
>> include/net/bond_3ad.h | 1 -
>> include/net/bonding.h | 1 +
>> 5 files changed, 62 insertions(+), 20 deletions(-)
>>
>
> Hi Jonathan,
> For all patches you should also CC the other maintainers of the bonding -
> Jay and Veaceslav, I'm adding them now just in case they've missed them.
> I have a few cosmetic nits which I don't have a strong feeling about i.e.
> if the others are okay with them - then ignore them, I've replied to the
> patches directly, but other than that you can add for the set my:
>
> Reviewed-by: Nikolay Aleksandrov <nikolay@redhat.com>
>
Hi Nikolay,
Appreciate the review... looking over comments now. Apologies for not
including other maintainers, will make sure to include them in v2 of
patch series.
^ permalink raw reply
* Re: [PATCH net-next] mii: Handle link state changes for forced modes in mii_check_media()
From: David Miller @ 2015-01-19 20:40 UTC (permalink / raw)
To: ben.hutchings; +Cc: ct178-internal, netdev, linux-kernel
In-Reply-To: <1421430935.1222.196.camel@xylophone.i.decadent.org.uk>
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
Date: Fri, 16 Jan 2015 17:55:35 +0000
> mii_check_media() does not update the link (carrier) state or log link
> changes when the link mode is forced. Drivers using the mii library
> must do this themselves, but most of them do not.
>
> Instead of changing them all, provide a sensible default behaviour
> similar to mii_check_link() when the mode is forced.
>
> via-rhine depends on it being a no-op in this case, so make its call
> to mii_check_media() conditional.
>
> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Seems reasonable, applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: DSA fixes for bridge and ip-autoconf
From: David Miller @ 2015-01-19 20:45 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, bridge, kaber, buytenh
In-Reply-To: <1421430962-18119-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 16 Jan 2015 09:56:00 -0800
> These two patches address some real world use cases of the DSA master and slave
> network devices.
>
> You have already seen patch 1 previously and you rejected it since my
> explanations were not good enough to provide a justification as to why it is
> useful, hopefully this time my explanation is better.
>
> Patch 2 solves a different, yet very real problem as well at the bridge layer
> when using DSA network devices.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
From: Alexei Starovoitov @ 2015-01-19 20:48 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Ingo Molnar, Steven Rostedt, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, David S. Miller,
Daniel Borkmann, Hannes Frederic Sowa, Brendan Gregg, Linux API,
Network Development, LKML
In-Reply-To: <54BCD3CF.9040205@hitachi.com>
On Mon, Jan 19, 2015 at 1:52 AM, Masami Hiramatsu
<masami.hiramatsu.pt@hitachi.com> wrote:
> If we can write the script as
>
> int bpf_prog4(s64 write_size)
> {
> ...
> }
>
> This will be much easier to play with.
yes. that's the intent for user space to do.
>> The example of this arbitrary pointer walking is tracex1_kern.c
>> which does skb->dev->name == "lo" filtering.
>
> At least I would like to see this way on kprobes event too, since it should be
> treated as a traceevent.
it's done already... one can do the same skb->dev->name logic
in kprobe attached program... so from bpf program point of view,
tracepoints and kprobes feature-wise are exactly the same.
Only input is different.
>> - kprobe programs are architecture dependent and need user scripting
>> language like ktap/stap/dtrace/perf that will dynamically generate
>> them based on debug info in vmlinux
>
> If we can use kprobe event as a normal traceevent, user scripting can be
> architecture independent too. Only perf-probe fills the gap. All other
> userspace tools can collaborate with perf-probe to setup the events.
> If so, we can avoid redundant works on debuginfo. That is my point.
yes. perf already has infra to read debug info and it can be extended
to understand C like script as:
int kprobe:sys_write(int fd, char *buf, size_t count)
{
// do stuff with 'count'
}
perf can be made to parse this text, recognize that it wants
to create kprobe on 'sys_write' function. Then based on
debuginfo figure out where 'count' is (either register or stack)
and generate corresponding bpf program either
using llvm/gcc backends or directly.
perf facility of extracting debug info can be made into
library too and used by ktap/dtrace tools for their
languages.
User space can innovate in many directions.
and, yes, once we have a scripting language whether
it's C like with perf or else, this language hides architecture
depend things from users.
Such scripting language will also hide the kernel
side differences between tracepoint and kprobe.
Just look how ktap scripts look alike for kprobes and tracepoints.
Whether ktap syntax becomes part of perf or perf invents
its own language, it's going to be good for users regardless.
The C examples here are just examples. Something
users can play with already until more user friendly
tools are being worked on.
^ permalink raw reply
* Re: [PATCH net-next 3/5] bonding: fix incorrect lacp mux state when agg not active
From: Jonathan Toppins @ 2015-01-19 20:50 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev; +Cc: Andy Gospodarek, Wilson Kok
In-Reply-To: <54BD5A53.8050609@redhat.com>
On 1/19/15 2:26 PM, Nikolay Aleksandrov wrote:
>> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>> index e9b706f..52a8772 100644
>> --- a/drivers/net/bonding/bond_3ad.c
>> +++ b/drivers/net/bonding/bond_3ad.c
>> @@ -471,10 +471,13 @@ static void __record_pdu(struct lacpdu *lacpdu, struct port *port)
>> * and the port is matched
>> */
>> if ((port->sm_vars & AD_PORT_MATCHED)
>> - && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION))
>> + && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION)) {
> In net/ it's preferred to have the logical operators at the end of the
> previous line. It'd be nice if we start fixing these in bond_3ad.c since
> they're being touched by the patch anyhow.
Ack, I prefer at the end too. Question, would it be acceptable to do the
cleanup of the entire bond_3ad.c code in a separate patch? That way the
fix vs. cleanup is clear.
>> case AD_MUX_COLLECTING_DISTRIBUTING:
>> if (!(port->sm_vars & AD_PORT_SELECTED) ||
>> (port->sm_vars & AD_PORT_STANDBY) ||
>> - !(port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION)) {
>> + !(port->partner_oper.port_state &
>> + AD_STATE_SYNCHRONIZATION) ||
>> + !(port->actor_oper_port_state &
>> + AD_STATE_SYNCHRONIZATION)) {
> IMO this one looks a bit confusing when broken up like that.
Ack, it seems in this case making checkpatch.pl happy should be secondary.
^ permalink raw reply
* Re: [PATCH net-next 1/5] bonding: keep bond interface carrier off until at least one active member
From: Jonathan Toppins @ 2015-01-19 20:54 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev; +Cc: Scott Feldman, Andy Gospodarek
In-Reply-To: <54BD5ABE.9040806@redhat.com>
On 1/19/15 2:27 PM, Nikolay Aleksandrov wrote:
> On 01/16/2015 04:57 PM, Jonathan Toppins wrote:
>> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
>> index 8baa87d..e9b706f 100644
>> --- a/drivers/net/bonding/bond_3ad.c
>> +++ b/drivers/net/bonding/bond_3ad.c
>> @@ -189,6 +189,7 @@ static inline int __agg_has_partner(struct aggregator *agg)
>> static inline void __disable_port(struct port *port)
>> {
>> bond_set_slave_inactive_flags(port->slave, BOND_SLAVE_NOTIFY_LATER);
>> + bond_3ad_set_carrier(port->slave->bond);
>> }
>>
>> /**
>> @@ -199,8 +200,10 @@ static inline void __enable_port(struct port *port)
>> {
>> struct slave *slave = port->slave;
>>
>> - if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave))
>> + if ((slave->link == BOND_LINK_UP) && bond_slave_is_up(slave)) {
> While at it please remove the extra ( ) around slave->link == BOND_LINK_UP.
>
Ack.
^ permalink raw reply
* Re: [PATCH net-next 3/5] bonding: fix incorrect lacp mux state when agg not active
From: David Miller @ 2015-01-19 20:56 UTC (permalink / raw)
To: jtoppins; +Cc: nikolay, netdev, gospo, wkok
In-Reply-To: <54BD6E28.8020705@cumulusnetworks.com>
From: Jonathan Toppins <jtoppins@cumulusnetworks.com>
Date: Mon, 19 Jan 2015 15:50:48 -0500
> On 1/19/15 2:26 PM, Nikolay Aleksandrov wrote:
>>> diff --git a/drivers/net/bonding/bond_3ad.c
>>> b/drivers/net/bonding/bond_3ad.c
>>> index e9b706f..52a8772 100644
>>> --- a/drivers/net/bonding/bond_3ad.c
>>> +++ b/drivers/net/bonding/bond_3ad.c
>>> @@ -471,10 +471,13 @@ static void __record_pdu(struct lacpdu *lacpdu,
>>> struct port *port)
>>> * and the port is matched
>>> */
>>> if ((port->sm_vars & AD_PORT_MATCHED)
>>> - && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION))
>>> + && (lacpdu->actor_state & AD_STATE_SYNCHRONIZATION)) {
>> In net/ it's preferred to have the logical operators at the end of the
>> previous line. It'd be nice if we start fixing these in bond_3ad.c
>> since
>> they're being touched by the patch anyhow.
>
> Ack, I prefer at the end too. Question, would it be acceptable to do
> the cleanup of the entire bond_3ad.c code in a separate patch? That
> way the fix vs. cleanup is clear.
If you're touching this line, fix it's style in-situ.
^ 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