From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Jason@zx2c4.com Received: from frisell.zx2c4.com (frisell.zx2c4.com [192.95.5.64]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id e74d558e for ; Fri, 21 Oct 2016 08:46:52 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id a61cd7d8 for ; Fri, 21 Oct 2016 08:46:51 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id c5d77a2d (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Fri, 21 Oct 2016 08:46:51 +0000 (UTC) Received: by mail-lf0-f50.google.com with SMTP id l131so127821611lfl.2 for ; Fri, 21 Oct 2016 01:47:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5809CB98.15179.767FB18@pageexec.gmail.com> References: <87mvi0jxsb.fsf@toke.dk> <58096029.23859.5C451AE@pageexec.gmail.com> <5809CB98.15179.767FB18@pageexec.gmail.com> From: "Jason A. Donenfeld" Date: Fri, 21 Oct 2016 17:47:52 +0900 Message-ID: To: Pipacs Content-Type: text/plain; charset=UTF-8 Cc: Emese Revfy , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Brad Spengler , WireGuard mailing list Subject: Re: [WireGuard] Error building against grsec-enabled kernel List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Oct 21, 2016 at 5:02 PM, PaX Team wrote: > are you sure it was for satisfying PaX only and not a bug itself? :) Blurg. I was overly hasty. Note to self: do not prepare conf presentations and push code at the same time. Indeed this /should/ be ~0, which means "unset". I can't see any bugs by making it 0, but it would make things "semantically incorrect", I think. So the bug is actually in the ipv6 fragmentation code. I just sent a patch upstream and CC'd you and Emese. > > 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. I'll use CONFIG_PAX_CONSTIFY_PLUGIN. Upstream uses __read_mostly for that structure always, everywhere else. They'll probably enforce their uniformity, so I'll stick a conditional redefinition of __read_mostly in compat.h.