On Tue, Sep 26, 2023, isaku.yamahata@xxxxxxxxx wrote: > From: Isaku Yamahata <isaku.yamahata@xxxxxxxxx> > > Refactor guest_memfd to use inode->i_private to store info about kvm_gmem. Why!?!?!? Sadly, I don't have telepathic superpowers. This changelog only explains *what* the code is doing, what I need to know is *why* you want to make this change. The below kinda sorta suggests that this is to simplify the code, but it's not at all obvious that that's the actual motivation, or the only motiviation. > Currently it is stored in the following way. > - flags in inode->i_private > - struct kvm_gmem in file->private_data > - struct kvm_gmem in linked linst in inode->i_mapping->private_list > And this list has single entry. > > The relationship between struct file, struct inode and struct kvm_gmem is > 1:1, not 1:many. No, it's not. Or at least it won't be in the future. As I explained before[1]: : The code is structured to allow for multiple gmem instances per inode. This isn't : actually possible in the initial code base, but it's on the horizon[*]. I included : the list-based infrastructure in this initial series to ensure that guest_memfd : can actually support multiple files per inode, and to minimize the churn when the : "link" support comes along. : [*] https://lore.kernel.org/all/cover.1691446946.git.ackerleytng@xxxxxxxxxx [1] https://lore.kernel.org/all/ZQsAiGuw%2F38jIOV7@xxxxxxxxxx
