On Tue, Jul 15, 2025 at 11:52:49AM +0200, David Hildenbrand wrote: > On 15.07.25 11:40, Lorenzo Stoakes wrote: > > On Tue, Jul 15, 2025 at 10:16:41AM +0200, Vlastimil Babka wrote: > > > > Andrew, could you please remove this patchset from mm-unstable for now > > > > until I fix the issue and re-post the new version? > > > > > > Andrew can you do that please? We keep getting new syzbot reports. > > > > I also pinged up top :P just to be extra specially clear... > > > > > > > > > The error I got after these fixes is: > > > > > > I suspect the root cause is the ioctls are not serialized against each > > > other > > > (probably not even against read()) and yet we treat m->private as safe to > > > work on. Now we have various fields that are dangerous to race on - for > > > example locked_vma and iter races would explain a lot of this. > > > > > > I suspect as long as we used purely seq_file workflow, it did the right > > > thing for us wrt serialization, but the ioctl addition violates that. We > > > should rather recheck even the code before this series, if dangerous ioctl > > > vs read() races are possible. And the ioctl implementation should be > > > refactored to use an own per-ioctl-call private context, not the > > > seq_file's > > > per-file-open context. > > > > Entirely agree with this analysis. I had a look at most recent report, see: > > > > https://lore.kernel.org/linux-mm/f13cda37-06a0-4281-87d1-042678a38a6b@lucifer.local/ > > > > AFAICT we either have to lock around the ioctl or find a new way of storing > > per-ioctl state. > > > > We'd probably need to separate out the procmap query stuff to do that > > though. Probably. > > When I skimmed that series the first time, I was wondering "why are we even > caring about PROCMAP_QUERY that in the context of this patch series". > > Maybe that helps :)
Haha well I think it's _still useful_ for avoid contention of the mmap lock. But we probably just need to bite bullet and lock per-fd for this > > -- > Cheers, > > David / dhildenb >
