All of lore.kernel.org
 help / color / mirror / Atom feed
* [PULL] cpumask offstack finalization
@ 2011-02-09  5:38 Rusty Russell
  2011-02-10 12:44 ` Ingo Molnar
  0 siblings, 1 reply; 11+ messages in thread
From: Rusty Russell @ 2011-02-09  5:38 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, anton, Mike Travis

Hi Ingo,

   A few more obsolete uses of cpumask has crept into the tree; all easily
fixed.  This is rebased onto your -tip tree and re-tested; it finally means
that we can detect obsolescent (and hence dangerous) cpumask usage when 
CONFIG_CPUMASK_OFFSTACK=y.  It finally reduces the actual allocation of
cpumask_var_t to the number of cpus we actually have.

I assume you want these via your tree: they definitely need testing across
architectures, though the transforms are mechanical.

Thanks!
Rusty.

The following changes since commit 25ca954821a28c2648feeb166bcea0488ee0c202:

  Merge branch 'core/urgent' (2011-02-08 16:18:50 +0100)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-x86.git cpumask

Rusty Russell (9):
      cpumask: remove obsolete cpu operation in x86/kernel/apb_timer.c
      cpumask: update obsolescent use of cpumask_t in include/linux/interrupt.h
      cpumask: update obsolescent use of cpu_isset in net/core/net-sysfs.c
      cpumask: update obsolescent use of cpumask_t in drivers/crypto/n2_core.c
      cpumask: truncate mm_struct.cpu_vm_mask for CONFIG_CPUMASK_OFFSTACK
      cpumask: make task_struct.cpus_allowed a cpumask_var_t
      cpumask: select disabling obsolete cpumask functions on x86
      cpumask: remove struct cpumask definition when CONFIG_CPUMASK_OFFSTACK=y
      cpumask: reduce cpumask_size

 arch/arm/mach-integrator/cpu.c               |    4 ++--
 arch/blackfin/kernel/process.c               |    3 ++-
 arch/ia64/kernel/cpufreq/acpi-cpufreq.c      |    4 ++--
 arch/ia64/kernel/mca.c                       |    2 +-
 arch/ia64/kernel/salinfo.c                   |    2 +-
 arch/ia64/kernel/topology.c                  |    2 +-
 arch/ia64/sn/kernel/sn2/sn_hwperf.c          |    2 +-
 arch/mips/include/asm/system.h               |    3 ++-
 arch/mips/kernel/cpufreq/loongson2_cpufreq.c |    2 +-
 arch/mips/kernel/traps.c                     |    8 ++++----
 arch/powerpc/kernel/smp.c                    |    2 +-
 arch/powerpc/platforms/cell/spufs/sched.c    |    2 +-
 arch/sh/kernel/cpufreq.c                     |    2 +-
 arch/sparc/kernel/sysfs.c                    |    2 +-
 arch/sparc/kernel/us2e_cpufreq.c             |    4 ++--
 arch/sparc/kernel/us3_cpufreq.c              |    4 ++--
 arch/x86/kernel/apb_timer.c                  |    2 +-
 arch/x86/kernel/cpu/mcheck/mce_intel.c       |    2 +-
 arch/x86/kernel/tboot.c                      |    2 +-
 drivers/acpi/processor_throttling.c          |    4 ++--
 drivers/crypto/n2_core.c                     |    6 +++---
 drivers/firmware/dcdbas.c                    |    2 +-
 drivers/infiniband/hw/ipath/ipath_file_ops.c |    6 +++---
 drivers/infiniband/hw/qib/qib_file_ops.c     |    6 +++---
 fs/proc/array.c                              |    4 ++--
 include/linux/cpumask.h                      |   25 +++++++++++++++++++------
 include/linux/cpuset.h                       |    2 +-
 include/linux/init_task.h                    |    9 ++++++++-
 include/linux/interrupt.h                    |    3 ++-
 include/linux/mm_types.h                     |   21 ++++++++++++++++++---
 include/linux/sched.h                        |    6 +++---
 kernel/cpuset.c                              |    8 ++++----
 kernel/fork.c                                |   23 +++++++++++++++++++----
 kernel/kthread.c                             |    2 +-
 kernel/sched.c                               |   18 +++++++++---------
 kernel/sched_cpupri.c                        |    4 ++--
 kernel/sched_fair.c                          |   12 ++++++------
 kernel/sched_rt.c                            |    6 +++---
 kernel/trace/trace_workqueue.c               |    6 +++---
 kernel/workqueue.c                           |    2 +-
 lib/Kconfig                                  |    8 ++++++--
 lib/cpumask.c                                |    2 ++
 lib/smp_processor_id.c                       |    2 +-
 mm/init-mm.c                                 |    2 +-
 net/core/net-sysfs.c                         |    2 +-
 45 files changed, 152 insertions(+), 93 deletions(-)

commit 248c3f52bec0473e5cc1be1c0888dc1a071e8019
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 11:59:52 2011 +1030

    cpumask: remove obsolete cpu operation in x86/kernel/apb_timer.c
    
    first_cpu -> cpumask_first
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

 arch/x86/kernel/apb_timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit 0574017fe487e189512a4a295671f3f2ec492443
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 15:49:05 2011 +1030

    cpumask: update obsolescent use of cpumask_t in include/linux/interrupt.h
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

 include/linux/interrupt.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

commit d1314fe9407523fc4f0a943612e7c1bb50c2fb8d
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 15:49:35 2011 +1030

    cpumask: update obsolescent use of cpu_isset in net/core/net-sysfs.c
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

 net/core/net-sysfs.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

commit a35b7541e121159caabe962bbe6f01488cef5485
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 15:50:40 2011 +1030

    cpumask: update obsolescent use of cpumask_t in drivers/crypto/n2_core.c
    
    These days we use struct cpumask, and cpumask_* instead of the obsolescent
    cpu_*/cpus_* functions.
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

 drivers/crypto/n2_core.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

commit baece92fc28acf8e2e44dc6e942c656df12150c9
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 11:59:51 2011 +1030

    cpumask: truncate mm_struct.cpu_vm_mask for CONFIG_CPUMASK_OFFSTACK
    
    Turns cpu_vm_mask into a bitmap, and truncate it to cpumask_size(): if
    CONFIG_CPUMASK_OFFSTACK is set, this will reflect nr_cpu_ids not NR_CPUS.
    
    I do this rather than the classic [0] dangling array trick, because of
    init_mm, which is static and widely referenced.
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: anton@samba.org
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Mike Travis <travis@sgi.com>

 arch/x86/kernel/tboot.c  |    2 +-
 include/linux/mm_types.h |   21 ++++++++++++++++++---
 kernel/fork.c            |    6 +++---
 mm/init-mm.c             |    2 +-
 4 files changed, 23 insertions(+), 8 deletions(-)

commit ae0849f28dba2ca41ca8d6631f5dcf9a81875eea
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 13:32:37 2011 +1030

    cpumask: make task_struct.cpus_allowed a cpumask_var_t
    
    This turns it into a pointer for everyone.  Rather than churn everyone
    via the tsk_cpus_allowed() wrapper, we change them directly.  If there
    are any users in the meantime they can use the wrapper.
    
    For CONFIG_CPUMASK_OFFSTACK=y, we now allocate it off the end; it
    would be better to avoid the indirection and use a dangling bitmap,
    but I didn't want to alter the layout of task_struct and risk breaking
    carefully balanced caches.
    
    Even better would be to point to the fixed "one cpu" and "all cpus"
    masks where possible, and make a copy when setting it to something
    else.  But you'd have to track down those naughty places which frob it
    directly...
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: anton@samba.org
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Mike Travis <travis@sgi.com>

 arch/arm/mach-integrator/cpu.c               |    4 ++--
 arch/blackfin/kernel/process.c               |    3 ++-
 arch/ia64/kernel/cpufreq/acpi-cpufreq.c      |    4 ++--
 arch/ia64/kernel/mca.c                       |    2 +-
 arch/ia64/kernel/salinfo.c                   |    2 +-
 arch/ia64/kernel/topology.c                  |    2 +-
 arch/ia64/sn/kernel/sn2/sn_hwperf.c          |    2 +-
 arch/mips/include/asm/system.h               |    3 ++-
 arch/mips/kernel/cpufreq/loongson2_cpufreq.c |    2 +-
 arch/mips/kernel/traps.c                     |    8 ++++----
 arch/powerpc/kernel/smp.c                    |    2 +-
 arch/powerpc/platforms/cell/spufs/sched.c    |    2 +-
 arch/sh/kernel/cpufreq.c                     |    2 +-
 arch/sparc/kernel/sysfs.c                    |    2 +-
 arch/sparc/kernel/us2e_cpufreq.c             |    4 ++--
 arch/sparc/kernel/us3_cpufreq.c              |    4 ++--
 arch/x86/kernel/cpu/mcheck/mce_intel.c       |    2 +-
 drivers/acpi/processor_throttling.c          |    4 ++--
 drivers/firmware/dcdbas.c                    |    2 +-
 drivers/infiniband/hw/ipath/ipath_file_ops.c |    6 +++---
 drivers/infiniband/hw/qib/qib_file_ops.c     |    6 +++---
 fs/proc/array.c                              |    4 ++--
 include/linux/cpuset.h                       |    2 +-
 include/linux/init_task.h                    |    9 ++++++++-
 include/linux/sched.h                        |    4 ++--
 kernel/cpuset.c                              |    8 ++++----
 kernel/fork.c                                |   17 ++++++++++++++++-
 kernel/kthread.c                             |    2 +-
 kernel/sched.c                               |   18 +++++++++---------
 kernel/sched_cpupri.c                        |    4 ++--
 kernel/sched_fair.c                          |   12 ++++++------
 kernel/sched_rt.c                            |    6 +++---
 kernel/trace/trace_workqueue.c               |    6 +++---
 kernel/workqueue.c                           |    2 +-
 lib/smp_processor_id.c                       |    2 +-
 35 files changed, 94 insertions(+), 70 deletions(-)

commit 1602bf3ac37e66f5ad7022de4dcde317db964e32
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 11:59:49 2011 +1030

    cpumask: select disabling obsolete cpumask functions on x86
    
    It currently depends on CONFIG_BROKEN; change to be set by
    CONFIG_CPUMASK_OFFSTACK now it all compiles.
    
    We also complete it: the header shouldn't refer to the deprected
    CPU_MASK_LAST_WORD, and the deprecated implementations are removed.
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: anton@samba.org
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Mike Travis <travis@sgi.com>

 include/linux/cpumask.h |    4 ++--
 include/linux/sched.h   |    2 +-
 lib/Kconfig             |    8 ++++++--
 lib/cpumask.c           |    2 ++
 4 files changed, 11 insertions(+), 5 deletions(-)

commit d2594c0ef22017f2fbf6eacd21aa74590982e36f
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 11:59:49 2011 +1030

    cpumask: remove struct cpumask definition when CONFIG_CPUMASK_OFFSTACK=y
    
    We're about to change CONFIG_CPUMASK_OFFSTACK so it only allocate
    nr_cpu_ids bits for all cpumasks.  We need to make sure that when
    CONFIG_CPUMASK_OFFSTACK is set:
    
    1) Noone uses the old bitmap ops, which use NR_CPUS bits (use cpumask_*)
    2) Noone uses assignment of struct cpumask (use cpumask_copy)
    3) Noone passes a struct cpumask (pass a pointer)
    4) Noone declares them on the stack (use cpumask_var_t)
    
    So we finally remove the definition of struct cpumask when
    CONFIG_CPUMASK_OFFSTACK=y.  This means that these usages will hit a compile
    error the moment that config option is turned on.
    
    Note that it also means you can't declare a static cpumask.  You
    should avoid this anyway (use cpumask_var_t), but there's a
    deliberately-ugly workaround for special cases, using DECLARE_BITMAP()
    and to_cpumask().
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: anton@samba.org
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Mike Travis <travis@sgi.com>

 include/linux/cpumask.h |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

commit 5a9c141a738da5bf0cdbab099ed62155fd47fb67
Author: Rusty Russell <rusty@rustcorp.com.au>
Date:   Wed Feb 9 11:59:48 2011 +1030

    cpumask: reduce cpumask_size
    
    Now we're sure noone is using old cpumask operators, nor *cpumask, we can
    allocate less bits safely.  This reduces the memory usage of off-stack
    cpumasks when CONFIG_CPUMASK_OFFSTACK=y but we don't have NR_CPUS actual
    cpus.
    
    Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: anton@samba.org
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Mike Travis <travis@sgi.com>

 include/linux/cpumask.h |    6 ++----
 1 files changed, 2 insertions(+), 4 deletions(-)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-09  5:38 [PULL] cpumask offstack finalization Rusty Russell
@ 2011-02-10 12:44 ` Ingo Molnar
  2011-02-10 19:29   ` Linus Torvalds
  2011-02-10 21:32   ` Rusty Russell
  0 siblings, 2 replies; 11+ messages in thread
