diff for duplicates of <20151029212232.GA6009@kroah.com> diff --git a/a/1.txt b/N1/1.txt index 580b096..579382f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,32 +2,32 @@ On Thu, Oct 29, 2015 at 05:15:48PM +0300, Roman Gushchin wrote: > 29.10.2015, 03:35, "Neil Brown" <neilb@suse.de>: > > On Wed, Oct 28 2015, Roman Gushchin wrote: > > -> >> After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") -> >> __find_stripe() is called under conf->hash_locks + hash. -> >> But handle_stripe_clean_event() calls remove_hash() under -> >> conf->device_lock. +> >> �After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") +> >> �__find_stripe() is called under conf->hash_locks + hash. +> >> �But handle_stripe_clean_event() calls remove_hash() under +> >> �conf->device_lock. > >> -> >> Under some cirscumstances the hash chain can be circuited, -> >> and we get an infinite loop with disabled interrupts and locked hash -> >> lock in __find_stripe(). This leads to hard lockup on multiple CPUs -> >> and following system crash. +> >> �Under some cirscumstances the hash chain can be circuited, +> >> �and we get an infinite loop with disabled interrupts and locked hash +> >> �lock in __find_stripe(). This leads to hard lockup on multiple CPUs +> >> �and following system crash. > >> -> >> I was able to reproduce this behavior on raid6 over 6 ssd disks. -> >> The devices_handle_discard_safely option should be set to enable trim -> >> support. The following script was used: +> >> �I was able to reproduce this behavior on raid6 over 6 ssd disks. +> >> �The devices_handle_discard_safely option should be set to enable trim +> >> �support. The following script was used: > >> -> >> for i in `seq 1 32`; do -> >> dd if=/dev/zero of=large$i bs=10M count=100 & -> >> done +> >> �for i in `seq 1 32`; do +> >> �����dd if=/dev/zero of=large$i bs=10M count=100 & +> >> �done > >> -> >> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru> -> >> Cc: Neil Brown <neilb@suse.de> -> >> Cc: Shaohua Li <shli@kernel.org> -> >> Cc: linux-raid@vger.kernel.org -> >> Cc: <stable@vger.kernel.org> # 3.10 - 3.19 +> >> �Signed-off-by: Roman Gushchin <klamm@yandex-team.ru> +> >> �Cc: Neil Brown <neilb@suse.de> +> >> �Cc: Shaohua Li <shli@kernel.org> +> >> �Cc: linux-raid@vger.kernel.org +> >> �Cc: <stable@vger.kernel.org> # 3.10 - 3.19 > > > > Hi Roman, -> > thanks for reporting this and providing a fix. +> > �thanks for reporting this and providing a fix. > > > > I'm a bit confused by that stable range: 3.10 - 3.19 > > diff --git a/a/content_digest b/N1/content_digest index bc895ee..c524fd7 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -16,32 +16,32 @@ "> 29.10.2015, 03:35, \"Neil Brown\" <neilb@suse.de>:\n" "> > On Wed, Oct 28 2015, Roman Gushchin wrote:\n" "> >\n" - "> >> \302\240After commit 566c09c53455 (\"raid5: relieve lock contention in get_active_stripe()\")\n" - "> >> \302\240__find_stripe() is called under conf->hash_locks + hash.\n" - "> >> \302\240But handle_stripe_clean_event() calls remove_hash() under\n" - "> >> \302\240conf->device_lock.\n" + "> >> \303\257\302\277\302\275After commit 566c09c53455 (\"raid5: relieve lock contention in get_active_stripe()\")\n" + "> >> \303\257\302\277\302\275__find_stripe() is called under conf->hash_locks + hash.\n" + "> >> \303\257\302\277\302\275But handle_stripe_clean_event() calls remove_hash() under\n" + "> >> \303\257\302\277\302\275conf->device_lock.\n" "> >>\n" - "> >> \302\240Under some cirscumstances the hash chain can be circuited,\n" - "> >> \302\240and we get an infinite loop with disabled interrupts and locked hash\n" - "> >> \302\240lock in __find_stripe(). This leads to hard lockup on multiple CPUs\n" - "> >> \302\240and following system crash.\n" + "> >> \303\257\302\277\302\275Under some cirscumstances the hash chain can be circuited,\n" + "> >> \303\257\302\277\302\275and we get an infinite loop with disabled interrupts and locked hash\n" + "> >> \303\257\302\277\302\275lock in __find_stripe(). This leads to hard lockup on multiple CPUs\n" + "> >> \303\257\302\277\302\275and following system crash.\n" "> >>\n" - "> >> \302\240I was able to reproduce this behavior on raid6 over 6 ssd disks.\n" - "> >> \302\240The devices_handle_discard_safely option should be set to enable trim\n" - "> >> \302\240support. The following script was used:\n" + "> >> \303\257\302\277\302\275I was able to reproduce this behavior on raid6 over 6 ssd disks.\n" + "> >> \303\257\302\277\302\275The devices_handle_discard_safely option should be set to enable trim\n" + "> >> \303\257\302\277\302\275support. The following script was used:\n" "> >>\n" - "> >> \302\240for i in `seq 1 32`; do\n" - "> >> \302\240\302\240\302\240\302\240\302\240dd if=/dev/zero of=large$i bs=10M count=100 &\n" - "> >> \302\240done\n" + "> >> \303\257\302\277\302\275for i in `seq 1 32`; do\n" + "> >> \303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275\303\257\302\277\302\275dd if=/dev/zero of=large$i bs=10M count=100 &\n" + "> >> \303\257\302\277\302\275done\n" "> >>\n" - "> >> \302\240Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>\n" - "> >> \302\240Cc: Neil Brown <neilb@suse.de>\n" - "> >> \302\240Cc: Shaohua Li <shli@kernel.org>\n" - "> >> \302\240Cc: linux-raid@vger.kernel.org\n" - "> >> \302\240Cc: <stable@vger.kernel.org> # 3.10 - 3.19\n" + "> >> \303\257\302\277\302\275Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>\n" + "> >> \303\257\302\277\302\275Cc: Neil Brown <neilb@suse.de>\n" + "> >> \303\257\302\277\302\275Cc: Shaohua Li <shli@kernel.org>\n" + "> >> \303\257\302\277\302\275Cc: linux-raid@vger.kernel.org\n" + "> >> \303\257\302\277\302\275Cc: <stable@vger.kernel.org> # 3.10 - 3.19\n" "> >\n" "> > Hi Roman,\n" - "> > \302\240thanks for reporting this and providing a fix.\n" + "> > \303\257\302\277\302\275thanks for reporting this and providing a fix.\n" "> >\n" "> > I'm a bit confused by that stable range: 3.10 - 3.19\n" "> >\n" @@ -65,4 +65,4 @@ "\n" greg k-h -c9d0a2ad68060167f708abf9c05d9bb53409bc887e1528e8f1c99aff9b745f4f +588fe9e62bcaf4e954c6183745f32d2c08a85c36fad50572f39e4767969a607d
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.