All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	Nick Piggin <npiggin@kernel.dk>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andi Kleen <ak@linux.intel.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] cpumask: fix lg_lock/br_lock.
Date: Tue, 28 Feb 2012 09:43:59 +0100	[thread overview]
Message-ID: <20120228084359.GJ21106@elte.hu> (raw)
In-Reply-To: <20120227155338.7b5110cd.akpm@linux-foundation.org>


* Andrew Morton <akpm@linux-foundation.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
> Subject: brlocks/lglocks: cleanups

This patch, while I agree with the goal of de-CPP-ing the 
lglocks code, violates my sense of taste and logic in numerous 
ways. If we touch this code it should be done right.

This patch should also probably go upstream through the 
locking/lockdep tree? Mind sending it us once you think it's 
ready?

> 
>  fs/dcache.c            |    4 
>  fs/file_table.c        |   17 +--
>  fs/internal.h          |    3 
>  fs/namei.c             |   24 ++--
>  fs/namespace.c         |  140 ++++++++++++++--------------
>  fs/pnode.c             |    4 
>  fs/proc_namespace.c    |    4 
>  include/linux/lglock.h |  189 +++++++--------------------------------
>  kernel/Makefile        |    2 
>  kernel/lglock.c        |  136 ++++++++++++++++++++++++++++
>  10 files changed, 269 insertions(+), 254 deletions(-)

It's absolutely crazy to do such a large patch that both 
uninlines the code and changes the API.

There is absolutely no good reason to do it like that - and the 
resulting merge pain on Andrew is a direct result of that: had 
it been kept separate it would be much easier and safer to 
update just the API change patch ...

Do those things in at least two patches, making the bigger API 
change patch plain and *OBVIOUS*.

> +struct lglock {
> +	arch_spinlock_t __percpu *lock;
> +	cpumask_t cpus;	/* XXX need to put on separate cacheline? */
> +	spinlock_t cpu_lock;
> +	struct notifier_block cpu_notifier;
> +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> +	struct lock_class_key lock_key;
> +	struct lockdep_map    lock_dep_map;
> +#endif
> +};

This is not a readable structure definition. Plenty of readable 
ones exist in the tree, they should be inspected for clues.

> +/* Only valid for statics */

what does this comment mean?

> +void lg_lock_init(struct lglock *lg, char *name);
> +void lg_local_lock(struct lglock *lg);
> +void lg_local_unlock(struct lglock *lg);
> +void lg_local_lock_cpu(struct lglock *lg, int cpu);
> +void lg_local_unlock_cpu(struct lglock *lg, int cpu);
> +void lg_global_lock_online(struct lglock *lg);
> +void lg_global_unlock_online(struct lglock *lg);
> +void lg_global_lock(struct lglock *lg);
> +void lg_global_unlock(struct lglock *lg);
> +
> +int lg_cpu_callback(struct notifier_block *nb, unsigned long action, void *hcpu);

These APIs lack documentation.

> +/* Note there is no uninit, so lglocks cannot be defined in
> + * modules (but it's fine to use them from there)
> + * Could be added though, just undo lg_lock_init
> + */

I'm sure Andi knows what the standard shape of multi-line 
comments is in the kernel? Why has he still not learned?

