All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Fiona Ebner <f.ebner@proxmox.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	akpm@linux-foundation.org,
	Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Wolfgang Bumiller <w.bumiller@proxmox.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: segfaults of processes while being killed after commit "mm: make the page fault mmap locking killable"
Date: Wed, 26 Jul 2023 11:26:53 +0200	[thread overview]
Message-ID: <20230726092652.GA7943@redhat.com> (raw)
In-Reply-To: <CAHk-=whKBx_UUKagfyF72EJrpqNCupF4yeoPgapjEBe1bynGcw@mail.gmail.com>

On 07/25, Linus Torvalds wrote:
>
> What exactly made you notice? Is it just the logging from
> 'show_unhandled_signals' being set?
>
> Because the actual signal itself, from the
>
>         force_sig_fault(SIGSEGV, si_code, (void __user *)address);
>
> in __bad_area_nosemaphore() should be overridden by the fact that a
> lethal signal was already pending.

Yes, SIGSEGV won't be even delivered, prepare_signal() returns F if
SIGNAL_GROUP_EXIT is set.

> But let's add a couple of signal people rather than the mm people to
> the participants. Eric, Oleg - would not an existing fatal signal take
> precedence over a new SIGSEGV? I obviously thought it did, but looking
> at 'get_signal()' and the signal delivery, I don't actually see any
> code to that effect.

See

		/* Has this task already been marked for death? */
		if ((signal->flags & SIGNAL_GROUP_EXIT) ||
		     signal->group_exec_task) {
			clear_siginfo(&ksig->info);
			ksig->info.si_signo = signr = SIGKILL;
			sigdelset(&current->pending.signal, SIGKILL);
			trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
				&sighand->action[SIGKILL - 1]);
			recalc_sigpending();
			goto fatal;
		}

in get_signal().

So yes, get_signal() returns SIGKILL if fatal_signal_pending() == T which
implies SIGNAL_GROUP_EXIT.

I think your patch is fine.

Oleg.


      parent reply	other threads:[~2023-07-26  9:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-25 11:16 segfaults of processes while being killed after commit "mm: make the page fault mmap locking killable" Fiona Ebner
2023-07-25 16:38 ` Linus Torvalds
2023-07-26  6:51   ` Thomas Lamprecht
2023-07-26  8:19   ` Fiona Ebner
2023-07-26 17:59     ` Linus Torvalds
2023-07-27  7:57       ` Fiona Ebner
2023-07-26  9:26   ` Oleg Nesterov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230726092652.GA7943@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=f.ebner@proxmox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=t.lamprecht@proxmox.com \
    --cc=torvalds@linux-foundation.org \
    --cc=w.bumiller@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.