From: Mateusz Guzik <mguzik@redhat.com>
To: Anshuman Khandual <anshuman.linux@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Alexey Dobriyan <adobriyan@gmail.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Jarod Wilson <jarod@redhat.com>,
Jan Stancek <jstancek@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 2/2] proc read mm's {arg,env}_{start,end} with mmap semaphore taken.
Date: Wed, 6 Jan 2016 20:43:31 +0100 [thread overview]
Message-ID: <20160106194329.GB14492@mguzik> (raw)
In-Reply-To: <CAKeScWjvz7Bja6wMw5euWNWYdZ5_ikEdgR1Qk77pcCFajHmbeQ@mail.gmail.com>
On Wed, Jan 06, 2016 at 03:14:22PM +0530, Anshuman Khandual wrote:
> On Wed, Jan 6, 2016 at 10:32 AM, Mateusz Guzik <mguzik@redhat.com> wrote:
> > Only functions doing more than one read are modified. Consumeres
> > happened to deal with possibly changing data, but it does not seem
> > like a good thing to rely on.
>
> There are no other functions which might be reading mm-> members without
> having a lock ? Why just deal with functions with more than one read ?
Ideally all functions would read stuff with some kind of lock.
However, if only one field is read, the lock does not change anything.
Similarly, if multiple fields are read, but are not used for
calculations against each other, the lock likely does not change
anything, so there is no rush here.
Using mmap_sem in all places may or may not be possible as it is, and
even if it is possible it may turn out to be wasteful and maybe
something else should be derived for protection of said fields (maybe a
seq counter?).
That said, patches here only deal with one actual I found and patch up
consumers which had the most potential for trouble. Patching everything
in some way definitely sounds like a good idea and I may get around to
that.
--
Mateusz Guzik
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-01-06 19:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 5:02 [PATCH 0/2] fix up {arg,env}_{start,end} vs prctl Mateusz Guzik
2016-01-06 5:02 ` [PATCH 1/2] prctl: take mmap sem for writing to protect against others Mateusz Guzik
2016-01-06 9:17 ` Anshuman Khandual
2016-01-06 9:35 ` Anshuman Khandual
2016-01-06 10:02 ` Mateusz Guzik
2016-01-06 5:02 ` [PATCH 2/2] proc read mm's {arg,env}_{start,end} with mmap semaphore taken Mateusz Guzik
2016-01-06 9:44 ` Anshuman Khandual
2016-01-06 19:43 ` Mateusz Guzik [this message]
2016-01-07 9:52 ` [PATCH 0/2] fix up {arg,env}_{start,end} vs prctl Cyrill Gorcunov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160106194329.GB14492@mguzik \
--to=mguzik@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.linux@gmail.com \
--cc=gorcunov@openvz.org \
--cc=jarod@redhat.com \
--cc=jstancek@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).