Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 7 Mar 2019 10:10:10 -0800
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Li RongQing <lirongqing@baidu.com>
Cc:     linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        Manfred Spraul <manfred@colorfullife.com>,
        Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] ipc: prevent lockup on alloc_msg and free_msg
Message-Id: <20190307101010.919d18394ae43ecf9d2a2212@linux-foundation.org>
In-Reply-To: <1551946222-25470-1-git-send-email-lirongqing@baidu.com>
References: <1551946222-25470-1-git-send-email-lirongqing@baidu.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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

> From: Li Rongqing <lirongqing@baidu.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@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.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().