From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756099AbdDESMM (ORCPT ); Wed, 5 Apr 2017 14:12:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55962 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754337AbdDESLR (ORCPT ); Wed, 5 Apr 2017 14:11:17 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5D9F985540 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=oleg@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5D9F985540 Date: Wed, 5 Apr 2017 20:11:03 +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 v2 3/5] clone: Disallown CLONE_THREAD with a shared sighand_struct Message-ID: <20170405181103.GA19444@redhat.com> References: <87d1dyw5iw.fsf@xmission.com> <87tw7aunuh.fsf@xmission.com> <87lgsmunmj.fsf_-_@xmission.com> <20170304170312.GB13131@redhat.com> <8760ir192p.fsf@xmission.com> <878tnkpv8h.fsf_-_@xmission.com> <874ly6a0h1.fsf_-_@xmission.com> <87k2728lrp.fsf_-_@xmission.com> <20170405162458.GF14536@redhat.com> <87o9waep28.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o9waep28.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.28]); Wed, 05 Apr 2017 18:11:16 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > I agree that changing userspace semantics is something to be very > careful with. But at least for purposes of discussion I think this is a > good patch. I agree that we need it with your approach, but imo it would be much better to not depend on the subtle changes like this. My 2/2 or your 1/5 are already bad enough. > I can avoid this change but it requires moving sighand->siglock > into signal_struct and introducing a new spinlock into sighand_struct > to just guard the signal handlers. Oh, this looks much, much worse to me. Oleg.