From: Antonio Quartulli <a@unstable.cc>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>,
Sven Eckelmann <sven.eckelmann@openmesh.com>
Cc: "Joseph Stefek" <joseph.stefek@openmesh.com>,
"Steffen Förster" <steffen@chemnitz.freifunk.net>
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Avoid spurious warnings from bat_v neigh_cmp implementation
Date: Mon, 16 Oct 2017 16:53:19 +0800 [thread overview]
Message-ID: <f18395d0-306a-80fb-4b88-22ece6ee2d23@unstable.cc> (raw)
In-Reply-To: <20171016074803.17947-1-sven.eckelmann@openmesh.com>
[-- Attachment #1.1: Type: text/plain, Size: 922 bytes --]
On 16/10/17 15:48, Sven Eckelmann wrote:
> The neighbor compare API implementation for B.A.T.M.A.N. V checks whether
> the neigh_ifinfo for this neighbor on a specific interface exists. A
> warning is printed when it isn't found.
>
> But it is not called inside a lock which would prevent that this
> information is lost right before batadv_neigh_ifinfo_get. It must therefore
> be expected that batadv_v_neigh_(cmp|is_sob) might not be able to get the
> requested neigh_ifinfo.
>
> 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.
>
> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
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 <a@unstable.cc>
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-10-16 8:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 7:48 [B.A.T.M.A.N.] [PATCH] batman-adv: Avoid spurious warnings from bat_v neigh_cmp implementation Sven Eckelmann
2017-10-16 8:53 ` Antonio Quartulli [this message]
2017-10-16 17:11 ` Sven Eckelmann
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=f18395d0-306a-80fb-4b88-22ece6ee2d23@unstable.cc \
--to=a@unstable.cc \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=joseph.stefek@openmesh.com \
--cc=steffen@chemnitz.freifunk.net \
--cc=sven.eckelmann@openmesh.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.