Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Subject: Re: [PATCH] rcu: Handle failure of memory allocation functions
To:     paulmck@kernel.org
Cc:     Davidlohr Bueso <dave@stgolabs.net>,
        Josh Triplett <josh@joshtriplett.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Neeraj Upadhyay <quic_neeraju@quicinc.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
        hukun@nfschina.com, qixu@nfschina.com, yuzhe@nfschina.com,
        renyu@nfschina.com
References: <20220611093055.1473-1-liqiong@nfschina.com>
 <20220611163432.GM1790663@paulmck-ThinkPad-P17-Gen-1>
From:   liqiong <liqiong@nfschina.com>
Message-ID: <e71a9031-68dc-93d0-7aff-e4060bb56a24@nfschina.com>
Date:   Sun, 12 Jun 2022 14:11:09 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20220611163432.GM1790663@paulmck-ThinkPad-P17-Gen-1>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk


在 2022年06月12日 00:34, Paul E. McKenney 写道:
> On Sat, Jun 11, 2022 at 05:30:55PM +0800, Li Qiong wrote:
>> Add warning when these functions (eg:kmalloc,vmalloc) fail, handle the
>> failure.
>>
>> Signed-off-by: Li Qiong <liqiong@nfschina.com>
> Good catch, thank you!  However...
>
>> ---
>>  kernel/rcu/rcutorture.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
>> index 7120165a9342..97f90e304ae3 100644
>> --- a/kernel/rcu/rcutorture.c
>> +++ b/kernel/rcu/rcutorture.c
>> @@ -1991,6 +1991,10 @@ static void rcu_torture_mem_dump_obj(void)
>>  
>>  	kcp = kmem_cache_create("rcuscale", 136, 8, SLAB_STORE_USER, NULL);
> As long as we are checking, why not also check this one?
>
> 							Thanx, Paul

Hi Paul,
Yes,  the kmem_cache_create  would fail too. 
I searched  "kernel" directory, found that It seems  all the code just check kmem_cache_alloc()，
So, I ignored   kmem_cache_create() .  I will submit a v2 patch.

Thanks,
Li Qiong


>
>>  	rhp = kmem_cache_alloc(kcp, GFP_KERNEL);
>> +	if (WARN_ON_ONCE(!rhp)) {
>> +		kmem_cache_destroy(kcp);
>> +		return;
>> +	}
>>  	pr_alert("mem_dump_obj() slab test: rcu_torture_stats = %px, &rhp = %px, rhp = %px, &z = %px\n", stats_task, &rhp, rhp, &z);
>>  	pr_alert("mem_dump_obj(ZERO_SIZE_PTR):");
>>  	mem_dump_obj(ZERO_SIZE_PTR);
>> @@ -2007,6 +2011,8 @@ static void rcu_torture_mem_dump_obj(void)
>>  	kmem_cache_free(kcp, rhp);
>>  	kmem_cache_destroy(kcp);
>>  	rhp = kmalloc(sizeof(*rhp), GFP_KERNEL);
>> +	if (WARN_ON_ONCE(!rhp))
>> +		return;
>>  	pr_alert("mem_dump_obj() kmalloc test: rcu_torture_stats = %px, &rhp = %px, rhp = %px\n", stats_task, &rhp, rhp);
>>  	pr_alert("mem_dump_obj(kmalloc %px):", rhp);
>>  	mem_dump_obj(rhp);
>> @@ -2014,6 +2020,8 @@ static void rcu_torture_mem_dump_obj(void)
>>  	mem_dump_obj(&rhp->func);
>>  	kfree(rhp);
>>  	rhp = vmalloc(4096);
>> +	if (WARN_ON_ONCE(!rhp))
>> +		return;
>>  	pr_alert("mem_dump_obj() vmalloc test: rcu_torture_stats = %px, &rhp = %px, rhp = %px\n", stats_task, &rhp, rhp);
>>  	pr_alert("mem_dump_obj(vmalloc %px):", rhp);
>>  	mem_dump_obj(rhp);
>> -- 
>> 2.11.0
>>