From: Ingo Molnar @ 2011-02-10 12:44 UTC (permalink / raw)
  To: Rusty Russell
  Cc: linux-kernel, anton, Mike Travis, Linus Torvalds, Andrew Morton,
	Thomas Gleixner, Peter Zijlstra


* Rusty Russell <rusty@rustcorp.com.au> wrote:

> Hi Ingo,
> 
>    A few more obsolete uses of cpumask has crept into the tree; all easily
> fixed.  This is rebased onto your -tip tree and re-tested; it finally means
> that we can detect obsolescent (and hence dangerous) cpumask usage when 
> CONFIG_CPUMASK_OFFSTACK=y.  It finally reduces the actual allocation of
> cpumask_var_t to the number of cpus we actually have.

Hm, could we get rid of the obsolete percpu APIs once and for all? The fact that 
they are still around cause the leakage into new code to begin with.

> I assume you want these via your tree: they definitely need testing across 
> architectures, though the transforms are mechanical.

Can do i guess - we can cross-test most architectures in -tip and via -next there 
will be more testing. No need to spread this out via a zillion maintainer trees i 
think.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 12:44 ` Ingo Molnar
@ 2011-02-10 19:29   ` Linus Torvalds
  2011-02-10 21:18     ` Ingo Molnar
  2011-02-10 21:32   ` Rusty Russell
  1 sibling, 1 reply; 11+ messages in thread
