linux-kernel - madvise() flags for not to sync dirty pages to the disk in shared mapping

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>] [day] [month] [year] [list]

Message-ID: <CACUYsyG03ysubRp7UKPEQzz3Fm9e-J_yxp4S60jZ37WwagiXxA@mail.gmail.com>
Date:   Wed, 12 Jun 2019 10:58:11 +0530
From:   dharmendra hans <dharamhans87@...il.com>
To:     linux-kernel@...r.kernel.org
Cc:     dharmendra singh <dharamhans87@...il.com>
Subject: madvise() flags for not to sync dirty pages to the disk in shared mapping

Hi,
I was searching for some  madvise() flag options which allow my
application to have choice of not syncing dirty pages created through
shared mmap() to the disk. Issue is that currently dirty pages created
by the application will be synced to the disk and there is no way
application can avoid that except MADV_REMOVE. But MADV_REMOVE punches
the hole in the file and it takes a lot of time if mapping size was
big, therefore one wants to avoid this option as it delays the further
state change in application.

So  one seems to have two issue.
1) Application is forced to wait during munmap() as dirty pages are synced.
2) if one kill the application process, it lands in process defunct
state for long time and it seems pages which were created by
application are being synced to the disk.

MADV_REMOVE seems to solve it but it is really slow due to file
truncation on mapped file.
What is desired is that application should be allowed choice of no
dirty pages sync without creating hole in the mapped file.

-Dharmendra