From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBovQ8oE02Y/pa3u+K1/b07CxNpcwzMikw6J8udvQ9RXRYkAxU6MR3GT/uaM/nI9D9PdUUzhU ARC-Seal: i=1; a=rsa-sha256; t=1516221823; cv=none; d=google.com; s=arc-20160816; b=qJGg3euTpChpWMWFg1rzlMq0ldGVWoDygdhfawBRSbj8hTlznYTySu+BZ6jJS1/EqA dV7M6/LwBQyYEmwEyi0jjgWFnrpPRnrCsGQFqvoaQHRRz0c2qERE5HukIqKtZ2m4iBdU GTogd9E36yVMDGQxinaXER+9kM3GDVqzfvYyH/A30B688mUWTV2lpAJ1iUV+pia8KGSy InoAkL7nhRamqelHtOwI4XjFUjr6IqMprxUjR93Jdp8UyXFLojgbkmIjcFCbDThu8/sL +/z2qygKTDB8ZUeRUHE/OsDCOP6B+y4hr8i6XjMF8dELmBGp0vh/HCS2R+T5VgZ6Uure XGiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=hSB50haNZ1T+eU87z0ZnscxEftqOBDwBeRui/bh2b6c=; b=TPpS2F4AEc56MzLJKPk88CiJsg2/PVS6pwEk7JKnKm3+eEuinb4DivRZWxdEllcRd5 M/gHR786uBwzcTZ/uZSlr2wA3Tb7tzgkOi4TdMYBF4oD+xubqlZNe5IiHugRAilEyH/Y yNDeROSw4rRwtFmq92wy8RxhsQ1MjoCVpPJehpkiTkoZAAbp0zXBsAjVJe9o8Pjv+nWy QU3+61Wv47Co/bmcb8Y2e2s5NJpugR/JpQNnkGiL6gYSpJJjzkwNdsMRyzZ6gUZOB7QQ 6Z2HkZSC5w5pxE7ECPb1TVx4C1/lrUa0laa87uUaTlcEPjjU251PP8u42U8gVzn8qZjg YEBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of oleg@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=oleg@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of oleg@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=oleg@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Wed, 17 Jan 2018 21:43:39 +0100 From: Oleg Nesterov To: "Eric W. Biederman" Cc: Kirill Tkhai , gregkh@linuxfoundation.org, jslaby@suse.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock" Message-ID: <20180117204339.GA10649@redhat.com> References: <151619233415.5683.18062849657787533510.stgit@localhost.localdomain> <151619277281.5683.16110625178528288163.stgit@localhost.localdomain> <87shb4floe.fsf@xmission.com> <20180117173415.GA7964@redhat.com> <87tvvke5p0.fsf@xmission.com> <20180117180450.GA8181@redhat.com> <87zi5ccowi.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zi5ccowi.fsf@xmission.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1589843366609121628?= X-GMAIL-MSGID: =?utf-8?q?1589873814450491739?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 01/17, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > >> To operate correctly, do_SAK() needs to kill everything that has the tty > >> open. Unless we can make that guarantee I don't see the point of > >> changing do_SAK. > > > > OK, but how this connects to this change? > > > > Again, this force_sig() doesn't match other send_sig()'s in __do_SAK(), > > and Kirill is going to turn them all into send_sig_info(SEND_SIG_FORCED). > > Just we need to discuss whether we need to skip the global init or not > > but this is another story. > > > > So why do you dislike this change? > > > > force_sig() should die anyway. At least in its current form, it should not > > be used unless task == current. But this is off-topic. > > I see that as a fair criticism of force_sig, > and a good argument to use send_sig(SIGKILL, SEND_SIG_FORCED). > > Which will kill the global init. and iiuc you think this is right. I won't argue, but again, this needs some discussion imo. And in fact Kirill was going to do this before anything else, it was me who (rightly or not) suggested to do this after cleanups because this is the user visible change. > What I don't like is a bunch of patches to introduce races and make > something more racy Why? I do not see how this series can add the new problems or races, technically it looks correct to me. > So we either need to say do_SAK is broken. In which case the proper fix > is to just delete the thing. I personally never used it so I am fine with your suggestion ;) > Or we need not to ensure the final > implemenation is an atomic kill of everything that has the tty open. Then I think we need some changes in drivers/tty/, with or without Kirill's changes. May be some flag set/cleared by __do_SAK() which should make tty_open() fail. Not sure about tty's passed via unix sockets... and actually I have no idea how much much paranoia __do_SAK() needs. Oleg.