09 Apr, 2009

1 commit

  • Since the whole point of try_then_request_module is to retry
    the operation after a module has been loaded, we must wait for
    the module to fully load.

    Otherwise all sort of things start breaking, e.g., you won't
    be able to read your encrypted disks on the first attempt.

    Signed-off-by: Herbert Xu
    Tested-by: Maciej Rutecki
    Tested-by: Patrick McHardy
    Signed-off-by: Linus Torvalds

    Herbert Xu
     

31 Mar, 2009

1 commit

  • There seems to be a common pattern in the kernel where drivers want to
    call request_module() from inside a module_init() function. Currently
    this would deadlock.

    As a result, several drivers go through hoops like scheduling things via
    kevent, or creating custom work queues (because kevent can deadlock on them).

    This patch changes this to use a request_module_nowait() function macro instead,
    which just fires the modprobe off but doesn't wait for it, and thus avoids the
    original deadlock entirely.

    On my laptop this already results in one less kernel thread running..

    (Includes Jiri's patch to use enum umh_wait)

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Rusty Russell (bool-ified)
    Cc: Jiri Slaby

    Arjan van de Ven
     

17 Oct, 2008

1 commit

  • We currently use a PM notifier to disable user mode helpers before suspend
    and hibernation and to re-enable them during resume. However, this is not
    an ideal solution, because if any drivers want to upload firmware into
    memory before suspend, they have to use a PM notifier for this purpose and
    there is no guarantee that the ordering of PM notifiers will be as
    expected (ie. the notifier that disables user mode helpers has to be run
    after the driver's notifier used for uploading the firmware).

    For this reason, it seems better to move the disabling and enabling of
    user mode helpers to separate functions that will be called by the PM core
    as necessary.

    [akpm@linux-foundation.org: remove unneeded ifdefs]
    Signed-off-by: Rafael J. Wysocki
    Cc: Alan Stern
    Acked-by: Pavel Machek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     

26 Jul, 2008

1 commit

  • Presently call_usermodehelper_setup() uses GFP_ATOMIC. but it can return
    NULL _very_ easily.

    GFP_ATOMIC is needed only when we can't sleep. and, GFP_KERNEL is robust
    and better.

    thus, I add gfp_mask argument to call_usermodehelper_setup().

    So, its callers pass the gfp_t as below:

    call_usermodehelper() and call_usermodehelper_keys():
    depend on 'wait' argument.
    call_usermodehelper_pipe():
    always GFP_KERNEL because always run under process context.
    orderly_poweroff():
    pass to GFP_ATOMIC because may run under interrupt context.

    Signed-off-by: KOSAKI Motohiro
    Cc: "Paul Menage"
    Reviewed-by: Li Zefan
    Acked-by: Jeremy Fitzhardinge
    Cc: Rusty Russell
    Cc: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KOSAKI Motohiro
     

22 Jul, 2008

2 commits


18 Jul, 2007

2 commits

  • Rather than using a tri-state integer for the wait flag in
    call_usermodehelper_exec, define a proper enum, and use that. I've
    preserved the integer values so that any callers I've missed should
    still work OK.

    Signed-off-by: Jeremy Fitzhardinge
    Cc: James Bottomley
    Cc: Randy Dunlap
    Cc: Christoph Hellwig
    Cc: Andi Kleen
    Cc: Paul Mackerras
    Cc: Johannes Berg
    Cc: Ralf Baechle
    Cc: Bjorn Helgaas
    Cc: Joel Becker
    Cc: Tony Luck
    Cc: Kay Sievers
    Cc: Srivatsa Vaddagiri
    Cc: Oleg Nesterov
    Cc: David Howells

    Jeremy Fitzhardinge
     
  • Rather than having hundreds of variations of call_usermodehelper for
    various pieces of usermode state which could be set up, split the
    info allocation and initialization from the actual process execution.

    This means the general pattern becomes:
    info = call_usermodehelper_setup(path, argv, envp); /* basic state */
    call_usermodehelper_(info, stuff...); /* extra state */
    call_usermodehelper_exec(info, wait); /* run process and free info */

    This patch introduces wrappers for all the existing calling styles for
    call_usermodehelper_*, but folds their implementations into one.

    Signed-off-by: Jeremy Fitzhardinge
    Cc: Andi Kleen
    Cc: Rusty Russell
    Cc: David Howells
    Cc: Bj?rn Steinbrink
    Cc: Randy Dunlap

    Jeremy Fitzhardinge
     

24 Feb, 2007

1 commit


17 Feb, 2007

1 commit

  • On recent systems, calls to /sbin/modprobe are handled by udev depending
    on the kind of device the kernel has discovered. This patch creates an
    uevent for the kernels internal request_module(), to let udev take control
    over the request, instead of forking the binary directly by the kernel.
    The direct execution of /sbin/modprobe can be disabled by setting:
    /sys/module/kmod/mod_request_helper (/proc/sys/kernel/modprobe)
    to an empty string, the same way /proc/sys/kernel/hotplug is disabled on an
    udev system.

    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

01 Oct, 2006

1 commit

  • A new member in the ever growing family of call_usermode* functions is
    born. The new call_usermodehelper_pipe() function allows to pipe data to
    the stdin of the called user mode progam and behaves otherwise like the
    normal call_usermodehelp() (except that it always waits for the child to
    finish)

    Signed-off-by: Andi Kleen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andi Kleen
     

26 Apr, 2006

1 commit


24 Jun, 2005

1 commit

  • The attached patch makes it possible to pass a session keyring through to the
    process spawned by call_usermodehelper(). This allows patch 3/3 to pass an
    authorisation key through to /sbin/request-key, thus permitting better access
    controls when doing just-in-time key creation.

    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds