Messages in this thread | | | Date | Wed, 27 Mar 2019 23:52:19 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH v2] x86/syscalls: Mark expected switch fall-throughs |
| |
On Thu, 28 Mar 2019, Dmitry V. Levin wrote: > On Wed, Mar 27, 2019 at 03:29:16PM +0100, Thomas Gleixner wrote: > > On Wed, 27 Mar 2019, Dmitry V. Levin wrote: > > > On Tue, Mar 26, 2019 at 04:12:45PM +0100, Oleg Nesterov wrote: > > > > On 03/23, Thomas Gleixner wrote: > > > [...] > > > > > 2) syscall_set_arguments() has been introduced in 2008 and we still have > > > > > no caller. Instead of polishing it, can it be removed completely or are > > > > > there plans to actually use it? > > > > > > > > I think it can die. > > > > > > When PTRACE_GET_SYSCALL_INFO is finally squeezed into the kernel, > > > we could discuss adding PTRACE_SET_SYSCALL_INFO as well, and it > > > will need syscall_set_arguments(). > > > > So if that ever happens, then adding the code back isn't rocket > > science. But if not, then there is no point in carrying the dead horse > > around another 11 years. > > Given that it took me roughly 4 months to get a relatively simple revert > of commit 5e937a9ae913 accepted into linux-next, adding the code back > might be time-consuming. > > Could we delay the removal of syscall_set_arguments() until > PTRACE_GET_SYSCALL_INFO is merged into the kernel? > I hope it won't take another 11 years.
Hope dies last :)
Seriously. If we keep it can we at least remove all the unused arguments which we have on both functions to simplify the whole mess?
Thanks,
tglx
| |