On Tue, Aug 25, 2015 at 08:59:13AM -0400, Hal Rosenstock wrote:
> > - if (mcast->logcount++ < 20) {
> > - if (status == -ETIMEDOUT || status == -EAGAIN) {
> > + bool silent_fail =
> > + test_bit(IPOIB_MCAST_FLAG_SENDONLY, &mcast->flags) &&
> > + status == -EINVAL;
>
> Aren't there other reasons that send only join might have EINVAL
> indicated ?
Not sure, the layers below all eat the detailed error code. Hopefully
EINVAL isn't re-used.
> Maybe it's better to be overly silent rather than overly
> verbose as to not spam the log but it seems like it would make debug of
> such cases harder.
It makes debugging harder to have worthless messages because they
obscure what is going on. The first time I saw this I assumed there
was an issue, but it turns out to be an expected failure.
The other issue is the way the rate limiting works:
> > + if (mcast->logcount < 20) {
> > + if (status == -ETIMEDOUT || status == -EAGAIN ||
> > + silent_fail) {
> > ipoib_dbg_mcast(priv, "%smulticast join failed for %pI6, status %d\n",
> > test_bit(IPOIB_MCAST_FLAG_SENDONLY, &mcast->flags) ? "sendonly " : "",
> > mcast->mcmember.mgid.raw, status);
So wasting logcount with expected failures just results in eating
unexpected failures...
> ipoib_dbg_mcast logging is conditionalized on CONFIG_INFINIBAND_IPOIB_DEBUG
Most distros turn this off so the change only impacts people trying to
debug this stuff.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
