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
| ||
|
Message-ID: <CAJWu+oqP64QzvPM6iHtzowek6s4p+3rb7WDXs1z51mwW-9mLbA@mail.gmail.com> Date: Wed, 4 Apr 2018 21:12:52 -0700 From: Joel Fernandes <joelaf@...gle.com> To: Matthew Wilcox <willy@...radead.org> Cc: Steven Rostedt <rostedt@...dmis.org>, Michal Hocko <mhocko@...nel.org>, Zhaoyang Huang <huangzhaoyang@...il.com>, Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>, kernel-patch-test@...ts.linaro.org, Andrew Morton <akpm@...ux-foundation.org>, "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>, Vlastimil Babka <vbabka@...e.cz> Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem On Wed, Apr 4, 2018 at 7:58 PM, Matthew Wilcox <willy@...radead.org> wrote: > On Wed, Apr 04, 2018 at 11:47:30AM -0400, Steven Rostedt wrote: >> I originally was going to remove the RETRY_MAYFAIL, but adding this >> check (at the end of the loop though) appears to have OOM consistently >> kill this task. >> >> I still like to keep RETRY_MAYFAIL, because it wont trigger OOM if >> nothing comes in and tries to do an allocation, but instead will fail >> nicely with -ENOMEM. > > I still don't get why you want RETRY_MAYFAIL. You know that tries > *harder* to allocate memory than plain GFP_KERNEL does, right? And > that seems like the exact opposite of what you want. No. We do want it to try harder but not if its already setup for failure.
Powered by blists - more mailing lists