Andrew Vagin reported the problem found by a checker:
CID 174702 (#1 of 1): Out-of-bounds access (INCOMPATIBLE_CAST)
incompatible_cast: Pointer &f->raw.counter points to an object whose
effective type is int (32 bits, signed) but is dereferenced as a wider
unsigned long (64 bits, unsigned). This may lead to memory corruption.
It looks like, this points to real problem, which may happen on big-endian
platforms. In the code I relay on the fact, that FDS_EVENT_BIT has a small
number and the value, it determines, fits into int type without problems.
But it's correct only for little-endian.
In case of big-endian, if the word size is 8 bytes, then FDS_EVENT value
is in the last bytes, so there is an access to wrong memory.
To fix the problem, I suggest to use little-endian byte order to work
with task_st futex. Then, the bits from 0 to 31 will be in the low adresses,
i.e. in task_st futex. There is new primitives test_and_set_bit_le() and
set_bit_le() borrowed from the linux kernel for that.
This fixes the problem, but I suppose, the checker does not see the problem
so deep, and just compares the types size, so it will fail again.
So, let's enlarge the bit field size to silence it.
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Subprojects usually have own "asm" directory,
so to eliminate collision specify complete path.
travis-ci: success for common: Use complete path in inclusion
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
