From: Al Viro <viro@ZenIV.linux.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
"Michael L. Semon" <mlsemon35@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
jason.low2@hp.com, linux-kernel@vger.kernel.org
Subject: Re: cred_guard_mutex vs seq_file::lock [was: Re: 3.14.0+/x86: lockdep and mutexes not getting along]
Date: Fri, 11 Apr 2014 16:07:25 +0100 [thread overview]
Message-ID: <20140411150724.GI18016@ZenIV.linux.org.uk> (raw)
In-Reply-To: <26259.1397227827@warthog.procyon.org.uk>
On Fri, Apr 11, 2014 at 03:50:27PM +0100, David Howells wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
>
> > Al, David, any bright ideas on how to best fix this?
>
> Have the seq_xxx() code throw an error if current->in_execve is true. I can't
> think of any circumstance where execve() should be reading anything that uses
> seq_xxx().
*cringe*
I don't like it. That really should be a responsiblity of specific ->show();
"I'm going to take that mutex, bugger off if we are in execve()" makes a lot
more sense than having e.g. seq_read() care of that. IOW, I would very
much prefer the patch you've sent last week.
And yes, it might leave lockdep false positives, but that's better dealt with
by annotating the sucker ("this guy has a separate lockdep class for its
->lock"). E.g. by splitting proc_single_file_operations in two and having
the one used for those files do lockdep_set_class() in its ->open().
next prev parent reply other threads:[~2014-04-11 15:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 5:12 3.14.0+/x86: lockdep and mutexes not getting along Michael L. Semon
2014-04-09 12:19 ` Kirill A. Shutemov
2014-04-10 5:42 ` Jason Low
2014-04-10 8:14 ` Peter Zijlstra
2014-04-10 9:15 ` Kirill A. Shutemov
2014-04-10 11:42 ` Peter Zijlstra
2014-04-10 9:18 ` Peter Zijlstra
2014-04-10 14:15 ` Peter Zijlstra
2014-04-11 13:59 ` Valdis.Kletnieks
2014-04-14 7:22 ` [tip:core/urgent] locking/mutex: Fix debug_mutexes tip-bot for Peter Zijlstra
2014-04-10 17:14 ` 3.14.0+/x86: lockdep and mutexes not getting along Jason Low
2014-04-10 17:28 ` Peter Zijlstra
2014-04-10 19:04 ` Jason Low
2014-04-10 23:26 ` Dave Jones
2014-04-10 23:30 ` Dave Jones
2014-04-11 3:48 ` Paul E. McKenney
2014-04-11 13:41 ` Michael L. Semon
2014-04-10 8:12 ` Peter Zijlstra
2014-04-10 8:13 ` Peter Zijlstra
2014-04-10 14:29 ` cred_guard_mutex vs seq_file::lock [was: Re: 3.14.0+/x86: lockdep and mutexes not getting along] Peter Zijlstra
2014-04-11 14:50 ` David Howells
2014-04-11 15:07 ` Al Viro [this message]
2014-07-30 22:31 ` Kirill A. Shutemov
2014-07-30 23:03 ` Kirill A. Shutemov
2014-07-31 7:26 ` 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=20140411150724.GI18016@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=dhowells@redhat.com \
--cc=jason.low2@hp.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mlsemon35@gmail.com \
--cc=peterz@infradead.org \
/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.