Hi David,
I studied the code in tcp_do_recvmsg yesterday, and was planning to report the
attempt to reset the read sequence as a bug. There are a couple of reasons why
it won't work as written:
(1) If a partial copy has been done, there's no point in partially resetting the
read sequence, because the EFAULT error return won't allow the partially copied
data to be used anyway.
(2) In the event of multiple readers (the reason for updating the sequence in
the first place), the later readers will have marked the earlier skbs in the
queue as used, so subsequently resetting the read sequence pointer won't help.
(And the later readers will have advanced to sequence themselves, so subtracting
a partial copy won't do the right thing.)
So it seems to me that the best approach is to just not attempt to reset the
sequence at all, but instead to regard the case of EFAULT during copy as an
error that ate all the bytes. (Such errors will be extremely rare in any event.)
If you did want to try resetting the read sequence, it would make more sense to
reset it to the original value, but only if a second reader hadn't moved it.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu