On Sun, Jan 04, 2026 at 10:12:50PM +0100, Mikulas Patocka wrote: > > > On Fri, 2 Jan 2026, Lorenzo Stoakes wrote: > > > +cc literally everyone you should have cc'd in mm :/ > > > > Hi Mikulas, > > > > You really need to check MAINTAINERS, you've sent a patch that changes > > mm/vma.c > > without cc'ing a single maintainer or reviewer of that file. I just > > happened to > > notice this by chance, even lei seemed to mess up the file query for some > > reason. > > I saw > > MEMORY MANAGEMENT > M: Andrew Morton <[email protected]> > L: [email protected] > S: Maintained > > in the MAINTAINERS file, so I sent the patch to Andrew and to > [email protected]. I should have sent it also to people on the "MEMORY > MANAGEMENT - CORE" section, but I missed it.
Yup things have changed :) scripts/get_maintainers.pl --no-git ... is the way to be sure. Understand if you haven't touched mm for a while you'd assume it was as was but now we really do try to have people assigned to each bit. > > > I'm confused in general about this patch, you sent it on 7th Nov? And it's > > been > > ignored until now and then taken without review to the hotfixes queue? > > I'm developing code that translates parallelizable loops written in the > Ajla programming language (www.ajla-lang.cz) into OpenCL and runs them on > the graphics card. Ajla sets up a periodic timer that sends a signal for > scheduling purposes and this signal interferes with OpenCL, causing the > -EINTR failures. > > So far, I worked around this bug by blocking all signals around the > functions clGetPlatformIDs and clGetDeviceIDs - but it would be better to > fix it in the Linux kernel and remove the signal-blocking hacks. Sure I get that, I'm just confused as to why this was suddenly taken to mm-unstable-hotfix out of the blue a couple months later. Anyway I sent another mail with review, please rework this patch accordingly. > > Mikulas > > Thanks, Lorenzo
