From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
David Howells <dhowells@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Sasha Levin <levinsasha928@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 0/5] (Was: procfs: silence lockdep warning about read vs. exec seq_file)
Date: Mon, 4 Aug 2014 10:59:50 +0400 [thread overview]
Message-ID: <20140804065950.GB2239@moon> (raw)
In-Reply-To: <20140803211843.GA13330@redhat.com>
On Sun, Aug 03, 2014 at 11:18:43PM +0200, Oleg Nesterov wrote:
> On 08/03, Oleg Nesterov wrote:
> >
> > The question is, why m_start() calls mm_access(). This is not even
> > strictly correct if the task execs between m_stop() + m_start().
> >
> > Can't we do something like below? The patch is obviously horrible and
> > incomplete, just to explain what I meant. Basically this is what
> > proc_mem_operations does.
>
> Absolutely untested, only for review.
>
> What do you all think?
>
> Sure, with this change you can't open (say) /proc/pid/maps, and read the
> new mappings after exec. But hopefully this is fine? And again, this
> matches /proc/pid/mem.
>
> lock_trace() users need another fix.
If only I didn't miss something obvious this is quite the good cleanup,
thanks Oleg!
next prev parent reply other threads:[~2014-08-04 6:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-02 20:10 [PATCH, RESEND] procfs: silence lockdep warning about read vs. exec seq_file Kirill A. Shutemov
2014-08-03 16:44 ` Oleg Nesterov
2014-08-03 21:18 ` [PATCH 0/5] (Was: procfs: silence lockdep warning about read vs. exec seq_file) Oleg Nesterov
2014-08-03 21:19 ` [PATCH 1/5] fs/proc/task_mmu.c: don't use task->mm in m_start() and show_*map() Oleg Nesterov
2014-08-03 21:19 ` [PATCH 2/5] fs/proc/task_mmu.c: unify/simplify do_maps_open() and numa_maps_open() Oleg Nesterov
2014-08-03 21:20 ` [PATCH 3/5] proc: introduce proc_mem_open() Oleg Nesterov
2014-08-03 21:20 ` [PATCH 4/5] fs/proc/task_mmu.c: introduce the "stable" proc_maps_private->mm Oleg Nesterov
2014-08-03 21:20 ` [PATCH 5/5] fs/proc/task_mmu.c: change m_start() to rely on priv->mm and avoid mm_access() Oleg Nesterov
2014-08-04 6:59 ` Cyrill Gorcunov [this message]
2014-08-04 9:20 ` [PATCH 0/5] (Was: procfs: silence lockdep warning about read vs. exec seq_file) Kirill A. Shutemov
2014-08-04 14:55 ` Oleg Nesterov
2014-08-05 3:42 ` [PATCH, RESEND] procfs: silence lockdep warning about read vs. exec seq_file Eric W. Biederman
2014-08-05 8:46 ` Kirill A. Shutemov
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=20140804065950.GB2239@moon \
--to=gorcunov@gmail.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=levinsasha928@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.