mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-01-23 02:14:37 +00:00
No description
blcrcheckpointcontainercontainerscriudmtcphighly-availablelinuxmemory-trackingmigrationparasitepost-copyrestoresnapshotsuspenduserfaultfdzero-downtime
b20780d6a0
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>
|
||
|---|---|---|
| contrib | ||
| coredump | ||
| crit | ||
| criu | ||
| Documentation | ||
| images | ||
| include/common | ||
| lib | ||
| scripts | ||
| soccr | ||
| test | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| COPYING | ||
| CREDITS | ||
| INSTALL.md | ||
| Makefile | ||
| Makefile.config | ||
| Makefile.install | ||
| Makefile.versions | ||
| README.md | ||
CRIU (Checkpoint and Restore in Userspace)
An utility to checkpoint/restore tasks. Using this tool, you can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space.
The project home is at http://criu.org.
Pages worth starting with are:
- Kernel configuration, compilation, etc
- A simple example of usage
- More sophisticated example with graphical app
A video tour on basic CRIU features
How to contribute
- How to submit patches;
- Send all bug reports to mailing list;
- Spread the word about CRIU in social networks;