From: Linus Torvalds @ 2011-02-10 19:29 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Rusty Russell, linux-kernel, anton, Mike Travis, Andrew Morton,
	Thomas Gleixner, Peter Zijlstra

On Thu, Feb 10, 2011 at 4:44 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> Hm, could we get rid of the obsolete percpu APIs once and for all? The fact that
> they are still around cause the leakage into new code to begin with.

Yes please.

And please don't expect it to be merged until the 39 merge window
unless this also fixes some serious bugs (I assume - without having
looked at the patch - that none of these are actually on-stack and
relevant for any thousand+ cpu machines?)

                      Linus

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 19:29   ` Linus Torvalds
@ 2011-02-10 21:18     ` Ingo Molnar
  0 siblings, 0 replies; 11+ messages in thread
From: Ingo Molnar @ 2011-02-10 21:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rusty Russell, linux-kernel, anton, Mike Travis, Andrew Morton,
	Thomas Gleixner, Peter Zijlstra


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Feb 10, 2011 at 4:44 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > Hm, could we get rid of the obsolete percpu APIs once and for all? The fact that 
> > they are still around cause the leakage into new code to begin with.
> 
> Yes please.
> 
> And please don't expect it to be merged until the 39 merge window unless this also 
> fixes some serious bugs (I assume - without having looked at the patch - that none 
> of these are actually on-stack and relevant for any thousand+ cpu machines?)

