From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754404AbdBURzh (ORCPT ); Tue, 21 Feb 2017 12:55:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58250 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751351AbdBURza (ORCPT ); Tue, 21 Feb 2017 12:55:30 -0500 Date: Tue, 21 Feb 2017 18:53:55 +0100 From: Oleg Nesterov To: "Eric W. Biederman" Cc: Andrew Morton , Mika =?iso-8859-1?Q?Penttil=E4?= , Aleksa Sarai , Andy Lutomirski , Attila Fazekas , Jann Horn , Kees Cook , Michal Hocko , Ulrich Obergfell , linux-kernel@vger.kernel.org Subject: Re: [PATCH V2 1/2] exec: don't wait for zombie threads with cred_guard_mutex held Message-ID: <20170221175354.GA31436@redhat.com> References: <20170213141452.GA30203@redhat.com> <20170213141516.GA30233@redhat.com> <20170213180454.GA2858@redhat.com> <87zihmpdkf.fsf@xmission.com> <20170220152202.GA13726@redhat.com> <87vas4wl3z.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vas4wl3z.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.25]); Tue, 21 Feb 2017 17:55:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/21, Eric W. Biederman wrote: > > Today cred_guard_mutex is part of making exec appear to be an atomic > operation to ptrace and and proc. To make exec appear to be atomic > we do need to take the mutex at the beginning and release it at the end > of exec. > > The semantics of exec appear atomic to ptrace_attach and to proc readers > are necessary to ensure we use the proper process credentials in the > event of a suid exec. This is clear. My point is that imo a) it is over-used in fs/proc and b) the scope of this mutex if execve is too huge. I see absolutely no reason to do copy_strings() with this mutex held, for example. And note that copy_strings() can use a lot of memory/time, it can trigger oom,swapping, etc. But let me repeat, this is a bit off-topic right now, this patch doesn't change anything in this respect, afaics. > I believe making cred_guard_mutex per task is an option. Reducing the > scope of cred_guard_mutex concerns me. There appear to be some fields > like sighand that we currently expose in proc please see another email, collect_sigign_sigcatch() is called without this mutex. > Do you know if we can make cred_guard_mutex a per-task lock again? I think we can, but this needs some (afaics simple) changes too. But for what? Note that the problem fixed by this series won't go away if we do this. So what do you think about this series? Oleg.