From: Joel Becker <Joel.Becker@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] + sysctl-use-rcu-protected-sysctl-for-ocfs-group-add-helper.patch added to -mm tree
Date: Fri, 8 Jan 2010 23:42:46 -0800 [thread overview]
Message-ID: <20100109074246.GA9760@mail.oracle.com> (raw)
In-Reply-To: <20100109064438.GB20773@basil.fritz.box>
On Sat, Jan 09, 2010 at 07:44:38AM +0100, Andi Kleen wrote:
> > NAK until I can figure out how to make it always succeed. We can't have
> > umount "succeed" like this.
>
> You can never make a usermode helper execution always succeed. fork()+exec()
> can always fail for a zillion different reasons, for example memory
> allocation. Even if you patched these paths to preallocate
> everything it could still bump into other global process limits.
Sure, usermode helpers can fail for a variety of reasons. Why
add one? Especially a kernel one. Userspace memory is much more
flexible.
> > Maybe the solution is GFP_ATOMIC. Maybe the solution is to lock on the
> > setting end. But this isn't it.
>
> There is no solution if you goal is to make it always succeed,
My goal is to surprise the sysadmin as little as possible.
> Besides right now you plain just have a race that can potentially
> crash the kernel when the helper is executed in the wrong
> window.
Oh, the race needs to be fixed. I can put a mutex around the
string, or I can put GFP_ATOMIC into your patch. I was wondering which
was preferable.
Joel
--
"The one important thing i have learned over the years is the
difference between taking one's work seriously and taking one's self
seriously. The first is imperative and the second is disastrous."
-Margot Fonteyn
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
next prev parent reply other threads:[~2010-01-09 7:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-08 23:54 + sysctl-use-rcu-protected-sysctl-for-ocfs-group-add-helper.patch added to -mm tree akpm
2010-01-09 0:08 ` [Ocfs2-devel] " Joel Becker
2010-01-09 0:55 ` Eric W. Biederman
2010-01-09 1:41 ` Andrew Morton
2010-01-09 3:00 ` Joel Becker
2010-01-09 5:26 ` Andrew Morton
2010-01-09 6:41 ` Andi Kleen
2010-01-09 6:44 ` Andi Kleen
2010-01-09 7:42 ` Joel Becker [this message]
2010-01-09 11:31 ` Andi Kleen
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=20100109074246.GA9760@mail.oracle.com \
--to=joel.becker@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/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.