On Tue, Mar 27, 2018 at 09:06:37AM +0200, Michal Hocko wrote: >On Mon 26-03-18 19:54:31, Sasha Levin wrote: >[...] >> About half a year ago. I'm not sure about the no visibility part - >> maintainers and authors would receive at least 3 mails for each patch >> that got in this way, and would have at least a week (usually a lot >> more) to object to the inclusion. Did you not receive any mails from >> me? > >Well, I was aware of your emails yet my free time didn't really allow me >to follow those patch bombs. I responded only when some email subject >hit my eyes as being non-stable candidate. So by no means the MM >backports were reviewed by me. And considering how hard it is to get any >review for MM patches in general I strongly suspect that others didn't >review either. Being aware is different than saying it was snuck in without anyone knowing. >In general I am quite skeptical about the automagic backports >selections, to be honest. MM patches should be reasonably good at >selecting stable backports and adding more patches on top just risks >regressions. Okay, let's take mm/ as a subsystem that is doing a good job with submitting stuff to -stable. There were 40 patches in total going into the 4.14 LTS tree that touched mm/. Out of those, 5 were selected via the "automagic" process: > 647a37ec1a17 mm/frame_vector.c: release a semaphore in 'get_vaddr_frames()' > d91c3f2e540f mm/early_ioremap: Fix boot hang with earlyprintk=efi,keep > b2ba0bd34695 kmemleak: add scheduling point to kmemleak_scan() > 5ca94e03675a slub: fix sysfs duplicate filename creation when slub_debug=O > 342ee8775800 mm, x86/mm: Fix performance regression in get_user_pages_fast() The only "questionable" one here I see is the performance regression one, which I decided to keep in because it's a rather severe one in a common code path. Even good subsystems might sometimes miss a patch or two. But yes, I've received less response from maintainers than I expected, so I'll switch it to an opt-in model for new patches that go upstream. -- Thanks, Sasha-- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
