Thread (14 messages) 14 messages, 6 authors, 2012-10-10

Re: btrfs send/receive review by vfs folks

From: Alex Lyakas <hidden>
Date: 2012-09-24 09:13:00
Also in: linux-fsdevel

Hi,
write_buf:
Used to write the stream to a user space supplied pipe. Please note
the ERESTARTSYS comment there, I need some help here as I don't know
how to handle that correctly. If I ignore the return value, it loops
forever. If I bail out to user space, it reenters the ioctl and starts
from the beginning (which is really bad). I have two possible
solutions in my mind.
1. Store some kind of state in the ioctl arguments so that we can
continue where we stopped when the ioctl reenters. This would however
complicate the code a lot.
2. Spawn a thread when the ioctl is called and leave the ioctl
immediately. I don't know if ERESTARTSYS can happen in vfs_xxx calls
if they happen from a non syscall thread.
I am hitting the ERESTARTSYS issue also. To easiest way to repro this
is to stop the user process in gdb.
As Alexander mentioned, restarting the ioctl from the beginning is
really bad, because some commands were already sent to the pipe, and
possibly consumed by the user mode (dump_thread). Also the command, on
which vfs_write() hit ERESTARTSYS, might not have been pushed fully to
the pipe. So if the ioctl() restarts, it starts filling the pipe with
duplicate commands, and at least one command in the pipe might be
corrupted. So the receive part cannot process such stream successfully
(usually it hits crc error).

In addition to what Alexander suggested, I have a third suggestion,
but I would like to know whether community believes this issue is
worth to fix.

Thanks!
Alex.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help