On 4/14/22 08:55, Alexey Dobriyan wrote: > On Thu, Apr 14, 2022 at 04:23:13AM +0100, Matthew Wilcox wrote: >> On Wed, Apr 13, 2022 at 04:06:13PM -0700, Andrew Morton wrote: >> > On Wed, 13 Apr 2022 18:25:53 -0400 "Alex Xu (Hello71)" <alex_y_xu@xxxxxxxx> wrote: >> > > > 258f669e7e88 was 4 years ago, so I guess a -stable backport isn't >> > > > really needed. >> > > >> > > Current behavior (4.19+): >> [...] >> > > Pre-4.19 and post-patch behavior: >> > >> > I don't think this will work very well. smaps_rollup is the sort of >> > system tuning thing for which organizations will develop in-house >> > tooling which never get relesaed externally. >> > >> > > 3. As mentioned previously, this was already the behavior between 4.14 >> > > and 4.18 (inclusive). >> > > >> > >> > Yup. Hm, tricky. I'd prefer to leave it alone if possible. How >> > serious a problem is this, really? >> >> I don't think "It's been like this for four years" is as solid an argument >> as you might like. Certain distributions (of the coloured millinery >> variety, for example) haven't updated their kernel since then and so >> there may well be many organisations who have not been exposed to the >> current behaviour. Even my employers distribution, while it offers a >> 5.4 based kernel, still has many customers who have not moved from the >> 4.14 kernel. Inertia is a real thing, and restoring this older behaviour >> might well be an improvement. > > Returning ESRCH is better so that programs don't waste time reading and > closing empty files and instantiating useless inodes. Hm, unfortunately I don't remember why I put return -ESRCH for this case in addition to get_proc_task() failing. I doubt it was a conscious decision to treat kthreads differently - I think I would have preferred consistency with maps/smaps. Can the awk use case be fixed with some flag to make it ignore the errors? > Of course it is different if this patch was sent as response to a regression.
