> I find "hardening" code that adds bugs to be particularly bad and > ugly, the same way that I absolutely *hate* debugging code that turns > out to make debugging impossible (we had that with the "better" stack > tracing code that caused kernel panics to kill the machine entirely > rather than show the backtrace, and I'm still bitter about it a decade > after the fact). Agree, it's very important for this code to be correct and the string functions have some subtleties so it needs scrutiny. I messed up strcpy between v1 and v2 trying to add a proper read overflow check. My fault for not looking more closely at strscpy before adopting it based on my misinterpretation of the API. This is primarily a bug finding feature right now and it has gotten a few fixed that actually matter (most were unimportant memcpy read past end of string constant but not all). I don't think it has another bug like this strscpy misuse itself, but there will need to be some more fixes for minor read overflows, etc. elsewhere in the tree before it'll actually make sense as a hardening feature because it can turn a benign read overflow into a DoS via BUG(). I think it will be fine for 4.13, but I definitely wouldn't propose 'default y' for a while, even if there was no performance cost (and there is). Fix for this issue is here in case anyone just looks only at this thread (realized I should have passed send-email a reply id): http://marc.info/?l=linux-fsdevel&m=150006772418003&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
