Hi Jane, looks good. Checkpatch prompts me to point out a couple more fixups:
This patch is titled:
"mm/memory-failure.c clean up..."
...to match the second patch it should be:
"mm/memory-failure: clean up..."
On Tue, Aug 6, 2019 at 10:26 AM Jane Chu <jane.chu@xxxxxxxxxx> wrote:
>
> add_to_kill() expects the first 'tk' to be pre-allocated, it makes
> subsequent allocations on need basis, this makes the code a bit
> difficult to read. Move all the allocation internal to add_to_kill()
> and drop the **tk argument.
>
> Signed-off-by: Jane Chu <jane.chu@xxxxxxxxxx>
> ---
> mm/memory-failure.c | 40 +++++++++++++---------------------------
> 1 file changed, 13 insertions(+), 27 deletions(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index d9cc660..51d5b20 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -304,25 +304,19 @@ static unsigned long dev_pagemap_mapping_shift(struct page *page,
> /*
> * Schedule a process for later kill.
> * Uses GFP_ATOMIC allocations to avoid potential recursions in the VM.
> - * TBD would GFP_NOIO be enough?
> */
> static void add_to_kill(struct task_struct *tsk, struct page *p,
> struct vm_area_struct *vma,
> - struct list_head *to_kill,
> - struct to_kill **tkc)
> + struct list_head *to_kill)
> {
> struct to_kill *tk;
>
> - if (*tkc) {
> - tk = *tkc;
> - *tkc = NULL;
> - } else {
> - tk = kmalloc(sizeof(struct to_kill), GFP_ATOMIC);
> - if (!tk) {
> - pr_err("Memory failure: Out of memory while machine check handling\n");
> - return;
> - }
> + tk = kmalloc(sizeof(struct to_kill), GFP_ATOMIC);
> + if (!tk) {
> + pr_err("Memory failure: Out of memory while machine check handling\n");
> + return;
> }
checkpatch points out that this error message can be deleted.
According to the commit that added this check (ebfdc40969f2
"checkpatch: attempt to find unnecessary 'out of memory' messages")
the kernel already prints a message and a backtrace on these events,
so seems like a decent additional cleanup to fold.
With those fixups you can add:
Reviewed-by: Dan Williams <dan.j.williams@xxxxxxxxx>
...along with Naoya's ack.
I would Cc: Andrew Morton on the v5 posting of these as he's the
upstream path for changes to this file.
