[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140305143800.GA29480@redhat.com>
Date: Wed, 5 Mar 2014 15:38:00 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Khalid Aziz <khalid.aziz@...cle.com>
Cc: tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
peterz@...radead.org, akpm@...ux-foundation.org,
andi.kleen@...el.com, rob@...dley.net, viro@...iv.linux.org.uk,
venki@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] Pre-emption control for userspace
On 03/04, Khalid Aziz wrote:
>
> On 03/04/2014 12:03 PM, Oleg Nesterov wrote:
>>
>> 1. mremap() can move this vma, so do_exit() can't trust ->uaddr
>>
>> 2. Even worse, mremap() itself is not safe. It can do ->close()
>> too and create the new vma with the same vm_ops. Another
>> unmap from (say) exit_mm() won't be happy.
>
> I agree this looks like a potential spot for trouble. I was asking if
> removing sys_munmap() of uaddr from do_exit() solves both of the above
> problems?
How? Of course this won't solve the problems. And there are more problems.
> You have convinced me this sys_munmap() I added is unnecessary.
Cough ;) I didn't try to convince you that it should be removed. It is
necessary (but of course you should not use sys_munmap(), say vm_munmap
is better.
But you know, I think this all doesn't matter. Imho, this proc/mmap
interface is horrible. Perhaps something like tls area visible to kernel
make sense, but it should be more generic at least.
You added /proc/sched_preempt_delay to avoid the syscall. I think it
would be better to simply add vdso_sched_preempt_delay() instead.
But the main problem, of course, is that this feature is questionable.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists