OL @@ -86,46 +132,44 @@ static int cr_read_file(struct cr_ctx *ctx, int objref)
OL goto out;
OL ret = -EINVAL;
OL + if (hh-fd_objref 0)
OL + goto out;
As far as I can tell, hh-fd_objref never gets set anywhere. On my
system, this causes restart to always fail
Dan Smith wrote:
OL @@ -86,46 +132,44 @@ static int cr_read_file(struct cr_ctx *ctx, int
objref)
OL goto out;
OL ret = -EINVAL;
OL + if (hh-fd_objref 0)
OL + goto out;
As far as I can tell, hh-fd_objref never gets set anywhere. On my
system, this causes
OL hh- fd_objref is set, for pipes, in fs/pipe.c (outcome of the
OL hh- move to f_ops). So the problem is that the field isn't
OL hh- explicitly zeroed otherwise.
Ah, gotcha.
Thanks!
--
Dan Smith
IBM Linux Technology Center
email: da...@us.ibm.com
Quoting Oren Laadan (or...@cs.columbia.edu):
While file pointers are shared objects, they may share an underlying
object themselves. For instance, file pointers of both ends of a pipe
that share the same pipe inode. In this case, the shared entity to
handle is the inode that is shared among
Serge E. Hallyn wrote:
Quoting Oren Laadan (or...@cs.columbia.edu):
While file pointers are shared objects, they may share an underlying
object themselves. For instance, file pointers of both ends of a pipe
that share the same pipe inode. In this case, the shared entity to
handle is the
Quoting Oren Laadan (or...@cs.columbia.edu):
While file pointers are shared objects, they may share an underlying
object themselves. For instance, file pointers of both ends of a pipe
that share the same pipe inode. In this case, the shared entity to
handle is the inode that is shared among
