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
| ||
|
Date: Wed, 9 Sep 2020 22:49:12 +0100 From: Matthew Wilcox <willy@...radead.org> To: Vlastimil Babka <vbabka@...e.cz> Cc: zangchunxin@...edance.com, akpm@...ux-foundation.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Muchun Song <songmuchun@...edance.com> Subject: Re: [PATCH v2] mm/vmscan: fix infinite loop in drop_slab_node On Wed, Sep 09, 2020 at 07:59:44PM +0200, Vlastimil Babka wrote: > - Exit also on other signals such as SIGABRT, SIGTERM? If I write to drop_caches > and think it's too long, I would prefer to kill it by ctrl-c and not just kill > -9. Dunno if the canonical way of testing for this is if > (signal_pending(current)) or differently. fatal_signal_pending() is the canonical way to do it. If your task has installed a signal handler for ABRT or TERM, that's its prerogative, but it's chosen not to get killed, and it's not allowed to see short reads/writes, so we can't break out early.
Powered by blists - more mailing lists