Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument

2018-11-21 Thread Andy Lutomirski
their argument. > > This change partially reverts commit 5e937a9ae913 ("syscall_get_arch: > remove useless function arguments"). > Reviewed-by: Andy Lutomirski # for x86 ___ linux-snps-arc mailing list linux-snps-arc@lists.inf

Re: [PATCH 06/13] arc: define syscall_get_arch()

2018-11-09 Thread Andy Lutomirski
> On Nov 9, 2018, at 8:50 AM, Vineet Gupta wrote: > >> On 11/8/18 7:16 PM, Dmitry V. Levin wrote: >> syscall_get_arch() is required to be implemented on all architectures >> that use tracehook_report_syscall_entry() in order to extend >> the generic ptrace API with PTRACE_GET_SYSCALL_INFO

Re: [PATCH 06/13] arc: define syscall_get_arch()

2018-11-09 Thread Andy Lutomirski
On Fri, Nov 9, 2018 at 8:11 AM Alexey Brodkin wrote: > > Hi Andy, > > On Fri, 2018-11-09 at 07:56 -0800, Andy Lutomirski wrote: > > > On Nov 9, 2018, at 7:27 AM, Alexey Brodkin > > > wrote: > > > > > > Hi Andy, > > > > &g

Re: [PATCH 06/13] arc: define syscall_get_arch()

2018-11-09 Thread Andy Lutomirski
> On Nov 9, 2018, at 7:27 AM, Alexey Brodkin > wrote: > > Hi Andy, > >> On Fri, 2018-11-09 at 07:17 -0800, Andy Lutomirski wrote: >> On Fri, Nov 9, 2018 at 6:22 AM Alexey Brodkin >> wrote: >>> Hi Dmitry, >>> >>&g

Re: [PATCH 06/13] arc: define syscall_get_arch()

2018-11-09 Thread Andy Lutomirski
On Fri, Nov 9, 2018 at 6:22 AM Alexey Brodkin wrote: > > Hi Dmitry, > > On Fri, 2018-11-09 at 06:16 +0300, Dmitry V. Levin wrote: > > syscall_get_arch() is required to be implemented on all architectures > > that use tracehook_report_syscall_entry() in order to extend > > the generic ptrace API

Re: [PATCH 00/13] Prepare for PTRACE_GET_SYSCALL_INFO

2018-11-08 Thread Andy Lutomirski
On Thu, Nov 8, 2018 at 7:13 PM Dmitry V. Levin wrote: > > syscall_get_arch() is required to be implemented on all architectures > that use tracehook_report_syscall_entry() in order to extend > the generic ptrace API with PTRACE_GET_SYSCALL_INFO request. Nice! I'm pretty sure you have vastly

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Andy Lutomirski
On Tue, Mar 14, 2017 at 9:12 AM, Till Smejkal <till.smej...@googlemail.com> wrote: > On Mon, 13 Mar 2017, Andy Lutomirski wrote: >> On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal >> <till.smej...@googlemail.com> wrote: >> > On Mon, 13 Mar 2017, Andy Lutomi

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-16 Thread Andy Lutomirski
On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal <till.smej...@googlemail.com> wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: >> > One advantage of VAS segments is that they can be globally queried by user >> > programs >> > which means that VAS se

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-14 Thread Andy Lutomirski
On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal <till.smej...@googlemail.com> wrote: > On Mon, 13 Mar 2017, Andy Lutomirski wrote: >> This sounds rather complicated. Getting TLB flushing right seems >> tricky. Why not just map the same thing into multiple mms? > > T

Re: [RFC PATCH 00/13] Introduce first class virtual address spaces

2017-03-13 Thread Andy Lutomirski
On Mon, Mar 13, 2017 at 3:14 PM, Till Smejkal wrote: > This patchset extends the kernel memory management subsystem with a new > type of address spaces (called VAS) which can be created and destroyed > independently of processes by a user in the system. During its

Re: NMI for ARC

2016-09-29 Thread Andy Lutomirski
On Thu, Sep 29, 2016 at 9:47 AM, Vineet Gupta <vineet.gup...@synopsys.com> wrote: > On 09/28/2016 11:43 PM, Peter Zijlstra wrote: >> On Wed, Sep 28, 2016 at 06:20:29PM -0700, Vineet Gupta wrote: >>> On 09/28/2016 03:26 PM, Andy Lutomirski wrote: > >>

Re: NMI for ARC

2016-09-29 Thread Andy Lutomirski
On Sep 28, 2016 6:20 PM, "Vineet Gupta" <vgu...@synopsys.com> wrote: > > On 09/28/2016 03:26 PM, Andy Lutomirski wrote: > >> Right, so what I think Vineet is asking is if we need to disable NMIs as > >> > well, we cannot on x86 disable NMIs so no. &

Re: NMI for ARC

2016-09-28 Thread Andy Lutomirski
On Wed, Sep 28, 2016 at 3:44 PM, Vineet Gupta <vineet.gup...@synopsys.com> wrote: > On 09/28/2016 03:26 PM, Andy Lutomirski wrote: >>>>>> 2. The low level return code, resume_user_mode_begin and/or >>>>>> resume_kernel_mode >>>>>>

Re: NMI for ARC

2016-09-28 Thread Andy Lutomirski
On Sep 28, 2016 1:37 PM, "Peter Zijlstra" <pet...@infradead.org> wrote: > > On Wed, Sep 28, 2016 at 12:25:11PM -0700, Andy Lutomirski wrote: > > > Yes. If the NMI returns to kernel space you must not attempt preemption > > > for reasons you found :-), >

Re: NMI for ARC

2016-09-28 Thread Andy Lutomirski
On Wed, Sep 28, 2016 at 12:16 AM, Peter Zijlstra wrote: > On Tue, Sep 27, 2016 at 05:22:13PM -0700, Vineet Gupta wrote: > >> > Yeah, Sparc64 might be a better example, it more closely matches your >> > hardware. See >> >