linux-kernel - Re: [PATCH] mm, gup: return EINTR when gup is interrupted by fatal signals

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wg_vgcq6R_JXUq0+GXuSLFV8tvfSTzFWjGTimJN1pjF+A@mail.gmail.com>
Date:   Thu, 9 Apr 2020 12:55:17 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Peter Xu <peterx@...hat.com>, Hillf Danton <hdanton@...a.com>,
        Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH] mm, gup: return EINTR when gup is interrupted by fatal signals

On Thu, Apr 9, 2020 at 12:11 AM Michal Hocko <mhocko@...nel.org> wrote:
>
> ERESTARTSYS is also quite confusing because the signal is fatal and so
> no handling will happen before returning to the userspace.

Ack. Except I'd rephrase that as "no restart" rather than "no handling".

We do end up handling the fatal signal, it's just that the handling
doesn't involve restarting, it just involves dying.

That said, I'll leave this to the usual channels, since it isn't
exactly the same kind of urgent fix that I picked up directly..

              Linus