linux-kernel - [QUESTION] Sharing a `struct page` across multiple `struct address

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:   Fri, 24 Jul 2020 17:22:21 -0700
From:   Vito Caputo <vcaputo@...garu.com>
To:     linux-kernel <linux-kernel@...r.kernel.org>
Cc:     linux-fsdevel@...r.kernel.org, Dave Chinner <david@...morbit.com>
Subject: [QUESTION] Sharing a `struct page` across multiple `struct
 address_space` instances

Hello folks,

I've been poking around the shmem/tmpfs code with an eye towards
adding reflink support to tmpfs.

Prior to looking at the code, conceptually I was envisioning the pages
in the reflink source inode's address_space would simply get their
refcounts bumped as they were added to the dest inode's address_space,
with some CoW flag set to prevent writes.

But there seems to be a fundamental assumption that a `struct page`
would only belong to a single `struct address_space` at a time, as it
has single `mapping` and `index` members for reverse mapping the page
to its address_space.

Am I completely lost here or does it really look like a rather
invasive modification to support this feature?

I have vague memories of Dave Chinner mentioning work towards sharing
pages across address spaces in the interests of getting reflink copies
more competitive with overlayfs in terms of page cache utilization.

Dave did you ever end up going down this path?

Regards,
Vito Caputo