Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754821Ab3HEVoQ (ORCPT ); Mon, 5 Aug 2013 17:44:16 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:3792 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754738Ab3HEVoO (ORCPT ); Mon, 5 Aug 2013 17:44:14 -0400 X-Authority-Analysis: v=2.0 cv=KJ7Y/S5o c=1 sm=0 a=Sro2XwOs0tJUSHxCKfOySw==:17 a=Drc5e87SC40A:10 a=pFOAptgLnqcA:10 a=5SG0PmZfjMsA:10 a=IkcTkHD0fZMA:10 a=meVymXHHAAAA:8 a=KGjhK52YXX0A:10 a=pvQ05lsfB1wA:10 a=D19gQVrFAAAA:8 a=1yBXjEugSY4mmSu6CksA:9 a=QEXdDO2ut3YA:10 a=Sro2XwOs0tJUSHxCKfOySw==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 67.255.60.225 Message-ID: <1375739051.22073.158.camel@gandalf.local.home> Subject: Re: [RFC] gcc feature request: Moving blocks into sections From: Steven Rostedt To: Mathieu Desnoyers Cc: Linus Torvalds , "H. Peter Anvin" , LKML , gcc , Ingo Molnar , Thomas Gleixner , David Daney , Behan Webster , Peter Zijlstra , Herbert Xu Date: Mon, 05 Aug 2013 17:44:11 -0400 In-Reply-To: <20130805212855.GA23044@Krystal> References: <1375725328.22073.101.camel@gandalf.local.home> <51FFEC56.6040206@linux.intel.com> <1375727010.22073.110.camel@gandalf.local.home> <51FFEEEC.5060902@linux.intel.com> <1375728583.22073.118.camel@gandalf.local.home> <51FFF430.1060701@linux.intel.com> <20130805195446.GA22359@Krystal> <20130805212855.GA23044@Krystal> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2492 Lines: 82 On Mon, 2013-08-05 at 17:28 -0400, Mathieu Desnoyers wrote: > Another thing that bothers me with Steven's approach is that decoding > jumps generated by the compiler seems fragile IMHO. The encodings wont change. If they do, then old kernels will not run on new hardware. Now if it adds a third option to jmp, then we hit the "die" path and know right away that it wont work anymore. Then we fix it properly. > > x86 decoding proposed by https://lkml.org/lkml/2012/3/8/464 : > > +static int make_nop_x86(void *map, size_t const offset) > +{ > + unsigned char *op; > + unsigned char *nop; > + int size; > + > + /* Determine which type of jmp this is 2 byte or 5. */ > + op = map + offset; > + switch (*op) { > + case 0xeb: /* 2 byte */ > + size = 2; > + nop = ideal_nop2_x86; > + break; > + case 0xe9: /* 5 byte */ > + size = 5; > + nop = ideal_nop; > + break; > + default: > + die(NULL, "Bad jump label section (bad op %x)\n", *op); > + __builtin_unreachable(); > + } > > My though is that the code above does not cover all jump encodings that > can be generated by past, current and future x86 assemblers. > > Another way around this issue might be to keep the instruction size > within a non-allocated section: > > static __always_inline bool arch_static_branch(struct static_key *key) > { > asm goto("1:" > "jmp %l[l_yes]\n\t" > "2:" > > ".pushsection __jump_table, \"aw\" \n\t" > _ASM_ALIGN "\n\t" > _ASM_PTR "1b, %l[l_yes], %c0 \n\t" > ".popsection \n\t" > > ".pushsection __jump_table_ilen \n\t" > _ASM_PTR "1b \n\t" /* Address of the jmp */ > ".byte 2b - 1b \n\t" /* Size of the jmp instruction */ > ".popsection \n\t" > > : : "i" (key) : : l_yes); > return false; > l_yes: > return true; > } > > And use (2b - 1b) to know what size of no-op should be used rather than > to rely on instruction decoding. > > Thoughts ? > Then we need to add yet another table of information to the kernel that needs to hang around. This goes with another kernel-discuss request talking about kernel data bloat. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/