On 03/28/2017 03:51 PM, Thomas Gleixner wrote:
On Tue, 28 Mar 2017, Dmitry Safonov wrote:
On 03/22/2017 01:21 AM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
v3:
- clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, this wants to be c
On Tue, 28 Mar 2017, Dmitry Safonov wrote:
> On 03/22/2017 01:21 AM, Thomas Gleixner wrote:
> > On Tue, 21 Mar 2017, Dmitry Safonov wrote:
> > > v3:
> > > - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
> >
> > For correctness sake, this wants to be cleared in the IA32 path as
On 03/22/2017 01:21 AM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
v3:
- clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, this wants to be cleared in the IA32 path as
well. It's not causing any harm, but
I'll amend the patch.
On 03/22/2017 01:34 AM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, h...@zytor.com wrote:
On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
v3:
- clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, this w
On Tue, 21 Mar 2017, h...@zytor.com wrote:
> On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner wrote:
> >On Tue, 21 Mar 2017, Dmitry Safonov wrote:
> >> v3:
> >> - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
> >
> >For correctness sake, this wants to be cleared in the IA32 p
On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner wrote:
>On Tue, 21 Mar 2017, Dmitry Safonov wrote:
>> v3:
>> - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
>
>For correctness sake, this wants to be cleared in the IA32 path as
>well. It's not causing any harm, but
>
>I'l
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
> v3:
> - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, this wants to be cleared in the IA32 path as
well. It's not causing any harm, but
I'll amend the patch.
Thanks,
tglx
2017-03-22 0:16 GMT+03:00 Adam Borowski :
> On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote:
>> After my changes to mmap(), its code now relies on the bitness of
>> performing syscall. According to that, it chooses the base of allocation:
>> mmap_base for 64-bit mmap() and mmap_compa
On March 21, 2017 2:16:48 PM PDT, Adam Borowski wrote:
>On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote:
>> After my changes to mmap(), its code now relies on the bitness of
>> performing syscall. According to that, it chooses the base of
>allocation:
>> mmap_base for 64-bit mmap()
On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote:
> After my changes to mmap(), its code now relies on the bitness of
> performing syscall. According to that, it chooses the base of allocation:
> mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall.
> It was done by:
>
After my changes to mmap(), its code now relies on the bitness of
performing syscall. According to that, it chooses the base of allocation:
mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall.
It was done by:
commit 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for
32-bit mm
11 matches
Mail list logo