On 2015-06-08 13:59, David Rientjes wrote:
I believe so (haven't actually read the patch itself, just the changelog), although it is only a change for certain configurations to a very specific and (I hope infrequently) used piece of functionality. Like I said above, if I wanted to crash my system, I'd be using sysrq-c; and if I'm using sysrq-f, I want _some_ task to die _now_.On Fri, 5 Jun 2015, Austin S Hemmelgarn wrote:I'm not sure what the benefit of this is, and it's adding more code. Having multiple pathways and requirements, such as constrained_alloc(), to oom kill a process isn't any clearer, in my opinion. It also isn't intended to be optimized since the oom killer called from the page allocator and from sysrq aren't fastpaths. To me, this seems like only a source code level change and doesn't make anything more clear but rather adds more code and obfuscates the entry path.At the very least, it does make the semantics of sysrq-f much nicer for admins (especially the bit where it ignores the panic_on_oom setting, if the admin wants the system to panic, he'll use sysrq-c). There have been times I've had to hit sysrq-f multiple times to get to actually kill anything, and this looks to me like it would eliminate that rather annoying issue as well.Are you saying there's a functional change with this patch/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature