public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dave Jones <davej@redhat.com>
Subject: Re: Fix quilt merge error in acpi-cpufreq.c
Date: Thu, 16 Apr 2009 10:57:05 +0930	[thread overview]
Message-ID: <200904161057.07108.rusty@rustcorp.com.au> (raw)
In-Reply-To: <alpine.LFD.2.00.0904150822020.4132@localhost.localdomain>

On Thu, 16 Apr 2009 12:58:45 am Linus Torvalds wrote:
> 
> On Wed, 15 Apr 2009, Rusty Russell wrote:
> > 
> >    The API is screwy.  It excludes the current CPU from the mask,
> > unconditionally.  It's a tlb flush helper masquerading as a general function.
> > 
> > (smp_call_function has the same issue).
> > 
> > Something like this?
> > 
> > Subject: smp_call_function_many: add explicit exclude_self flag
> 
> No. This just makes the API even screwier. It fixes the 
> "smp_processor_id()" thing, but it is 
> 
>  (a) horribly buggy

Sure.  Did it even compile?

>      Those 
> 
> 	if (exclude_self && cpu == this_cpu)
> 		cpu = cpumask_next_and(cpu, mask, cpu_online_mask);
> 
>      things are wrong - we need to do that "jump over our own CPU" thing 
>      regardless of whether 'exclude_self' is set or not, since we're going 
>      to special-case our own CPU anyway.

I don't think so (smp_call_function_single will DTRT if 
cpu == smp_processor_id).  But I didn't test to be sure.

>  (c) Wrong, even if it wasn't (horribly buggy)^2
> 
>      Adding "flags" to an interface doesn't make it better. Quite the 
>      reverse. It makes it worse.

Uglier.  Worse?  It would have prevented Andrew's mistake.

>      It also makes it even MORE different from 
>      all the other smp_call_function's, which just do the 'self' cpu 
>      without any stupid conditionals and flags.

You've said this twice, but unfortunately that doesn't make it true.

smp_call_function() is the original from which this derives, and it has
always skipped the current cpu.  Hence on_each_cpu().

I'd love to see a fix which isn't ugly and doesn't put a cpumask on the
stack.

> > Impact: clarify and extend confusing API
> 
> And what the hell is up with these bogus "Impact:" things? Who started 
> doing that, and why?

Ingo wants them.  Example:

	lguest: don't expect linear addresses in gdt pvops

	Impact: fix guest crash 'lguest: bad read address 0x4800000 len 256'

What's more important in the subject line?  That it fixes a crash, or what it
does?

Thanks,
Rusty.

  parent reply	other threads:[~2009-04-16  1:27 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200904140159.n3E1x1K1014705@hera.kernel.org>
2009-04-14  2:05 ` Fix quilt merge error in acpi-cpufreq.c Ingo Molnar
2009-04-15  5:44   ` Ingo Molnar
2009-04-15 10:44     ` Rusty Russell
2009-04-15 15:28       ` Linus Torvalds
2009-04-15 16:26         ` Ingo Molnar
2009-04-15 16:46           ` H. Peter Anvin
2009-04-15 17:00             ` H. Peter Anvin
2009-04-15 17:19           ` Linus Torvalds
2009-04-15 18:47             ` H. Peter Anvin
2009-04-15 19:43               ` Linus Torvalds
2009-04-15 20:07                 ` Ingo Molnar
2009-04-15 20:32                 ` Andrew Morton
2009-04-15 21:03                   ` Ingo Molnar
2009-04-15 21:15                     ` Linus Torvalds
2009-04-15 22:40                       ` Ingo Molnar
2009-04-15 23:08                         ` Linus Torvalds
2009-04-16  0:08                           ` Ingo Molnar
2009-04-16  0:23                             ` Linus Torvalds
2009-04-16  0:38                               ` Linus Torvalds
2009-04-16  0:50                                 ` Ingo Molnar
2009-04-16  4:33                                   ` H. Peter Anvin
2009-04-16  7:14                                     ` Ingo Molnar
2009-04-16 15:24                                   ` Valdis.Kletnieks
2009-04-15 23:49                       ` David Miller
2009-04-16 11:00                         ` Christoph Hellwig
2009-04-15 21:17                     ` Andrew Morton
2009-04-15 23:04                       ` Ingo Molnar
2009-04-15 21:23                 ` David Miller
2009-04-15 22:48                   ` Ingo Molnar
2009-04-15 23:11                     ` Linus Torvalds
2009-04-16  0:44                       ` Ingo Molnar
2009-04-16  1:03                         ` Linus Torvalds
2009-04-16  1:46                           ` Ingo Molnar
2009-04-16  2:22                             ` Linus Torvalds
2009-04-16  7:23                               ` Ingo Molnar
2009-04-16  3:55                             ` Theodore Tso
2009-04-16  7:44                               ` Ingo Molnar
2009-04-16 15:41                             ` Valdis.Kletnieks
2009-04-16 13:04                   ` Valdis.Kletnieks
2009-04-16  2:00               ` Rusty Russell
2009-04-16  2:22                 ` Paul Gortmaker
2009-04-16  2:34                 ` Linus Torvalds
2009-04-16  3:10                 ` Ray Lee
2009-04-16  7:56                 ` Ingo Molnar
2009-04-16 11:57                   ` Theodore Tso
2009-04-16 13:55                 ` Jonathan Corbet
2009-04-20  8:14                   ` Rusty Russell
2009-04-20 10:38                     ` Ingo Molnar
2009-04-22  4:18                       ` Rusty Russell
2009-04-21 19:37                     ` Jonathan Corbet
2009-04-22  1:58                       ` Rusty Russell
2009-04-16  1:27         ` Rusty Russell [this message]
2009-04-16  2:31           ` Theodore Tso
2009-04-16  8:02             ` Ingo Molnar
2009-04-15 15:05     ` Linus Torvalds
2009-04-15 15:22       ` Ali Gholami Rudi
2009-04-15 16:41       ` Ingo Molnar
     [not found] <crh66-6nQ-7@gated-at.bofh.it>
     [not found] ` <crilu-8hM-13@gated-at.bofh.it>
     [not found]   ` <crjhu-1lb-13@gated-at.bofh.it>
     [not found]     ` <crkQl-3QL-7@gated-at.bofh.it>
     [not found]       ` <crm5K-5NR-17@gated-at.bofh.it>
     [not found]         ` <crmyK-6DP-9@gated-at.bofh.it>
     [not found]           ` <crnXV-g5-27@gated-at.bofh.it>
     [not found]             ` <croh9-VK-5@gated-at.bofh.it>
     [not found]               ` <croTQ-1Jm-1@gated-at.bofh.it>
     [not found]                 ` <crqVM-4UC-11@gated-at.bofh.it>
2009-04-16  5:46                   ` Niel Lambrechts

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=200904161057.07108.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox