From: Wang YanQing <udknight@gmail.com>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: xiaoguangrong@cn.fujitsu.com, mingo@elte.hu,
paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
a.p.zijlstra@chello.nl, npiggin@suse.de,
deepthi@linux.vnet.ibm.com, peterz@infradead.org,
rusty@rustcorp.com.au, heiko.carstens@de.ibm.com,
rostedt@goodmis.org, miltonm@bga.com,
srivatsa.bhat@linux.vnet.ibm.com, jens.axboe@oracle.com,
tj@kernel.org, akpm@linux-foundation.org,
svaidy@linux.vnet.ibm.com, shli@kernel.org, tglx@linutronix.de,
lig.fnst@cn.fujitsu.com, anton@samba.org
Subject: Re: [PATCH 3/3] smp/ipi:Remove check around csd lock in handler for smp_call_function variants
Date: Sat, 6 Jul 2013 13:45:53 +0800 [thread overview]
Message-ID: <20130706054552.GA2929@udknight> (raw)
In-Reply-To: <20130705162720.16888.81958.stgit@preeti.in.ibm.com>
On Fri, Jul 05, 2013 at 09:57:21PM +0530, Preeti U Murthy wrote:
> call_single_data is always locked by all callers of
> arch_send_call_function_single_ipi() or
> arch_send_call_function_ipi_mask() which results in execution of
> generic_call_function_interrupt() handler.
>
> Hence remove the check for lock on csd in generic_call_function_interrupt()
> handler, before unlocking it.
I can't find where is the generic_call_function_interrupt :)
> Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
> Cc: srivatsa.bhat@linux.vnet.ibm.com
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Rusty Russell <rusty@rustcorp.com.au
> ---
>
> kernel/smp.c | 14 +-------------
> 1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/kernel/smp.c b/kernel/smp.c
> index b6981ae..d37581a 100644
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@ -181,25 +181,13 @@ void generic_smp_call_function_single_interrupt(void)
>
> while (!list_empty(&list)) {
> struct call_single_data *csd;
> - unsigned int csd_flags;
>
> csd = list_entry(list.next, struct call_single_data, list);
> list_del(&csd->list);
>
> - /*
> - * 'csd' can be invalid after this call if flags == 0
> - * (when called through generic_exec_single()),
> - * so save them away before making the call:
> - */
> - csd_flags = csd->flags;
> -
You haven't mention this change in the ChangeLog, don't do it.
I can't see any harm to remove csd_flags, but I hope others
check it again.
> csd->func(csd->info);
>
> - /*
> - * Unlocked CSDs are valid through generic_exec_single():
> - */
> - if (csd_flags & CSD_FLAG_LOCK)
> - csd_unlock(csd);
> + csd_unlock(csd);
I don't like this change, I think check CSD_FLAG_LOCK
to make sure we really need csd_unlock is good.
Just like you can't know who and how people will use the
API, so some robust check code is good.
next prev parent reply other threads:[~2013-07-06 5:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-05 16:26 [PATCH 0/3] smp/ipi: Minor cleanups in smp_call_function variants Preeti U Murthy
2013-07-05 16:27 ` [PATCH 1/3] smp/ipi: Remove redundant cfd->cpumask_ipi mask Preeti U Murthy
2013-07-06 3:13 ` Wang YanQing
2013-07-06 5:29 ` Preeti U Murthy
2013-07-06 6:03 ` Wang YanQing
2013-07-07 16:45 ` Preeti U Murthy
2013-07-05 16:27 ` [PATCH 2/3] smp/ipi:Clarify ambiguous comments around deadlock scenarios in smp_call_function variants Preeti U Murthy
2013-07-06 6:12 ` Wang YanQing
2013-07-06 7:48 ` Preeti U Murthy
2013-07-06 19:48 ` Thomas Gleixner
2013-07-07 16:29 ` Preeti U Murthy
2013-07-05 16:27 ` [PATCH 3/3] smp/ipi:Remove check around csd lock in handler for " Preeti U Murthy
2013-07-06 5:45 ` Wang YanQing [this message]
2013-07-06 8:06 ` Preeti U Murthy
2013-07-06 14:21 ` Wang YanQing
2013-07-07 16:23 ` Preeti U Murthy
2013-07-07 17:25 ` Wang YanQing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130706054552.GA2929@udknight \
--to=udknight@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=anton@samba.org \
--cc=deepthi@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jens.axboe@oracle.com \
--cc=lig.fnst@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miltonm@bga.com \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=shli@kernel.org \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=xiaoguangrong@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.