Aw: RE: [OpenAFS] compile fails kernel version 4.4.0-1-default
Mon, 7 Mar 2016 11:23:24 -0500
I'm no C programmer, but from my rudimentary reading of the code, wasn't
there always a chance for -ERESTARTSYS to be returned from inside the
while() loop inside splice_from_pipe_next(...)?
On Mon, 7 Mar 2016, Benjamin Kaduk wrote:
> On Thu, 3 Mar 2016, Michael Dressel wrote:
>> it is me who reported the issue on archlinux. Let me know if I can help
>> with reproducing the issue or anything else.
>> For curiosity, could anyone explain to me what change in the 4.4 kernel
>> created the issue for openafs? Or rather what was the intention of the
>> change in 4.4?
> I am given to understand that the proximal trigger is linux commit
> which addds a path wherein -ERESTARTSYS can be returned from within VFS
> library code. (Maybe there are other such paths, but we maybe just didn't
> notice before?) This particular function, splice_from_pipe_next(), ends
> up getting called from the low-level afs_linux_storeproc() routine. There
> are many call paths in the cache manager that end up at this function,
> most of which are not prepared to properly handle an ERESTARTSYS return.
> Since this status can be returned after some data has already been
> written, the correct behavior upon receiving it is far from clear ... a
> path towards a client free of this vector for data corruption may involve
> avoiding the dependence on splice_from_pipe_next() in preference to
> adopting all call sites to handle the ERSTARTSYS case.
> OpenAFS-info mailing list