On 21 Oct 2016 at 11:32, Jason A. Donenfeld wrote: > On Fri, Oct 21, 2016 at 9:24 AM, PaX Team <[email protected]> wrote: > > in any case, whoever can reproduce this should print out the value of > > head->mac_header before the increment. my guess based on past experience > > on similar network problems is that the field is probably invalid (ffff > > or similar) and adding to it will trigger the size overflow check. this > > in turn means that there's usually some higher level logic bug and you'll > > have to talk to netdev guys as i'm way out of my depths at that point ;). > > Fixed: > https://git.zx2c4.com/WireGuard/commit/?id=867c815c31c754bf97b5fb29afd295b7cf195159
are you sure it was for satisfying PaX only and not a bug itself? :) with the ffff initial value you were basically off by one (unsigned arithmetic wraps so it's as if you had initialized the fields to -1 instead of 0), didn't that matter somewhere beyond the size overflow checks? > >> >> OK, so turns out just getting rid of the __read_mostly fixes things. > > > > FWIW, i've been carrying such a local patch on my gentoo box too ;). > > Got a good #ifdef for PAX that I should use to conditionally not use > __read_mostly in case PAX is in use? if you ask me, you should just get rid of __read_mostly unconditionally (which is what i do in PaX as it interferes with constification) as rtnl_link_ops extends over several cache lines so any concerns with false sharing with writable data would at most affect only a few fields that are rarely used (or the fields could be reordered and/or aligned for such affect). otherwise you'll need to have your own #ifdef based on CONSTIFY_PLUGIN as suggested originally by Toke. cheers, PaX Team _______________________________________________ WireGuard mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/wireguard
