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 :)
--
Cheers,
David / dhildenb
