On Sat, Aug 23, 2014 at 09:29:15PM +0200, Oleg Nesterov wrote:
> On 08/23, Cyrill Gorcunov wrote:
> >
> > On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> > >
> > > And btw, where do you see RLIMIT_STACK in do_shmat() ?
> >
> > Indirectly, though start_stack pointer. We assign it
On 08/23, Cyrill Gorcunov wrote:
>
> On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> >
> > And btw, where do you see RLIMIT_STACK in do_shmat() ?
>
> Indirectly, though start_stack pointer. We assign it in setup_arg_pages
> taking into
> account RLIMIT_STACK value, then do_shmat
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
> > >
> > > Besides, it can't help anyway. cred_guard_mutex is per-process (not
> > > per-thread),
> > > suppose that a vfork()'ed child does prctl() while another thread reads
> > > the
> > > parent's /proc/pid/auxv.
> >
> > Then
On 08/23, Cyrill Gorcunov wrote:
>
> On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
> >
> > On 08/23, Oleg Nesterov wrote:
> > >
> > > On 08/23, Cyrill Gorcunov wrote:
> > >
> > > > Looks like I need
> > > > to use cred_guard_mutex instead of task_lock here, no?
> > >
> > > Please
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
> forgot to mention,
>
> On 08/23, Oleg Nesterov wrote:
> >
> > On 08/23, Cyrill Gorcunov wrote:
> >
> > > Looks like I need
> > > to use cred_guard_mutex instead of task_lock here, no?
> >
> > Please don't. First of all, it can't
forgot to mention,
On 08/23, Oleg Nesterov wrote:
>
> On 08/23, Cyrill Gorcunov wrote:
>
> > Looks like I need
> > to use cred_guard_mutex instead of task_lock here, no?
>
> Please don't. First of all, it can't help because proc_pid_auxv() doesn't hold
> this lock. It does mm_access() which drops
On 08/23, Cyrill Gorcunov wrote:
>
> On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
> > >
> > > It should protect from allocation/devetion/mergin of another vma. IOW when
> > > I lookup for vma I need to be sure it exist and won't disappear at least
> > > while I validate it.
> >
>
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
> >
> > It should protect from allocation/devetion/mergin of another vma. IOW when
> > I lookup for vma I need to be sure it exist and won't disappear at least
> > while I validate it.
>
> plus you need mmap_sem (at least for reading)
On 08/23, Cyrill Gorcunov wrote:
>
> On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
> > Hi Cyrill,
> >
> > I think the patch is fine but I can't understand the usage of mmap_sem
> > and alloc_lock,
> >
> > > + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
> >
> >
On 08/23, Cyrill Gorcunov wrote:
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma()
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
It should protect from allocation/devetion/mergin of another vma. IOW when
I lookup for vma I need to be sure it exist and won't disappear at least
while I validate it.
plus you need mmap_sem (at least for reading) when you
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
It should protect from allocation/devetion/mergin of another vma. IOW when
I lookup for vma I need to be sure it exist and won't disappear at least
while I validate it.
plus you need
forgot to mention,
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't help because proc_pid_auxv() doesn't hold
this lock. It does mm_access() which drops this lock
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
forgot to mention,
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't help because
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
Besides, it can't help anyway. cred_guard_mutex is per-process (not
per-thread),
suppose that a vfork()'ed child does prctl() while another thread reads
the
parent's /proc/pid/auxv.
Then either I need to use
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
And btw, where do you see RLIMIT_STACK in do_shmat() ?
Indirectly, though start_stack pointer. We assign it in setup_arg_pages
taking into
account RLIMIT_STACK value, then do_shmat operates
On Sat, Aug 23, 2014 at 09:29:15PM +0200, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
And btw, where do you see RLIMIT_STACK in do_shmat() ?
Indirectly, though start_stack pointer. We assign it in
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
> Hi Cyrill,
>
> I think the patch is fine but I can't understand the usage of mmap_sem
> and alloc_lock,
>
> > + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
>
> OK, find_vma() needs mmap_sem. But otherwise,
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
> + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this should be called
under down_read(>mmap_sem) ? What this lock tries to
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this should be called
under down_read(mm-mmap_sem) ? What this lock tries to
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this
22 matches
Mail list logo
