On Tue, 1 Nov 2011 11:06:01 -0700
Tejun Heo <tj@xxxxxxxxxx> 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 <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
