Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp8690imm; Thu, 2 Aug 2018 12:55:17 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdknpzhiAG4n8AgQAy+KyNpUOczlZCVuEXDpot7qIE7LmgV9xTbo5gOp3AMYsrPthO27iEx X-Received: by 2002:a63:be05:: with SMTP id l5-v6mr804049pgf.330.1533239717199; Thu, 02 Aug 2018 12:55:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533239717; cv=none; d=google.com; s=arc-20160816; b=gReVzix9+Yf1YeqtgMHU4/8IHmWSorQjeQWylTFT2Fl+d6HuElKmxLGE/Bg/VnenQ5 j4Pm0b4MW82CoQlnw6sLBDCC8EvAhqVS20Bk5Un2lVbQJIAmTNVCFmcf/R453eGPjZU5 V9lYY/K4HIgixTvofivpotY2ybdnUJYTfvCibIMU66biRzVc0fr97R+NO6pqnLS3G1yJ 63xdD3uTjlT6W64zLToGFs+WqMMN1DhhiTGpCOSdm0H3jn0VCcqBw5MTAxcwh4ix3Kat KnXz1Yx8JNZsFAXfI/JCfRMpyBUYTbD97QCnOB+jMdhJWrjmauzbp035n7tuwN9J8q7T 3kaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=7p8mIWf/t8LtjE55u0+fpsgskGxy2peYtkHsQGFdXbs=; b=JlrZX9AhM0KUT6cvhGwPVvmCga+YZa5ne3B3EZjd/U8Qm34pZuXI22ArWPqUGwaNrL JTpcF5j6rlwoS/SPLkKBcczEOd6OR1ISr7KVq2mV2Oi6uemi1uWbSOSWOucWVDTHagPM 94T7nekkB26D3dnPH4iJmNRuANn7Pye4MiOdEA+nLNSdBAE6vpcTOuEs2SmwwmA1Nhej 4X4wA65arve9Rbp85pYi4eekRfrD5jcHenwWwDsn2ceBZScdIy5MIgukMg4p0RWpICJD XOmDa17al4n1QpPx4SPRiazC4jUunOt8Uhl+cIGCaCHuLyOX2qIghiVg6mgGrgaukQPA KuqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gc9Apsxe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j11-v6si1950079pll.234.2018.08.02.12.55.01; Thu, 02 Aug 2018 12:55:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gc9Apsxe; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729034AbeHBVqj (ORCPT + 99 others); Thu, 2 Aug 2018 17:46:39 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:37959 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726268AbeHBVqj (ORCPT ); Thu, 2 Aug 2018 17:46:39 -0400 Received: by mail-it0-f67.google.com with SMTP id v71-v6so5209105itb.3; Thu, 02 Aug 2018 12:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7p8mIWf/t8LtjE55u0+fpsgskGxy2peYtkHsQGFdXbs=; b=gc9Apsxe5TjepHnJDyt/m2ksSDqPmXKL2fPL6BCsy6ps7tjIKyKkmGUkCyyME7bNmK +e/1qgLrVhn1HKJMTcnGtdyON1z+Hj+RrCtkFh9r/MzXR3lPvobzxtZksBe36dkABg3D txDv75SoFPVfXKmR1XzmU+NAG6EGLkUGHji5Gf5pW3QgXunZWcOi6odVgyMwmcvA9tL5 NWsx2tuIjRRpuspjScNtCbqtkIAuOOtYROHYXKC+PdC9BZuUxJQ2HSWjZAvYTUUDMsH/ 5yS9/WqtlIkIz7cQzv54mNRx5QoccpqAIcA8v8UDGllHzETfw7J0jlrEb/LSQQIHxZui lokQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7p8mIWf/t8LtjE55u0+fpsgskGxy2peYtkHsQGFdXbs=; b=qevQJUSpPJiqdgmqE3M20LScAkeY1Nfv15ZWMYPcmxwvjvpGDbah1SpwX4gSs5jWE+ qjFKsYywRVZ7hXaS8gwqfL5nU4Azxdn2fHMoAMeYIrpXilQypyA/IjXfT41ZGJ8Ftzz+ h/M1vKDJQ7R+ZUpv41WQdh52RGj3cpfdVJn9RHF8bYSqeHmMtAnH0tHbbOPg5ETG0qdN p8B6e4TEf8+mhq09xEv6DnWjI2BWXmMi3npKmoCYXzp6njUQvaS9jlDab/v5PC/xLao7 FfqmW5jhpdZqGRAIsahn3lk02936wvzri+QqxGgJ7/jTM2wKukeUB/l32gupsqeBm6tp kVYQ== X-Gm-Message-State: AOUpUlGgOVwzDKIGUfY5DSQOFVG27owXINCEYecdAr7aIkhgi9Q0r+yQ Hc58tQOwqRsCNKaePAqR3llwB7Jrfv7xrqoF0/u9YGO4 X-Received: by 2002:a02:943:: with SMTP id f64-v6mr919178jad.31.1533239642044; Thu, 02 Aug 2018 12:54:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac0:bc4a:0:0:0:0:0 with HTTP; Thu, 2 Aug 2018 12:53:41 -0700 (PDT) In-Reply-To: <20180731005615.GA2911@visor> References: <20180731005615.GA2911@visor> From: Dmitry Safonov <0x7f454c46@gmail.com> Date: Thu, 2 Aug 2018 20:53:41 +0100 Message-ID: Subject: Re: [PATCH RESEND] exec: don't force_sigsegv processes with a pending fatal signal To: Ivan Delalande Cc: Al Viro , linux-fsdevel@vger.kernel.org, open list , Oleg Nesterov , Andy Lutomirski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ivan, 2018-07-31 1:56 GMT+01:00 Ivan Delalande : > We were seeing unexplained segfaults in coreutils processes and other > basic utilities that we tracked down to binfmt_elf failing to load > segments for ld.so. Digging further, the actual problem seems to occur > when a process gets sigkilled while it is still being loaded by the > kernel. In our case when _do_page_fault goes for a retry it will return > early as it first checks for fatal_signal_pending(), so load_elf_interp > also returns with error and as a result search_binary_handler will > force_sigsegv() which is pretty confusing as nothing actually failed > here. > > Fixes: 19d860a140be ("handle suicide on late failure exits in execve() in search_binary_handler()") > Reference: https://lkml.org/lkml/2013/2/14/5 > Signed-off-by: Ivan Delalande +Cc: Oleg Nesterov +Cc: Andy Lutomirski > --- > fs/exec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/exec.c b/fs/exec.c > index bdd0eacefdf5..6e8007edbb2d 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1656,7 +1656,8 @@ int search_binary_handler(struct linux_binprm *bprm) > if (retval < 0 && !bprm->mm) { > /* we got to flush_old_exec() and failed after it */ > read_unlock(&binfmt_lock); > - force_sigsegv(SIGSEGV, current); > + if (!fatal_signal_pending(current)) > + force_sigsegv(SIGSEGV, current); I would suggest to add something like: : if (print_fatal_signals) : pr_info("load_binary() failed: %d\n", retval); It was interesting to catch that it actually segfaults during loading, probably will save someone a couple of minutes too ;-) > return retval; > } > if (retval != -ENOEXEC || !bprm->file) { Thanks, Dmitry