tunable/max_map_count: set a safer upper limit

oom-killer's behavior is worse than expected, so we have to set a safer
upper limit for max_map_count file. In this patch we set it to:
min{65536, available_memory}.

Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
Revert "mm/oom: add oom control check for memcg"

This reverts commit 071a94b4baf498a4c9d334c4022aa5e1bfad0d29.

OOM control is not stable on every platform, read() might be blocked due
to not receiving oom notification from eventfd. revert this patch for
now.

Signed-off-by: Caspar Zhang <caspar@casparzhang.com>
mem/oom: avoid unexpected error when no memcg swap accounting

Since commit http://git.kernel.org/linus/a42c390cfa0c,
which added an option to control memcg swap, when kernel
neither set CGROUP_MEM_RES_CTLR_SWAP_ENABLED nor add
'swapaccount=1' kernel parameter, that indicates memcg swap
accounting is disabled, it will have no such file:
memory.memsw.*, then oom03 & oom04 cases will fail.

The patch fixed it: removed memsw cases when memcg swap
accounting is disabled, and added a TCONF:
tst_resm(TCONF,"memcg swap accounting is disabled");

Signed-off-by: Zhouping Liu <zliu@redhat.com>
Reviewed-by: Caspar Zhang <czhang@redhat.com>
Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
mq_timedreceive: 10-2.c: check timeout error rather than invalid parameter error

10-2.c now passes the invalid parameter to mq_timedreceive by specifying
a negative value to nanoseconds field, and checks whether EINVAL is not
returned when a message can be removed from the queue immediately.

However, this may not be a appropriate testing of mq_timedreceive.
POSIX spec of mq_timedreceive says:
    The validity of the abstime parameter need not be checked
    if a message can be removed from the message queue immediately.

This is open for interpretation of POSIX spec, and it was argued about in LKML.
    https://lkml.org/lkml/2012/3/14/589

The conclusion in LKML was that what POSIX spec says is "you don't *have*
to check validity". That is, it is allowed to check the validity.

On the other hand, actually, timeout error should not be returned when message
can be performed immediately.

Therefore, I modify the testcase to check timeout error rather than invalid
parameter error.

Signed-off-by: Akira Takeuchi <takeuchi.akr@jp.panasonic.com>
Signed-off-by: Kiyoshi Owada <owada.kiyoshi@jp.panasonic.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
testfrmw:disable thread cancelability while output is running

Function output can be canceled by pthread_cancel(), which,
maybe, leads to a deadlock as it calls pthread_mutex_lock().
That's catched in case "pthread_join/4-1.c".

So,disable thread cancelability until output finishes.

Signed-off-by: DAN LI <li.dan@cn.fujitsu.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
aio_read:8-1.c: Forget initializing struct aiocb before using it

There are 2 changes in this patch.
 1. Initialize the aiocb struct before using it.
 2. If Prioritized Input and Output option is supported, submit the
    aiocb with invalid aio_reqprio, else return untested.

Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
mq_timedreceive: fix the bad coding style

code cleanups

Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>