Hi Andrew, On Thu, 10 Mar 2005 20:40:06 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > in_atomic() is not a reliable indication of whether it is currently safe > to call schedule(). > > arch/ppc64/kernel/viopath.c
in_atomic() in viopath.c was just used to determine if we had initialised enough to be able to wait in a semaphore (i.e. schedule). Thus it can be replaced now with checking system_state for SYSTEM_RUNNING. Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> Test booted on iSeries (which is the only place it is used). -- Cheers, Stephen Rothwell [EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ diff -ruNp linus/arch/ppc64/kernel/viopath.c linus-in_atomic/arch/ppc64/kernel/viopath.c --- linus/arch/ppc64/kernel/viopath.c 2005-01-22 06:09:01.000000000 +1100 +++ linus-in_atomic/arch/ppc64/kernel/viopath.c 2005-03-11 17:19:45.000000000 +1100 @@ -79,7 +79,7 @@ static void handleMonitorEvent(struct Hv /* * We use this structure to handle asynchronous responses. The caller * blocks on the semaphore and the handler posts the semaphore. However, - * if in_atomic() is true in the caller, then wait_atomic is used ... + * if system_state is not SYSTEM_RUNNING, then wait_atomic is used ... */ struct doneAllocParms_t { struct semaphore *sem; @@ -465,7 +465,7 @@ static int allocateEvents(HvLpIndex remo DECLARE_MUTEX_LOCKED(Semaphore); atomic_t wait_atomic; - if (in_atomic()) { + if (system_state != SYSTEM_RUNNING) { parms.used_wait_atomic = 1; atomic_set(&wait_atomic, 1); parms.wait_atomic = &wait_atomic; @@ -475,7 +475,7 @@ static int allocateEvents(HvLpIndex remo } mf_allocate_lp_events(remoteLp, HvLpEvent_Type_VirtualIo, 250, /* It would be nice to put a real number here! */ numEvents, &viopath_donealloc, &parms); - if (in_atomic()) { + if (system_state != SYSTEM_RUNNING) { while (atomic_read(&wait_atomic)) mb(); } else
pgp8HryQkIgDo.pgp
Description: PGP signature
