all_cpu_cache_info can be __cpuinitdata because
only referenced from __cpuinit code.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/ia64/kernel/palinfo.c |8
arch/ia64/kernel/salinfo.c |4 ++--
arch/ia64/kernel/topology.c | 12 ++--
3 files changed, 12 insertions(
msr_class_cpu_callback() can be marked __cpuinit, being the notifier
callback for a __cpuinitdata notifier_block. So can be marked
msr_device_create() too, called only from the newly-__cpuinit
msr_class_cpu_callback() or from __init-marked msr_init().
Signed-off-by: Satyam Sharma <[EM
__cpuinit.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpuid.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpuid.c b/arch/i386/kernel/cpuid.c
index 5c2faa1..a6761fd 100644
--- a/arch/i386/kernel/cpuid.c
+++ b/arc
unconditionally now.)
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_irq.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c
b/drivers/infiniband/hw/ehca/ehca_irq.c
index e
#ifdef-ery elsewhere in kernel code, as
shown in forthcoming patch. Also do the same for unregister_xxx case.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
include/linux/cpu.h |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpu.h b/inc
, as shown in forthcoming patch.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
include/linux/cpu.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 1d5ded0..ed6fa22 100644
--- a/include/linux/cpu.h
+++ b/i
on this list.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/intel_cacheinfo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/intel_cacheinfo.c
b/arch/i386/kernel/cpu/intel_cacheinfo.c
index 16499fe..79e9c4f
.
assocs[], levels[] and types[] are only referenced from function that is
__cpuinit. So these are candidates for being marked __cpuinitdata.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/kernel/cpu/intel_cacheinfo.c | 12 ++--
1 files changed, 6 insertions
On Thu, 23 Aug 2007, Satyam Sharma wrote:
>
> I must say, this is an amazingly cunning idea. Only things I can think of
> against this would be: the dropping of unneeded code is not guaranteed,
> but depends on compiler. And we saw from the "static inline {return 0;}"
&
lback itself as __cpuinit.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
block/ll_rw_blk.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index a15845c..91ec907 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
On Mon, 20 Aug 2007, Andrew Morton wrote:
> On Tue, 21 Aug 2007 10:07:31 +0530 (IST) Satyam Sharma <[EMAIL PROTECTED]>
> wrote:
> >
> > WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch:
> > reference
> > to .init.text: (be
On Mon, 20 Aug 2007, Andrew Morton wrote:
On Tue, 21 Aug 2007 10:07:31 +0530 (IST) Satyam Sharma [EMAIL PROTECTED]
wrote:
WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch:
reference
to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex
, and the callback itself as __cpuinit.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
block/ll_rw_blk.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index a15845c..91ec907 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
On Thu, 23 Aug 2007, Satyam Sharma wrote:
I must say, this is an amazingly cunning idea. Only things I can think of
against this would be: the dropping of unneeded code is not guaranteed,
but depends on compiler. And we saw from the static inline {return 0;}
testcase that gcc can sometimes
.
assocs[], levels[] and types[] are only referenced from function that is
__cpuinit. So these are candidates for being marked __cpuinitdata.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/intel_cacheinfo.c | 12 ++--
1 files changed, 6 insertions(+), 6
on this list.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
arch/i386/kernel/cpu/intel_cacheinfo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/intel_cacheinfo.c
b/arch/i386/kernel/cpu/intel_cacheinfo.c
index 16499fe..79e9c4f 100644
--- a/arch
, as shown in forthcoming patch.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
include/linux/cpu.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 1d5ded0..ed6fa22 100644
--- a/include/linux/cpu.h
+++ b/include/linux
elsewhere in kernel code, as
shown in forthcoming patch. Also do the same for unregister_xxx case.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
include/linux/cpu.h |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index
unconditionally now.)
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_irq.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c
b/drivers/infiniband/hw/ehca/ehca_irq.c
index ee06d8b
__cpuinit.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
arch/i386/kernel/cpuid.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpuid.c b/arch/i386/kernel/cpuid.c
index 5c2faa1..a6761fd 100644
--- a/arch/i386/kernel/cpuid.c
+++ b/arch/i386
msr_class_cpu_callback() can be marked __cpuinit, being the notifier
callback for a __cpuinitdata notifier_block. So can be marked
msr_device_create() too, called only from the newly-__cpuinit
msr_class_cpu_callback() or from __init-marked msr_init().
Signed-off-by: Satyam Sharma [EMAIL
all_cpu_cache_info can be __cpuinitdata because
only referenced from __cpuinit code.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
arch/ia64/kernel/palinfo.c |8
arch/ia64/kernel/salinfo.c |4 ++--
arch/ia64/kernel/topology.c | 12 ++--
3 files changed, 12 insertions(+), 12
that was
registered by appldata_init() during module startup. This will lead
to oops if hotplug notification comes after module has been unloaded.
Let's fix this by unregistering the notifier appropriately (before
appldata_offline_cpu()'ing the CPUs).
Signed-off-by: Satyam Sharma [EMAIL PROTECTED
as __cpuinit also.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
[ I don't have x86_64 toolchain, but it's still obvious enough to me
that the existing code would cause said section mismatch warnings. ]
arch/x86_64/kernel/mce.c |6 +++---
arch/x86_64/kernel/mce_amd.c | 10
On Thu, 23 Aug 2007, Satyam Sharma wrote:
BTW the __exit module_exit function appldata_exit() of this driver
fails to unregister_hotcpu_notifier() the notifier_block that was
registered by appldata_init() during module startup. This will lead
to oops if hotplug notification comes after
The notifier_block is already __cpuinitdata, thereby allowing us to
safely mark the callback function as __cpuinit also, thereby saving
space when HOTPLUG_CPU=n.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/cpufreq/cpufreq.c |2 +-
1 files changed, 1 insertions(+), 1
drivers/video/geode/lxfb_core.c: In function 'lxfb_setup':
drivers/video/geode/lxfb_core.c:564: warning: unused variable 'opt'
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/video/geode/lxfb_core.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers
such #ifdef's from the rest of the kernel tree -- those will
come in a subsequent patch.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
include/linux/cpufreq.h |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index
of this module to being incorrectly printed with /sbin/modinfo :-(
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/cpufreq/cpufreq_stats.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq
barely 10 lines
above this one :-)
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
[ Rudolf, Mark, would it be acceptable to you to remove all the open
#ifdef HOTPLUG_CPU from this file and replace them with __cpuinit{data}
instead? That could increase size of modular builds, but would
Hi Dave,
On Wed, 22 Aug 2007, Dave Hansen wrote:
One of the top ten sysfs problems is that users use statically
allocated kobjects. This patch reminds them that this is a
naughty thing.
Hmm, I might've missed previous discussion regarding this, but I'm
curious to know why using statically
On Wed, 22 Aug 2007, WANG Cong wrote:
Remove unnecessary white spaces, tabs, white lines, wrap lines, parenthesises,
braces, semicolons etc.
:-)
The file clearly had a lot of codingstyle problems, but so does your
patch, sadly.
@@ -134,8 +134,8 @@ MODULE_PARM_DESC(osrun_time, how many s
Hi,
On Tue, 21 Aug 2007, Geoff Levand wrote:
> Rene Herman wrote:
> > On 08/21/2007 10:01 PM, Joe Perches wrote:
> >
> >> On Tue, 2007-08-21 at 12:01 -0700, Geoff Levand wrote:
> >
> >>> Could you verify that cbe-oss-dev is a subscriber's
> >>> only list? I didn't see anything that said it
>
On Tue, 21 Aug 2007, Chris Snook wrote:
> David Miller wrote:
> > From: Linus Torvalds <[EMAIL PROTECTED]>
> > Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
> >
> > > Ie a "barrier()" is likely _cheaper_ than the code generation downside
> > > from using "volatile".
> >
> > Assuming GCC were
On Tue, 21 Aug 2007, Geert Uytterhoeven wrote:
> On Tue, 21 Aug 2007, Satyam Sharma wrote:
> > On Tue, 21 Aug 2007, Geert Uytterhoeven wrote:
> > >
> > > [ and you dropped the cell mailing list from the CC list ]
> >
> > I don't enjoy getting "t
On Tue, 21 Aug 2007, Geert Uytterhoeven wrote:
> On Tue, 21 Aug 2007, Satyam Sharma wrote:
> >
> > This is turning rather funny :-)
> >
> > * Why the printk() conversion specifier must be "%llu"?
> >
> > When reusing parts of this code (s
On Tue, 21 Aug 2007, Geert Uytterhoeven wrote:
On Tue, 21 Aug 2007, Satyam Sharma wrote:
This is turning rather funny :-)
* Why the printk() conversion specifier must be %llu?
When reusing parts of this code (such as this debug message) for another
32-bit driver (we certainly
On Tue, 21 Aug 2007, Geert Uytterhoeven wrote:
On Tue, 21 Aug 2007, Satyam Sharma wrote:
On Tue, 21 Aug 2007, Geert Uytterhoeven wrote:
[ and you dropped the cell mailing list from the CC list ]
I don't enjoy getting this is a subscriber-only list notifications,
thank you
On Tue, 21 Aug 2007, Chris Snook wrote:
David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
Ie a barrier() is likely _cheaper_ than the code generation downside
from using volatile.
Assuming GCC were ever better about the
Hi,
On Tue, 21 Aug 2007, Geoff Levand wrote:
Rene Herman wrote:
On 08/21/2007 10:01 PM, Joe Perches wrote:
On Tue, 2007-08-21 at 12:01 -0700, Geoff Levand wrote:
Could you verify that cbe-oss-dev is a subscriber's
only list? I didn't see anything that said it
specifically in
, let's mark thermal_throttle_cpu_notifier as __cpuinitdata to fix
the section mismatch warning.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
[The other section mismatch mentioned in bugzilla #8679 is already fixed.]
arch/i386/kernel/cpu/mcheck/therm_throt.c |2 +-
1 files chan
Hi Geert,
On Mon, 20 Aug 2007, Geert Uytterhoeven wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
> > On Sat, 18 Aug 2007, Jan Engelhardt wrote:
> > > On Aug 18 2007 20:07, Satyam Sharma wrote:
> > > >On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
> >
Hi Geert,
On Mon, 20 Aug 2007, Geert Uytterhoeven wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
On Sat, 18 Aug 2007, Jan Engelhardt wrote:
On Aug 18 2007 20:07, Satyam Sharma wrote:
On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
On Thu, 16 Aug 2007, NeilBrown wrote
, let's mark thermal_throttle_cpu_notifier as __cpuinitdata to fix
the section mismatch warning.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
[The other section mismatch mentioned in bugzilla #8679 is already fixed.]
arch/i386/kernel/cpu/mcheck/therm_throt.c |2 +-
1 files changed, 1
On Sun, 19 Aug 2007, David Brownell wrote:
> On Sunday 19 August 2007, Anton Altaparmakov wrote:
> > >
> > > ISTR we don't *have* a uintptr_t on all architectures, or that would
> > > be the appropriate thing to use in these 32/64 bit ABI scenarios.
> > >
> > >
> > >> Use unsigned long or
On Sun, 19 Aug 2007, David Brownell wrote:
On Sunday 19 August 2007, Anton Altaparmakov wrote:
ISTR we don't *have* a uintptr_t on all architectures, or that would
be the appropriate thing to use in these 32/64 bit ABI scenarios.
Use unsigned long or uintptr_t instead.
On Sat, 18 Aug 2007, Jan Engelhardt wrote:
> On Aug 18 2007 20:07, Satyam Sharma wrote:
> >On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
> >
> >> On Thu, 16 Aug 2007, NeilBrown wrote:
> >> [...]
> >> > dev_dbg(>sbd.core,
> &g
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > GCC manual, section 6.1, "When
^^
> > > is a Volatile Object Accessed?" doesn't say anything of the
^^^
> > > kind.
^
> > True,
On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
> On Thu, 16 Aug 2007, NeilBrown wrote:
> [...]
> > dev_dbg(>sbd.core,
> > "%s:%u: bio %u: %u segs %u sectors from %lu\n",
> > - __func__, __LINE__, i, bio_segments(bio),
> > -
On Fri, 17 Aug 2007, Jeff Dike wrote:
> Style fixes in hostfs.
> Index: linux-2.6.22/fs/hostfs/hostfs_kern.c
> [...]
> @@ -6,22 +6,15 @@
> * 2003-02-10 Petr Baudis <[EMAIL PROTECTED]>
> */
>
> -#include
> #include
> #include
> -#include
> -#include
> +#include
> #include
>
On Fri, 17 Aug 2007, Linus Torvalds wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
> >
> > No code does (or would do, or should do):
> >
> > x.counter++;
> >
> > on an "atomic_t x;" anyway.
>
> That's just an example
[ LOL, you _are_ shockingly petty! ]
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > The documentation simply doesn't say "+m" is allowed. The code to
> > > allow it was added for the benefit of people who do not read the
> > > documentation. Documentation for "+m" might get added later
[ LOL, you _are_ shockingly petty! ]
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
The documentation simply doesn't say +m is allowed. The code to
allow it was added for the benefit of people who do not read the
documentation. Documentation for +m might get added later if it
is
On Fri, 17 Aug 2007, Linus Torvalds wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
No code does (or would do, or should do):
x.counter++;
on an atomic_t x; anyway.
That's just an example of a general problem.
No, you don't use x.counter++. But you *do* use
On Fri, 17 Aug 2007, Jeff Dike wrote:
Style fixes in hostfs.
Index: linux-2.6.22/fs/hostfs/hostfs_kern.c
[...]
@@ -6,22 +6,15 @@
* 2003-02-10 Petr Baudis [EMAIL PROTECTED]
*/
-#include linux/stddef.h
#include linux/fs.h
#include linux/module.h
-#include linux/init.h
On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
On Thu, 16 Aug 2007, NeilBrown wrote:
[...]
dev_dbg(dev-sbd.core,
%s:%u: bio %u: %u segs %u sectors from %lu\n,
- __func__, __LINE__, i, bio_segments(bio),
-
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
GCC manual, section 6.1, When
^^
is a Volatile Object Accessed? doesn't say anything of the
^^^
kind.
^
True,
On Sat, 18 Aug 2007, Jan Engelhardt wrote:
On Aug 18 2007 20:07, Satyam Sharma wrote:
On Fri, 17 Aug 2007, Geert Uytterhoeven wrote:
On Thu, 16 Aug 2007, NeilBrown wrote:
[...]
dev_dbg(dev-sbd.core,
%s:%u: bio %u: %u segs %u sectors from
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > The "asm volatile" implementation does have exactly the same
> > > > > reordering guarantees as the "volatile cast" thing,
> > > >
> > > > I don't think so.
> > >
> > > "asm volatile" creates a side effect.
> >
> > Yeah.
> >
> > >
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > I didn't quite understand what you said here, so I'll tell what I think:
> >
> > * foo() is a compiler barrier if the definition of foo() is invisible to
> > the compiler at a callsite.
>
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > atomic_dec() writes
> > > > > to memory, so it _does_ have "volatile semantics", implicitly, as
> > > > > long as the compiler cannot optimise the atomic variable away
> > > > > completely -- any store counts as a side effect.
> > > >
>
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Paul E. McKenney wrote:
>
> > On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> > > On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> > > >
> > > > gcc bugzilla bug #33102, for whatever that ends
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
> On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
> > On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > > That was merged over my objections. IMHO ksize(NULL) should fail since we
> > > are determining the size of an unallocated
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > No it does not have any volatile semantics. atomic_dec() can be
> > > > reordered
> > > > at will by the compiler within the current basic unit if you do not add
> > > > a
> > > > barrier.
> > >
> > > "volatile" has nothing to do with
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > #define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
> >
> > [ This is exactly equivalent to using "+m" in the constraints, as recently
> > explained on a GCC list somewhere, in response to the patch in my bitops
> > series a
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
>
> > Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
> > return 0).
>
> That was merged over my objections. IMHO ksize(NULL) should fail since we
&g
On Sat, 18 Aug 2007, Satyam Sharma wrote:
> On Fri, 17 Aug 2007, Christoph Lameter wrote:
>
> > On Fri, 17 Aug 2007, Andrew Morton wrote:
> >
> > > are we seeing a pattern here? We could stick the unlikely inside
> > > ZERO_OR_NULL_PTR() itself
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Andrew Morton wrote:
>
> > are we seeing a pattern here? We could stick the unlikely inside
> > ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
> > be future callsites at which it is likely, who
On Fri, 17 Aug 2007, Andrew Morton wrote:
> On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
> Satyam Sharma <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
> >
> > Considering kfree(NULL) would normally occur
On Fri, 17 Aug 2007, Arjan van de Ven wrote:
>
> On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
> > On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
> > Satyam Sharma <[EMAIL PROTECTED]> wrote:
> >
> > > [PATCH] {slub, slob}: use unlik
On Fri, 17 Aug 2007, Segher Boessenkool wrote:
> > > atomic_dec() already has volatile behavior everywhere, so this is
> > > semantically
> > > okay, but this code (and any like it) should be calling cpu_relax() each
> > > iteration through the loop, unless there's a compelling reason not to.
>
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
> On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
> >
> > On Thu, 16 Aug 2007, Paul E. McKenney wrote:
> >
> > > On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> > > >
>
On Fri, 17 Aug 2007, Satyam Sharma wrote:
> On Fri, 17 Aug 2007, Andi Kleen wrote:
> [...]
>
> [PATCH] i386, x86_64: __const_udelay() should not be marked inline
Eek, this one wasn't quite right on both counts, (1) correctness of
kernel/crash.c did not depend on __const_ud
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
> >
> > > Because they should be thinking about them in terms of barriers, over
> > > which the compiler / CPU is not to reorder accesses or cache
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> [...]
> > You think both these are equivalent in terms of "looks":
> >
> > |
> > while (!atomic_read()) {
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
> > > Satyam Sharma wrote:
> > >
> > > It is very obvious. msleep calls schedule() (ie. sleeps), which is
> > > always a barrier.
> >
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> > [...]
> > The point is about *author expecations*. If people do expect atomic_read()
> > (or a variant thereof) to have volatile semantics, why not give them such
> > a variant?
>
> Because t
On Fri, 17 Aug 2007, Paul Mackerras wrote:
> Satyam Sharma writes:
>
> > I wonder if this'll generate smaller and better code than _both_ the
> > other atomic_read_volatile() variants. Would need to build allyesconfig
> > on lots of diff arch's etc to test the theo
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> >
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> > > Also, why would you want to make these insane accessors for atomic_t
> > > types? Just make sure everybody knows the basics o
n becomes __const_udelay() after some
macro-ing in various headers). So let's not mark it as "inline" either.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/i386/lib/delay.c |2 +-
arch/x86_64/lib/delay.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> >
> > On Fri, 17 Aug 2007, Nick Piggin wrote:
>
> > > > Sure, now
> > > > that I learned of these properties I can start to audit code and insert
> > > > barriers
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
> [...]
> > Granted, the above IS buggy code. But, the stated objective is to avoid
> > heisenbugs.
^^
> Anyway, why are you making up code snippets that are buggy in other
> ways in order t
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Stefan Richter wrote:
> [...]
> Just use spinlocks if you're not absolutely clear about potential
> races and memory ordering issues -- they're pretty cheap and simple.
I fully agree with this. As Paul Mackerras mentioned elsewhere,
a lot of authors
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > #define atomic_read_volatile(v) \
> > ({ \
> > forget((v)->counter); \
&g
On Fri, 17 Aug 2007, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
> > > Herbert Xu writes:
> > >
> > > > Can you find an actual atomic_read code snippet there that is
> > > > broken without the volatile modifier?
> > >
> > >
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
> On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
> > On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
> > >
> > > The compiler can also reorder non-volatile accesses. For an example
> > > patch that cares about this,
codingstyle while I was there.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
fs/hostfs/hostfs_user.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/hostfs/hostfs_user.c b/fs/hostfs/hostfs_user.c
index 5625e24..a554a0a 100644
--- a/fs/hostfs/hostfs_use
On Fri, 17 Aug 2007, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
> >
> > The cost of doing so seems to me to be well down in the noise - 44
> > bytes of extra kernel text on a ppc64 G5 config, and I don't believe
> > the extra few cycles for the
On Fri, 17 Aug 2007, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
The cost of doing so seems to me to be well down in the noise - 44
bytes of extra kernel text on a ppc64 G5 config, and I don't believe
the extra few cycles for the occasional extra
-by: Satyam Sharma [EMAIL PROTECTED]
---
fs/hostfs/hostfs_user.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/hostfs/hostfs_user.c b/fs/hostfs/hostfs_user.c
index 5625e24..a554a0a 100644
--- a/fs/hostfs/hostfs_user.c
+++ b/fs/hostfs/hostfs_user.c
@@ -283,12 +283,12
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 09:34:41AM -0700, Paul E. McKenney wrote:
The compiler can also reorder non-volatile accesses. For an example
patch that cares about this, please see:
On Fri, 17 Aug 2007, Paul Mackerras wrote:
Herbert Xu writes:
On Fri, Aug 17, 2007 at 03:09:57PM +1000, Paul Mackerras wrote:
Herbert Xu writes:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
There are some in
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
#define atomic_read_volatile(v) \
({ \
forget((v)-counter); \
((v)-counter
On Fri, 17 Aug 2007, Nick Piggin wrote:
Stefan Richter wrote:
[...]
Just use spinlocks if you're not absolutely clear about potential
races and memory ordering issues -- they're pretty cheap and simple.
I fully agree with this. As Paul Mackerras mentioned elsewhere,
a lot of authors
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
[...]
Granted, the above IS buggy code. But, the stated objective is to avoid
heisenbugs.
^^
Anyway, why are you making up code snippets that are buggy in other
ways in order to support this assertion being made
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Sure, now
that I learned of these properties I can start to audit code and insert
barriers where I believe they are needed, but this simply means that
almost all
and arch/i386/kernel/crash.c:101 explicitly _depends_ upon it not being
inlined, and also it's an exported symbol (modules may want to call
mdelay() and udelay() that often becomes __const_udelay() after some
macro-ing in various headers). So let's not mark it as inline either.
Signed-off-by: Satyam
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Also, why would you want to make these insane accessors for atomic_t
types? Just make sure everybody knows the basics of barriers, and they
can apply that knowledge to atomic_t
On Fri, 17 Aug 2007, Paul Mackerras wrote:
Satyam Sharma writes:
I wonder if this'll generate smaller and better code than _both_ the
other atomic_read_volatile() variants. Would need to build allyesconfig
on lots of diff arch's etc to test the theory though.
I'm sure it would
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
[...]
The point is about *author expecations*. If people do expect atomic_read()
(or a variant thereof) to have volatile semantics, why not give them such
a variant?
Because they should be thinking about them in terms
301 - 400 of 1619 matches
Mail list logo
