diff for duplicates of <11544331.gmjPRolTO7@merkaba> diff --git a/a/1.txt b/N1/1.txt index 714d99d..a178110 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,13 +2,13 @@ Bart Van Assche - 11.04.18, 14:50: > On Tue, 2018-04-10 at 14:54 -0700, tj@kernel.org wrote: > > Ah, yeah, I was moving it out of add_timer but forgot to actully add > > it to the issue path. Fixed patch below. -> >=20 +> > > > BTW, no matter what we do w/ the request handover between normal and > > timeout paths, we'd need something similar. Otherwise, while we can > > reduce the window, we can't get rid of it. ->=20 +> > (+Martin Steigerwald) -[=E2=80=A6] +[…] > Thank you for having shared this patch. It looks interesting to me. > What I know about the blk-mq timeout handling is as follows: > * Nobody who has reviewed the blk-mq timeout handling code with this @@ -16,47 +16,45 @@ Bart Van Assche - 11.04.18, 14:50: > * However, several people have reported kernel crashes that disappear > when the blk-mq timeout code is reworked. I'm referring to "nvme-rdma > corrupts memory upon timeout" -> =20 +> > (http://lists.infradead.org/pipermail/linux-nvme/2018-February/015848 > .html) and also to a "RIP: scsi_times_out+0x17" crash during boot -> (https://bugzilla.kernel.org/show_bug.cgi?id=3D199077). +> (https://bugzilla.kernel.org/show_bug.cgi?id=199077). Yes, with the three patches: -=2D '[PATCH] blk-mq_Directly schedule q->timeout_work when aborting a=20 +- '[PATCH] blk-mq_Directly schedule q->timeout_work when aborting a request.mbox' -=2D '[PATCH v2] block: Change a rcu_read_{lock,unlock}_sched() pair into=20 +- '[PATCH v2] block: Change a rcu_read_{lock,unlock}_sched() pair into rcu_read_{lock,unlock}().mbox' -=2D '[PATCH v4] blk-mq_Fix race conditions in request timeout=20 +- '[PATCH v4] blk-mq_Fix race conditions in request timeout handling.mbox' -the occasional hangs on some boots / resumes from hibernation appear to=20 +the occasional hangs on some boots / resumes from hibernation appear to be gone. -Also it appears that the error loading SMART data issue is gone as well=20 -(see my bug report). However it is still to early to say for sure. I=20 -think I need at least 2-3 days of additional testing with this kernel to=20 +Also it appears that the error loading SMART data issue is gone as well +(see my bug report). However it is still to early to say for sure. I +think I need at least 2-3 days of additional testing with this kernel to be sufficiently sure about it. -However=E2=80=A6 I could also test another patch, but from reading the rest= - of=20 -this thread so far I have no clear on whether to try one of the new=20 -patches and if so which one and whether adding it on top of some of the=20 +However… I could also test another patch, but from reading the rest of +this thread so far I have no clear on whether to try one of the new +patches and if so which one and whether adding it on top of some of the patches I already applied or using it as a replacement of it. -So while doing a training this and next week I can apply a patch here=20 -and then, but I won=C2=B4t have much time to read the complete discussion t= -o=20 +So while doing a training this and next week I can apply a patch here +and then, but I won´t have much time to read the complete discussion to figure out what to apply. -Personally as a stable kernel has been released with those issues, I=20 -think its good to fix it up soon. On the other hand it may take quite=20 -some time til popular distros carry 4.16 for regular users. And I have=20 -no idea how frequent the reported issues are, i.e. how many users would=20 +Personally as a stable kernel has been released with those issues, I +think its good to fix it up soon. On the other hand it may take quite +some time til popular distros carry 4.16 for regular users. And I have +no idea how frequent the reported issues are, i.e. how many users would be affected. Thanks, -=2D-=20 +-- Martin diff --git a/a/content_digest b/N1/content_digest index 3af1a62..4724956 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -20,13 +20,13 @@ "> On Tue, 2018-04-10 at 14:54 -0700, tj@kernel.org wrote:\n" "> > Ah, yeah, I was moving it out of add_timer but forgot to actully add\n" "> > it to the issue path. Fixed patch below.\n" - "> >=20\n" + "> > \n" "> > BTW, no matter what we do w/ the request handover between normal and\n" "> > timeout paths, we'd need something similar. Otherwise, while we can\n" "> > reduce the window, we can't get rid of it.\n" - ">=20\n" + "> \n" "> (+Martin Steigerwald)\n" - "[=E2=80=A6]\n" + "[\342\200\246]\n" "> Thank you for having shared this patch. It looks interesting to me.\n" "> What I know about the blk-mq timeout handling is as follows:\n" "> * Nobody who has reviewed the blk-mq timeout handling code with this\n" @@ -34,49 +34,47 @@ "> * However, several people have reported kernel crashes that disappear\n" "> when the blk-mq timeout code is reworked. I'm referring to \"nvme-rdma\n" "> corrupts memory upon timeout\"\n" - "> =20\n" + "> \n" "> (http://lists.infradead.org/pipermail/linux-nvme/2018-February/015848\n" "> .html) and also to a \"RIP: scsi_times_out+0x17\" crash during boot\n" - "> (https://bugzilla.kernel.org/show_bug.cgi?id=3D199077).\n" + "> (https://bugzilla.kernel.org/show_bug.cgi?id=199077).\n" "\n" "Yes, with the three patches:\n" "\n" - "=2D '[PATCH] blk-mq_Directly schedule q->timeout_work when aborting a=20\n" + "- '[PATCH] blk-mq_Directly schedule q->timeout_work when aborting a \n" "request.mbox'\n" "\n" - "=2D '[PATCH v2] block: Change a rcu_read_{lock,unlock}_sched() pair into=20\n" + "- '[PATCH v2] block: Change a rcu_read_{lock,unlock}_sched() pair into \n" "rcu_read_{lock,unlock}().mbox'\n" "\n" - "=2D '[PATCH v4] blk-mq_Fix race conditions in request timeout=20\n" + "- '[PATCH v4] blk-mq_Fix race conditions in request timeout \n" "handling.mbox'\n" "\n" - "the occasional hangs on some boots / resumes from hibernation appear to=20\n" + "the occasional hangs on some boots / resumes from hibernation appear to \n" "be gone.\n" "\n" - "Also it appears that the error loading SMART data issue is gone as well=20\n" - "(see my bug report). However it is still to early to say for sure. I=20\n" - "think I need at least 2-3 days of additional testing with this kernel to=20\n" + "Also it appears that the error loading SMART data issue is gone as well \n" + "(see my bug report). However it is still to early to say for sure. I \n" + "think I need at least 2-3 days of additional testing with this kernel to \n" "be sufficiently sure about it.\n" "\n" - "However=E2=80=A6 I could also test another patch, but from reading the rest=\n" - " of=20\n" - "this thread so far I have no clear on whether to try one of the new=20\n" - "patches and if so which one and whether adding it on top of some of the=20\n" + "However\342\200\246 I could also test another patch, but from reading the rest of \n" + "this thread so far I have no clear on whether to try one of the new \n" + "patches and if so which one and whether adding it on top of some of the \n" "patches I already applied or using it as a replacement of it.\n" "\n" - "So while doing a training this and next week I can apply a patch here=20\n" - "and then, but I won=C2=B4t have much time to read the complete discussion t=\n" - "o=20\n" + "So while doing a training this and next week I can apply a patch here \n" + "and then, but I won\302\264t have much time to read the complete discussion to \n" "figure out what to apply.\n" "\n" - "Personally as a stable kernel has been released with those issues, I=20\n" - "think its good to fix it up soon. On the other hand it may take quite=20\n" - "some time til popular distros carry 4.16 for regular users. And I have=20\n" - "no idea how frequent the reported issues are, i.e. how many users would=20\n" + "Personally as a stable kernel has been released with those issues, I \n" + "think its good to fix it up soon. On the other hand it may take quite \n" + "some time til popular distros carry 4.16 for regular users. And I have \n" + "no idea how frequent the reported issues are, i.e. how many users would \n" "be affected.\n" "\n" "Thanks,\n" - "=2D-=20\n" + "-- \n" Martin -b924d7bc39a674feb69efe80b4ff4f27bb62f5854e8cc600548c179292fb5939 +5c760a97ca81a9b590c0e19192cdf43b41e8670cc0481fe289e9d017d7ed2870
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.