On Tue, 20 Jul 2021 14:43:52 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote: > On 18.07.21 23:41, Suren Baghdasaryan wrote: > > process_mrelease needs to be added in the CONFIG_MMU-dependent block which > > comes before __task_will_free_mem and task_will_free_mem. Move these > > functions before this block so that new process_mrelease syscall can use > > them. > > > > Signed-off-by: Suren Baghdasaryan <surenb@xxxxxxxxxx> > > --- > > changes in v2: > > - Fixed build error when CONFIG_MMU=n, reported by kernel test robot. This > > required moving task_will_free_mem implemented in the first patch > > - Renamed process_reap to process_mrelease, per majority of votes > > - Replaced "dying process" with "process which was sent a SIGKILL signal" in > > the manual page text, per Florian Weimer > > - Added ERRORS section in the manual page text > > - Resolved conflicts in syscall numbers caused by the new memfd_secret syscall > > - Separated boilerplate code wiring-up the new syscall into a separate patch > > to facilitate the review process > > > > mm/oom_kill.c | 150 +++++++++++++++++++++++++------------------------- > > 1 file changed, 75 insertions(+), 75 deletions(-) > > TBH, I really dislike this move as it makes git blame a lot harder with > any real benefit. > > Can't you just use prototypes to avoid the move for now in patch #2? > > static bool task_will_free_mem(struct task_struct *task); This change makes the code better - it's silly to be adding forward declarations just because the functions are in the wrong place. If that messes up git-blame then let's come up with better tooling rather than suffering poorer kernel code because the tools aren't doing what we want of them. Surely?
