lkml.org 
[lkml]   [2015]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] proc: fix PAGE_SIZE limit of /proc/$PID/cmdline
On Thu, May 28, 2015 at 01:29:42AM +0300, Alexey Dobriyan wrote:
> > > +
> > > + page = (char *)__get_free_page(GFP_TEMPORARY);
> > > + if (!page) {
> > > + rv = -ENOMEM;
> > > + goto out_mmput;
> > > + }
> > > +
> > > + down_read(&mm->mmap_sem);
> > > + arg_start = mm->arg_start;
> > > + arg_end = mm->arg_end;
> > > + env_start = mm->env_start;
> > > + env_end = mm->env_end;
> > > + up_read(&mm->mmap_sem);
> >
> > Could you please explain why this down/up is needed?
>
> Code is written this way to get constistent snapshot of data.

it does not. you fetch data into local variables which is the
same as simply read them locklessly in general (because later
you refer to local vars).

> If you look at PR_SET_MM_* code, you'll notice down_read(&mm->mmap_sem)
> as well which is a separate bug because you're _writing_ those fields
> eventually in prctl_set_mm(), yuck!

yes, there members are modified under read-lock and initially
i didn't see any problem with that except one can have inconsistent
statistics output because another process modified these fields
(we validate that new members are having sane values at least
in new interface and after your first patch). But now I think
that down_write may be more suitable here.

Cyrill


\
 
 \ /
  Last update: 2015-05-28 01:21    [W:0.056 / U:0.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site