From mboxrd@z Thu Jan 1 00:00:00 1970 From: Serhey Popovych Subject: Re: [PATCH iproute2 2/3] utils: ll_map: Update name and type for existing entry Date: Thu, 28 Dec 2017 20:22:53 +0200 Message-ID: <7db01772-1777-ee32-4511-817000e8d6c9@gmail.com> References: <1513755451-9800-1-git-send-email-serhe.popovych@gmail.com> <1513755451-9800-3-git-send-email-serhe.popovych@gmail.com> <20171228094645.19549fcc@xeon-e3> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DHLtndIZEcgjz6K7ieQHWV1K3VMBfvQUh" Cc: netdev@vger.kernel.org To: Stephen Hemminger Return-path: Received: from mail-lf0-f66.google.com ([209.85.215.66]:38452 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754053AbdL1SXA (ORCPT ); Thu, 28 Dec 2017 13:23:00 -0500 Received: by mail-lf0-f66.google.com with SMTP id w196so28099904lff.5 for ; Thu, 28 Dec 2017 10:23:00 -0800 (PST) In-Reply-To: <20171228094645.19549fcc@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DHLtndIZEcgjz6K7ieQHWV1K3VMBfvQUh Content-Type: multipart/mixed; boundary="JEkt7s1aYWQlG8BlLRbyx22s0OLu4wSJf"; protected-headers="v1" From: Serhey Popovych To: Stephen Hemminger Cc: netdev@vger.kernel.org Message-ID: <7db01772-1777-ee32-4511-817000e8d6c9@gmail.com> Subject: Re: [PATCH iproute2 2/3] utils: ll_map: Update name and type for existing entry References: <1513755451-9800-1-git-send-email-serhe.popovych@gmail.com> <1513755451-9800-3-git-send-email-serhe.popovych@gmail.com> <20171228094645.19549fcc@xeon-e3> In-Reply-To: <20171228094645.19549fcc@xeon-e3> --JEkt7s1aYWQlG8BlLRbyx22s0OLu4wSJf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen Hemminger wrote: > On Wed, 20 Dec 2017 09:37:30 +0200 > Serhey Popovych wrote: >=20 >> In case of we update existing entry we need not only rehash >> but also update name in existing entry. >> >> Need to update device type too since cached interface might >> be deleted and new with same index, but different type >> added (e.g. eth0 and ppp0). >> >> Reuse new entry initialization path to avoid duplications. >> >> Signed-off-by: Serhey Popovych >=20 > Can you provide an example where this is an observed bug? > I suspect that unless you use a batch mode command the reload > of the cache on next invocation is solving this. >=20 =46rom my side example from description is pretty clear: eth0 -> ppp0 or rename eth0 -> eth1, etc. According to ll_remember_index() code we might be called with non-empty cache. If ll_get_by_index() returns an entry with name that differs from current we need: 1. Rehash in ->name_hash (done with current code) 2. Update entry name (not done with current code) That's my point of view. Thanks. --JEkt7s1aYWQlG8BlLRbyx22s0OLu4wSJf-- --DHLtndIZEcgjz6K7ieQHWV1K3VMBfvQUh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJaRTaBAAoJEBTawMmQ61bBWv0IAL+pHc18jyhrht9ytv+1yOTU FxlJuwYvu8UHM7SDkM74G0ualmxyH+Spsqfnnzx1tv7qVmvo6qz+rWWdN5SbHOn6 f2wgENd9AtcJACzbLFRSFvIwulBsz6EOFp0gpvad99Vquip2XeJFy7an21DyDzn1 zhJkrXSMxAhfGnlHXfjozfxzBBhGR9orZ8PivmbcLmC8pEfrhF4mgmxvv1CMYKvO 582EK1VoEfCJRliZ8gOCQE68PIotmH1dxzqZb6m6KHKohfR3tBZ4RWQuyzJHQhvD F1lXt5fIOvl0Rib0mqtJLMLai8hcFDiFnKv6UK/yf9xNE9re/28b+6/NtO8ccrs= =tp+m -----END PGP SIGNATURE----- --DHLtndIZEcgjz6K7ieQHWV1K3VMBfvQUh--