Aw: RE: [OpenAFS] compile fails kernel version 4.4.0-1-default

[Stephen Joyce]

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:
>
>> Hi,
>>
>> 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
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c725bfce7968009756ed2836a8cd7ba4dc163011,
> 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.
>
> -Ben
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>