Re: +AFs-PATCH+AF0- blk-mq: Set request mapping to NULL in blk+AF8-mq+AF8-put+AF8-driver+AF8-tag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2018-12-04 at 23:48 +-0530, Kashyap Desai wrote:
+AD4 Let me explain the issue. It is not a race, but very straight issue.

Please clarify what makes you think that iterating over all requests does not
race with request completion. Is request submission perhaps blocked during the
firmware recovery process? Does the firmware recovery process wait for
completion interrupts that are in progress to finish?

+AD4 Let's
+AD4 say we have one scsi+AF8-device /dev/sda and total IO submitted +- completed are
+AD4 some number 100.
+AD4 All the 100 IO is +ACo-completed+ACo.   Now, As part of Firmware recovery, driver
+AD4 tries to find our outstanding IOs using scsi+AF8-host+AF8-find+AF8-tag().
+AD4 Block layer will return all the 100 commands to the driver but really those
+AD4 100 commands are not outstanding. This patch will return +ACo-actual+ACo
+AD4 outstanding commands.

Would iterating over started requests be a good alternative to the patch
that you had posted? The header above blk+AF8-mq+AF8-tagset+AF8-busy+AF8-iter() is as follows
(this function is used by e.g. the skd driver for firmware recovery):

/+ACoAKg
 +ACo blk+AF8-mq+AF8-tagset+AF8-busy+AF8-iter - iterate over all started requests in a tag set
 +ACo +AEA-tagset:	Tag set to iterate over.
 +ACo +AEA-fn:		Pointer to the function that will be called for each started
 +ACo		request. +AEA-fn will be called as follows: +AEA-fn(rq, +AEA-priv,
 +ACo		reserved) where rq is a pointer to a request. 'reserved'
 +ACo		indicates whether or not +AEA-rq is a reserved request.
 +ACo +AEA-priv:	Will be passed as second argument to +AEA-fn.
 +ACo-/

+AD4 I am not able to find right context from srp, but I check the srp code and
+AD4 looks like that driver is getting scmd using scsi+AF8-host+AF8-find+AF8-tag() for live
+AD4 command.

Sorry, my e-mail was a bit too short to be comprehensible. When running
sg+AF8-reset -d /dev/sd... in a loop it is possible that the SCSI reset handler
terminates a request while the SRP driver is handling a request completion
for one of the terminated requests. That is why both srp+AF8-process+AF8-srp() and
the reset handler call srp+AF8-claim+AF8-req() to make sure that only one of these
two contexts completes a request.

Bart.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux