From: Michal Soltys <soltys@ziu.info>
To: "Mahesh Bandewar (महेश बंडेवार)" <maheshb@google.com>,
"Vincent Bernat" <vincent@bernat.ch>
Cc: "Maciej Żenczykowski" <zenczykowski@gmail.com>,
"David Miller" <davem@davemloft.net>,
"Linux NetDev" <netdev@vger.kernel.org>,
"Jay Vosburgh" <jay.vosburgh@canonical.com>,
"Chonggang Li" <chonggangli@google.com>
Subject: Re: [PATCH net 1/1] bonding: fix PACKET_ORIGDEV regression on bonding masters
Date: Wed, 16 Jan 2019 03:58:28 +0100 [thread overview]
Message-ID: <8aa3dcac-3597-5576-741f-849985ce8d1d@ziu.info> (raw)
In-Reply-To: <CAF2d9jhmaZZN7U1JcECr6eYNwMuusTwOqk04QN=Gvr9suqpuNw@mail.gmail.com>
On 19/01/15 03:19, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Mon, Jan 14, 2019 at 12:00 AM Vincent Bernat <vincent@bernat.ch> wrote:
>>
>> ❦ 13 janvier 2019 18:01 -08, Maciej Żenczykowski <zenczykowski@gmail.com>:
>>
>> > But I seem to recall that the core problem we were trying to solve was
>> > that a daemon listening
>> > on an AF_PACKET ethertype 88CC [LLDP] socket not bound to any device
>> > would not receive LLDP packets
>> > arriving on inactive bond slaves (either active-backup or lag).
>>
>> Just tested and with 4.9.150, I am in fact unable to receive anything
>> on a backup link when listening to the active-backup master device or to
>> "any" device.
>>
>> > Perhaps going from:
>> > /* don't change skb->dev for link-local packets */
>> > if (is_link_local_ether_addr(eth_hdr(skb)->h_dest)) return RX_HANDLER_PASS;
>> > if (bond_should_deliver_exact_match(skb, slave, bond)) return
>> > RX_HANDLER_EXACT;
>> >
>> > to something more like:
>> > if (bond_should_deliver_exact_match(skb, slave, bond)) {
>> > /* don't change skb->dev for link-local packets on inactive slaves */
>> > if (is_link_local_ether_addr(eth_hdr(skb)->h_dest)) return RX_HANDLER_PASS;
>> > return RX_HANDLER_EXACT;
>> > }
>> >
>> > would fix both problems?
>>
> thanks for jumping in and offering a solution. This should fix the issue.
>
> NACK for the revert-patch!
>
> Folks, please, revert is not the solution! Last time when there was a
> problem posted I offered you a solution, so wasn't that enough to
> prove that we care about solving the problem that you are facing while
> continuing to have this functionality? No one wants to break your use
> case, it happens only because one is not aware of it. Thank you David
> for resorting to resolve it.
Mahesh, that's not it. But:
Since Vincent reported PACKET_ORIGDEV regression late november, none of
you replied to anything posted until now. And if David hadn't called you
guys directly, I'm not sure you would have at this point. Reverting and
Vincent's offer to patch to update packet(7) were also clearly mentioned
in the previous thread, none of them commented/nacked/acked either. Me
an Vincent have been scratching our head for a while off list - but our
guessing can only go as far as time goes on.
Maciej now was the first to ever provide the actual details about the
issue you were facing originally. My bad I haven't added him to CC from
the very beginning.
Anyway, I'll test Maciej's version in bridging context in coming days
and look closer at the code overall. It probably works fine if Vincent
is seeing packets on masters, but I'd rather be sure.
next prev parent reply other threads:[~2019-01-16 2:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 16:29 [PATCH net 0/1] bonding: fix PACKET_ORIGDEV regression Michal Soltys
2019-01-07 16:29 ` [PATCH net 1/1] bonding: fix PACKET_ORIGDEV regression on bonding masters Michal Soltys
2019-01-07 17:12 ` David Miller
2019-01-08 13:46 ` Vincent Bernat
2019-01-13 23:03 ` David Miller
2019-01-14 2:01 ` Maciej Żenczykowski
2019-01-14 8:00 ` Vincent Bernat
2019-01-15 2:19 ` Mahesh Bandewar (महेश बंडेवार)
2019-01-16 2:58 ` Michal Soltys [this message]
2019-01-16 2:01 ` Michal Soltys
2019-01-18 0:27 ` Michal Soltys
2019-01-18 6:58 ` Maciej Żenczykowski
2019-01-29 1:47 ` Michal Soltys
2019-01-29 9:39 ` Maciej Żenczykowski
2019-02-18 16:55 ` [PATCH v2] bonding: fix PACKET_ORIGDEV regression Michal Soltys
2019-02-19 1:51 ` David Ahern
2019-02-19 9:14 ` Maciej Żenczykowski
2019-02-21 21:21 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8aa3dcac-3597-5576-741f-849985ce8d1d@ziu.info \
--to=soltys@ziu.info \
--cc=chonggangli@google.com \
--cc=davem@davemloft.net \
--cc=jay.vosburgh@canonical.com \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.org \
--cc=vincent@bernat.ch \
--cc=zenczykowski@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox