On Mon, Oct 31, 2011 at 6:53 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Mon, Oct 31, 2011 at 06:45:48PM -0500, Steve French wrote: >> >> Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> >> >> Cc: Jeff Layton <jlayton@xxxxxxxxxx> >> >> --- >> >> Neil, Steve, do the network filesystems need a way to indicate "I can >> >> either be killed or enter freezer"? >> >> Probably, yes, but I will defer to Jeff as he has looked >> more recently at these issues. >> >> I can explain cifs state, and disconnect/reconnection of sessions >> (and smb2 is a little more feature rich in this regard), but will >> let Jeff explain the more subtle points you are getting at. > > Hmmm... I'm getting confused. > > For nfs, this really is a non-issue. Either the user wants nointr or > intr behavior. NFS nointr is rather crazy - it's basically "nothing > can do anything to tasks which is doing NFS IO until it's complete" > and really meant to be used for servers sharing filesystems for /usr, > /home and stuff. It doesn't make whole lot of sense on systems which > may go suspend and that's why there's intr option. > > I suppose the problem is that cifs doesn't know how to do 'intr' yet, > right? If that really is the problem, the correct long term solution > would be implementing proper intr behavior and it doesn't make any > sense to push this type of change to PM core to for short term > workaround. Just use prepare_to_wait() / schedule() / finish_wait() > directly w/ INTERRUPTIBLE sleep and don't break out of wait loop on > signal_pending(). If this should be used in multiple places, write up > a wait_event_XXX() wrapper. There is absolutely no reason to change > wakeup condition. It isn't that simple (among other reasons due to much time waiting in the socket interface), but since this directly addresses problems Jeff has spent much time debugging, I would like him to chime in. -- Thanks, Steve -- 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
