Re: Removing entry trampoline and associated reversions
On 27/08/18 19:42, Andy Lutomirski wrote: > [gah -- accidentally hit send] > > On Mon, Aug 27, 2018 at 9:42 AM, Andy Lutomirski wrote: >> Hi all- >> >> We had an unfortunate conflict. Adrian did all the plumbing to get >> entry_trampoline to play nicelyh with kcore and perf. Meanwhile, I >> was working on getting rid of the entry trampoline. Adrian's code is >> merged and mine is finally in good shape, and there's an obvious >> conflict. >> >> So I did a bunch of reverts, all but one of which were clean. The >> series is here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti We are kind of stuck with the 'perf tools' changes as they are. That is because CONFIG_KASAN changes the size of the cpu entry area, which means that the kernel patches are still potentially useful for kernels from v4.15 to v4.19 incl., which in turn means we still need 'perf tools' support for them. If we didn't want to support that, we still need the tools workaround that hard-codes the trampoline addresses for v4.15 to v4.19. And possibly we would need to ensure perf.data files (and copies of kcore) with trampoline maps recorded, are still handled correctly. >> >> and the messy revert is here: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti=50ef6380e448650b48db979d7d1f20a325b0a273 Should be able to get rid of KCORE_REMAP and kcore_list.vaddr also. > > Is this the right approach? > You could leave the tools changes to me if you want.
Re: Removing entry trampoline and associated reversions
On 27/08/18 19:42, Andy Lutomirski wrote: > [gah -- accidentally hit send] > > On Mon, Aug 27, 2018 at 9:42 AM, Andy Lutomirski wrote: >> Hi all- >> >> We had an unfortunate conflict. Adrian did all the plumbing to get >> entry_trampoline to play nicelyh with kcore and perf. Meanwhile, I >> was working on getting rid of the entry trampoline. Adrian's code is >> merged and mine is finally in good shape, and there's an obvious >> conflict. >> >> So I did a bunch of reverts, all but one of which were clean. The >> series is here: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti We are kind of stuck with the 'perf tools' changes as they are. That is because CONFIG_KASAN changes the size of the cpu entry area, which means that the kernel patches are still potentially useful for kernels from v4.15 to v4.19 incl., which in turn means we still need 'perf tools' support for them. If we didn't want to support that, we still need the tools workaround that hard-codes the trampoline addresses for v4.15 to v4.19. And possibly we would need to ensure perf.data files (and copies of kcore) with trampoline maps recorded, are still handled correctly. >> >> and the messy revert is here: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti=50ef6380e448650b48db979d7d1f20a325b0a273 Should be able to get rid of KCORE_REMAP and kcore_list.vaddr also. > > Is this the right approach? > You could leave the tools changes to me if you want.
Re: Removing entry trampoline and associated reversions
[gah -- accidentally hit send] On Mon, Aug 27, 2018 at 9:42 AM, Andy Lutomirski wrote: > Hi all- > > We had an unfortunate conflict. Adrian did all the plumbing to get > entry_trampoline to play nicelyh with kcore and perf. Meanwhile, I > was working on getting rid of the entry trampoline. Adrian's code is > merged and mine is finally in good shape, and there's an obvious > conflict. > > So I did a bunch of reverts, all but one of which were clean. The > series is here: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti > > and the messy revert is here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti=50ef6380e448650b48db979d7d1f20a325b0a273 Is this the right approach?
Re: Removing entry trampoline and associated reversions
[gah -- accidentally hit send] On Mon, Aug 27, 2018 at 9:42 AM, Andy Lutomirski wrote: > Hi all- > > We had an unfortunate conflict. Adrian did all the plumbing to get > entry_trampoline to play nicelyh with kcore and perf. Meanwhile, I > was working on getting rid of the entry trampoline. Adrian's code is > merged and mine is finally in good shape, and there's an obvious > conflict. > > So I did a bunch of reverts, all but one of which were clean. The > series is here: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti > > and the messy revert is here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pti=50ef6380e448650b48db979d7d1f20a325b0a273 Is this the right approach?
Removing entry trampoline and associated reversions
Hi all- We had an unfortunate conflict. Adrian did all the plumbing to get entry_trampoline to play nicelyh with kcore and perf. Meanwhile, I was working on getting rid of the entry trampoline. Adrian's code is merged and mine is finally in good shape, and there's an obvious conflict. So I did a bunch of reverts, all but one of which were clean. The series is here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti and the messy revert is here:
Removing entry trampoline and associated reversions
Hi all- We had an unfortunate conflict. Adrian did all the plumbing to get entry_trampoline to play nicelyh with kcore and perf. Meanwhile, I was working on getting rid of the entry trampoline. Adrian's code is merged and mine is finally in good shape, and there's an obvious conflict. So I did a bunch of reverts, all but one of which were clean. The series is here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti and the messy revert is here:
