On Sat, 2018-08-04 at 18:56 +-0530, Sreekanth Reddy wrote: +AD4- No Bart, their is no race condition here. Since chain lookup table +AD4- entry is uniquely accessed using smid value. And this smid (which is +AD4- scmd-+AD4-request-+AD4-tag +-1) is unique for each IO request. And +AD4- +AF8-base+AF8-get+AF8-chain+AF8-buffer+AF8-tracker() function is called only during IO +AD4- submission time (i.e. before submitting the IO to the IOC firmware) +AD4- and mpt3sas+AF8-base+AF8-clear+AF8-st() function is called in the ISR (i.e during +AD4- IO completion) path. So for a particular IO these two functions called +AD4- at two different instances of time. Hello Sreekanth, In mpt3sas+AF8-base+AF8-get+AF8-smid+AF8-scsiio() I found the following code: struct scsiio+AF8-tracker +ACo-request +AD0- scsi+AF8-cmd+AF8-priv(scmd)+ADs- u16 smid +AD0- scmd-+AD4-request-+AD4-tag +- 1+ADs- request-+AD4-smid +AD0- smid+ADs- That confirms what you wrote about smid being unique for each I/O request. However, this also raises new questions. As far as I can see all code in the I/O path that accesses the chain+AF8-lookup+AFsAXQ- array uses index smid - 1. The patch at the start of this e-mail thread modifies two functions, namely mpt3sas+AF8-remove+AF8-dead+AF8-ioc+AF8-func() and mpt3sas+AF8-base+AF8-clear+AF8-st(). Since the chain+AF8-lookup+AFsAXQ- array is indexed with the smid and hence contains request- private data, how is it even possible that these functions race against each other? Is there perhaps code that accesses the chain+AF8-lookup+AFsAXQ- array and that is called from another context than the I/O completion path? Is the patch at the start of this e-mail thread the result of a theoretical concern or of a real failure? In the latter case, which sequence of actions triggered the failure? The answer to this question should already have been mentioned in the description of v1 of this patch. Thanks, Bart.
