From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oleg@redhat.com>
X-Google-Smtp-Source: ACJfBotJxtdTmxDR7jyRpGFbDy95Dcncll/nWc/eo3OjWDeYWcljrMJQAPa438xC2RaDqjR6tZf4
ARC-Seal: i=1; a=rsa-sha256; t=1516210798; cv=none;
        d=google.com; s=arc-20160816;
        b=UlyB9kyW4qTzG+9dI88XV2kF+omwwwJFL4eETaAUc1/7B2UsaBz+Htb5RrXlKuhr3I
         WtsAA5EAfbls9Mzf7f+ljOkNGOBJTGf5pZDXbPGc9zjiOs9rPy/Tuiwi5/hdJ8Sg9qj2
         UxCNEc1ZF1C1HcYvxtfwSXBth+kKnuGOUS9gh7NUV5nZIrt+wCOT4yQMibsm8ZYRlldX
         oUDLUvV1Nve1iPsK3WcKcNARy+PqgPl/fRDN7GXacV2NNNTSxI5YQNxUokukI64QK2ty
         fKE69X+4QDvl7hNcpeEiJ34kR1NHEPYnhQxcq4QmJt96XLFUHJhmrLWbSD9ooTKqhfMI
         0Vzw==
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=G/FcXsZVJTvn6h9R55Y/iLw1JU0RWV5bRU+iNlxJipU=;
        b=yyROKSoGmMSDcIn23bEkWA173ek3h/g8+/SgVfEXiyPwZi18eYpcIR5HENgvKrKi7+
         8jgHjP1Pt+gw361wcU9YipB4wtUHx3C6eWaNoElbI8CsOy62DVfTP0HwuV3hppCUaOw/
         YjpCEVol/IMMFwbEaECXVYga2LifbPNtG4F4dENgjultXOEp28RDwPw1SWNg+b4xwTyb
         WXlZPwH+z98lLIgWqPQPpxwM48TB7/mJI7ulgyh7jVozrb/enZniWFj5IZciFkyCSvKt
         xpzHwbW0KzBaP+qLGA9noGpossFQRNcLfimR2EBG2boL8sXasxTprF1n/OO19AMN5YCe
         pcMw==
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 18:39:55 +0100
From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>, gregkh@linuxfoundation.org,
	jslaby@suse.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] tty: Use RCU read lock to iterate tasks and
 threads in __do_SAK()
Message-ID: <20180117173955.GB7964@redhat.com>
References: <151619233415.5683.18062849657787533510.stgit@localhost.localdomain>
 <151619279470.5683.15554197416743431023.stgit@localhost.localdomain>
 <87lggwh1ef.fsf@xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87lggwh1ef.fsf@xmission.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: =?utf-8?q?1589843382995363774?=
X-GMAIL-MSGID: =?utf-8?q?1589862254550112683?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On 01/17, Eric W. Biederman wrote:
>
> __do_SAK() needs to be 100% accurate.

But it can't. A process/thread can open tty right after the check.

> I do not see the rcu_read_lock
> guaranteeing that new processes created while the process list is being
> iterated that happen to have a reference to the tty will be seen.

We can't miss the new child if its parent has this tty opened at fork() time,
__do_SAK() sends SIGKILL and ->siglock serializes __do_SAK() with copy_process()
which checks signal_pending() under the same ->siglock. So either fork() should
fail or for_each_process() should see the new child.

Right?

Otherwise we do not care. The child can open tty later but this doesn't differ
from the "race" above.

Oleg.