RE: [PATCH 3/4] sunrpc: make rpc_wait_bit_killable handle freeze events

[Myklebust, Trond]

> -----Original Message-----
> From: Jeff Layton [mailto:jlayton@xxxxxxxxxx]
> Sent: Tuesday, October 11, 2011 6:12 AM
> To: Pavel Machek
> Cc: Myklebust, Trond; smfrench@xxxxxxxxx; rjw@xxxxxxx; linux-
> pm@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-cifs@xxxxxxxxxxxxxxx; linux-
> nfs@xxxxxxxxxxxxxxx; john@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 3/4] sunrpc: make rpc_wait_bit_killable handle
freeze
> events
> 
> On Tue, 11 Oct 2011 08:19:23 +0200
> Pavel Machek <pavel@xxxxxx> wrote:
> 
> > On Wed 2011-09-28 07:52:40, Jeff Layton wrote:
> > > Allow the wait_on_bit_killable sleeps in SUNRPC layer to respect
the
> > > freezer. This should allow suspend and hibernate events to occur,
> > > even when there are RPC's pending on the wire.
> >
> > Will the RPC protocols used handle that correctly? What will happen
> > during resume?
> >
> 
> That depends on the state of the socket during resume. If the
> suspend/resume is quick enough, then the socket may still be
connected, or
> if we're using UDP then we might just get the reply and carry on
successfully.
> Otherwise, the call will eventually time out, or will be cancelled
when the
> kernel finds that the socket has been closed.
> 
> Either way, this should do the right thing.

Well... The problem when this sort of thing happens is with the replay
cache. If the RPC in question was a mkdir, for instance, then replaying
the RPC call when you wake up can be problematic because chances are
that the server will have forgotten who created the directory, and so
will reply with EEXIST instead of OK.
However this is a generic problem when the client is unable to talk to
the server for a while, and is not particular to suspend.

Cheers
  Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/