In article <[email protected]>,
Robert Elz  <[email protected]> wrote:
>    Date:        Wed, 23 Dec 2015 16:22:05 +0000 (UTC)
>    From:        [email protected] (Christos Zoulas)
>    Message-ID:  <[email protected]>
>
>
>Looks like it has been slightly reformed by the experience too...

Still needs isolation and contemplation.

>While looking there I noticed a couple of nits (that have been there
>"forever" - nothing to do with your changes) but that you might want to
>fix while cleaning up...

[....]

>What the comment should probably say is something like
>
>       /*
>        * Disallow v6 addresses without a specific mask or masklen
>        */
>

Fixed.

>Also, even more minor (and again, old) there are space/tab mixups in the
>#defines that are now in mountd.h

Fixed.

>
>Lastly, I can fathom no reason at all for all the code calling getnameinfo()
>and setting nt_name - as best I can tell, nothing uses it.   It happens only
>in a subset of cases, so it is hard to believe that anything depends upon
>it that I have missed.   I think I'd just rip all of that nonsense out, and
>see what happens...

Doesn't put_exlist use it?

>The other call to getnameinfo() appears to be just to validate that the
>address just lovingly extracted from the string is in fact a valid addr.
>I'm not sure under what conditions that could fail (what binary addr form
>is going to be invald?   (In the sense of getnameinfo(AI_NUMERICHOST)
>failing anyway?)   Maybe for some other address family than v4 or v6, but
>this code is never going to work for them anyway.   So I think I'd rip
>out that one as well.

Again put_exlist uses that... But for what? We need to revisit the
export mess anyway. I just got bitten by wedge renumbering making my
fs exported invalid (and crashing ffs) since we still use dev_t for
fsid and that's not stable in a wedge world... There is also an
ancient PR about export issues.

christos

Reply via email to