| 1 |
On 02/19/2016 03:37 AM, Alex McWhirter wrote: |
| 2 |
> Git bisect if officially the coolest thing i've seen in a long time. I |
| 3 |
> wish i would have known about it earlier... |
| 4 |
> |
| 5 |
> Anyways... |
| 6 |
> |
| 7 |
> e5a4b0bb803b39a36478451eae53a880d2663d5b is the first bad commit |
| 8 |
> commit e5a4b0bb803b39a36478451eae53a880d2663d5b |
| 9 |
> Author: Al Viro <viro@×××××××××××××××.uk> |
| 10 |
> Date: Mon Nov 24 18:17:55 2014 -0500 |
| 11 |
> |
| 12 |
> switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to |
| 13 |
> primitives |
| 14 |
> |
| 15 |
> ... making both non-draining. That means that tcp_recvmsg() becomes |
| 16 |
> non-draining. And _that_ would break iscsit_do_rx_data() unless we |
| 17 |
> a) make sure tcp_recvmsg() is uniformly non-draining (it is) |
| 18 |
> b) make sure it copes with arbitrary (including shifted) |
| 19 |
> iov_iter (it does, all it uses is iov_iter primitives) |
| 20 |
> c) make iscsit_do_rx_data() initialize ->msg_iter only once. |
| 21 |
> |
| 22 |
> Fortunately, (c) is doable with minimal work and we are rid of one |
| 23 |
> the two places where kernel send/recvmsg users would be unhappy with |
| 24 |
> non-draining behaviour. |
| 25 |
> |
| 26 |
> Actually, that makes all but one of ->recvmsg() instances |
| 27 |
> iov_iter-clean. |
| 28 |
> The exception is skcipher_recvmsg() and it also isn't hard to convert |
| 29 |
> to primitives (iov_iter_get_pages() is needed there). That'll wait |
| 30 |
> a bit - there's some interplay with ->sendmsg() path for that one. |
| 31 |
> |
| 32 |
> Signed-off-by: Al Viro <viro@×××××××××××××××.uk> |
| 33 |
> |
| 34 |
> :040000 040000 b4d6852e73bd3d54a30b72441c8e35f79dc07266 |
| 35 |
> f0b90ef68ee891b38decf571247002c1d7fad519 M drivers |
| 36 |
> :040000 040000 8ba2fadf14c05a86a7c21448dac52fed661a2e12 |
| 37 |
> 0051ec4b6f273dbaed2bed21e4fddd48664d5afa M include |
| 38 |
> :040000 040000 d28e72369891521f7d853b30612a32cf65a27f6b |
| 39 |
> b828e68082a6fed2cf240aad4b365c5808928122 M net |
| 40 |
> |
| 41 |
> |
| 42 |
|
| 43 |
Here's a snippet from the kernel list... |
| 44 |
|
| 45 |
> Ok, so bit more info. This only seems to effect local disk transfers, |
| 46 |
not server -> client transfers. I can verify this behaviour on Debian |
| 47 |
and Gentoo, as well as on a Sun Fire V215 and Sun Blade 150. |
| 48 |
> |
| 49 |
> Steps to reproduce. |
| 50 |
> |
| 51 |
> rysnc -a rsync://rsync.ca.gentoo.org/gentoo-portage/ ~/portage |
| 52 |
> rsync -a ~/portage ~/portage2 |
| 53 |
> |
| 54 |
> You should see something around these lines occur... |
| 55 |
> |
| 56 |
> rsync: [sender] write error: Broken pipe (32) |
| 57 |
> rsync error: error in socket IO (code 10) at io.c(820) [sender=3.1.1] |
| 58 |
> |
| 59 |
> |
| 60 |
> If you don't want to download the whole portage tree, you can probably |
| 61 |
get away with a large subdirectory like x11-libs. |
| 62 |
> |
| 63 |
> I.E. |
| 64 |
> |
| 65 |
> rysnc -a rsync://rsync.ca.gentoo.org/gentoo-portage/x11-libs ~/x11-libs |
| 66 |
> rsync -a ~/x11-libs ~/x11-libs2 |
| 67 |
> |
| 68 |
> As stated earlier, using git bisect to eventually roll back commit |
| 69 |
e5a4b0bb803b39a36478451eae53a880d2663d5b will resolve the problem. |
| 70 |
|
| 71 |
Mike, any ideas of what else i could do to try and pick this apart a bit |
| 72 |
more? |
Archives