linux-kernel - bonding: link state question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <020577f3-763d-48fd-73ce-db38c3c7fdf9@redhat.com>
Date:   Sat, 7 Aug 2021 17:26:34 -0400
From:   Jonathan Toppins <jtoppins@...hat.com>
To:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Veaceslav Falico <vfalico@...il.com>,
        Jay Vosburgh <j.vosburgh@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: bonding: link state question

Is there any reason why bonding should have an operstate of up when none 
of its slaves are in an up state? In this particular scenario it seems 
like the bonding device should at least assert NO-CARRIER, thoughts?

$ ip -o -d link show | grep "bond5"
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc 
fq_codel master bond5 state DOWN mode DEFAULT group default qlen 1000\ 
  link/ether 8c:8c:aa:f8:62:16 brd ff:ff:ff:ff:ff:ff promiscuity 0 
minmtu 68 maxmtu 9000 \    bond_slave state ACTIVE mii_status UP 
link_failure_count 0 perm_hwaddr 8c:8c:aa:f8:62:16 queue_id 0 
numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
41: bond5: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc 
noqueue state UP mode DEFAULT group default qlen 1000\    link/ether 
8c:8c:aa:f8:62:16 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 
65535 \    bond mode balance-xor miimon 0 updelay 0 downdelay 0 
peer_notify_delay 0 use_carrier 1 arp_interval 0 arp_validate none 
arp_all_targets any primary_reselect always fail_over_mac none 
xmit_hash_policy layer2 resend_igmp 1 num_grat_arp 1 all_slaves_active 0 
min_links 0 lp_interval 1 packets_per_slave 1 lacp_rate slow ad_select 
stable tlb_dynamic_lb 1 numtxqueues 16 numrxqueues 16 gso_max_size 65536 
gso_max_segs 65535

$ cat /sys/class/net/enp0s31f6/operstate
down

$ cat /sys/class/net/bond5/operstate
up

This is an older kernel (4.18.0-305.7.1.el8_4.x86_64) but I do not see 
any changes upstream that would indicate a change in this operation.

Thanks,
-Jon