md: don't use flush_signals in userspace processes
authorMikulas Patocka <mpatocka@redhat.com>
Wed, 7 Jun 2017 23:05:31 +0000 (19:05 -0400)
committerBen Hutchings <ben@decadent.org.uk>
Thu, 12 Oct 2017 14:27:10 +0000 (15:27 +0100)
commit4c99d233b2d0f847332c676cc31b03bd9225d2c5
tree5f2606a41d76634935384f90b72c77dffa633ef9
parentbf97987fb94cc7d90154a217a3464d46efb8ee69
md: don't use flush_signals in userspace processes

commit f9c79bc05a2a91f4fba8bfd653579e066714b1ec upstream.

The function flush_signals clears all pending signals for the process. It
may be used by kernel threads when we need to prepare a kernel thread for
responding to signals. However using this function for an userspaces
processes is incorrect - clearing signals without the program expecting it
can cause misbehavior.

The raid1 and raid5 code uses flush_signals in its request routine because
it wants to prepare for an interruptible wait. This patch drops
flush_signals and uses sigprocmask instead to block all signals (including
SIGKILL) around the schedule() call. The signals are not lost, but the
schedule() call won't respond to them.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
drivers/md/raid1.c
drivers/md/raid5.c