From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Galbraith Subject: Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection Date: Fri, 01 Sep 2017 21:24:10 +0200 Message-ID: <1504293850.6217.4.camel@gmx.de> References: <1503996623.8323.20.camel@gmx.de> <1504025721.6024.25.camel@gmx.de> <1504030207.6560.0.camel@gmx.de> <1504069332.8352.3.camel@gmx.de> <1504113212.5852.6.camel@gmx.de> <1504115735.5852.11.camel@gmx.de> <1504145389.23109.4.camel@gmx.de> <1504149176.23109.9.camel@gmx.de> <1504187918.27500.16.camel@gmx.de> <1504199967.666.16.camel@gmx.de> <1504249070.17604.20.camel@gmx.de> <1504271369.332.29.camel@gmx.de> <1504288357.6035.21.camel@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Peter Zijlstra , LKML , Ingo Molnar , "Reshetova, Elena" , Network Development To: Kees Cook Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Fri, 2017-09-01 at 11:58 -0700, Kees Cook wrote: > > The section stuff is supposed to be a trick to push the error case off > into the .text.unlikely area to avoid needing a jmp over the handler > and with possibly some redundancy removal done by the compiler (though > this appears to be rather limited) if it notices a bunch of error > paths are the same. However, in your disassembly, it's inline (!!) in > the code, as if "pushsection" and "popsection" were entirely ignored. > > And when I make my own in6_dev_getx(), I see the same disassembly: > > 0xffffffff818a757b <+181>: lock incl 0x1e0(%rbx) > 0xffffffff818a7582 <+188>: js 0xffffffff818a7584 > 0xffffffff818a7584 <+190>: lea 0x1e0(%rbx),%rcx > 0xffffffff818a758b <+197>: (bad) > > Which is VERY different from how it looks in other places! > > e.g. from lkdtm_REFCOUNT_INC_SATURATED: > > 0xffffffff815657df <+47>: lock incl -0xc(%rbp) > 0xffffffff815657e3 <+51>: js 0xffffffff81565cac > ... > 0xffffffff81565cac: lea -0xc(%rbp),%rcx > 0xffffffff81565cb0: (bad) > > So, at least I can reproduce this in the build now. I must not be > exercising these paths. FWIW, this is with Ubuntu's 6.3.0 gcc. > > I'll try to figure out what's going on here... Heh, make in6_dev_getx() __always_inline. swapper/0-1 [000] d..1 1.438587: ip6_route_init_special_entries: PRE refs.counter:3 swapper/0-1 [000] d..1 1.438590: ip6_route_init_special_entries: POST refs.counter:4 swapper/0-1 [000] d..1 1.438591: ip6_route_init_special_entries: PRE refs.counter:4 swapper/0-1 [000] d..1 1.438592: ip6_route_init_special_entries: POST refs.counter:5 swapper/0-1 [000] d..1 1.438592: ip6_route_init_special_entries: PRE refs.counter:5 swapper/0-1 [000] d..1 1.438593: ip6_route_init_special_entries: POST refs.counter:6 -Mike