All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1489613676.2660.8.camel@sandisk.com>

diff --git a/a/1.txt b/N1/1.txt
index 201dc16..ceae849 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,37 +1,32 @@
 On Wed, 2017-03-15 at 20:18 +0800, Ming Lei wrote:
 > On Wed, Mar 15, 2017 at 12:07:37AM +0000, Bart Van Assche wrote:
-> > Both the old and the new check look racy to me. The REQ_ATOM_STARTED bi=
-t can
-> > be changed concurrently by blk_mq_start_request(), __blk_mq_finish_requ=
-est()
->=20
-> blk_mq_start_request() and __blk_mq_finish_request() won't be run concurr=
-ently.
->=20
+> > Both the old and the new check look racy to me. The REQ_ATOM_STARTED bit can
+> > be changed concurrently by blk_mq_start_request(), __blk_mq_finish_request()
+> 
+> blk_mq_start_request() and __blk_mq_finish_request() won't be run concurrently.
+> 
 > From view of __blk_mq_finish_request():
->=20
+> 
 > 	- if it is run from merge queue io path(blk_mq_merge_queue_io()),
 > 	blk_mq_start_request() can't be run at all, and the COMPLETE flag
 > 	is kept as previous value(zero)
->=20
+> 
 > 	- if it is run from normal complete path, COMPLETE flag is cleared
 > 	before the req/tag is released to tag set.
->=20
-> so there isn't race in blk_mq_start_request() vs. __blk_mq_finish_request=
-()
+> 
+> so there isn't race in blk_mq_start_request() vs. __blk_mq_finish_request()
 > wrt. timeout.
->=20
-> > or __blk_mq_requeue_request(). Another issue with this function is that=
- the
->=20
+> 
+> > or __blk_mq_requeue_request(). Another issue with this function is that the
+> 
 > __blk_mq_requeue_request() can be run from two pathes:
->=20
+> 
 > 	- dispatch failure, in which case the req/tag isn't released to tag set
-> =09
+> 	
 > 	- IO completion path, in which COMPLETE flag is cleared before requeue.
-> =09
-> so I can't see races with timeout in case of start rq vs. requeue rq.=20
->=20
+> 	
+> so I can't see races with timeout in case of start rq vs. requeue rq. 
+> 
 > > request passed to this function can be reinitialized concurrently.
 
 Hello Ming,
@@ -39,4 +34,4 @@ Hello Ming,
 You misinterpret what I wrote. I was referring to manipulation of
 REQ_ATOM_STARTED from different contexts and not to what you explained.
 
-Bart.=
+Bart.
diff --git a/a/content_digest b/N1/content_digest
index 62e098b..d886fd7 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -16,38 +16,33 @@
  "b\0"
  "On Wed, 2017-03-15 at 20:18 +0800, Ming Lei wrote:\n"
  "> On Wed, Mar 15, 2017 at 12:07:37AM +0000, Bart Van Assche wrote:\n"
- "> > Both the old and the new check look racy to me. The REQ_ATOM_STARTED bi=\n"
- "t can\n"
- "> > be changed concurrently by blk_mq_start_request(), __blk_mq_finish_requ=\n"
- "est()\n"
- ">=20\n"
- "> blk_mq_start_request() and __blk_mq_finish_request() won't be run concurr=\n"
- "ently.\n"
- ">=20\n"
+ "> > Both the old and the new check look racy to me. The REQ_ATOM_STARTED bit can\n"
+ "> > be changed concurrently by blk_mq_start_request(), __blk_mq_finish_request()\n"
+ "> \n"
+ "> blk_mq_start_request() and __blk_mq_finish_request() won't be run concurrently.\n"
+ "> \n"
  "> From view of __blk_mq_finish_request():\n"
- ">=20\n"
+ "> \n"
  "> \t- if it is run from merge queue io path(blk_mq_merge_queue_io()),\n"
  "> \tblk_mq_start_request() can't be run at all, and the COMPLETE flag\n"
  "> \tis kept as previous value(zero)\n"
- ">=20\n"
+ "> \n"
  "> \t- if it is run from normal complete path, COMPLETE flag is cleared\n"
  "> \tbefore the req/tag is released to tag set.\n"
- ">=20\n"
- "> so there isn't race in blk_mq_start_request() vs. __blk_mq_finish_request=\n"
- "()\n"
+ "> \n"
+ "> so there isn't race in blk_mq_start_request() vs. __blk_mq_finish_request()\n"
  "> wrt. timeout.\n"
- ">=20\n"
- "> > or __blk_mq_requeue_request(). Another issue with this function is that=\n"
- " the\n"
- ">=20\n"
+ "> \n"
+ "> > or __blk_mq_requeue_request(). Another issue with this function is that the\n"
+ "> \n"
  "> __blk_mq_requeue_request() can be run from two pathes:\n"
- ">=20\n"
+ "> \n"
  "> \t- dispatch failure, in which case the req/tag isn't released to tag set\n"
- "> =09\n"
+ "> \t\n"
  "> \t- IO completion path, in which COMPLETE flag is cleared before requeue.\n"
- "> =09\n"
- "> so I can't see races with timeout in case of start rq vs. requeue rq.=20\n"
- ">=20\n"
+ "> \t\n"
+ "> so I can't see races with timeout in case of start rq vs. requeue rq. \n"
+ "> \n"
  "> > request passed to this function can be reinitialized concurrently.\n"
  "\n"
  "Hello Ming,\n"
@@ -55,6 +50,6 @@
  "You misinterpret what I wrote. I was referring to manipulation of\n"
  "REQ_ATOM_STARTED from different contexts and not to what you explained.\n"
  "\n"
- Bart.=
+ Bart.
 
-92f2530a500ca63c67d9bb7d24480a89c4f4dda1ba75afdb739ca898eb4486d9
+6bb65d6e84fca1b49b51239af32b7acf9aa015f93bbc1da1709e198b2d86bfa5

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.