Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751525AbbEBIaT (ORCPT ); Sat, 2 May 2015 04:30:19 -0400 Received: from cantor2.suse.de ([195.135.220.15]:60357 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751056AbbEBIaQ (ORCPT ); Sat, 2 May 2015 04:30:16 -0400 Date: Sat, 2 May 2015 18:30:01 +1000 From: NeilBrown To: Ingo Molnar Cc: Linus Torvalds , Evgeniy Polyakov , Stephen Smalley , Alex Williamson , Oleg Nesterov , linux-kernel , kvm Subject: Re: [PATCH] signals: Generate warning when flush_signals() is called from non-kthread context Message-ID: <20150502183001.07eae212@notabene.brown> In-Reply-To: <20150501193813.GA2812@gmail.com> References: <1430502057.4472.255.camel@redhat.com> <20150501193813.GA2812@gmail.com> X-Mailer: Claws Mail 3.10.1-162-g4d0ed6 (GTK+ 2.24.25; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/ff0KRIE/QIPugvyeT72OLGf"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3327 Lines: 101 --Sig_/ff0KRIE/QIPugvyeT72OLGf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 1 May 2015 21:38:13 +0200 Ingo Molnar wrote: > drivers/md/md.c > drivers/md/raid1.c > drivers/md/raid5.c >=20 > Hm, so I'm not super sure about the flush_signals() in=20 > raid1.c:make_request() AFAICS we can do direct RAID1 writes in=20 > raid1_unplug(). That looks unsafe ... I've Cc:-ed Neil. >=20 > raid5.c seems safe: raid5_unplug() doesn't create requests directly,=20 > leaves it all for the mddev kthread. Both raid1.c and raid5.c call flush_signals() in the make_request function (in unusual circumstances). I wanted a uninterruptible wait which didn't add to load-average. That approach works in kernel threads... All the calls in md.c are in a kernel thread so safe, but I'd rather have an explicit "uninterruptible, but no load-average" wait.... I should probably change the make_request code to queue the request somewhere rather than wait for it to be serviceable. I'll look into that... > In any case, it seems to me that the patch below would be justified?=20 > Totally untested and so. __flush_signals() not affected. Fine by me - does seem justified. Thanks, NeilBrown >=20 > Thanks, >=20 > Ingo >=20 > --- > kernel/signal.c | 4 ++++ > 1 file changed, 4 insertions(+) >=20 > diff --git a/kernel/signal.c b/kernel/signal.c > index d51c5ddd855c..100e30afe5d2 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -427,6 +427,10 @@ void flush_signals(struct task_struct *t) > { > unsigned long flags; > =20 > + /* Only kthreads are allowed to destroy signals: */ > + if (WARN_ON_ONCE(!(current->flags & PF_KTHREAD))) > + return; > + > spin_lock_irqsave(&t->sighand->siglock, flags); > __flush_signals(t); > spin_unlock_irqrestore(&t->sighand->siglock, flags); > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ --Sig_/ff0KRIE/QIPugvyeT72OLGf Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIVAwUBVUSLCTnsnt1WYoG5AQJYag/9Hg2i6P1t68iJEKModSOmHUPh6jQH7UMi UowQpp5Fbw1gva94qUzeTfhiKE8Z10AucRTxPDptan/+vjOL9NyOpWsTwON9LjOl 1c0HIrR5jOp/uwfI0/vZ65AZlT3Xj6PBhicmf0XBw5kZfX2Mrio2qQfL9295HGaV aHAeuWHNFaUqrGY/m9MsP6KPtb++KaXKGFBYruO8cNeiPjIoF5Qbhurwq1wIikUR XJ1josa5F9VcRtsQAL1jqMPO2GC4PSy8GCM6x/0kcTcz9UBre54sQorHx9F8y4Is AmRGZW8gZ+eIyLOsebKHevUtg6kB+vC+NIgGkw1kn8tqpArK0JOitSK3K3Fb0hP2 5EYhZTj9rDPojjyn+sEtCQRhwN+EAaWXV+z3jursZqmsCTkfUfTLy15JMP1dFCEo q+m5ve8gl9aSUqqOG4ZhsVg02QPIVH0pPztDIjJlvUxeYavTWahaJ68imOjTCo8Z uvGNC/huvSBmu08dJb9Dz1KO5092hJvtjecvPiWz+oEPFWk/j2RAVK1Ufb15DoCg +Fk1u+NtE+tKsCO1lWy+MVFXR3peLGcEHFe5b8RcdZ4g7ehEkkWNRQccNMkXX61I tGvZ0EGL5NVvxd7aflIczX+pKKJDeUeEx5afFG4+QdWadfN0gGFs+t2MH7uN0oJp fnKCVBjlNKE= =bgrE -----END PGP SIGNATURE----- --Sig_/ff0KRIE/QIPugvyeT72OLGf-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/