t;> return of ad_agg_selection_logic).
>>
>> I believe I understand the described problem, but I don't see
>> how the patch fixes it. I suspect (but haven't tested) that the proper
>> fix is to acquire mode_lock in bond_update_slave_arr while ca
update_slave_arr remains false at
return of ad_agg_selection_logic).
I believe I understand the described problem, but I don't see
how the patch fixes it. I suspect (but haven't tested) that the proper
fix is to acquire mode_lock in bond_update_slave_arr while calling
bond_3ad_get_active_agg_info to avoid conflict with the state machine.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
uot;,
>+ opt->name, val->string);
>+ }
>+ break;
> default:
> break;
> }
>--
>2.25.1
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
));
>>
>> analysis: port->aggregator is still NULL, which causes problem.
>>
>> aggregator = __get_first_agg(port);
>> ad_agg_selection_logic(aggregator, update_slave_arr);
>>
>> if (!port->aggregator->is_active)
>> port->actor_oper_port_state &= ~LACP_STATE_SYNCHRONIZATION;
Correct, if the "did not find a suitable aggregator" path is
taken, port->aggregator is NULL and bad things happen in the above
block.
This is something that needs to be fixed, but I'm also concerned
that there are other issues lurking, so I'd like to be able to reproduce
this.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
ted by copying bond_eth_hash(). :)
>
>> > +{
>> > + struct ethhdr *mac_hdr = (struct ethhdr *)skb_mac_header(skb);
>>
>> I don't see anything in the patch making sure the interface actually
>> has a L2 header. Should we validate somehow the ifc is Ethernet?
>
>I don't think it's necessary. There doesn't appear to be any explicit
>check for BOND_XMIT_POLICY_LAYER2 either. I believe we're guaranteed to
>not have anything but an ethernet header here, as the only other type I'm
>aware of being supported is Infiniband, but we limit that to active-backup
>only, and xmit_hash_policy isn't valid for active-backup.
This is correct, interfaces in a bond other than active-backup
will all be ARPHRD_ETHER. I'm unaware of a way to get a packet in there
without at least an Ethernet header.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
Jarod Wilson wrote:
>On Thu, Jan 07, 2021 at 07:03:40PM -0500, Jarod Wilson wrote:
>> On Fri, Dec 18, 2020 at 04:18:59PM -0800, Jay Vosburgh wrote:
>> > Jarod Wilson wrote:
>> >
>> > >This comes from an end-user request, where they're running multip
oks sane to begin with, is
>fleshing out Documentation/networking/bonding.rst.
I'm sure you're aware, but any final submission will also need
to include netlink and iproute2 support.
>Cc: Jay Vosburgh
>Cc: Veaceslav Falico
>Cc: Andy Gospodarek
>Cc: "David
+;
>> }
>> }
>>
>> @@ -4117,6 +4118,7 @@ static struct slave *bond_get_slave_by_id(struct
>> bonding *bond,
>> break;
>> if (bond_slave_can_tx(slave))
>> return slave;
>> +bond->rr_tx_counter++;
>> }
>> /* no slave that can tx has been found */
>> return NULL;
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
gt;+ "active " : "backup ") : "",
>+ bond->params.downdelay *
>bond->params.miimon);
>+ }
>+ break;
>+
>+ case BOND_LINK_DOWN:
>+ slave_info(bond->dev, slave->dev, "link status down again after
>%d ms\n",
>+ (bond->params.updelay - slave->delay) *
>+ bond->params.miimon);
>+ break;
>+
>+ case BOND_LINK_BACK:
>+ if (slave->delay) {
>+ slave_info(bond->dev, slave->dev, "link status up,
>enabling it in %d ms\n",
>+ bond->params.updelay * bond->params.miimon);
>+ }
>+ break;
>+ }
>+
> if (notify) {
> bond_queue_slave_event(slave);
> bond_lower_state_changed(slave);
>--
>2.28.0
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
Jarod Wilson wrote:
>On Wed, Dec 2, 2020 at 12:55 PM Jay Vosburgh
>wrote:
>>
>> Jarod Wilson wrote:
>>
>> >Don't try to adjust XFRM support flags if the bond device isn't yet
>> >registered. Bad things can currently happen when n
hanged.
>
>v2: rework based on further testing and suggestions from ivecera
>
>Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load")
>Reported-by: Ivan Vecera
>Suggested-by: Ivan Vecera
>Cc: Jay Vosburgh
>Cc: Veaceslav Falico
>Cc: Andy Gospodarek
Jarod Wilson wrote:
>Simply refer to what was the bonding "master" as the "bond" or bonding
>device, depending on context. However, do retain compat code for the
>bonding_masters sysfs interface to avoid breaking userspace.
>
>Cc: Jay Vosburgh
>Cc: Veace
ces entirely
>untouched, but update documentation to reference their deprecated
>nature, explain the name changes, add references to NetworkManager,
>include more netlink/iproute2 examples and make note of netlink
>being the preferred interface for userspace interaction with bonds.
>
*
>+ * Return true if the address is a multicast for IPv6.
>+ */
>+static inline bool is_ipv6_multicast_ether_addr(const u8 *addr)
>+{
>+ return (addr[0] & addr[1]) == 0x33;
>+}
I don't think this does what is intended. It will return true
for a MAC that starts with any two values whose bitwise AND is 0x33,
e.g., 0x73 0x3b. For IPv6 multicast, the first two octets of the MAC
must be exactly 0x33 0x33.
-J
>+
>+/**
> * is_valid_ether_addr - Determine if the given Ethernet address is valid
> * @addr: Pointer to a six-byte array containing the Ethernet address
> *
>--
>1.8.3.1
---
-Jay Vosburgh, jay.vosbu...@canonical.com
LIU Yulong wrote:
>Hi Jay,
>
>
>
>Thank you for your response and review. Please see my inline comments.
I'm still reviewing your commentary, but to answer your final
question regarding updating the patch, you'll need to repost the entire
patch (with the new changes). This repost shoul
one step than a piecemeal addition and removal from the
existing UAPI. That makes for a much clearer flag day event for end
users. By this I mean leave proc / sysfs as-is today, and then after a
suitable deprecation period, remove it wholesale (rather than a compile
time option).
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
Jarod Wilson wrote:
>On Tue, Sep 22, 2020 at 8:01 PM Stephen Hemminger
> wrote:
>>
>> On Tue, 22 Sep 2020 16:47:07 -0700
>> Jay Vosburgh wrote:
>>
>> > Stephen Hemminger wrote:
>> >
>> > >On Tue, 22 Sep 2020 09:37:30 -0400
>> &
enable, and
enabling will break the UAPI?
>Then you might convince maintainers to update documentation as well.
>Last I checked there were still references to ifenslave.
Distros still include ifenslave, but it's now a shell script
that uses sysfs. I see it used in scripts from time to time.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
. As far
>as I can tell, there is no breakage of existing interfaces with this
>set, unless the user consciously opts to do so via Kconfig.
>
>Jarod Wilson (5):
> bonding: rename struct slave member link to link_state
> bonding: rename slave to link where possible
> bon
owest" here?
>Also, the type of the speed field is u32, not unsigned long, so adjust
>that accordingly, as required to make min() function here without
>complaining about mismatching types.
>
>Fixes: bb5b052f751b ("bond: add support to read speed and duplex via ethtool
Jay Vosburgh wrote:
>sathyanarayanan.kuppusw...@linux.intel.com wrote:
>
>From: Kuppuswamy Sathyanarayanan
>>
>>Fatal (DPC) error recovery is currently broken for non-hotplug
>>capable devices. With current implementation, after successful
>>fatal error rec
is system),
>as well as successful failover and recovery mid-netperf.
>
>v2: rebase on latest net-next and wrap with #ifdef CONFIG_XFRM_OFFLOAD
>v3: add new CONFIG_BOND_XFRM_OFFLOAD option and fix shutdown path
>
>CC: Jay Vosburgh
>CC: Veaceslav Falico
>CC: Andy Gospodar
after reset link operation which will also fix the above
>mentioned issue.
>
>[original patch is from jay.vosbu...@canonical.com]
>[original patch link
>https://lore.kernel.org/linux-pci/12115.1588207324@famine/]
>Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_l
a similar problem.
>
>Fixes: 07699f9a7c8d ("bonding: add sysfs /slave dir for bond slave devices.")
>Signed-off-by: Qiushi Wu
Acked-by: Jay Vosburgh
>---
> drivers/net/bonding/bond_sysfs_slave.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff
_recovery. After 6d2c89441571 report_slot_reset is not
>invoked, and the device does not recover.
>
>[original patch is from jay.vosbu...@canonical.com]
>[original patch link
>https://lore.kernel.org/linux-pci/18609.1588812972@famine/]
>Fixes: 6d2c89441571 ("PCI/ERR: Update erro
the commit 4d2c0cda,
>its log says " Some NIC drivers don't have correct speed/duplex
>settings at the time they send NETDEV_UP notification ...".
>
>Anyway, I think the lacp status should be fixed correctly,
>since link-monitoring (miimon) set SPEED/DUPLEX right here.
I suspect this is going to be related to the concurrent
discussion with Aleksei, and would like to see the instrumentation
results from his tests before adding another change to attempt to
resolve this.
Also, what device are you using for your testing, and are you
able to run the instrumentation patch that I provided to Aleksei and
provide its results?
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
e that testing duplex here is correct; is_enabled
is not controlled by duplex, but by carrier state. Duplex does affect
whether or not a port is permitted to aggregate, but that's entirely
separate logic (the AD_PORT_LACP_ENABLED flag).
Would it be better to call bond_3ad_handle_link_change() here,
instead of manually testing duplex and setting is_enabled?
-J
> continue;
>
> case BOND_LINK_UP:
>--
>1.8.3.1
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
;
>(port->partner_oper.port_state & AD_STATE_SYNCHRONIZATION) &&
>+ (port->partner_oper.port_state & AD_STATE_COLLECTING) &&
> !__check_agg_selection_timer(port)) {
> if (port->aggregator->is_active)
> port->sm_mux_state =
>
>--
>Thanks,
>Felix
---
-Jay Vosburgh, jay.vosbu...@canonical.com
hould this be tagged with
Fixes: 278339a42a1b ("bonding: propogate vlan_features to bonding master")
as 30d8177e8ac7 was? If not, is there an appropriate commit id?
Acked-by: Jay Vosburgh
-J
>---
> drivers/net/bonding/bond_main.c | 2 ++
> 1 file changed, 2 i
Presuming that this is the case, I don't see that there's much
else to be done here, and so:
Acked-by: Jay Vosburgh
>The simple fix is to instead set the slave link to BOND_LINK_DOWN again,
>if the link has never been up (last_link_up == 0), so the link state
>doesn'
_count);
>
> static ssize_t perm_hwaddr_show(struct slave *slave, char *buf)
> {
>- return sprintf(buf, "%pM\n", slave->perm_hwaddr);
>+ return sprintf(buf, "%*phC\n",
>+ slave->dev->addr_len,
>+
continue;
>@@ -3238,7 +3238,7 @@ static inline u32 bond_eth_hash(struct sk_buff *skb)
>
> ep = skb_header_pointer(skb, 0, sizeof(hdr_tmp), &hdr_tmp);
> if (ep)
>- return ep->h_dest[5] ^ ep->h_source[5] ^ ep->h_proto;
>+ retu
&newval);
thus, newval.value is initially be32, but stored in a u64.
__bond_opt_set will call bond_opt_parse, which in turn will call
bond_option_arp_ip_targets_set (via .set), and the change above would
swap the newval.value back to host order (on little endian architectures
for which cpu_to_be32 is not a no-op).
Am I misunderstanding? Did you test this change on an x86 or
other little endian system?
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
In general, yes, but in this case, the condition should be
impossible to hit, so BUG_ON seems appropriate.
If bond_slave_get_rtnl/rcu() returns NULL for an actual bonding
slave, other code paths (bond_fill_slave_info, bond_handle_frame) will
likely crash before getting to this one.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
nto bond_option_active_slave_set for a slave prior to
bond_enslave registering the rx_handler for that slave, as these
operations are mutexed by RTNL.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
ew_active);
This is a reasonable idea in principle, but will require
additional changes to prevent dereferencing new_active if it is NULL
(which would happen just below this point in the code).
-J
> if (new_active == old_active) {
> /* do nothing */
>--
>2.7.4
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
gt;> bond->params.arp_interval = 0;
>> /* set miimon to default value */
>> bond->params.miimon = BOND_DEFAULT_MIIMON;
>> -netdev_info(bond->dev, "Setting MII monitoring interval to
>> %d\n",
>> +netdev_dbg(bond->dev, "Setting MII monitoring interval to %d\n",
>> bond->params.miimon);
>
>etc...
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
; }
>@@ -4121,8 +4121,8 @@ static void bond_ethtool_get_drvinfo(struct net_device
>*bond_dev,
>
> static const struct ethtool_ops bond_ethtool_ops = {
> .get_drvinfo= bond_ethtool_get_drvinfo,
>- .get_settings = bond_ethtool_get_settings,
>
}
>+ pr_info("%s is being deleted...\n", ifname);
>+ unregister_netdevice(bond_dev);
>+ } else {
>+ pr_err("unable to delete non-existent %s\n", ifname);
>+ res = -ENODEV;
>+ }
>+ rtnl_unlock();
> } else
> goto err_no_cmd;
>
>@@ -139,7 +170,7 @@ static ssize_t bonding_store_bonds(struct class *cls,
> return res;
>
> err_no_cmd:
>- pr_err("no command found in bonding_masters - use +ifname or
>-ifname\n");
>+ pr_err("no command found in bonding_masters - use +ifname or -ifname or
>?-ifname\n");
> return -EPERM;
> }
>
>--
>1.8.3.1
>
---
-Jay Vosburgh, jay.vosbu...@canonical.com
the description above, this test is insuring that
the code doesn't use the broadcast MAC address for the client. Changing
it seems like a bad thing to do, as it would cause traffic for the
client to be sent to the ethernet broadcast address.
This might, in fact, make the described test run better, but it
has nothing to do with rebalancing and would negatively impact other
hosts on the network.
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
, but I'd actually today get good use from a
"rx_drop_unforwardable" (or an equivalent but shorter name) counter that
counts every time a packet is dropped due to is_skb_forwardable()
returning false. __dev_forward_skb does this (and hits rx_dropped), as
does the bridge (and does not co
ext curr_arp_slave
automatically.
I also wonder if the fail_over_mac option would affect this
behavior, as it would cause the slaves to keep their MAC address for the
duration, so the switch would not see the MAC move from port to port.
Another thought would be to have the curr_arp_slave
Uwe Koziolek wrote:
>On Tue, Sep 01, 2015 at 05:41 PM +0200, Andy Gospodarek wrote:
>> On Mon, Aug 17, 2015 at 10:51:27PM +0200, Uwe Koziolek wrote:
>>> On Mon, Aug 17, 2015 at 09:14PM +0200, Jay Vosburgh wrote:
>>>> Uwe Koziolek wrote:
>>>>
>
sed change is bypassing the slave change for 2 additional calls
>of bond_ab_arp_probe.
>Now the retries are not only for an up bond available, they are also
>implemented for a down bond.
Does this delay failover or bringup on switches that are not
"problematic"? I.e.,
didate for failover/reselection and current
>active slave is still up.
>
>Signed-off-by: Mazhar Rana
>Signed-off-by: Jay Vosburgh
I don't believe I posted a Signed-off-by, so you really
shouldn't include one for me without it being explicitly stated.
In any e
GMAIL wrote:
>Hi Jay,
>
>On Friday 03 July 2015 02:12 AM, Jay Vosburgh wrote:
>
>> [ added netdev to cc ]
>>
>> Mazhar Rana wrote:
>>
>>> When "primary_reselect" is set to "failure", primary interface should
>>&g
rimary;
+ struct slave *slave, *bestslave = NULL;
struct list_head *iter;
int mintime = bond->params.updelay;
- primary = rtnl_dereference(bond->primary_slave);
- if (primary && primary->link == BOND_LINK_UP &&
- bond_should_change_active(bond)
Paul E. McKenney wrote:
>On Sat, Oct 25, 2014 at 11:18:27AM -0700, Paul E. McKenney wrote:
>> On Sat, Oct 25, 2014 at 09:38:16AM -0700, Jay Vosburgh wrote:
>> > Paul E. McKenney wrote:
>> >
>> > >On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrot
Paul E. McKenney wrote:
>On Fri, Oct 24, 2014 at 05:20:48PM -0700, Jay Vosburgh wrote:
>> Paul E. McKenney wrote:
>>
>> >On Fri, Oct 24, 2014 at 03:59:31PM -0700, Paul E. McKenney wrote:
>> [...]
>> >> Hmmm... It sure looks like we have some callbacks
Paul E. McKenney wrote:
>On Fri, Oct 24, 2014 at 09:33:33PM -0700, Jay Vosburgh wrote:
>> Looking at the dmesg, the early boot messages seem to be
>> confused as to how many CPUs there are, e.g.,
>>
>> [0.00] SLUB: HWalign=64, Order=0-3, Mi
U_UP_CANCELED_FROZEN:
>- for_each_rcu_flavor(rsp)
>+ for_each_rcu_flavor(rsp) {
> rcu_cleanup_dead_cpu(cpu, rsp);
>+ do_nocb_deferred_wakeup(per_cpu_ptr(rsp->rda, cpu));
>+ }
> break;
> default:
&
Paul E. McKenney wrote:
>On Fri, Oct 24, 2014 at 03:02:04PM -0700, Jay Vosburgh wrote:
>> Paul E. McKenney wrote:
>>
[...]
>> I've got an ftrace capture from unmodified -net, it looks like
>> this:
>>
>> ovs-vswitchd-902 [000] 471.
9] 0: 88013fc0e3c0 l:88013fc0e3c0 n:88013fc8e3c0 ...
[ 360.496469] 1: 88013fc8e3c0 l:88013fc0e3c0 n: (null) .G.
[ 360.503407] 2: 88013fd0e3c0 l:88013fd0e3c0 n:88013fd8e3c0 ...
[ 360.510346] 3: 88013fd8e3c0 l:88013fd0e3c0 n: (null) ...
---
-Jay Vosburgh, jay.vosbu...@canonical.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
for_each_possible_cpu(cpu) {
>+ if (!rcu_is_nocb_cpu(cpu))
>+ continue;
>+ rdp = per_cpu_ptr(rsp->rda, cpu);
>+ pr_alert("%3d: %p l:%p n:%p %c%c%c\n",
>+ cpu,
>+
Thanx, Paul
>
>> >
>> >
>> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
>> > index 29fb23f33c18..927c17b081c7 100644
>> > --- a/
Paul E. McKenney wrote:
>On Thu, Oct 23, 2014 at 09:48:34PM -0700, Jay Vosburgh wrote:
>> Paul E. McKenney wrote:
[...]
>> >Either way, my patch assumed that 39953dfd4007 (rcu: Avoid misordering in
>> >__call_rcu_nocb_enqueue()) would work and that 1772947bd012 (rcu
reads process pending callbacks after spawning)
>and c847f14217d5 (rcu: Avoid misordering in nocb_leader_wait())?
Just a note to add that I am also reliably inducing what appears
to be this issue on a current -net tree, when configuring openvswitch
via script. I am available to test patches or bisect tomorrow (Friday)
US time if needed.
The stack is as follows:
[ 1320.492020] INFO: task ovs-vswitchd:1303 blocked for more than 120 seconds.
[ 1320.498965] Not tainted 3.17.0-testola+ #1
[ 1320.503570] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 1320.511374] ovs-vswitchdD 88013fc14600 0 1303 1302 0x0004
[ 1320.511378] 8801388d77d8 0002 880031144b00
8801388d7fd8
[ 1320.511382] 00014600 00014600 8800b092e400
880031144b00
[ 1320.511385] 8800b1126000 81c58ad0 81c58ad8
7fff
[ 1320.511389] Call Trace:
[ 1320.511396] [] schedule+0x29/0x70
[ 1320.511399] [] schedule_timeout+0x1dc/0x260
[ 1320.511404] [] ? check_preempt_curr+0x8d/0xa0
[ 1320.511407] [] ? ttwu_do_wakeup+0x1d/0xd0
[ 1320.511410] [] wait_for_completion+0xa6/0x160
[ 1320.511413] [] ? wake_up_state+0x20/0x20
[ 1320.511417] [] _rcu_barrier+0x157/0x200
[ 1320.511419] [] rcu_barrier+0x15/0x20
[ 1320.511423] [] netdev_run_todo+0x60/0x300
[ 1320.511427] [] rtnl_unlock+0xe/0x10
[ 1320.511435] [] internal_dev_destroy+0x55/0x80
[openvswitch]
[ 1320.511440] [] ovs_vport_del+0x32/0x40 [openvswitch]
[ 1320.511444] [] ovs_dp_detach_port+0x30/0x40 [openvswitch]
[ 1320.511448] [] ovs_vport_cmd_del+0xc5/0x110 [openvswitch]
[ 1320.511452] [] genl_family_rcv_msg+0x1a5/0x3c0
[ 1320.511455] [] ? genl_family_rcv_msg+0x3c0/0x3c0
[ 1320.511458] [] genl_rcv_msg+0x91/0xd0
[ 1320.511461] [] netlink_rcv_skb+0xc1/0xe0
[ 1320.511463] [] genl_rcv+0x2c/0x40
[ 1320.511466] [] netlink_unicast+0xf6/0x200
[ 1320.511468] [] netlink_sendmsg+0x31d/0x780
[ 1320.511472] [] ? netlink_rcv_wake+0x44/0x60
[ 1320.511475] [] ? netlink_recvmsg+0x1d3/0x3e0
[ 1320.511479] [] sock_sendmsg+0x93/0xd0
[ 1320.511484] [] ? apparmor_file_alloc_security+0x20/0x40
[ 1320.511487] [] ? verify_iovec+0x47/0xd0
[ 1320.511491] [] ___sys_sendmsg+0x399/0x3b0
[ 1320.511495] [] ? kernfs_seq_stop_active+0x32/0x40
[ 1320.511499] [] ? native_sched_clock+0x35/0x90
[ 1320.511502] [] ? native_sched_clock+0x35/0x90
[ 1320.511505] [] ? sched_clock+0x9/0x10
[ 1320.511509] [] ? acct_account_cputime+0x1c/0x20
[ 1320.511512] [] ? account_user_time+0x8b/0xa0
[ 1320.511516] [] ? __fget_light+0x25/0x70
[ 1320.511519] [] __sys_sendmsg+0x42/0x80
[ 1320.511521] [] SyS_sendmsg+0x12/0x20
[ 1320.511525] [] tracesys_phase2+0xd8/0xdd
-J
---
-Jay Vosburgh, jay.vosbu...@canonical.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
vior described above if the bond has been
administratively set down and then back up. This effect should not
occur when slaves are added while the bond is up; it's something that
only happens after a down/up bounce of the bond.
That said, the patch itself looks fine to me.
Signed-off
et similarly to active-backup: the curr_active_slave is
active, other slaves are inactive. The "inactive" setting for alb is
special, and means to not pass broadcast or multicast, but let unicast
through.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fu...@us.ibm.c
zheng.li wrote:
>于 2014年03月21日 01:02, Jay Vosburgh 写道:
>> Zheng Li wrote:
>>
>>> Except bond mode 1, in other bond modes, inactive slaves should keep
>>> inactive flag to 1 to refuse to receive broadcast packets. Now, active
>>> slave send broadcas
> BOND_SLAVE_NOTIFY_NOW);
> }
> }
>--
>1.7.6.5
>
---
-Jay Vosburgh, IBM Linux Technology Center, fu...@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
rom networking normally go through
Davem; I can check the patch and repost it to netdev against 3.4.46 if
everybody is ok with that.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fu...@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
rectly
>from disk from doing so easily...grrr.
>
>Jay Vosburgh wrote:
>> The miimon functionality is used to check link state and notice
>> when slaves lose carrier.
>---
> If I am running 'rr' on 2 channels -- specifically for the purpose
>of link spe
nder peers unable to
>communicate with the destinations beyond the bridge.
>
>Signed-off-by: Zheng Li
>Cc: Jay Vosburgh
>Cc: Andy Gospodarek
>Cc: "David S. Miller"
Signed-off-by: Jay Vosburgh
>---
> drivers/net/bonding/bond_alb.c |6 ++
> drivers/net
gt;[ 59.801446] [] __ethtool_get_settings+0x85/0x140
>[ 59.801450] [] bond_update_speed_duplex+0x23/0x60
>[ 59.801471] [] bond_mii_monitor+0x354/0x640
>[ 59.801475] [] process_one_work+0x1a7/0x680
>[ 59.801477] [] ? process_one_work+0x146/0x680
>[ 59.801481]
k the ARP reply side of this is fine (and is what is
>> described in teh changelog), but the ARP request behavior change is new
>> with this version.
>>
>> Since prior versions of the patch didn't cause this code to be
>> skipped, is this change inte
rt slaves with link down for
>ARP monitor", this was masked by slaves always starting in UP
>state with ARP monitor (and MII monitor not relying on
>curr_active_slave being NULL if there is no slave up).
>
>Signed-off-by: Michal Kubecek
Signed-off-by: Jay Vosburgh
> driver
ment) on the active slave due to bridged
ARP traffic?
-J
>Signed-off-by: Zheng Li
>Cc: Jay Vosburgh
>Cc: Andy Gospodarek
>Cc: "David S. Miller"
>
>---
> drivers/net/bonding/bond_alb.c |6 ++
> drivers/net/bonding/bonding.h | 13 +
&
Zheng Li wrote:
>ARP traffic passing through a bridge and out via the bond (when the bond is a
>port of the bridge) should not have its source MAC address adjusted by the
>receive load balance code in rlb_arp_xmit.
>
>Signed-off-by: Zheng Li
>Cc: Jay Vosburgh
>Cc:
if (net_ratelimit()) {
> pr_warning("%s: no path to arp_ip_target %pI4 via
> rt.dev %s\n",
> bond->dev->name, &targets[i],
>--
>1.7.9.5
>
---
-Jay Vosburgh, IBM Linux Technology Center
d(slave->dev, ARPOP_REQUEST, targets[i],
>addr, 0);
>+ continue;
>+ }
>+
> if (net_ratelimit()) {
> pr_warning("%s: no path to arp_ip_target %pI4 via
> rt.dev %s\n",
> bond->
oot problem (just one manifestation of it). A better subject might be
something like "rlb mode should not alter ARP replies originating via
bridge."
>Cc: Jay Vosburgh
>Cc: Andy Gospodarek
>Cc: "David S. Miller"
>Signed-off-by: Zheng Li
>
>---
> dri
wo namespaces have an skge device
with the same name, will there be a debugfs conflict there as well?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fu...@us.ibm.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
one link."
I do not see that it is correct to attach the links to a common
aggregator, as your output indicates that no partner association has
been created (the Partner MAC is all zeroes) and the links are therefore
apparently connected to a device that cannot perform aggregation.
o have the
bond_arp_send() function perform a neigh_lookup() prior to calling
arp_create(), and use the result of the lookup (if any) in the
arp_create() call.
So, no, with the caveat that I haven't tried it, I don't see a
reason that bonding couldn't do what you're looking
), and remove the mode test from
bonding_store_xmit_hash().
This would be consistent with the way the arp_ip_target option
is treated: the actual value is always displayed, even if it is not
used, and it is legal to change the value, regardless of the mode.
Other than this, I
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>This patch fixes a cut'n'paste error in
>commit 1b76b31693d4a6088dec104ff6a6ead54081a3c2.
>
>Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Please apply.
-J
Acked-
but HEA is part of that, so it's probably got the answers you're
looking for.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PR
r type of function, and passing the carrier state of the
"external switch port" to the internal port.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
gger a NULL pointer dereference in sysfs. I was not able to
induce the failure with the non-sysfs code path, but for consistency I
updated that code as well.
I also did some testing of the bonding /proc file being open
while the bond is being deleted, and didn't see any problems th
gger a NULL pointer dereference in sysfs. I was not able to
induce the failure with the non-sysfs code path, but for consistency I
updated that code as well.
I also did some testing of the bonding /proc file being open
while the bond is being deleted, and didn't see any problems th
es. I'm thinking to clean it up for general posting early
next week, and address additional problems from there (since it's
hopefully at least a big step forward).
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send th
long term fix, which involves refactoring the
bonding link monitoring and failover system. Jaroslav's patch looks to
be a subset of the patch Andy is working on.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line &
a. With this patch, arp monitoring works correctly
>again.
>
>This also needs to make its way into the 2.6.19 stable series.
>
>Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]>
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]>
-J
---
-Jay Vosburgh, IBM Li
rs call tr_type_trans
>from their packet receive handlers.
>
>Signed-off-by: Jay Vosburg <[EMAIL PROTECTED]>
Pretty close.
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
>It is my understanding that this same patch has been submitted multiple
>times in the pas
ts in
the described case.
I haven't tested the patch, but conceptually the problem John
described in his original mail sounds plausible, as does the fix for it.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send t
86 matches
Mail list logo
