From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
References: <20171016074803.17947-1-sven.eckelmann@openmesh.com>
From: Antonio Quartulli
Message-ID:
Date: Mon, 16 Oct 2017 16:53:19 +0800
MIME-Version: 1.0
In-Reply-To: <20171016074803.17947-1-sven.eckelmann@openmesh.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="aiQP9uCvJIdSEb4MrJxLeNje0l8SPthoF"
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Avoid spurious warnings from
bat_v neigh_cmp implementation
List-Id: The list for a Better Approach To Mobile Ad-hoc Networking
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
To: The list for a Better Approach To Mobile Ad-hoc Networking , Sven Eckelmann
Cc: Joseph Stefek , =?UTF-8?Q?Steffen_F=c3=b6rster?=
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aiQP9uCvJIdSEb4MrJxLeNje0l8SPthoF
Content-Type: multipart/mixed; boundary="gv0uxaLlXreK8SUg8s9QnlNFb4HBIFxhP";
protected-headers="v1"
From: Antonio Quartulli
To: The list for a Better Approach To Mobile Ad-hoc Networking
,
Sven Eckelmann
Cc: Joseph Stefek ,
=?UTF-8?Q?Steffen_F=c3=b6rster?=
Message-ID:
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Avoid spurious warnings from
bat_v neigh_cmp implementation
References: <20171016074803.17947-1-sven.eckelmann@openmesh.com>
In-Reply-To: <20171016074803.17947-1-sven.eckelmann@openmesh.com>
--gv0uxaLlXreK8SUg8s9QnlNFb4HBIFxhP
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 16/10/17 15:48, Sven Eckelmann wrote:
> The neighbor compare API implementation for B.A.T.M.A.N. V checks wheth=
er
> the neigh_ifinfo for this neighbor on a specific interface exists. A
> warning is printed when it isn't found.
>=20
> But it is not called inside a lock which would prevent that this
> information is lost right before batadv_neigh_ifinfo_get. It must there=
fore
> be expected that batadv_v_neigh_(cmp|is_sob) might not be able to get t=
he
> requested neigh_ifinfo.
>=20
> A WARN_ON for such a situation seems not to be appropriate because this=
> will only flood the kernel logs. The warnings must therefore be removed=
=2E
>=20
> Signed-off-by: Sven Eckelmann
Yeah, this makes sense. As a read only operation, the lock is not held
on purpose, therefore such situation has to be expected.
Acked-by: Antonio Quartulli
--=20
Antonio Quartulli
--gv0uxaLlXreK8SUg8s9QnlNFb4HBIFxhP--
--aiQP9uCvJIdSEb4MrJxLeNje0l8SPthoF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEERdCuyFSHc3WdqS4EB6U8WA7yzXQFAlnkc4QACgkQB6U8WA7y
zXQZbw//SRSR+hO+ZMAZJZwWDmFWHBTqnEY0dlFvYacYF4M2cdh+VpUxG5eD/gfj
rGTVCvzoE1AdGjnwawwLc1rn/1J/OU08RUo8OBJ3YXe9UhhJF4tQ/E2+z99zhuPe
PhNVNDSXgOunb76QCSnRdTvrD4YNSvaq+o42HCml1lnRb0j/cKI2UrDFK/TcUfmq
0UwpqThCAmmr6yJ7oKj1k1sDAuhTQvndImAn88GFtdnSkyV0KXc9M2OdLCHxiP75
cQvKZ6QFm2yWT6xCAOriSddySQsDSoAaSVl5BwxHyFLto9TKb0o9qw2LygU2mcED
N8FgBHOVxtxOM1oXxk5IxuJHBiG1Q4drgEitbA/Y8B/4OzFUt+kccpkiDlK4dRbt
8ghjVxiaUnhV2ZdHJDXvBrJ9PdsUCwHfvErorYpqy35SOrUWYuoYh38bLssjrbl0
6w832Pc/dET6CdE0zWLROT8Ynn6t7ifu9e9Bge/B6chgtCutkgzLTze4c16hb3pk
knj3ZSxO5QklgtXFwa/LivBaMbKWz/EC0UsgUxMyxYESl33B3dhlBcGCU1zxMZt7
n+6vkaUm5v4q86FYUd/8RSiOQyyXFtRf1dA7UceOz2y9iBr0dhKyFtcX2jMX3RS6
LgK4OxqTXb304q2fHPXX1pK2hIjQ6tf299RNEzDxOEVuGvHzVvk=
=/mmg
-----END PGP SIGNATURE-----
--aiQP9uCvJIdSEb4MrJxLeNje0l8SPthoF--