On Fri, Feb 18, 2022 at 1:30 AM David Laight wrote:
>
> From: Andy Lutomirski
> > Sent: 17 February 2022 19:15
> ...
> > This isn't actually optimal. On x86, TASK_SIZE_MAX is a bizarre
> > constant that has a very specific value to work around a bug^Wdesign
On Wed, Feb 16, 2022 at 5:19 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> There are many different ways that access_ok() is defined across
> architectures, but in the end, they all just compare against the
> user_addr_max() value or they accept anything.
>
> Provide one definition that wor
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
> 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 reque
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,
> > >
> > > >
> 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
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 wi
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 more
On Tue, Mar 14, 2017 at 9:12 AM, Till Smejkal
wrote:
> On Mon, 13 Mar 2017, Andy Lutomirski wrote:
>> On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
>> wrote:
>> > On Mon, 13 Mar 2017, Andy Lutomirski wrote:
>> >> This sounds rather complicated. Getting T
On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal
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 segments can be shared by applications t
On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
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?
>
> This is exactly what happens at the e
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 lifetime
> such a VAS can be atta
On Thu, Sep 29, 2016 at 9:47 AM, Vineet Gupta
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:
>
>>
>
On Sep 28, 2016 6:20 PM, "Vineet Gupta" 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.
> >> >
> &
On Wed, Sep 28, 2016 at 3:44 PM, Vineet Gupta
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
>>>>>> > > >> require inter
On Sep 28, 2016 1:37 PM, "Peter Zijlstra" 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 :-),
> >
> > Last time
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
>> > arch/sparc/include/asm/irqflags_64.h:arch_local_irq_save().
>>
>> So I finall
17 matches
Mail list logo
