lkml.org 
[lkml]   [2007]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Remove process freezer from suspend to RAM pathway
    From
    Date
    On Thu, 2007-07-05 at 11:30 +0200, Pavel Machek wrote:
    >
    > ...but the moment you start blocking tasks that done driver request,
    > you _do_ have mini-freezer of your own, with pretty much the same
    > problems.

    No, not at all the same problems. Those tasks will block, but that will
    be harmless because we won't have some "freezer" things waiting for all
    tasks to reach a "stable" point (calling try_to_freeze()). We just let
    them block wherever we want, as long as it doesn't prevent a -driver-
    from suspending, which should be allright, we have no problem.

    > In another message I shown that removing freezer will not help with
    > FUSE in general case.

    I disagree.

    > It probably does not help with firmware, too; as soon as udev attempts
    > to do something with your wireless card, it is blocked, and if the
    > wireless card needs the firmware from udev, you are deadlocked.

    Firmware load has been a problem since day 1, I've talked about it
    multiple times, it's broken with or without the freezer, and so far, the
    reaction of pretty much everybody has been to dig their head deeper in
    the mud and ignore the problem.

    There are other issues (again, with or without freezer) that should be
    dealt with. For example, drivers that haven't yet got their suspend()
    callback or already have got their resume() may rely on services of the
    kernel that are still blocked, that's where things may go hairy.
    request_firmware() within resume() is a typical example of that.

    There are a few things we should do in that area. For example, once we
    start to call driver suspend's, we should probably set a system wide
    flag that will do things such as:

    - block usermode helpers (either make call_usermodehelper return
    something like -EBUSY or have it queue up the calls and issue them later
    when thing are resuming, we need to look closely at what semantic we
    want here).

    - Silently add GFP_NOIO to all allocations, to avoid having things
    blocking in kmalloc() with a mutex held that will deadlock with
    suspend() in a driver for example. Or set some way to have all GFP
    waiters wakeup and fail rather than wait for IOs. It's hard/bizarre but
    necessary, again, with or without a freezer.

    - Deal with the firmware problem. The best way is probably to have an
    async request_firmware interface(). Another thing is, drivers may want
    to cache their firmware in main memory, that sort of thing...

    And that's just a small list off the top of my mind, of known problems
    that will cause deadlocks or misbehaviours today, with or without the
    freezer, and that need to be addressed.

    Ben.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-06 00:51    [W:2.739 / U:0.932 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site