On Thu, 8 Jun 2017, NeilBrown wrote: > On Wed, Jun 07 2017, Mikulas Patocka wrote: > > > 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@xxxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx > > Thanks for catching that! > > Acked-by: NeilBrown <neilb@xxxxxxxx> > > NeilBrown BTW. why does md_thread do "allow_signal(SIGKILL)" and then "if (signal_pending(current)) flush_signals(current)"? Does userspace really send SIGKILL to MD kernel threads? The SIGKILL will be lost when flush_signals is called, so it looks quite dubious. Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