Yeah, i considered it strictly .39 material.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 12:44 ` Ingo Molnar
  2011-02-10 19:29   ` Linus Torvalds
@ 2011-02-10 21:32   ` Rusty Russell
  2011-02-10 22:13     ` Thomas Gleixner
  1 sibling, 1 reply; 11+ messages in thread
From: Rusty Russell @ 2011-02-10 21:32 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, anton, Mike Travis, Linus Torvalds, Andrew Morton,
	Thomas Gleixner, Peter Zijlstra

On Thu, 10 Feb 2011 11:14:16 pm Ingo Molnar wrote:
> 
> * Rusty Russell <rusty@rustcorp.com.au> wrote:
> 
> > Hi Ingo,
> > 
> >    A few more obsolete uses of cpumask has crept into the tree; all easily
> > fixed.  This is rebased onto your -tip tree and re-tested; it finally means
> > that we can detect obsolescent (and hence dangerous) cpumask usage when 
> > CONFIG_CPUMASK_OFFSTACK=y.  It finally reduces the actual allocation of
> > cpumask_var_t to the number of cpus we actually have.
> 
> Hm, could we get rid of the obsolete percpu APIs once and for all? The fact that 
> they are still around cause the leakage into new code to begin with.

Yes; it'll be a fair bit of arch churn, but it can be done in stages easily.
I thought about marking them all __deprecated but that just annoys people.

