From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755895AbdDEQpR (ORCPT ); Wed, 5 Apr 2017 12:45:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49926 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755411AbdDEQon (ORCPT ); Wed, 5 Apr 2017 12:44:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 32BC119D22F Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 32BC119D22F Date: Wed, 5 Apr 2017 18:44:30 +0200 From: Oleg Nesterov To: "Eric W. Biederman" Cc: Andrew Morton , Aleksa Sarai , Andy Lutomirski , Attila Fazekas , Jann Horn , Kees Cook , Michal Hocko , Ulrich Obergfell , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [RFC][PATCH 2/2] exec: If possible don't wait for ptraced threads to be reaped Message-ID: <20170405164429.GG14536@redhat.com> References: <87tw7aunuh.fsf@xmission.com> <87lgsmunmj.fsf_-_@xmission.com> <20170304170312.GB13131@redhat.com> <8760ir192p.fsf@xmission.com> <878tnkpv8h.fsf_-_@xmission.com> <87vaqooggs.fsf_-_@xmission.com> <20170402153517.GA12637@redhat.com> <877f32k5ew.fsf@xmission.com> <20170403181252.GA31390@redhat.com> <87inmlnqx1.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87inmlnqx1.fsf@xmission.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 05 Apr 2017 16:44:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/03, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > I meant that may_hang == 0 implies zap_other_threads(do_count => -1) which should > > return the number of threads which didn't pass exit_notify(). The returned value > > can be wrong unless you change exit_notify() to set exit_state under > > siglock. but I forgot to add that, of course, this problem is very minor because we can only miss a thread which is already at the end of exit_notify() so nothing bad can happen. But imo should be fixed anyway, simply because this looks wrong/racy. Your recent 4/5 has the same problem. > Interesting an existing bug. Hmm... what do you mean? The current code looks fine. Oleg.