All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: john.johansen@canonical.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	fhrbata@redhat.com, rusty@rustcorp.com.au, apw@canonical.com,
	Michal Januszewski <spock@gentoo.org>,
	rientjes@google.com, tj@kernel.org, akpm@linux-foundation.org,
	arjan@linux.intel.com, Lars Ellenberg <drbd-dev@lists.linbit.com>
Subject: [Drbd-dev] [PATCH 0/1] usermodehelper: use UMH_WAIT_PROC consistently
Date: Wed, 8 Feb 2012 15:03:33 +0100	[thread overview]
Message-ID: <20120208140333.GA3547@redhat.com> (raw)
In-Reply-To: <201202080227.q182RnCp077670@www262.sakura.ne.jp>

On 02/08, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
>
> > Subject: [PATCH 1/5] usermodehelper: kill umh_wait, renumber UMH_* constants
> >
> > No functional changes, preparation.
> >
> > umh_wait doesn't can't be used as a bitmask, and we do not want
> > to add another argument call_usermodehelper_* helpers.
> >
> > Kill this enum and redefine the UMH_* constants.
>
> There are several users that call call_usermodehelper() without using this
> enum. security/tomoyo/load_policy.c is one of such users

... and there are more.

Thanks a lot Tetsuo.

> and there will be some
> in out-of-tree code.

Well, they should be fixed imho.

> Since I think distro kernels want
> to backport this killable request_module() patchset, this patch should not
> change the constants in a way that makes impossible to detect kABI changes.

Good point, but I think the backporter should take care to not break
the KABI. I do not think we should defer the possible cleanups for
the sake of backporting.

It is possible to skip the first patch and add UMH_KILLABLE, just
call_usermodehelper_exec() needs the additional wait != UMH_NO_WAIT
check before testind/clearing UMH_KILLABLE. UMH_NO_WAIT | KILLABLE
is not possible.

>  #define UMH_WAIT_EXEC	 0	/* wait for the exec, but not the process */
>  #define UMH_WAIT_PROC	 1	/* wait for the process to complete */
>  #define UMH_KILLABLE	 2	/* wait for EXEC/PROC killable */
>  #define UMH_NO_WAIT     4	/* don't wait at all */
>
> might be acceptable because we can remap -1 -> UMH_NO_WAIT on
> call_usermodehelper_exec() side.

Yes... but I think it is better to fix the users.

Perhaps we can do something like

	#define UMH_NO_WAIT	0x8000
	#define UMH_WAIT_EXEC	0x8001
	#define UMH_WAIT_	0x8002

and then call_usermodehelper_exec() does

	/* catch the old buggy users */
	BUG_ON(!(wait & 0x8000) || (wait < 0))

In any case. Whatever we do, I think we should fix the current ab-users.

Andrew, could you take this patch? Or should I split this trivial change
by file/maintainer?

Oleg.


  parent reply	other threads:[~2012-02-08 14:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120202173504.GA25528@redhat.com>
     [not found] ` <201202032254.GCJ30240.SLMOVFFHtJOFOQ@I-love.SAKURA.ne.jp>
     [not found]   ` <20120203151534.GB32503@redhat.com>
     [not found]     ` <201202041426.ICI23458.FFFtOMLOJOVSQH@I-love.SAKURA.ne.jp>
     [not found]       ` <201202051415.JEB43260.SFMJOHLtOFVQOF@I-love.SAKURA.ne.jp>
     [not found]         ` <201202072055.GEC05251.FFMSVHOLOFOQJt@I-love.SAKURA.ne.jp>
     [not found]           ` <20120207171031.GA11215@redhat.com>
2012-02-07 18:44             ` [RFC PATCH 1-5] make request_module() killable Oleg Nesterov
     [not found]             ` <201202080227.q182RnCp077670@www262.sakura.ne.jp>
2012-02-08 14:03               ` Oleg Nesterov [this message]
2012-02-08 14:04                 ` [Drbd-dev] [PATCH 1/1] usermodehelper: use UMH_WAIT_PROC consistently Oleg Nesterov

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=20120208140333.GA3547@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=arjan@linux.intel.com \
    --cc=drbd-dev@lists.linbit.com \
    --cc=fhrbata@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.johansen@canonical.com \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rientjes@google.com \
    --cc=rusty@rustcorp.com.au \
    --cc=spock@gentoo.org \
    --cc=tj@kernel.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.