On Mon, Jun 01, 2015 at 12:53:36PM -0700, Andy Lutomirski wrote: > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf <jpoim...@redhat.com> wrote: > > On Fri, May 29, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote: > >> On Thu, May 28, 2015 at 6:17 AM, Ingo Molnar <mi...@kernel.org> wrote: > >> > > >> > * Jan Beulich <jbeul...@suse.com> wrote: > >> > > >> >> > and meanwhile you can keep a revert of this patch ported to SUSE > >> >> > kernels in > >> >> > whatever fashion you prefer. > >> >> > >> >> Funny suggestion - I don't think that's reasonable for us to do. Or if > >> >> we were > >> >> to, we could as well invest in doing the re-work you're asking for; I > >> >> don't > >> >> think anyone will have the time to do either. > >> > > >> > That's fair enough: if there's not enough resources to keep a feature > >> > maintainable > >> > upstream then it should not be upstream in that form. > >> > > >> > This isn't just some driver we can let bit-rot in peace until it finds a > >> > maintainer (or not), without affecting anyone but users of that driver. > >> > > >> > This is hundreds of usage sites of ugly code intermixed with critical > >> > pieces of > >> > assembly code that negatively affects the hackability of everything. > >> > > >> > Also, with the feature missing completely, maybe someone finds a method > >> > to > >> > introduce it in a maintainable fashion, while with the feature included > >> > upstream > >> > there's very little pressure to do that. As a bonus we'd also win a > >> > workable dwarf > >> > unwinder. > >> > >> Before doing something drastic like this, I think we should get Josh's > >> opinion, since I think he's working on a new (?) unwinder. > >> > >> FWIW, musl is considering some kind of automatic annotation scheme: > >> > >> http://www.openwall.com/lists/musl/2015/05/13/5 > > > > Thanks for the link! I found a newer version of it here: > > > > http://www.openwall.com/lists/musl/2015/05/31/5 > > > > Overall I think that script is a really good solution. > > > > From what I can tell, it tracks the CFA (stack pointer) perfectly. > > (Which is actually pretty straightfoward if you just hook into function > > entry/exit, push/pop, and add/sub to rsp). > > > > It also does a nice job at making a best effort at tracking the caller's > > register values (which are less important than CFA but still nice to > > have). > > It might be nice to be able to reliably unwind out from an exception / > interrupt / syscall frame into userspace or into the kernel code that > trapped, complete with registers. > > In any event, we'll almost certainly have to manually annotate these > weird types of entries. I wonder if we could manage to annotate just > the entry parts and let a magic script do the rest.
Yeah. Any callable function can be annotated "magically". We may have to manually annotate the rest. -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
