On Mon, Apr 24, 2023 at 07:53:26PM -0300, Jason Gunthorpe wrote: > On Mon, Apr 24, 2023 at 08:18:33PM +0100, Lorenzo Stoakes wrote: > > > I think this patch suggestion has scope crept from 'incremental > > improvement' to 'major rework of GUP' at this point. > > I don't really expect to you clean up all the callers - but we are > trying to understand what is actually wrong here to come up with the > right FOLL_ names and overall strategy. Leave behind a comment, for > instance. > Right, but you are suggesting introducing a whole new GUP interface holding the right locks etc. which is really scope-creeping from the original intent. I'm not disagreeing that we need an interface that can return things in a state where the dirtying can be done correctly, I just don't think _this_ patch series is the place for it. > I don't think anyone has really thought about the ptrace users too > much till now, we were all thinking about DMA use cases, it shows we > still have some areas that need attention. I do like to feel that my recent glut of GUP activity, even if noisy and frustrating, has at least helped give some insights into usage and semantics :) > > > Also surely you'd want to obtain the PTL of all mappings to a file? > > No, just one is fine. If you do the memcpy under a single PTL that > points at a writable copy of the page then everything is trivially > fine because it is very similar to what the CPU itself would do, which > is fine by definition.. > > Jason Except you dirty a page that is mapped elsewhere that thought everything was cleaned and... not sure the PTLs really help you much? Anyway I feel we're digressing into the broader discussion which needs to be had, but not when trying to unstick the vmas series :) I am going to put forward an opt-in variant of this change that explicitly checks whether any VMA in the range requires dirty page tracking, if not failing the GUP operation. This can then form the basis of the opt-OUT variant (it'll be the same check code right?) and help provide a basis for the additional work that clearly needs to be done. It will also replace the open-coded VMA check in io_uring so has utility and justification just from that. If we want to be more adventerous the opt-in variant could default to on for FOLL_LONGTERM too, but that discussion can be had over on that patch series.
