From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754213AbcBBJL1 (ORCPT ); Tue, 2 Feb 2016 04:11:27 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34150 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754012AbcBBJLX (ORCPT ); Tue, 2 Feb 2016 04:11:23 -0500 Date: Tue, 2 Feb 2016 10:11:18 +0100 From: Ingo Molnar To: Wei Tang Cc: akpm@linux-foundation.org, peterz@infradead.org, tj@kernel.org, kirill.shutemov@linux.intel.com, jason.low2@hp.com, xypron.glpk@gmx.de, oleg@redhat.com, koct9i@gmail.com, josh@joshtriplett.org, ebiederm@xmission.com, cyphar@cyphar.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] kernel/fork.c: use sizeof() instead of sizeof Message-ID: <20160202091118.GB30393@gmail.com> References: <1454399594-14307-1-git-send-email-tangwei@cmss.chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1454399594-14307-1-git-send-email-tangwei@cmss.chinamobile.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Wei Tang wrote: > This patch fixes the checkpatch.pl warning to fork.c: > > WARNING: sizeof sig->rlim should be sizeof(sig->rlim) > > Signed-off-by: Wei Tang > --- > kernel/fork.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/fork.c b/kernel/fork.c > index 2e391c7..30e04d2 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1143,7 +1143,7 @@ static int copy_signal(unsigned long clone_flags, struct task_struct *tsk) > sig->real_timer.function = it_real_fn; > > task_lock(current->group_leader); > - memcpy(sig->rlim, current->signal->rlim, sizeof sig->rlim); > + memcpy(sig->rlim, current->signal->rlim, sizeof(sig->rlim)); > task_unlock(current->group_leader); > > posix_cpu_timers_init_group(sig); So there's over 1,000 such occurances in the kernel and we do not need this drip-drip churn... If anyone feels strongly about accepting such patches, then the right solution is to create a Coccinelle semantic patch to run over the whole kernel and get over with the churn once and for all. Thanks, Ingo