On Mon, Nov 28, 2016 at 04:18:03PM -0200, Marcelo Ricardo Leitner wrote:

On Mon, Nov 28, 2016 at 07:09:25PM +0100, Florian Westphal wrote:

quoted

Neil Horman [off-list ref] wrote:

[ trimming CCs ]

quoted

On Mon, Nov 28, 2016 at 06:47:10PM +0100, Florian Westphal wrote:

quoted

Neil Horman [off-list ref] wrote:

quoted

I'm not sure I agree with that.  Generally speaking it seems like the right
thing to do, if you want to avoid filling logs with warnings, but this is the
sort of error that is going to be accompanied by severe service interruption.
I'd rather see a reason behind that in the logs, than just have it occur
silently.

Its not silent -- the setsockopt call will fail and userspace should
display an error.

Thats not true.  If the OOM succedes in freeing enough memory to fulfill the
request the setsockopt may complete without error, you're just left with a
killed process...somewhere.  Thats seems a bit dodgy to me

__GFP_NOWARN is about allocation failures only and it won't disable OOM
kill messages.  oom_kill_process() has no idea on GFP_NOWARN when doing
the logging.

quoted

We should prevent OOM killer from running in first place (GFP_NORETRY should work).

Oh. Really?

Now I see why. Then we're basically saying that's better to fail this
operation than to kill some random process around.
And kmalloc() is already using GFP_NORETRY in this same place.

  Marcelo