From: Nicholas Piggin <npiggin@gmail.com> To: "Luis R. Rodriguez" <mcgrof@kernel.org> Cc: gnomes@lxorguk.ukuu.org.uk, linux-ia64@vger.kernel.org, jkosina@suse.cz, benh@kernel.crashing.org, ming.lei@canonical.com, heiko.carstens@de.ibm.com, platform-driver-x86@vger.kernel.org, James.Bottomley@HansenPartnership.com, paul.gortmaker@windriver.com, paulus@samba.org, mpe@ellerman.id.au, hpa@zytor.com, masami.hiramatsu.pt@hitachi.com, mchehab@osg.samsung.com, linux-arch@vger.kernel.org, markus.heiser@darmarit.de, sparclinux@vger.kernel.org, xen-devel@lists.xensource.com, linux@arm.linux.org.uk, linux-sh@vger.kernel.org, will.deacon@arm.com, korea.drzix@gmail.com, x86@kernel.org, anil.s.keshavamurthy@intel.com, fontana@sharpeleven.org, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, dvhart@infradead.org, dwmw2@infradead.org, david.vrabel@citrix.com, linux-xtensa@linux-xtensa.org, pali.rohar@gmail.com, keescook@chromium.org, arnd@arndb Subject: Re: [PATCH v4 04/16] generic-sections: add section core helpers Date: Thu, 25 Aug 2016 12:06:33 +1000 [thread overview] Message-ID: <20160825120633.057b2f6f@roar.ozlabs.ibm.com> (raw) In-Reply-To: <20160824201253.GS3296@wotan.suse.de> On Wed, 24 Aug 2016 22:12:53 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> wrote: > On Wed, Aug 24, 2016 at 01:51:41PM +1000, Nicholas Piggin wrote: > > On Tue, 23 Aug 2016 19:33:06 +0200 > > "Luis R. Rodriguez" <mcgrof@kernel.org> wrote: > > > > > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote: > > > > On Fri, 19 Aug 2016 14:34:02 -0700 > > > > mcgrof@kernel.org wrote: > > > > > +/** > > > > > + * DOC: Standard ELF section use in Linux > > > > > + * > > > > > + * Linux makes use of the standard ELF sections, this sections documents > > > > > + * these. > > > > > + */ > > > > > + > > > > > +/** > > > > > + * DOC: SECTION_RODATA > > > > > + * > > > > > + * Macro name for code which must be protected from write access, read only > > > > > + * data. > > > > > + */ > > > > > +#define SECTION_RODATA .rodata > > > > > > > > These, for example. The exact name of the section is important in linker > > > > scripts and asm, so I can't see the benefit of hiding it. I could be > > > > missing the bigger picture. > > > > > > There's two goals by using a macro for these core names. One is to allow us > > > to easily aggregate documentation in central place for each, the second is > > > to then provide more easily grep'able helpers so we can use them when devising > > > extensions or using them in extensions which further customize the sections > > > in the kernel. > > Just thought of more more justification I had forgotten. I cover it below. > > > Documentation is good, but not necessary to have the extra name indirection. > > Fair point. > > > Sections tend (not always, but it would be nice if they did) to follow the > > .name convention, which makes them reasonably easy to grep for. > > git grep .text doesn't work but that is typically expected... > git grep \.text doesn't work as expected > > Ah finally: > > git grep "\.text" seems to work. But WTF. This is simply how grep works though. > But: > > git grep SECTION_TEXT works as expected immediately. > > I guess its a matter of perspective. > > > They are also > > the names you'll be grepping for when you look at disassembly. > > Sure but if you're grepping asm, you very likely know what to look for. After you have gone through the extra layer of naming indirection to work out what it is. I'm still not sold on the name indirection and hiding wildcards. Not just for asm grepping, but I don't think it's a negative thing for devs working on the linker to know what actual section names and commands are being used, as much as possible. > > > > > +/** > > > > > + * DOC: SECTION_TEXT > > > > > + * > > > > > + * Macro name used to annotate code (functions) used during regular > > > > > + * kernel run time. This is combined with `SECTION_RODATA`, only this > > > > > + * section also allows for execution. > > > > > + * > > > > > + */ > > > > > +#define SECTION_TEXT .text > > > > > > > > I can't see how these comments are right. .rodata doesn't seem like it > > > > should be combined with .text, and is not currently on powerpc. I think > > > > it's for data, not code. > > > > > > On x86 and powerpc .rodata follows .text. > > > > But follows is not the same as combined. > > True and as I confirmed below, on PowerPC this is certainly not true. OK. > > And together with the comment that RODATA is for code (which is wrong, it's data), > > Where did I have that? If you refer to the above SECTION_TEXT documentation, it > refers to SECTION_TEXT being for code, but the goal was to highlight that > SECTION_TEXT is for execution, while SECTION_RODATA was for data. This > certainly can use some love though, thanks, will just drop the SECTION_RODATA > reference *or* properly explain the whole thing below. +/** + * DOC: SECTION_RODATA + * + * Macro name for code which must be protected from write access, read only + * data. + */ +#define SECTION_RODATA .rodata This together with the "combined with .text" part confused me. > > it make it seem like it is actually combined. > > Will fix to ensure this is understood in proper context. Thanks. > > > Its not intended to grab .text but rather its for helpers that provide customizations > > > based on a core section as base, in this case given your example it would be used by > > > section ranges and linker tables for .text. Both section ranges and linker tables > > > use postfix .something for their customizations. The SECTION_ALL() macro then is > > > a helper for customizations on a core section. > > > > Right, it's just that .text.* is *immediately* obvious. SECTION_ALL() is not. > > Which is why I was suggesting perhaps an alternative name. > > > > If the name is misleading would SECTION_CORE_ALL() be better with some documentation > > > explaining this and the above goal ? > > > > I don't know... not to be glib, but .section.* would be better and not require > > documentation. > > Well consider the issues below for a second... and keep in mind with linker > tables we are about to open the prospect to add more things into the kernel's > sections more easily than before. > > > CORE does not really add anything as far as I can see. Other types of .text including > > ones which are automatically generated by the compiler, for better or worse, are > > .text.x sections too. > > Actually, sorry, in this case SECTION_ALL() *was* intended for things that are > not linker tables or section ranges, instead this was for globs that want to > use the new section macro names, so we only use this for: > *(SECTION_ALL(SECTION_RODATA)) at this time. It would seem we just did not > have .text.* and friends (other section names documented here). So this is > more of a reaction to provide a way to use a glob for section names if they > have a macro name. > > The idea was to add helpers to do the globbing more easily. > > The glob for sections now documented is SECTION_ALL() > The glob that is range specific is SECTION_RNG_ALL() > The glob that is linker table specific is SECTION_TBL_ALL() I still don't see this is better than .text* .text.* .text.range.* .text.table.* etc. > > The only one needing SECTION_ALL() it turns out was .rodata: > > - *(.rodata) *(.rodata.*) \ > + *(SECTION_RODATA) *(SECTION_ALL(SECTION_RODATA)) \ > > > I would like to see more standardisation of naming convention -- some sections start > > with .., some start with no dots, some use . to separate logical "subsections", others > > use underscores or something else. > > Agreed... Actually while at it -- anyone happen to know why the two dot thing > started creeping up? I'm not sure, but I suspect it may have been due to . not being a valid C symbol name. I'm not saying it's always the wrong thing to do, but I think copy&paste and lack of documentation has left the naming conventions in need of some love. The section names themselves of course can and should have some greppable distinguishing conventions -- we don't need macro name for that. > > I just don't see it would be a problem to simply use the raw names and linker > > wildcards for it. > > A concern here is more abuse over this if we now expose APIs to users to > more easily customize sections. So let's review what the chances are. > > $ git grep DEFINE_SECTION_RANGE| egrep -v "tools|include|Document" > kernel/kprobes.c:DEFINE_SECTION_RANGE(kprobes, SECTION_TEXT); > > These require the actual desired section specified. Do we want > to just hide that ? Or are we OK in assuming users willing to use > proper names here? For me, DEFINE_SECTION_RANGE(kprobes, .text) would be fine. > > BTW, I'm not trying to bikeshed :) This doesn't affect the value of your > > patch at all, it was just an offhand thing I saw. > > Just saying, if you say its ugly please help me with a different name then. Sure, but point taken it's more productive to discuss fundamentals first. Let's consider exact details afterward. > > It's fine, I don't mind too much. I think asm-generic/asm.h should be > > fine for generic asm'isms though. Or assembler.h to match compiler.h. > > I'd like address this in asm.h but I would hope we can do this as a secondary > step, given the length of this patch set already. Thoughts ? It's not a big deal, so whatever suits you. Some of the bugfixes and cleanups could be pushed through various arch and other maintainers first too, which would make the core series look more managable and touch fewer parts. > > Well but your macros are not linker sections. They are "Linux sections", which > > appear to give you a start and end symbol name, but does not direct the linker > > to create a specific output section. > > You're right the above can use some love to help explain this better. > > How about: > > At the top just use "Linux sections helpers" > > Then: > > /** > * DOC: Introduction > * > * We document below a dedicated set of helpers used in Linux to make sections > * defined in the Linux linker script accessible in C code in a generic form and > * and provide certain attributes about them. > */ > > > I just can't work out what exactly is a > > "custom Linux section", and what DECLARE_LINUX_SECTION(), for example, actaully > > gives you. > > Its a way to replace the: > > extern char foo[], foo__end[]; > > So this provides a generalized form to use declarations used in C code to make > the linker script start and end symbols from esctions accessible in C code. Since > DEFINE_SECTION_RANGE() and DEFINE_LINKTABLE() macros use this, then the > DECLARE_LINUX_SECTION() is only needed if you need access to these symbols in C > code outside of the one that is defining and mainly in charge of managing the > section. We provide DECLARE_*() helpers for section ranges and linker tables > though so those can be used instead to help annotate the type of a custom > section they are. Oh, that makes more sense. The SECTION stuff and custom sections was confusing me. I would prefer just to drop all the LINUX_SECTION naming and make it match the functionality you're using. For example: +DEFINE_LINKTABLE(struct jump_entry, __jump_table); + /* mutex to protect coming/going of the the jump_label table */ static DEFINE_MUTEX(jump_label_mutex); @@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key *key, void __init jump_label_init(void) { - struct jump_entry *iter_start = __start___jump_table; - struct jump_entry *iter_stop = __stop___jump_table; struct static_key *key = NULL; struct jump_entry *iter; @@ -292,9 +293,10 @@ void __init jump_label_init(void) return; jump_label_lock(); - jump_label_sort_entries(iter_start, iter_stop); + jump_label_sort_entries(LINUX_SECTION_START(__jump_table), + LINUX_SECTION_END(__jump_table)); Now I think this is a fine abstraction to have. I think it would look even cleaner if you had: LINKTABLE_START(__jump_table) LINKTABLE_END(__jump_table) Then do we need to even have the LINUX_SECTION middle man at all? Thanks, Nick _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com> To: "Luis R. Rodriguez" <mcgrof@kernel.org> Cc: hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, jpoimboe@redhat.com, bp@alien8.de, linux@arm.linux.org.uk, mhiramat@kernel.org, masami.hiramatsu.pt@hitachi.com, jbaron@akamai.com, heiko.carstens@de.ibm.com, ananth@linux.vnet.ibm.com, anil.s.keshavamurthy@intel.com, davem@davemloft.net, realmz6@gmail.com, x86@kernel.org, luto@amacapital.net, keescook@chromium.org, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, rusty@rustcorp.com.au, gnomes@lxorguk.ukuu.org.uk, alan@linux.intel.com, dwmw2@infradead.org, arnd@arndb.de, ming.lei@canonical.com, linux-arch@vger.kernel.org, benh@kernel.crashing.org, ananth@in.ibm.com, pebolle@tiscali.nl, fontana@sharpeleven.org, david.vrabel@citrix.com, konrad.wilk@oracle.com, mcb30@ipxe.org, jgross@suse.com, andrew.cooper3@citrix.com, andriy.shevchenko@linux.intel.com, paul.gortmaker@windriver.com, xen-devel@lists.xensource.com, ak@linux.intel.com, pali.rohar@gmail.com, dvhart@infradead.org, platform-driver-x86@vger.kernel.org, mmarek@suse.com, linux@rasmusvillemoes.dk, jkosina@suse.cz, korea.drzix@gmail.com, linux-kbuild@vger.kernel.org, tony.luck@intel.com, akpm@linux-foundation.org, linux-ia64@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, rostedt@goodmis.org, jani.nikula@intel.com, mchehab@osg.samsung.com, markus.heiser@darmarit.de, acme@redhat.com, jolsa@kernel.org, msalter@redhat.com, chris@zankel.net, jcmvbkbc@gmail.com, linux-xtensa@linux-xtensa.org, paulus@samba.org, mpe@ellerman.id.au, James.Bottomley@HansenPartnership.com Subject: Re: [PATCH v4 04/16] generic-sections: add section core helpers Date: Thu, 25 Aug 2016 12:06:33 +1000 [thread overview] Message-ID: <20160825120633.057b2f6f@roar.ozlabs.ibm.com> (raw) Message-ID: <20160825020633.fIIepdmnAVgszN69XCXugH3FzuRwqT2VcasrvmJJzfA@z> (raw) In-Reply-To: <20160824201253.GS3296@wotan.suse.de> On Wed, 24 Aug 2016 22:12:53 +0200 "Luis R. Rodriguez" <mcgrof@kernel.org> wrote: > On Wed, Aug 24, 2016 at 01:51:41PM +1000, Nicholas Piggin wrote: > > On Tue, 23 Aug 2016 19:33:06 +0200 > > "Luis R. Rodriguez" <mcgrof@kernel.org> wrote: > > > > > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote: > > > > On Fri, 19 Aug 2016 14:34:02 -0700 > > > > mcgrof@kernel.org wrote: > > > > > +/** > > > > > + * DOC: Standard ELF section use in Linux > > > > > + * > > > > > + * Linux makes use of the standard ELF sections, this sections documents > > > > > + * these. > > > > > + */ > > > > > + > > > > > +/** > > > > > + * DOC: SECTION_RODATA > > > > > + * > > > > > + * Macro name for code which must be protected from write access, read only > > > > > + * data. > > > > > + */ > > > > > +#define SECTION_RODATA .rodata > > > > > > > > These, for example. The exact name of the section is important in linker > > > > scripts and asm, so I can't see the benefit of hiding it. I could be > > > > missing the bigger picture. > > > > > > There's two goals by using a macro for these core names. One is to allow us > > > to easily aggregate documentation in central place for each, the second is > > > to then provide more easily grep'able helpers so we can use them when devising > > > extensions or using them in extensions which further customize the sections > > > in the kernel. > > Just thought of more more justification I had forgotten. I cover it below. > > > Documentation is good, but not necessary to have the extra name indirection. > > Fair point. > > > Sections tend (not always, but it would be nice if they did) to follow the > > .name convention, which makes them reasonably easy to grep for. > > git grep .text doesn't work but that is typically expected... > git grep \.text doesn't work as expected > > Ah finally: > > git grep "\.text" seems to work. But WTF. This is simply how grep works though. > But: > > git grep SECTION_TEXT works as expected immediately. > > I guess its a matter of perspective. > > > They are also > > the names you'll be grepping for when you look at disassembly. > > Sure but if you're grepping asm, you very likely know what to look for. After you have gone through the extra layer of naming indirection to work out what it is. I'm still not sold on the name indirection and hiding wildcards. Not just for asm grepping, but I don't think it's a negative thing for devs working on the linker to know what actual section names and commands are being used, as much as possible. > > > > > +/** > > > > > + * DOC: SECTION_TEXT > > > > > + * > > > > > + * Macro name used to annotate code (functions) used during regular > > > > > + * kernel run time. This is combined with `SECTION_RODATA`, only this > > > > > + * section also allows for execution. > > > > > + * > > > > > + */ > > > > > +#define SECTION_TEXT .text > > > > > > > > I can't see how these comments are right. .rodata doesn't seem like it > > > > should be combined with .text, and is not currently on powerpc. I think > > > > it's for data, not code. > > > > > > On x86 and powerpc .rodata follows .text. > > > > But follows is not the same as combined. > > True and as I confirmed below, on PowerPC this is certainly not true. OK. > > And together with the comment that RODATA is for code (which is wrong, it's data), > > Where did I have that? If you refer to the above SECTION_TEXT documentation, it > refers to SECTION_TEXT being for code, but the goal was to highlight that > SECTION_TEXT is for execution, while SECTION_RODATA was for data. This > certainly can use some love though, thanks, will just drop the SECTION_RODATA > reference *or* properly explain the whole thing below. +/** + * DOC: SECTION_RODATA + * + * Macro name for code which must be protected from write access, read only + * data. + */ +#define SECTION_RODATA .rodata This together with the "combined with .text" part confused me. > > it make it seem like it is actually combined. > > Will fix to ensure this is understood in proper context. Thanks. > > > Its not intended to grab .text but rather its for helpers that provide customizations > > > based on a core section as base, in this case given your example it would be used by > > > section ranges and linker tables for .text. Both section ranges and linker tables > > > use postfix .something for their customizations. The SECTION_ALL() macro then is > > > a helper for customizations on a core section. > > > > Right, it's just that .text.* is *immediately* obvious. SECTION_ALL() is not. > > Which is why I was suggesting perhaps an alternative name. > > > > If the name is misleading would SECTION_CORE_ALL() be better with some documentation > > > explaining this and the above goal ? > > > > I don't know... not to be glib, but .section.* would be better and not require > > documentation. > > Well consider the issues below for a second... and keep in mind with linker > tables we are about to open the prospect to add more things into the kernel's > sections more easily than before. > > > CORE does not really add anything as far as I can see. Other types of .text including > > ones which are automatically generated by the compiler, for better or worse, are > > .text.x sections too. > > Actually, sorry, in this case SECTION_ALL() *was* intended for things that are > not linker tables or section ranges, instead this was for globs that want to > use the new section macro names, so we only use this for: > *(SECTION_ALL(SECTION_RODATA)) at this time. It would seem we just did not > have .text.* and friends (other section names documented here). So this is > more of a reaction to provide a way to use a glob for section names if they > have a macro name. > > The idea was to add helpers to do the globbing more easily. > > The glob for sections now documented is SECTION_ALL() > The glob that is range specific is SECTION_RNG_ALL() > The glob that is linker table specific is SECTION_TBL_ALL() I still don't see this is better than .text* .text.* .text.range.* .text.table.* etc. > > The only one needing SECTION_ALL() it turns out was .rodata: > > - *(.rodata) *(.rodata.*) \ > + *(SECTION_RODATA) *(SECTION_ALL(SECTION_RODATA)) \ > > > I would like to see more standardisation of naming convention -- some sections start > > with .., some start with no dots, some use . to separate logical "subsections", others > > use underscores or something else. > > Agreed... Actually while at it -- anyone happen to know why the two dot thing > started creeping up? I'm not sure, but I suspect it may have been due to . not being a valid C symbol name. I'm not saying it's always the wrong thing to do, but I think copy&paste and lack of documentation has left the naming conventions in need of some love. The section names themselves of course can and should have some greppable distinguishing conventions -- we don't need macro name for that. > > I just don't see it would be a problem to simply use the raw names and linker > > wildcards for it. > > A concern here is more abuse over this if we now expose APIs to users to > more easily customize sections. So let's review what the chances are. > > $ git grep DEFINE_SECTION_RANGE| egrep -v "tools|include|Document" > kernel/kprobes.c:DEFINE_SECTION_RANGE(kprobes, SECTION_TEXT); > > These require the actual desired section specified. Do we want > to just hide that ? Or are we OK in assuming users willing to use > proper names here? For me, DEFINE_SECTION_RANGE(kprobes, .text) would be fine. > > BTW, I'm not trying to bikeshed :) This doesn't affect the value of your > > patch at all, it was just an offhand thing I saw. > > Just saying, if you say its ugly please help me with a different name then. Sure, but point taken it's more productive to discuss fundamentals first. Let's consider exact details afterward. > > It's fine, I don't mind too much. I think asm-generic/asm.h should be > > fine for generic asm'isms though. Or assembler.h to match compiler.h. > > I'd like address this in asm.h but I would hope we can do this as a secondary > step, given the length of this patch set already. Thoughts ? It's not a big deal, so whatever suits you. Some of the bugfixes and cleanups could be pushed through various arch and other maintainers first too, which would make the core series look more managable and touch fewer parts. > > Well but your macros are not linker sections. They are "Linux sections", which > > appear to give you a start and end symbol name, but does not direct the linker > > to create a specific output section. > > You're right the above can use some love to help explain this better. > > How about: > > At the top just use "Linux sections helpers" > > Then: > > /** > * DOC: Introduction > * > * We document below a dedicated set of helpers used in Linux to make sections > * defined in the Linux linker script accessible in C code in a generic form and > * and provide certain attributes about them. > */ > > > I just can't work out what exactly is a > > "custom Linux section", and what DECLARE_LINUX_SECTION(), for example, actaully > > gives you. > > Its a way to replace the: > > extern char foo[], foo__end[]; > > So this provides a generalized form to use declarations used in C code to make > the linker script start and end symbols from esctions accessible in C code. Since > DEFINE_SECTION_RANGE() and DEFINE_LINKTABLE() macros use this, then the > DECLARE_LINUX_SECTION() is only needed if you need access to these symbols in C > code outside of the one that is defining and mainly in charge of managing the > section. We provide DECLARE_*() helpers for section ranges and linker tables > though so those can be used instead to help annotate the type of a custom > section they are. Oh, that makes more sense. The SECTION stuff and custom sections was confusing me. I would prefer just to drop all the LINUX_SECTION naming and make it match the functionality you're using. For example: +DEFINE_LINKTABLE(struct jump_entry, __jump_table); + /* mutex to protect coming/going of the the jump_label table */ static DEFINE_MUTEX(jump_label_mutex); @@ -274,8 +277,6 @@ static void __jump_label_update(struct static_key *key, void __init jump_label_init(void) { - struct jump_entry *iter_start = __start___jump_table; - struct jump_entry *iter_stop = __stop___jump_table; struct static_key *key = NULL; struct jump_entry *iter; @@ -292,9 +293,10 @@ void __init jump_label_init(void) return; jump_label_lock(); - jump_label_sort_entries(iter_start, iter_stop); + jump_label_sort_entries(LINUX_SECTION_START(__jump_table), + LINUX_SECTION_END(__jump_table)); Now I think this is a fine abstraction to have. I think it would look even cleaner if you had: LINKTABLE_START(__jump_table) LINKTABLE_END(__jump_table) Then do we need to even have the LINUX_SECTION middle man at all? Thanks, Nick
next prev parent reply other threads:[~2016-08-25 2:06 UTC|newest] Thread overview: 292+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-19 21:33 [PATCH v4 00/16] linux: generalize sections, ranges and linker tables mcgrof 2016-08-19 21:33 ` mcgrof 2016-08-19 21:33 ` [PATCH v4 01/16] x86: remove LTO_REFERENCE_INITCALL() mcgrof 2016-08-19 21:33 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 02/16] dell-smo8800: include uaccess.h mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 03/16] scripts/module-common.lds: enable generation mcgrof 2016-08-19 21:34 ` [PATCH v4 04/16] generic-sections: add section core helpers mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-23 1:26 ` Nicholas Piggin 2016-08-23 1:26 ` Nicholas Piggin 2016-08-23 17:33 ` Luis R. Rodriguez 2016-08-23 17:33 ` Luis R. Rodriguez 2016-08-24 3:51 ` Nicholas Piggin 2016-08-24 3:51 ` Nicholas Piggin 2016-08-24 20:12 ` Luis R. Rodriguez 2016-08-24 20:12 ` Luis R. Rodriguez 2016-08-25 2:06 ` Nicholas Piggin [this message] 2016-08-25 2:06 ` Nicholas Piggin 2016-08-25 6:05 ` Luis R. Rodriguez 2016-08-25 6:05 ` Luis R. Rodriguez 2016-08-25 6:51 ` Nicholas Piggin 2016-08-25 6:51 ` Nicholas Piggin 2016-08-25 17:52 ` Luis R. Rodriguez 2016-08-25 17:52 ` Luis R. Rodriguez 2016-08-26 3:00 ` Nicholas Piggin 2016-08-26 6:38 ` Luis R. Rodriguez 2016-08-26 7:33 ` Nicholas Piggin 2016-08-26 7:33 ` Nicholas Piggin 2016-08-26 13:22 ` Luis R. Rodriguez 2016-08-26 13:22 ` Luis R. Rodriguez 2016-08-26 13:28 ` Nicholas Piggin 2016-08-26 13:28 ` Nicholas Piggin 2016-08-19 21:34 ` [PATCH v4 05/16] xtensa: skip adding literal when SORT() is used mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 07/16] tables.h: add linker table support mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 09/16] firmware/Makefile: force recompilation if makefile changes mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 10/16] firmware: port built-in section to linker table mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 11/16] jump_label: move guard #endif down where it belongs mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 12/16] jump_label: port __jump_table to linker tables mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 13/16] dynamic_debug: port to use " mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 14/16] kprobes: move kprobe declarations to asm-generic/kprobes.h mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-22 15:11 ` Masami Hiramatsu 2016-08-22 15:11 ` Masami Hiramatsu 2016-08-23 16:31 ` Luis R. Rodriguez 2016-08-23 16:31 ` Luis R. Rodriguez 2016-08-29 14:04 ` Masami Hiramatsu 2016-08-29 14:04 ` Masami Hiramatsu 2016-08-30 20:07 ` Luis R. Rodriguez 2016-08-30 20:07 ` Luis R. Rodriguez 2017-02-01 20:02 ` Luis R. Rodriguez 2017-02-01 20:02 ` Luis R. Rodriguez 2016-08-19 21:34 ` [PATCH v4 15/16] kprobes: port .kprobes.text to section range mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:34 ` [PATCH v4 16/16] kprobes: port blacklist kprobes to linker table mcgrof 2016-08-19 21:34 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 0/7] tools: add linker table userspace sandbox mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 1/7] tools: add a userspace tools bug.h mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 2/7] tools: add a basic tools printk.h mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 3/7] tools: add init.h for tools mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 4/7] tools: add __used and enable to override mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 5/7] tools: expand export.h with VMLINUX_SYMBOL() mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 6/7] tools: add __section() to compiler.h mcgrof 2016-08-19 21:41 ` mcgrof 2016-08-19 21:41 ` [PATCH v1 7/7] tools: add userspace linker table sandbox mcgrof 2016-08-19 22:31 ` Kees Cook 2016-08-23 0:07 ` Luis R. Rodriguez 2016-08-23 0:28 ` H. Peter Anvin 2016-08-23 0:28 ` H. Peter Anvin 2016-08-23 14:30 ` Arnaldo Carvalho de Melo 2016-08-23 14:30 ` Arnaldo Carvalho de Melo 2016-08-24 2:28 ` Kees Cook 2016-08-24 2:28 ` Kees Cook 2016-08-24 12:39 ` Arnaldo Carvalho de Melo 2016-08-24 12:39 ` Arnaldo Carvalho de Melo 2016-08-24 16:20 ` Luis R. Rodriguez 2016-08-24 16:20 ` Luis R. Rodriguez 2016-08-24 19:17 ` Arnaldo Carvalho de Melo 2016-08-24 19:17 ` Arnaldo Carvalho de Melo 2016-08-20 4:57 ` [PATCH v1 0/7] tools: add linker table userspace sandbox Rob Landley 2016-08-20 4:57 ` Rob Landley 2016-08-21 4:59 ` Rich Felker 2016-08-21 4:59 ` Rich Felker 2016-08-22 4:04 ` H. Peter Anvin 2016-08-22 4:04 ` H. Peter Anvin 2016-08-22 9:59 ` Vegard Nossum 2016-08-22 9:59 ` Vegard Nossum 2016-08-23 15:49 ` Luis R. Rodriguez 2016-08-23 15:49 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 0/6] " Luis R. Rodriguez 2016-12-22 2:39 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 1/6] tools: add a userspace tools bug.h Luis R. Rodriguez 2016-12-22 2:39 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 2/6] tools: add init.h for tools Luis R. Rodriguez 2016-12-22 2:39 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 3/6] tools: add __used and enable to override Luis R. Rodriguez 2016-12-22 2:39 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 4/6] tools: expand export.h with VMLINUX_SYMBOL() Luis R. Rodriguez 2016-12-22 2:39 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 5/6] tools: add __section() to compiler.h Luis R. Rodriguez 2016-12-22 2:39 ` Luis R. Rodriguez 2016-12-22 2:39 ` [PATCH v2 6/6] tools: add userspace linker table sandbox Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 0/6] tools: add linker table userspace sandbox Luis R. Rodriguez 2017-01-09 15:02 ` Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 1/6] tools: add a userspace tools bug.h Luis R. Rodriguez 2017-01-09 15:02 ` Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 2/6] tools: add init.h for tools Luis R. Rodriguez 2017-01-09 15:02 ` Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 3/6] tools: add __used and enable to override Luis R. Rodriguez 2017-01-09 15:02 ` Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 4/6] tools: expand export.h with VMLINUX_SYMBOL() Luis R. Rodriguez 2017-01-09 15:02 ` Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 5/6] tools: add __section() to compiler.h Luis R. Rodriguez 2017-01-09 15:02 ` Luis R. Rodriguez 2017-01-09 15:02 ` [PATCH v3 6/6] tools: add userspace linker table sandbox Luis R. Rodriguez 2017-01-15 21:12 ` [PATCH v4 0/6] tools: add linker table userspace sandbox Luis R. Rodriguez 2017-01-15 21:12 ` Luis R. Rodriguez 2017-01-15 21:12 ` [PATCH v4 1/6] tools: add a userspace tools bug.h Luis R. Rodriguez 2017-01-15 21:12 ` Luis R. Rodriguez 2017-01-19 11:01 ` Greg KH 2017-01-19 11:01 ` Greg KH 2017-01-15 21:12 ` [PATCH v4 2/6] tools: add init.h for tools Luis R. Rodriguez 2017-01-15 21:12 ` Luis R. Rodriguez 2017-01-19 11:02 ` Greg KH 2017-01-19 11:02 ` Greg KH 2017-01-15 21:12 ` [PATCH v4 3/6] tools: add __used and enable to override Luis R. Rodriguez 2017-01-15 21:12 ` Luis R. Rodriguez 2017-01-19 11:02 ` Greg KH 2017-01-19 11:02 ` Greg KH 2017-01-15 21:12 ` [PATCH v4 4/6] tools: expand export.h with VMLINUX_SYMBOL() Luis R. Rodriguez 2017-01-15 21:12 ` Luis R. Rodriguez 2017-01-19 11:03 ` Greg KH 2017-01-19 11:03 ` Greg KH 2017-01-19 11:04 ` Greg KH 2017-01-19 11:04 ` Greg KH 2017-01-15 21:12 ` [PATCH v4 5/6] tools: add __section() to compiler.h Luis R. Rodriguez 2017-01-15 21:12 ` Luis R. Rodriguez 2017-01-19 11:04 ` Greg KH 2017-01-19 11:04 ` Greg KH 2017-01-15 21:12 ` [PATCH v4 6/6] tools: add userspace linker table sandbox Luis R. Rodriguez 2017-01-19 11:07 ` Greg KH 2016-12-22 2:37 ` [PATCH v5 00/14] linux: generalize sections, ranges and linker tables Luis R. Rodriguez 2016-12-22 2:37 ` Luis R. Rodriguez 2016-12-22 2:37 ` [PATCH v5 01/14] generic-sections: add section core helpers Luis R. Rodriguez 2016-12-22 2:37 ` Luis R. Rodriguez 2016-12-22 2:37 ` [PATCH v5 02/14] xtensa: skip adding literal when SORT() is used Luis R. Rodriguez 2016-12-22 2:37 ` Luis R. Rodriguez 2016-12-22 2:37 ` [PATCH v5 03/14] ranges.h: add helpers to build and identify Linux section ranges Luis R. Rodriguez 2016-12-22 2:37 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 04/14] tables.h: add linker table support Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 13:58 ` Andy Shevchenko 2016-12-22 13:58 ` Andy Shevchenko 2017-01-03 21:25 ` Luis R. Rodriguez 2017-01-03 21:25 ` Luis R. Rodriguez 2017-01-04 9:47 ` Andy Shevchenko 2017-01-06 20:00 ` Luis R. Rodriguez 2017-01-06 20:43 ` Andy Shevchenko 2017-01-09 14:22 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 05/14] kbuild: enable option to force compile force-obj-y and force-lib-y Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 06/14] firmware/Makefile: force recompilation if makefile changes Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 07/14] firmware: port built-in section to linker table Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 08/14] jump_label: move guard #endif down where it belongs Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 09/14] jump_label: port __jump_table to linker tables Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 14:08 ` Andy Shevchenko 2016-12-22 14:08 ` Andy Shevchenko 2017-01-03 21:27 ` Luis R. Rodriguez 2017-01-03 21:27 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 10/14] dynamic_debug: port to use " Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 11/14] kprobes: move kprobe declarations to asm-generic/kprobes.h Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 12/14] kprobes: port .kprobes.text to section range Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 13/14] kprobes: port blacklist kprobes to linker table Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2016-12-22 2:38 ` [PATCH v5 14/14] lib: add linker tables test driver Luis R. Rodriguez 2016-12-22 2:38 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 00/14] linux: generalize sections, ranges and linker tables Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 01/14] generic-sections: add section core helpers Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-16 14:46 ` Borislav Petkov 2017-01-16 14:46 ` Borislav Petkov 2017-01-09 14:58 ` [PATCH v6 02/14] xtensa: skip adding literal when SORT() is used Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 03/14] ranges.h: add helpers to build and identify Linux section ranges Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 04/14] tables.h: add linker table support Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 05/14] kbuild: enable option to force compile force-obj-y and force-lib-y Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 06/14] firmware/Makefile: force recompilation if makefile changes Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 07/14] firmware: port built-in section to linker table Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 08/14] jump_label: move guard #endif down where it belongs Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 09/14] jump_label: port __jump_table to linker tables Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 10/14] dynamic_debug: port to use " Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 11/14] kprobes: move kprobe declarations to asm-generic/kprobes.h Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 12/14] kprobes: port .kprobes.text to section range Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 13/14] kprobes: port blacklist kprobes to linker table Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 14:58 ` [PATCH v6 14/14] lib: add linker tables test driver Luis R. Rodriguez 2017-01-09 14:58 ` Luis R. Rodriguez 2017-01-09 16:27 ` [PATCH v6 00/14] linux: generalize sections, ranges and linker tables Andy Shevchenko 2017-01-09 16:27 ` Andy Shevchenko 2017-01-09 16:36 ` Luis R. Rodriguez 2017-01-09 17:12 ` Shevchenko, Andriy 2017-01-09 17:16 ` Luis R. Rodriguez 2017-01-09 18:29 ` Andy Shevchenko 2017-01-09 18:29 ` Andy Shevchenko 2017-01-11 14:37 ` Luis R. Rodriguez 2017-01-11 14:37 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 " Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 01/14] generic-sections: add section core helpers Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:09 ` Greg KH 2017-01-19 11:09 ` Greg KH 2017-01-15 21:10 ` [PATCH v7 02/14] xtensa: skip adding literal when SORT() is used Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-18 11:29 ` Borislav Petkov 2017-01-18 11:29 ` Borislav Petkov 2017-01-15 21:10 ` [PATCH v7 03/14] ranges.h: add helpers to build and identify Linux section ranges Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:11 ` Greg KH 2017-01-19 11:11 ` Greg KH 2017-01-15 21:10 ` [PATCH v7 04/14] tables.h: add linker table support Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:13 ` Greg KH 2017-01-19 11:13 ` Greg KH 2017-01-15 21:10 ` [PATCH v7 05/14] kbuild: enable option to force compile force-obj-y and force-lib-y Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:18 ` Greg KH 2017-01-19 11:18 ` Greg KH 2017-01-15 21:10 ` [PATCH v7 06/14] firmware/Makefile: force recompilation if makefile changes Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:19 ` Greg KH 2017-01-19 11:19 ` Greg KH 2017-01-23 16:12 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 07/14] firmware: port built-in section to linker table Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 08/14] jump_label: move guard #endif down where it belongs Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:20 ` Greg KH 2017-01-19 11:20 ` Greg KH 2017-01-15 21:10 ` [PATCH v7 09/14] jump_label: port __jump_table to linker tables Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-19 11:24 ` Greg KH 2017-01-19 11:24 ` Greg KH 2017-01-15 21:10 ` [PATCH v7 10/14] dynamic_debug: port to use " Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 11/14] kprobes: move kprobe declarations to asm-generic/kprobes.h Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 12/14] kprobes: port .kprobes.text to section range Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 13/14] kprobes: port blacklist kprobes to linker table Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez 2017-01-15 21:10 ` [PATCH v7 14/14] lib: add linker tables test driver Luis R. Rodriguez 2017-01-15 21:10 ` Luis R. Rodriguez -- strict thread matches above, loose matches on Subject: below -- 2016-08-19 21:32 [PATCH v4 00/16] linux: generalize sections, ranges and linker tables mcgrof 2016-08-19 21:32 ` [PATCH v4 04/16] generic-sections: add section core helpers mcgrof 2016-08-19 21:32 ` mcgrof 2016-08-19 21:47 ` Kees Cook 2016-08-22 23:13 ` Luis R. Rodriguez
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160825120633.057b2f6f@roar.ozlabs.ibm.com \ --to=npiggin@gmail.com \ --cc=James.Bottomley@HansenPartnership.com \ --cc=anil.s.keshavamurthy@intel.com \ --cc=arnd@arndb \ --cc=benh@kernel.crashing.org \ --cc=catalin.marinas@arm.com \ --cc=david.vrabel@citrix.com \ --cc=dvhart@infradead.org \ --cc=dwmw2@infradead.org \ --cc=fontana@sharpeleven.org \ --cc=gnomes@lxorguk.ukuu.org.uk \ --cc=heiko.carstens@de.ibm.com \ --cc=hpa@zytor.com \ --cc=jkosina@suse.cz \ --cc=keescook@chromium.org \ --cc=korea.drzix@gmail.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-ia64@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=linux-xtensa@linux-xtensa.org \ --cc=linux@arm.linux.org.uk \ --cc=markus.heiser@darmarit.de \ --cc=masami.hiramatsu.pt@hitachi.com \ --cc=mcgrof@kernel.org \ --cc=mchehab@osg.samsung.com \ --cc=ming.lei@canonical.com \ --cc=mingo@redhat.com \ --cc=mpe@ellerman.id.au \ --cc=pali.rohar@gmail.com \ --cc=paul.gortmaker@windriver.com \ --cc=paulus@samba.org \ --cc=platform-driver-x86@vger.kernel.org \ --cc=sparclinux@vger.kernel.org \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ --cc=xen-devel@lists.xensource.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).