On Thu, Jan 23, 2025 at 1:51 AM Fuad Tabba <tabba@xxxxxxxxxx> wrote: > > On Wed, 22 Jan 2025 at 22:16, Ackerley Tng <ackerleytng@xxxxxxxxxx> wrote: > > > > Fuad Tabba <tabba@xxxxxxxxxx> writes: > > > > Hey Fuad, I'm still working on verifying all this but for now this is > > one issue. I think this can be fixed by checking if the folio->mapping > > is NULL. If it's NULL, then the folio has been disassociated from the > > inode, and during the dissociation (removal from filemap), the > > mappability can also either > > > > 1. Be unset so that the default mappability can be set up based on > > GUEST_MEMFD_FLAG_INIT_MAPPABLE, or > > 2. Be directly restored based on GUEST_MEMFD_FLAG_INIT_MAPPABLE > > Thanks for pointing this out. I hadn't considered this case. I'll fix > in the respin. > Can the below scenario cause trouble? 1) Userspace converts a certain range of guest memfd as shared and grabs some refcounts on shared memory pages through existing kernel exposed mechanisms. 2) Userspace converts the same range to private which would cause the corresponding mappability attributes to be *MAPPABILITY_NONE. 3) Userspace truncates the range which will remove the page from pagecache. 4) Userspace does the fallocate again, leading to a new page getting allocated without freeing the older page which is still refcounted (step 1). Effectively this could allow userspace to keep allocating multiple pages for the same guest_memfd range.
