[AFD]
authorCameron Gutman <aicommander@gmail.com>
Mon, 27 Aug 2012 04:16:28 +0000 (04:16 +0000)
committerCameron Gutman <aicommander@gmail.com>
Mon, 27 Aug 2012 04:16:28 +0000 (04:16 +0000)
commit6c0d0cbab02d0fb13e48aacef7e26ae613ce7dae
treee5c68c400515868f703504bdb877e0418e33c13a
parent55be1f528f9b9ea2faa1fbeafea9bd8811862e67
[AFD]
- Fix one of the worst bugs in AFD of all time. Our AFD code operated under the assumption that none of the input parameters would change once we called LockRequest. This assumption is completely false. The only guarantee that made was that the pages never disappeared from us, not they they couldn't be modified. There are frequent cases where the user-mode buffer was modified from underneath us (WSPRecv allocates the struct on stack which makes it invalid during overlapped operations that complete later). When this happened, we would bugcheck when we tried to unlock the buffers since we accessed this in a member of the struct the caller passed us.
- I've fixed this by adding a parameter to LockRequest which specifies whether the buffer should be copied back when it is unlocked.
- This bug has been around for ages and I was never able to figure out why we just freed garbage sometimes. Now that the ws2_32_winetest exposed it reliably, I was finally able to fix it.

svn path=/trunk/; revision=57175
reactos/drivers/network/afd/afd/bind.c
reactos/drivers/network/afd/afd/connect.c
reactos/drivers/network/afd/afd/context.c
reactos/drivers/network/afd/afd/info.c
reactos/drivers/network/afd/afd/listen.c
reactos/drivers/network/afd/afd/lock.c
reactos/drivers/network/afd/afd/main.c
reactos/drivers/network/afd/afd/read.c
reactos/drivers/network/afd/afd/select.c
reactos/drivers/network/afd/afd/write.c
reactos/drivers/network/afd/include/afd.h