linux-kernel - Re: [PATCH] ipc: prevent lockup on alloc_msg and free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Mar 2019 10:10:10 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Li RongQing <lirongqing@...du.com>
Cc:     linux-kernel@...r.kernel.org, Davidlohr Bueso <dbueso@...e.de>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Manfred Spraul <manfred@...orfullife.com>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] ipc: prevent lockup on alloc_msg and free_msg

On Thu,  7 Mar 2019 16:10:22 +0800 Li RongQing <lirongqing@...du.com> wrote:

> From: Li Rongqing <lirongqing@...du.com>
> 
> msgctl10 of ltp triggers the following lockup When CONFIG_KASAN
> is enabled on large memory SMP systems, the pages initialization
> can take a long time, if msgctl10 requests a huge block memory,
> and it will block rcu scheduler, so release cpu actively.
> 
> ...
>
> Signed-off-by: Zhang Yu <zhangyu31@...du.com>
> Signed-off-by: Li RongQing <lirongqing@...du.com>

This signoff ordering somewhat implies that Zhang Yu was the author. 
But you added "From: Li Rongqing", so you will be recorded as the
patch's author.  Is this correct?

> --- a/ipc/msgutil.c
> +++ b/ipc/msgutil.c
> @@ -18,6 +18,7 @@
>  #include <linux/utsname.h>
>  #include <linux/proc_ns.h>
>  #include <linux/uaccess.h>
> +#include <linux/sched.h>
>  
>  #include "util.h"
>  
> @@ -72,6 +73,7 @@ static struct msg_msg *alloc_msg(size_t len)
>  		seg->next = NULL;
>  		pseg = &seg->next;
>  		len -= alen;
> +		cond_resched();
>  	}

This looks OK.

>  	return msg;
> @@ -178,5 +180,6 @@ void free_msg(struct msg_msg *msg)
>  		struct msg_msgseg *tmp = seg->next;
>  		kfree(seg);
>  		seg = tmp;
> +		cond_resched();
>  	}

This does not.  mqueue_evict_inode() (at least) calls free_msg() from
under spin_lock().