And yes, this is definitely .39+.

Thanks,
Rusty.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 21:32   ` Rusty Russell
@ 2011-02-10 22:13     ` Thomas Gleixner
  2011-02-10 23:51       ` Linus Torvalds
  0 siblings, 1 reply; 11+ messages in thread
From: Thomas Gleixner @ 2011-02-10 22:13 UTC (permalink / raw)
  To: Rusty Russell
  Cc: Ingo Molnar, linux-kernel, anton, Mike Travis, Linus Torvalds,
	Andrew Morton, Peter Zijlstra

On Fri, 11 Feb 2011, Rusty Russell wrote:

> On Thu, 10 Feb 2011 11:14:16 pm Ingo Molnar wrote:
> > 
> > * Rusty Russell <rusty@rustcorp.com.au> wrote:
> > 
> > > Hi Ingo,
> > > 
> > >    A few more obsolete uses of cpumask has crept into the tree; all easily
> > > fixed.  This is rebased onto your -tip tree and re-tested; it finally means
> > > that we can detect obsolescent (and hence dangerous) cpumask usage when 
> > > CONFIG_CPUMASK_OFFSTACK=y.  It finally reduces the actual allocation of
> > > cpumask_var_t to the number of cpus we actually have.
> > 
> > Hm, could we get rid of the obsolete percpu APIs once and for all? The fact that 
> > they are still around cause the leakage into new code to begin with.
> 
> Yes; it'll be a fair bit of arch churn, but it can be done in stages easily.
> I thought about marking them all __deprecated but that just annoys people.

Wrong. __deprecated is not annoying enough. See __do_IRQ().  The
__deprecated warning was ignored for years. It might work if it pops
up in every file compiled :)

Thanks,

	tglx


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 22:13     ` Thomas Gleixner
@ 2011-02-10 23:51       ` Linus Torvalds
  2011-02-10 23:59         ` Ingo Molnar
  2011-02-11 13:44         ` Alexey Dobriyan
  0 siblings, 2 replies; 11+ messages in thread
From: Linus Torvalds @ 2011-02-10 23:51 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Rusty Russell, Ingo Molnar, linux-kernel, anton, Mike Travis,
	Andrew Morton, Peter Zijlstra

On Thu, Feb 10, 2011 at 2:13 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Wrong. __deprecated is not annoying enough.

Wrong.

The problem with __deprecated is that it is a F*CKING STUPID thing to
have, and I've wanted to remove it so many times.

It's annoying as hell, but it's annoying to the wrong people. It
doesn't annoy the people who need to fix things up (they may have one
or two cases they care about), it annoys everybody ELSE (who sees all
the cases that it warns about, whether they are able to do something
about it or not).

THAT is the fundamental problem with __deprecated. It's annoying, but
the annoyance is spread out entirely incorrectly. Even to people for
whom one of the warnings might be relevant, it's pointless, because
all the non-relevant cases it triggers.

So never _ever_ mark anything "deprecated". If you want to get rid of
something, get rid of it and fix the callers. Don't say "somebody else
should get rid of it, because it's deprecated".

And yes, next time this discussion comes up, I _will_ remove that
piece-of-sh*t. It's a disease. It's just a stupid way to say "somebody
else should deal with this problem". It's a way to make excuses. It's
crap. It was a mistake to ever take any of that to begin with.

                               Linus

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 23:51       ` Linus Torvalds
@ 2011-02-10 23:59         ` Ingo Molnar
  2011-02-11 13:41           ` Alexey Dobriyan
  2011-02-11 13:44         ` Alexey Dobriyan
  1 sibling, 1 reply; 11+ messages in thread
From: Ingo Molnar @ 2011-02-10 23:59 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Rusty Russell, linux-kernel, anton, Mike Travis,
	Andrew Morton, Peter Zijlstra


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> And yes, next time this discussion comes up, I _will_ remove that piece-of-sh*t. 

Hey, if that's what it takes to get __deprecated removed i'll bring it up tomorrow!!
:-)

	Ingo

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 23:59         ` Ingo Molnar
@ 2011-02-11 13:41           ` Alexey Dobriyan
  2011-02-11 14:07             ` Ingo Molnar
  0 siblings, 1 reply; 11+ messages in thread
