On Fri, Jul 29, 2022 at 10:12 AM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > That's a good point. Though note that the current WARN_ON is also > dependent on DEBUG being set.
Sure. And I think that's ok. > > (a) that constant should be a bit lower, so that we *can* use a 1kB > > stack frame warning on 64-bit architectures > > That's not so much possible. This needs to do a DFS traversal of the > trie, which means it can be 128 nodes deep since IPv6 addresses have > 128 bits. Ahh. Ok. That at least explains where the constant comes from. That would be a good thing to have somewhere in that definition of the value ;) And I agree that malloc() isn't a great choice. I don't really worry about the stack frame warning (I just raised it to the same 2k limit I have on my x86-64 box), so doing that 1k allocation is fine. And with that constant 128 explained, I don't think it's wrong to not even test for overflow. We don't test for things that can't happen. But *if* you test for it for debug purposes, then at that point I think you need to just do the "warn and don't corrupt stack". Linus