linux-kernel - [PATCH 0/1] fsopen: fsconfig syscall restart fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Sep 2020 19:46:35 +0300
From:   Alexander Mikhalitsyn <alexander.mikhalitsyn@...tuozzo.com>
To:     viro@...iv.linux.org.uk
Cc:     avagin@...il.com,
        Alexander Mikhalitsyn <alexander.mikhalitsyn@...tuozzo.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/1] fsopen: fsconfig syscall restart fix

Hi guys!

Sometimes ago our CRIU CI started reporting hardly-reproducible (on developer
environment) error "EBUSY" from fsconfig syscall in the CRIU cgroups code.
https://github.com/checkpoint-restore/criu/blob/criu-dev/criu/cgroup.c#L585
The machine on which we caught this problem is PowerPC (POWER8). After tracing
and debugging that we realized that problem is that we get ERESTARTNOINR
from vfs_get_tree function in vfs_fsconfig_locked. After a more deep
investigation, we found that the source is cgroup1_get_tree() and
restart_syscall() at the end. I personally have no idea why we caught this only
on POWER8 VM and have no such problem on amd64. But anyway this is incorrect
behaviour and our patch should fix this problem and make this impossible on all
architectures.

Big thanks to Andrei Vagin. He helped me a lot to fully understand the
problem and prepare this patch.

Regards, Alex

Alexander Mikhalitsyn (1):
  fsopen: fsconfig syscall restart fix

 fs/fsopen.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

-- 
2.25.1