From: Alexey Dobriyan @ 2011-02-11 13:41 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel

On Fri, Feb 11, 2011 at 1:59 AM, Ingo Molnar <mingo@elte.hu> wrote:
> Hey, if that's what it takes to get __deprecated removed i'll bring it up tomorrow!!
> :-)

But first, deprecate it!

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-10 23:51       ` Linus Torvalds
  2011-02-10 23:59         ` Ingo Molnar
@ 2011-02-11 13:44         ` Alexey Dobriyan
  1 sibling, 0 replies; 11+ messages in thread
From: Alexey Dobriyan @ 2011-02-11 13:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Thomas Gleixner, Rusty Russell, Ingo Molnar, linux-kernel, anton,
	Mike Travis, Andrew Morton, Peter Zijlstra

On Fri, Feb 11, 2011 at 1:51 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So never _ever_ mark anything "deprecated". If you want to get rid of
> something, get rid of it and fix the callers.

Does this apply to drivers/staging/ ?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PULL] cpumask offstack finalization
  2011-02-11 13:41           ` Alexey Dobriyan
@ 2011-02-11 14:07             ` Ingo Molnar
  0 siblings, 0 replies; 11+ messages in thread
From: Ingo Molnar @ 2011-02-11 14:07 UTC (permalink / raw)
  To: Alexey Dobriyan; +Cc: linux-kernel, Thomas Gleixner


* Alexey Dobriyan <adobriyan@gmail.com> wrote:

> On Fri, Feb 11, 2011 at 1:59 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > Hey, if that's what it takes to get __deprecated removed i'll bring it up tomorrow!!
> > :-)
> 
> But first, deprecate it!

No need, it's already marked __deprecated ;-)

	Ingo

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2011-02-11 14:07 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-09  5:38 [PULL] cpumask offstack finalization Rusty Russell
2011-02-10 12:44 ` Ingo Molnar
2011-02-10 19:29   ` Linus Torvalds
2011-02-10 21:18     ` Ingo Molnar
2011-02-10 21:32   ` Rusty Russell
2011-02-10 22:13     ` Thomas Gleixner
2011-02-10 23:51       ` Linus Torvalds
2011-02-10 23:59         ` Ingo Molnar
2011-02-11 13:41           ` Alexey Dobriyan
2011-02-11 14:07             ` Ingo Molnar
2011-02-11 13:44         ` Alexey Dobriyan

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.