Message ID | cover.1589885479.git.liu.denton@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | remote-curl: fix deadlocks when remote server disconnects | expand |
On Tue, May 19, 2020 at 06:53:53AM -0400, Denton Liu wrote: > Changes since v2: > > * Use if-else tower in "transport: extract common fetch_pack() call" > > * Rename to `lenbuf_hex` and remove null-terminator sentence in > "pkt-line: extern packet_length()" > > * Fix "a a" typo in "remote-curl: error on incomplete packet" > > * Don't send flush packet after response end packet > > * Move stateless delimiter checks closer to where message processing > happens in do_fetch_pack_v2() This looks good to me, modulo the minor comment fixup from Eric. I did have one final question, though. Our discussion focused a lot on checking the 0002 packets in the success case. But we didn't discuss how fetch-pack would deal with an unexpected 0002 packet (i.e., the case that the server response is truncated, but then remote-curl tacks on its 0002). It _seems_ to work, because that's the case your invalid-shallow test is covering. I'm just not sure if it works consistently, or what error we might produce in some cases (e.g., saying "woah, what's the weird 0002 packet" instead of "the server response ended unexpectedly" or something). I suspect any remaining issues there are cosmetic, and it might be OK to just discover them organically through use. But if you happen to have done some poking around there, it would be nice to hear it. Thanks for working on this. When we had the initial discussion, I was really worried the solution was going to be quite nasty, but I think it turned out to be reasonably nice. -Peff
Hi Peff, On Tue, May 19, 2020 at 02:40:04PM -0400, Jeff King wrote: > It _seems_ to work, because that's the case your invalid-shallow test is > covering. I'm just not sure if it works consistently, or what error we > might produce in some cases (e.g., saying "woah, what's the weird 0002 > packet" instead of "the server response ended unexpectedly" or > something). > > I suspect any remaining issues there are cosmetic, and it might be OK to > just discover them organically through use. But if you happen to have > done some poking around there, it would be nice to hear it. From what I can tell, every time a packet is read using the reader in do_fetch_pack_v2(), we're careful about checking the packet type so we should be safe there. Also, when piping stuff over to index-pack and unpack-objects, it looks like the resulting call to recv_sideband() treats any control packets as flush packets so it should handle the 0002 fine. I could have missed checking some spots, though. But as far as I can tell, if it can't handle the 0002 properly, it was already buggy to begin with. I agree that we can let any remaining issues be shaken out through use. > Thanks for working on this. When we had the initial discussion, I was > really worried the solution was going to be quite nasty, but I think it > turned out to be reasonably nice. Thanks, Denton > -Peff