Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <cc502fe7-716b-8114-c9e6-439e3b9cf0f6@proxmox.com>
Date:   Wed, 26 Jul 2023 10:19:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: segfaults of processes while being killed after commit "mm: make
 the page fault mmap locking killable"
Content-Language: en-US
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Oleg Nesterov <oleg@redhat.com>
Cc:     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
References: <8d063a26-43f5-0bb7-3203-c6a04dc159f8@proxmox.com>
 <CAHk-=whKBx_UUKagfyF72EJrpqNCupF4yeoPgapjEBe1bynGcw@mail.gmail.com>
From:   Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <CAHk-=whKBx_UUKagfyF72EJrpqNCupF4yeoPgapjEBe1bynGcw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

Am 25.07.23 um 18:38 schrieb Linus Torvalds:
> On Tue, 25 Jul 2023 at 04:16, Fiona Ebner <f.ebner@proxmox.com> wrote:
>>
>> will end up without a vma and cause/log the segfault. Of course the
>> process is already being killed, but I'd argue it is very confusing to
>> users when apparent segfaults from such processes are being logged by
>> the kernel.
> 
> Ahh. Yes, that wasn't the intent. A process that is being killed
> should exit with the lethal signal, not SIGSEGV.
> 

Checking the status from waitpid, it does show that the process was
terminated by signal 9, even if the segfault was logged.

> But before we revert it, would you mind trying out the attached
> trivial patch instead?
> 

The patch works for me too :) (after adding the missing tsk argument
like Thomas pointed out)

> I'd also still be interested if the symptoms were anything else than
> 'show_unhandled_signals' causing the show_signal_msg() dance, and
> resulting in a message something like
> 
>     a.out[1567]: segfault at xyz ip [..] likely on CPU X
> 
> in dmesg...
> 
Yes, AFAICS, it is just those messages and nothing else.

Best Regards,
Fiona