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@lucife...
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.
I don't think a per-priv say lock is necessarily _that_ egregious since are people _really_ opening this one file and doing multiple parallel queries all that much?
Anyway this latest report seems entirely about the procmap stuff.