On Wed, Oct 16, 2024 at 08:37:12PM GMT, Miklos Szeredi wrote: > On Wed, 16 Oct 2024 at 19:52, Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote: > > > If I understand you correctly, you are saying fuse server doing wrong > > things like accessing the files it is serving is not something we need > > to care about. > > I don't think detecting such recursion is feasible or even generally possible. > > > More specifically all the operations which directly > > manipulates the folios it is serving (like migration) should be ignored. > > Is this correct? > > Um, not sure I understand. If migration can be triggered on fuse > folios that results in the task that triggered the migration to wait > on the fuse folio, then that's bad. Why is it bad? I can understand fuse server getting blocked on fuse folios is bad but why it is bad for other applications/tasks? I am wondering network filesystems have to handle similar situation then why is it bad just for fuse? > Ignoring fuse folios is the only > solution that I can see, and that's basically what the current temp > page copy does. > > Sprinkling mm code with fuse specific conditionals seems the only > solution if we want to get rid of the temp page thing. Hopefully > there aren't too many of those. It might be a bit more than sprinkling. The reclaim code has to activate the folio to avoid reclaiming the folio in near future. I am not sure what we will need to do for move_pages() syscall.
