09 Jun, 2009

1 commit

  • Our async work synchronization was broken by "async: make sure
    independent async domains can't accidentally entangle" (commit
    d5a877e8dd409d8c702986d06485c374b705d340), because it would report
    the wrong lowest active async ID when there was both running and
    pending async work.

    This caused things like no being able to read the root filesystem,
    resulting in missing console devices and inability to run 'init',
    causing a boot-time panic.

    This fixes it by properly returning the lowest pending async ID: if
    there is any running async work, that will have a lower ID than any
    pending work, and we should _not_ look at the pending work list.

    There were alternative patches from Jaswinder and James, but this one
    also cleans up the code by removing the pointless 'ret' variable and
    the unnecesary testing for an empty list around 'for_each_entry()' (if
    the list is empty, the for_each_entry() thing just won't execute).

    Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=13474
    Reported-and-tested-by: Chris Clayton
    Cc: Jaswinder Singh Rajput
    Cc: James Bottomley
    Cc: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

25 May, 2009

1 commit

  • The problem occurs when async_synchronize_full_domain() is called when
    the async_pending list is not empty. This will cause lowest_running()
    to return the cookie of the first entry on the async_pending list, which
    might be nothing at all to do with the domain being asked for and thus
    cause the domain synchronization to wait for an unrelated domain. This
    can cause a deadlock if domain synchronization is used from one domain
    to wait for another.

    Fix by running over the async_pending list to see if any pending items
    actually belong to our domain (and return their cookies if they do).

    Signed-off-by: James Bottomley
    Signed-off-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    James Bottomley
     

29 Mar, 2009

1 commit


09 Feb, 2009

5 commits


06 Feb, 2009

1 commit

  • alpha:

    kernel/async.c: In function 'run_one_entry':
    kernel/async.c:141: warning: format '%lli' expects type 'long long int', but argument 2 has type 'async_cookie_t'
    kernel/async.c:149: warning: format '%lli' expects type 'long long int', but argument 2 has type 'async_cookie_t'
    kernel/async.c:149: warning: format '%lld' expects type 'long long int', but argument 4 has type 's64'
    kernel/async.c: In function 'async_synchronize_cookie_special':
    kernel/async.c:250: warning: format '%lli' expects type 'long long int', but argument 3 has type 's64'

    Cc: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

13 Jan, 2009

1 commit

  • At 37000 feet somewhere near Greenland I woke up from a half-sleep with the
    realisation that __lowest_in_progress() is buggy. After landing I checked
    and there were indeed 2 problems with it; this patch fixes both:
    * The order of the list checks was wrong
    * The locking was not correct.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

10 Jan, 2009

1 commit


09 Jan, 2009

1 commit

  • turns out that there are real problems with allowing async
    tasks that are scheduled from async tasks to run after
    the async_synchronize_full() returns.

    This patch makes the _full more strict and a complete
    synchronization. Later I might need to add back a lighter
    form of synchronization for other uses.. but not right now.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

08 Jan, 2009

2 commits

  • while tracking the asynchronous calls during boot using the initcall_debug
    convention is useful, doing it once the kernel is done is actually
    bad now that we use asynchronous operations post boot as well...

    Signed-off-by: Arjan van de Ven

    Arjan van de Ven
     
  • Right now, most of the kernel boot is strictly synchronous, such that
    various hardware delays are done sequentially.

    In order to make the kernel boot faster, this patch introduces
    infrastructure to allow doing some of the initialization steps
    asynchronously, which will hide significant portions of the hardware delays
    in practice.

    In order to not change device order and other similar observables, this
    patch does NOT do full parallel initialization.

    Rather, it operates more in the way an out of order CPU does; the work may
    be done out of order and asynchronous, but the observable effects
    (instruction retiring for the CPU) are still done in the original sequence.

    Signed-off-by: Arjan van de Ven

    Arjan van de Ven