[CRIU] [PATCHv3 00/23] Rectify 32-bit compatible C/R on x86
Andrei Vagin
avagin at virtuozzo.com
Mon Jan 9 10:19:08 PST 2017
On Mon, Jan 09, 2017 at 08:43:28PM +0300, Dmitry Safonov wrote:
> On 01/09/2017 08:42 PM, Andrei Vagin wrote:
> > On Mon, Jan 09, 2017 at 11:45:24AM +0300, Dmitry Safonov wrote:
> > > On 01/09/2017 10:37 AM, Andrei Vagin wrote:
> > > > On Thu, Dec 15, 2016 at 02:11:34PM +0300, Dmitry Safonov wrote:
> > > > > On 12/15/2016 01:58 PM, Dmitry Safonov wrote:
> > > > > > On 12/15/2016 03:37 AM, Andrei Vagin wrote:
> > > > > > > On Tue, Dec 13, 2016 at 04:14:06PM +0300, Pavel Emelyanov wrote:
> > > > > > > > Applied
> > > > > > >
> > > > > > > Good job!
> > > > > > >
> > > > > > > Dima, pls tell me how to execute tests for x32. Thanks!
> > > > > >
> > > > > > The support for 32-bit C/R is only from v4.9 kernel (just reminder).
> > > > > >
> > > > > > Here we go. I ran it with:
> > > > > > COMPAT_TEST=y make zdtm
> > > > > > ./test/zdtm.py run --all --keep-going
> > > > >
> > > > > Ugh-oh, forget to mention:
> > > > > some tests need libraries to be linked with, so you may need to install
> > > > > libcap-devel.i686 libaio-devel.i686, maybe something else - you'll spot
> > > > > it easily by liking errors.
> > > > >
> > > >
> > > > How can I check whether a kernel has all required patches?
> > > >
> > > > criu check --feature smth-x32
> > >
> > > You need this to check that it's supported on test-host, right?
> > > I'll add this to `criu check`; right now there is kerndat test
> > > kerndat_compat_restore(), but yet no call for it in criu check.
> >
> > I want to add smth like this into travis-test:
> >
> > criu check --feature smth-x32 && {
> > git clean -dxf test/zdtm
> > make COMPAT_TEST=y -C test/zdtm/static/ env00
> > ./test/zdtm.py run -t zdtm/static/env00
> > }
>
> I've send the patch for this ("cr-check: add compat_restore check").
> Hmm, but Travis uses an old kernel, AFAIK.
> So, it will be with your cool hack to update kernel to v4.9 or newer?
We execute this script to check linux-next. And I have a branch to check
linux-next in travis, it works like a charm
https://travis-ci.org/avagin/criu/builds/190165929
>
> >
> > >
> > > >
> > > > > >
> > > > > > For now, many tests fails with "new mapping appeared" with the address
> > > > > > of vsyscall page. That comes from 64-bit restorer. That's not a real
> > > > > > mapping (in the meaning of vma), so it cann't be unmapped in jump to
> > > > > > restorer. I've talked to Andy and he said he has patches for adding
> > > > > > arch_prctl for disabling vsyscall mapping emulation on per-process
> > > > > > basis. So for now all restored 32-bit processes have vsyscall mapping
> > > > > > after restore. It lays over 32-bit visible 4Gb space, so the only
> > > > > > side-effect is /proc/.../maps.
> > > > > > For the purpose of testing, I load kernel with boot parameter
> > > > > > `vsyscall=none' for now.
> > > > > >
> > > > > > Then the following 32-bit tests are failing now (WIP, should be
> > > > > > excluded for awhile):
> > > > > > ################### 51 TEST(S) FAILED (TOTAL 284/SKIPPED 38)
> > > > > > ###################
> > > > > > * zdtm/transition/maps008(unknown)
> > > > > > * zdtm/transition/file_aio(unknown)
> > > > > > * zdtm/static/mntns_link_ghost(unknown)
> > > > > > * zdtm/static/futex(unknown)
> > > > > > * zdtm/static/mntns_open(unknown)
> > > > > > * zdtm/static/stopped12(unknown)
> > > > > > * zdtm/static/fanotify00(unknown)
> > > > > > * zdtm/static/cgroup04(unknown)
> > > > > > * zdtm/static/stopped01(unknown)
> > > > > > * zdtm/static/fpu01(unknown)
> > > > > > * zdtm/static/file_locks03(unknown)
> > > > > > * zdtm/static/sigaltstack(unknown)
> > > > > > * zdtm/static/sse00(unknown)
> > > > > > * zdtm/static/helper_zombie_child(unknown)
> > > > > > * zdtm/static/cgroup01(unknown)
> > > > > > * zdtm/static/stopped02(unknown)
> > > > > > * zdtm/static/futex-rl(unknown)
> > > > > > * zdtm/static/macvlan(unknown)
> > > > > > * zdtm/static/rtc(unknown)
> > > > > > * zdtm/static/netns-dev(unknown)
> > > > > > * zdtm/static/vdso01(unknown)
> > > > > > * zdtm/static/cgroup00(unknown)
> > > > > > * zdtm/static/file_locks04(unknown)
> > > > > > * zdtm/static/cgroup02(unknown)
> > > > > > * zdtm/static/bridge(unknown)
> > > > > > * zdtm/static/del_standalone_un(unknown)
> > > > > > * zdtm/static/file_locks01(unknown)
> > > > > > * zdtm/static/timerfd(unknown)
> > > > > > * zdtm/static/file_locks02(unknown)
> > > > > > * zdtm/static/cgroup_stray(unknown)
> > > > > > * zdtm/static/sse20(unknown)
> > > > > > * zdtm/static/autofs(unknown)
> > > > > > * zdtm/static/sigpending(unknown)
> > > > > > * zdtm/static/stopped(unknown)
> > > > > > * zdtm/static/clone_fs(unknown)
> > > > > > * zdtm/static/mntns_link_remap(unknown)
> > > > > > * zdtm/static/maps02(unknown)
> > > > > > * zdtm/static/pthread00(unknown)
> > > > > > * zdtm/static/deleted_unix_sock(unknown)
> > > > > > * zdtm/static/shm(unknown)
> > > > > > * zdtm/static/cgroupns(unknown)
> > > > > > * zdtm/static/packet_sock_mmap(unknown)
> > > > > > * zdtm/static/fpu00(unknown)
> > > > > > * zdtm/static/shm-unaligned(unknown)
> > > > > > * zdtm/static/socket_aio(unknown)
> > > > > > * zdtm/static/maps00(unknown)
> > > > > > * zdtm/static/mlock_setuid(unknown)
> > > > > > * zdtm/static/different_creds(unknown)
> > > > > > * zdtm/static/pthread01(unknown)
> > > > > > * zdtm/static/mmx00(unknown)
> > > > > > * zdtm/static/signalfd00(unknown)
> > > > > > ##################################### FAIL
> > > > > > #####################################
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Dmitry
> > >
> > >
> > > --
> > > Dmitry
>
>
> --
> Dmitry
More information about the CRIU
mailing list