[PATCH] Fix Bird/Bird6 wrong LSA collisions detection

[Mikkelsen, Asbjorn]

Thanks for looking at the patch, Ondrej.

1. Discussing it with an SME here, this seems a fair description of what is happening.

2. I think that part of the comment might be inaccurate now, since as you say, the NULL case is already covered above it.

3. They could be removed. During the debugging process of the issue we had, we found it more convenient to log the issues rather than using OSPF_TRACE.

4. The patch should be attributed to @mdelagueronniere, actually.


Thanks,

Asbjorn


On 06.11.18, 16:15, "Ondrej Zajicek" <santiago at crfreenet.org> wrote:
    Hi
    
    Thanks for the patch, i have some questions:
    
    1) Am i understand correctly the cause that there is struct top_hash_entry
    and associated struct ort entry, but struct ort entry got removed while
    struct top_hash_entry still links to it, so when new struct ort for given
    network is allocated, it is technically different from old one and that
    cause the collision?
    
    2) The comment says that nf is NULL in this case:
    
      if (!en->nf || !en->lsa_body)
        en->nf = lsa->nf;
    
      if (en->lsa_body && (en->lsa.age == LSA_MAXAGE))
      {
        /* en could be an unexpected self-originated lsa in which case nf is NULL */
        log(L_INFO "%s: Found flushing LSA while originating %I/%d with fib: %p",
          p->p.name, lsa->nf->fn.prefix, lsa->nf->fn.pxlen, en->nf);
        en->nf = lsa->nf;
      }
    
    But if en->nf is null, the issue is handled by the first condition above,
    so the second condition is not necessary? So i assume the comment is not
    correct?
    
    
    3) There are some unrelated OSPF_TRACE() to log(L_INFO) changes in the
    patch, could be removed?
    
    
    4) Who the patch should be attributed to? To you (as per commit), or to
    @jcharbon (as noted in the comment in the PR)?
    
    -- 
    Elen sila lumenn' omentielvo
    
    Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
    OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
    "To err is human -- to blame it on a computer is even more so."