[6.0] Fix usage of recycled lists in the thread pool #99387
Conversation
Fixed the usage of ThreadpoolMgr::RecycledLists to use the same processor count upon access as what is used to allocate the array.
|
Tagging subscribers to this area: @mangod9 Issue DetailsFixed the usage of ThreadpoolMgr::RecycledLists to use the same processor count upon access as what is used to allocate the array. Customer ImpactThe current processor number is used to access the recycled lists array in the thread pool, and the array is allocated using a processor count determined at initialization time. There are some cases where the current processor number may be greater than the predetermined processor count. An out-of-bounds access to the relevant array can lead to a hang, crash, or corruption. A hang was seen on Win11 by a 1p customer, where scheduling changes led to the initializing thread running on a different CPU group from the primary CPU group of the process, the processor count determined using GetSystemInfo returns the number of processors in the CPU group the calling thread is running on, and the primary CPU group had more processors. Regression?No TestingVerified that the issue is resolved on a multi-CPU-group machine. RiskLow, the fix ensures that all accesses into the relevant array are within bounds.
|
jeffschwMSFT
left a comment
jeffschwMSFT
left a comment
There was a problem hiding this comment.
approved. we will take for consideration in 6.0.x
rbhanda
added
Servicing-approved
|
@kouvel @jeffschwMSFT today is Code Complete for the April Release. If this is ready, please go ahead and merge it before 4pm PT, otherwise it will have to wait until the May Release. |
|
Merging since the single test failure is in eventsource |
7 participants
Fixed the usage of ThreadpoolMgr::RecycledLists to use the same processor count upon access as what is used to allocate the array.
Customer Impact
The current processor number is used to access the recycled lists array in the thread pool, and the array is allocated using a processor count determined at initialization time. There are some cases where the current processor number may be greater than the predetermined processor count. An out-of-bounds access to the relevant array can lead to a hang, crash, or corruption. A hang was seen on Win11 by a 1p customer, where scheduling changes led to the initializing thread running on a different CPU group from the primary CPU group of the process, the processor count determined using GetSystemInfo returns the number of processors in the CPU group the calling thread is running on, and the primary CPU group had more processors.
Regression?
No
Testing
Verified that the issue is resolved on a multi-CPU-group machine.
Risk
Low, the fix ensures that all accesses into the relevant array are within bounds.