On Tue, 1 Nov 2011 11:06:01 -0700 Tejun Heo <[email protected]> wrote: > On Tue, Nov 01, 2011 at 06:59:53PM +0100, Oleg Nesterov wrote: > > > #define wait_event_freezekillable(wq, condition) \ > > > do { > > > \ > > > DEFINE_WAIT(__wait); \ > > > for (;;) { \ > > > prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); \ > > > if (condition || fatal_signal_pending(current)) \ > > > break; \ > > > schedule(); \ > > > > No, this can't work, afaics. > > > > Once the caller recieves a non-fatal signal (gets TIF_SIGPENDING), > > schedule() won't block in TASK_INTERRUPTIBLE state. > > > > IOW, wait_event_freezekillable() becomes a busy-wait loop. > > Yeah yeah, Trond already pointed it out. I forgot about the > sigpending special case in schedule(), which I think is rather odd, oh > well. Any better ideas? >
This is (obviously) not my area of expertise, but the TAKE_WAKEFREEZE flag that you mentioned earlier might be the best way to solve this. Tasks that want to be awoken on freezer events can set that flag and we can have the freezer code wake them up. For the NFS and CIFS code, we'll just ensure that we set that flag This does mean a rather nasty proliferation of new wait_event_* macros, and we'll need a new schedule_timeout_freezekillable() variant for the new state. It looks fairly straightforward to implement though. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