> +void lg_local_lock(struct lglock *lg)
> +{
> +	arch_spinlock_t *lock;
> +	preempt_disable();

I'm sure Andi knows what's wrong here, he has been reviewed 
dozens of times for similar mistakes in the x86 trees.

> +void lg_local_unlock(struct lglock *lg)
> +{
> +	arch_spinlock_t *lock;
> +	rwlock_release(&lg->lock_dep_map, 1, _RET_IP_);

ditto.

> +void lg_local_lock_cpu(struct lglock *lg, int cpu)
> +{
> +	arch_spinlock_t *lock;
> +	preempt_disable();

ditto.

> +	arch_spinlock_t *lock;
> +	rwlock_release(&lg->lock_dep_map, 1, _RET_IP_);

ditto.

> +{
> +	int i;
> +	spin_lock(&lg->cpu_lock);

ditto.

> +{
> +	int i;
> +	rwlock_release(&lg->lock_dep_map, 1, _RET_IP_);

ditto.

> +{
> +	int i;
> +	preempt_disable();

ditto.

> +{
> +	int i;
> +	rwlock_release(&lg->lock_dep_map, 1, _RET_IP_);

ditto.

> +int lg_cpu_callback(struct notifier_block *nb,
> +                              unsigned long action, void *hcpu)

ugly linebreak, we can do better.


> +{
> +	struct lglock *lglock = container_of(nb, struct lglock, cpu_notifier);
> +	switch (action & ~CPU_TASKS_FROZEN) {

sigh.

Until these defects (and probably more, haven't done a full 
check) are fixed:

Nacked-by: Ingo Molnar <mingo@elte.hu>

Thanks,

	Ingo

  reply	other threads:[~2012-02-28  8:44 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-27 23:22 [PATCH] cpumask: fix lg_lock/br_lock Rusty Russell
2012-02-27 23:53 ` Andrew Morton
2012-02-27 23:53   ` Andrew Morton
2012-02-28  8:43   ` Ingo Molnar [this message]
2012-02-28 11:25     ` Andi Kleen
2012-02-28 12:51       ` Ingo Molnar
2012-02-28 21:27     ` Andrew Morton
2012-02-29  5:44       ` Srivatsa S. Bhat
2012-02-29  9:17         ` Ingo Molnar
2012-02-29 11:12           ` Srivatsa S. Bhat
2012-03-01  7:38             ` Ingo Molnar
2012-03-01  9:15               ` Srivatsa S. Bhat
2012-03-01  9:45                 ` Ingo Molnar
2012-03-01  9:56                   ` Srivatsa S. Bhat
2012-03-01  8:12             ` Srivatsa S. Bhat
2012-03-01  8:24               ` Srivatsa S. Bhat
2012-03-01  8:12               ` Srivatsa S. Bhat
2012-03-01  8:15               ` [PATCH 1/3] CPU hotplug: Fix issues with callback registration Srivatsa S. Bhat
2012-03-01  8:27                 ` Srivatsa S. Bhat
2012-03-01  8:15                 ` Srivatsa S. Bhat
2012-03-01  8:16               ` [PATCH 2/3] CPU hotplug, arch/powerpc: Fix CPU hotplug " Srivatsa S. Bhat
2012-03-01  8:28                 ` Srivatsa S. Bhat
2012-03-01  8:16                 ` Srivatsa S. Bhat
2012-03-01  8:18               ` [PATCH 3/3] CPU hotplug, arch/sparc: " Srivatsa S. Bhat
2012-03-01  8:30                 ` Srivatsa S. Bhat
2012-03-01  8:18                 ` Srivatsa S. Bhat
2012-02-29  8:29       ` [PATCH] cpumask: fix lg_lock/br_lock Ingo Molnar
2012-02-29  8:58         ` Peter Zijlstra
2012-02-29  9:32           ` Ingo Molnar
2012-02-28 11:24   ` Andi Kleen
2012-03-05  7:02     ` Rusty Russell
2012-03-05  7:03     ` [PATCH 1/3] lglock: remove online variants of lock Rusty Russell
2012-04-20 11:12       ` Nick Piggin
2012-03-05  7:04     ` [PATCH 2/3] brlocks/lglocks: API cleanups Rusty Russell
2012-03-05  7:05     ` [PATCH 3/3] brlocks/lglocks: turn into functions Rusty Russell
2012-04-20 11:21       ` Nick Piggin
2012-05-07  3:39         ` Rusty Russell
2012-05-07  5:46           ` Al Viro
2012-05-08  3:59             ` [PATCH 1/3] lglock: remove online variants of lock Rusty Russell
2012-05-08  4:50               ` Al Viro
2012-05-08  6:12                 ` Rusty Russell
2012-05-08  4:02             ` [PATCH 2/3] brlocks/lglocks: API cleanups Rusty Russell
2012-05-08  4:02             ` [PATCH 3/3] brlocks/lglocks: turn into functions Rusty Russell
2012-05-09  7:35           ` Nick Piggin
2012-05-09  7:35             ` Nick Piggin

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=20120228084359.GJ21106@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@kernel.dk \
    --cc=rusty@rustcorp.com.au \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.