lkml.org 
[lkml]   [2016]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Getting rid of dynamic TASK_SIZE (on x86, at least)
On Tue, May 10, 2016 at 10:49 AM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> On Tue, May 10, 2016 at 10:26:05AM -0700, Andy Lutomirski wrote:
> ...
>> >>
>> >> It's annoying and ugly. It also makes the idea of doing 32-bit CRIU
>> >> restore by starting in 64-bit mode and switching to 32-bit more
>> >> complicated because it requires switching TASK_SIZE.
>> >
>> > Well, you know I'm not sure it's that annoying. It serves as it should
>> > for task limit. Sure we can add one more parameter into get-unmapped-addr
>> > but same time the task-size will be present in say page faulting code
>> > (the helper might be renamed but it will be here still).
>>
>> Why should the page faulting code care at all what type of task it is?
>> If there's a vma there, fault it in. If there isn't, then don't.
>
> __bad_area_nosemaphore
> ...
> /* Kernel addresses are always protection faults: */
> if (address >= TASK_SIZE)
> error_code |= PF_PROT;
>
> For sure page faulting must consider what kind of fault is it.
> Or we gonna drop such code at all?

That code was bogus. (Well, it was correct unless user code had a way
to create a funny high mapping in an otherwise 32-bit task, but it
still should have been TASK_SIZE_MAX.) Fix sent.

--Andy

\
 
 \ /
  Last update: 2016-05-10 23:41    [W:2.605 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site