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.
Probably you didn't mean that, but no, schedule() is not barrier
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
[...]
You think both these are equivalent in terms of looks:
|
while (!atomic_read(v)) { | while (!atomic_read_xxx(v
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 memory
operations, rather than special
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_udelay() being uninlined
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.
I'll
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 unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL
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:
First of all, I think this illustrates that what you want
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 only in error paths and
kfree(ZERO_SIZE_PTR
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 knows?
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. That's a little bit sleazy though - there
might
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
are determining the size of an unallocated
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 few weeks back
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 reordering.
If you're
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 object.
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 up being
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.
I don't think an
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.
* foo() is also a compiler barrier
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.
Side effects aren't
allowed to be
Hi Linus,
[ and others; I think there's a communication gap in a lot of this
thread, and a little summary would be useful. Hence this posting. ]
On Thu, 16 Aug 2007, Linus Torvalds wrote:
> On Fri, 17 Aug 2007, Paul Mackerras wrote:
> >
> > I'm really surprised it's as much as a few K. I
[ Your mailer drops Cc: lists, munges headers,
does all sorts of badness. Please fix that. ]
On Thu, 16 Aug 2007, David Schwartz wrote:
>
> > There is a quite convincing argument that such an access _is_ an
> > access to a volatile object; see GCC PR21568 comment #9. This
> > probably isn't
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Here, I should obviously admit that the semantics of *(volatile int *)&
> > aren't any neater or well-defined in the _language standard_ at all. The
> > standard does say (verbatim) "precisely what constitutes as access to
> > object of
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
> > Note that "volatile"
> > is a type-qualifier, not a type itself, so a cast of the _object_ itself
> > to a qualified-type i.e. (volatile int) would not make the access itself
> > volatile-qualified.
>
> There is no such thing as
On Thu, 16 Aug 2007, Andy Whitcroft wrote:
> A couple of people suggested adding checks to checkpatch for trailing
> semicolons on conditionals, where the conditional block may not be
> actually conditional:
>
> if (err);
> return err;
>
> While regression testing the
Hi Ilpo,
On Thu, 16 Aug 2007, Ilpo Järvinen wrote:
>
> ...I guess those guys hunting for broken busyloops in the other thread
> could also benefit from similar searching commands introduced in this
> thread... ...Ccing Satyam to caught their attention too.
>
>
> > On Wed, Aug 15, 2007 at
, Satyam Sharma wrote:
> On Thu, 16 Aug 2007, Satyam Sharma wrote:
> [...]
> > On Wed, 15 Aug 2007, Bill Fink wrote:
> > > [...]
> > > I'm curious about one minor tangential point. Why, instead of:
> > >
> > > b = *(volatile int *)
> > >
&g
, Satyam Sharma wrote:
On Thu, 16 Aug 2007, Satyam Sharma wrote:
[...]
On Wed, 15 Aug 2007, Bill Fink wrote:
[...]
I'm curious about one minor tangential point. Why, instead of:
b = *(volatile int *)a;
why can't this just be expressed as:
b = (volatile int
Hi Ilpo,
On Thu, 16 Aug 2007, Ilpo Järvinen wrote:
...I guess those guys hunting for broken busyloops in the other thread
could also benefit from similar searching commands introduced in this
thread... ...Ccing Satyam to caught their attention too.
On Wed, Aug 15, 2007 at
On Thu, 16 Aug 2007, Andy Whitcroft wrote:
A couple of people suggested adding checks to checkpatch for trailing
semicolons on conditionals, where the conditional block may not be
actually conditional:
if (err);
return err;
While regression testing the changes, I
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
Note that volatile
is a type-qualifier, not a type itself, so a cast of the _object_ itself
to a qualified-type i.e. (volatile int) would not make the access itself
volatile-qualified.
There is no such thing as volatile-qualified access
On Thu, 16 Aug 2007, Segher Boessenkool wrote:
Here, I should obviously admit that the semantics of *(volatile int *)
aren't any neater or well-defined in the _language standard_ at all. The
standard does say (verbatim) precisely what constitutes as access to
object of
[ Your mailer drops Cc: lists, munges headers,
does all sorts of badness. Please fix that. ]
On Thu, 16 Aug 2007, David Schwartz wrote:
There is a quite convincing argument that such an access _is_ an
access to a volatile object; see GCC PR21568 comment #9. This
probably isn't the
Hi Linus,
[ and others; I think there's a communication gap in a lot of this
thread, and a little summary would be useful. Hence this posting. ]
On Thu, 16 Aug 2007, Linus Torvalds wrote:
On Fri, 17 Aug 2007, Paul Mackerras wrote:
I'm really surprised it's as much as a few K. I tried
On Thu, 16 Aug 2007, Satyam Sharma wrote:
> Hi Bill,
>
>
> On Wed, 15 Aug 2007, Bill Fink wrote:
>
> > On Wed, 15 Aug 2007, Satyam Sharma wrote:
> >
> > > (C)
> > > $ cat tp3.c
> > > int a;
> > >
> > > void func(void
Hi Bill,
On Wed, 15 Aug 2007, Bill Fink wrote:
> On Wed, 15 Aug 2007, Satyam Sharma wrote:
>
> > (C)
> > $ cat tp3.c
> > int a;
> >
> > void func(void)
> > {
> > *(volatile int *) = 10;
> > *(volatile int *) = 20;
> > }
&g
On Thu, 16 Aug 2007, Satyam Sharma wrote:
> On Thu, 16 Aug 2007, Paul Mackerras wrote:
> > Herbert Xu writes:
> >
> > > See sk_stream_mem_schedule in net/core/stream.c:
> > >
> > > /* Under limit. */
> > > if (atomic_read(
On Thu, 16 Aug 2007, Paul Mackerras wrote:
> Herbert Xu writes:
>
> > See sk_stream_mem_schedule in net/core/stream.c:
> >
> > /* Under limit. */
> > if (atomic_read(sk->sk_prot->memory_allocated) <
> > sk->sk_prot->sysctl_mem[0]) {
> > if
On Wed, 15 Aug 2007, Christoph Lameter wrote:
> On Wed, 15 Aug 2007, Paul E. McKenney wrote:
>
> > Understood. My point is not that the impact is precisely zero, but
> > rather that the impact on optimization is much less hurtful than the
> > problems that could arise otherwise, particularly
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> [...]
> > BTW:
> >
> > #define atomic_read(a) (*(volatile int *)&(a))
> > #define atomic_set(a,i) (*(volatile int *)&(a) = (i))
> >
> > int a;
> >
> > void func(void)
> > {
> > int b;
> >
> > b = atomic_read(a);
> >
Hi Herbert,
On Thu, 16 Aug 2007, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:28:42AM +0530, Satyam Sharma wrote:
> >
> > > The udelay itself certainly should have some form of cpu_relax in it.
> >
> > Yes, a form of barrier() must be present in mdelay() or
[ Sorry for empty subject line in previous mail. I intended to make
a patch so cleared it to change it, but ultimately neither made
a patch nor restored subject line. Done that now. ]
On Thu, 16 Aug 2007, Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wr
e register only,
so these look like real bugs to me. With the fix below, this becomes:
0xc1019706 :pause
0xc1019708 :cmpl $0x0,0xc144c4c8
0xc101970f :je 0xc1019706
which looks nice and healthy. ]
Thanks to Heiko Carstens for noticing this.
Signed-off-by: Satyam Sha
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > > > What you probably mean is that the compiler has to assume any code
> > > > it cannot currently see can do anything (insofar as allowed by the
> > > > relevant standards etc.)
> >
> > I think this was just terminology confusion here again.
[ The Cc: list scares me. Should probably trim it. ]
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > >>How does the compiler know that msleep() has got barrier()s?
> > >
> > >Because msleep_interruptible() is in a separate
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > "Volatile behaviour" itself isn't consistently defined (at least
> > definitely not consistently implemented in various gcc versions across
> > platforms),
>
> It should be consistent across platforms; if not, file a bug please.
>
> > but it
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 10:48:28PM +0530, Satyam Sharma wrote:
> > [...]
> > Not for i386 and x86_64 -- those have atomic ops without any "volatile"
> > semantics (currently as per existing definitions).
>
Hi Paul,
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
> > [...]
> > No, I'd actually prefer something like what Christoph Lameter suggested,
> > i.e. users (such as above) who want "volatile"-like be
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
> > On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
> > >
> > > Do we really need another set of APIs? Can you give even one example
> > > where the pre-existing
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
> > Herbert Xu wrote:
> > > On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
> > >>> I don't know if this here is affected:
>
a signal (might never happen in practice, as
it ignores signals). But considering kthread_stop() must not be mixed with
kthreads that can exit on their own, I think changing the code like this
is clearer. This change means the thread can cut its sleep short when
receive a signal but looking at the
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > On Wed, 15 Aug 2007, Stefan Richter wrote:
> >> Doesn't "atomic WRT all processors" require volatility?
> >
> > No, it definitely doesn't. Why should it?
> >
> > "
Hi Rene,
On Wed, 15 Aug 2007, Rene Herman wrote:
> It mostly is just about that it seems. However, this would not also allow the
> other information currently in the MAINTAINERS file to be queried in similar
> ways.
>
> Git could grow a generic file meta data implementation through the use of
On Wed, 15 Aug 2007, Herbert Xu wrote:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
> >> textdata bss dec hex filename
> >> 3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
> >> 3435308 249176
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> > the first place? Atomic ops guarantee atomicity, which has nothing
> > to do with "volatility" -- users that expect
On Wed, 15 Aug 2007, Stefan Richter wrote:
Satyam Sharma wrote:
[ BTW, why do we want the compiler to not optimize atomic_read()'s in
the first place? Atomic ops guarantee atomicity, which has nothing
to do with volatility -- users that expect volatility from
atomic ops
On Wed, 15 Aug 2007, Herbert Xu wrote:
Andi Kleen [EMAIL PROTECTED] wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
textdata bss dec hex filename
3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
3435308 249176 176128 3860612
Hi Rene,
On Wed, 15 Aug 2007, Rene Herman wrote:
It mostly is just about that it seems. However, this would not also allow the
other information currently in the MAINTAINERS file to be queried in similar
ways.
Git could grow a generic file meta data implementation through the use of
On Wed, 15 Aug 2007, Stefan Richter wrote:
Satyam Sharma wrote:
On Wed, 15 Aug 2007, Stefan Richter wrote:
Doesn't atomic WRT all processors require volatility?
No, it definitely doesn't. Why should it?
Atomic w.r.t. all processors is just your normal, simple atomicity
for SMP
changing the code like this
is clearer. This change means the thread can cut its sleep short when
receive a signal but looking at the code around, that sounds okay (and
again, it might never actually recieve a signal in practice).
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
drivers/ieee1394
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
Herbert Xu wrote:
On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
I don't know if this here is affected:
[...something like]
b = atomic_read
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
Do we really need another set of APIs? Can you give even one example
where the pre-existing volatile semantics
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 10:48:28PM +0530, Satyam Sharma wrote:
[...]
Not for i386 and x86_64 -- those have atomic ops without any volatile
semantics (currently as per existing definitions).
I claim unit volumes with arm, and the majority
Hi Paul,
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
[...]
No, I'd actually prefer something like what Christoph Lameter suggested,
i.e. users (such as above) who want volatile-like behaviour from atomic
ops can use
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
Volatile behaviour itself isn't consistently defined (at least
definitely not consistently implemented in various gcc versions across
platforms),
It should be consistent across platforms; if not, file a bug please.
but it is /expected/
[ The Cc: list scares me. Should probably trim it. ]
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
How does the compiler know that msleep() has got barrier()s?
Because msleep_interruptible() is in a separate compilation
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
What you probably mean is that the compiler has to assume any code
it cannot currently see can do anything (insofar as allowed by the
relevant standards etc.)
I think this was just terminology confusion here again. Isn't any code
+14
which looks nice and healthy. ]
Thanks to Heiko Carstens for noticing this.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
include/asm-i386/mach-default/mach_wakecpu.h |3 ++-
include/asm-i386/mach-es7000/mach_wakecpu.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions
[ Sorry for empty subject line in previous mail. I intended to make
a patch so cleared it to change it, but ultimately neither made
a patch nor restored subject line. Done that now. ]
On Thu, 16 Aug 2007, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 06:06:00AM +0530, Satyam Sharma wrote
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
[...]
BTW:
#define atomic_read(a) (*(volatile int *)(a))
#define atomic_set(a,i) (*(volatile int *)(a) = (i))
int a;
void func(void)
{
int b;
b = atomic_read(a);
atomic_set(a, 20);
b =
Hi Herbert,
On Thu, 16 Aug 2007, Herbert Xu wrote:
On Thu, Aug 16, 2007 at 06:28:42AM +0530, Satyam Sharma wrote:
The udelay itself certainly should have some form of cpu_relax in it.
Yes, a form of barrier() must be present in mdelay() or udelay() itself
as you say, having
On Wed, 15 Aug 2007, Christoph Lameter wrote:
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
Understood. My point is not that the impact is precisely zero, but
rather that the impact on optimization is much less hurtful than the
problems that could arise otherwise, particularly as
On Thu, 16 Aug 2007, Paul Mackerras wrote:
Herbert Xu writes:
See sk_stream_mem_schedule in net/core/stream.c:
/* Under limit. */
if (atomic_read(sk-sk_prot-memory_allocated)
sk-sk_prot-sysctl_mem[0]) {
if (*sk-sk_prot-memory_pressure)
On Thu, 16 Aug 2007, Satyam Sharma wrote:
On Thu, 16 Aug 2007, Paul Mackerras wrote:
Herbert Xu writes:
See sk_stream_mem_schedule in net/core/stream.c:
/* Under limit. */
if (atomic_read(sk-sk_prot-memory_allocated)
sk-sk_prot-sysctl_mem[0
Hi Bill,
On Wed, 15 Aug 2007, Bill Fink wrote:
On Wed, 15 Aug 2007, Satyam Sharma wrote:
(C)
$ cat tp3.c
int a;
void func(void)
{
*(volatile int *)a = 10;
*(volatile int *)a = 20;
}
$ gcc -Os -S tp3.c
$ cat tp3.s
...
movl$10, a
movl$20
On Thu, 16 Aug 2007, Satyam Sharma wrote:
Hi Bill,
On Wed, 15 Aug 2007, Bill Fink wrote:
On Wed, 15 Aug 2007, Satyam Sharma wrote:
(C)
$ cat tp3.c
int a;
void func(void)
{
*(volatile int *)a = 10;
*(volatile int *)a = 20;
}
$ gcc -Os -S tp3.c
, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
kfree(ZERO_SIZE_PTR) is uncommon as well, so let's use unlikely() for
the condition check in SLUB's and SLOB's kfree() to optimize for the
common case. SLAB has this already.
On Tue, 14 Aug 2007, Tim Bird wrote:
> Hi all,
>
> I have a quick question.
>
> I'm trying to resurrect a patch from the Linux-tiny patch suite,
> to do accounting of kmalloc memory allocations. In testing it
> with Linux 2.6.22, I've found a large number of kfrees of
> NULL pointers.
>
>
On Tue, 14 Aug 2007, Christoph Lameter wrote:
> On Thu, 9 Aug 2007, Chris Snook wrote:
>
> > This patchset makes the behavior of atomic_read uniform by removing the
> > volatile keyword from all atomic_t and atomic64_t definitions that currently
> > have it, and instead explicitly casts the
On Tue, 14 Aug 2007, Christoph Lameter wrote:
On Thu, 9 Aug 2007, Chris Snook wrote:
This patchset makes the behavior of atomic_read uniform by removing the
volatile keyword from all atomic_t and atomic64_t definitions that currently
have it, and instead explicitly casts the variable
On Tue, 14 Aug 2007, Tim Bird wrote:
Hi all,
I have a quick question.
I'm trying to resurrect a patch from the Linux-tiny patch suite,
to do accounting of kmalloc memory allocations. In testing it
with Linux 2.6.22, I've found a large number of kfrees of
NULL pointers.
Is this
in error paths and
kfree(ZERO_SIZE_PTR) is uncommon as well, so let's use unlikely() for
the condition check in SLUB's and SLOB's kfree() to optimize for the
common case. SLAB has this already.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
mm/slob.c |2 +-
mm/slub.c |2 +-
2 files
On Mon, 13 Aug 2007, Arjan van de Ven wrote:
>
> On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
> > Hello,
> >
> > I don't recall discusion about this so here are my 3 cents:
> >
> > I like the idea.
>
> I don't actually. It shows a central MAINTAINERS file is the
t
instead, like the other archs do.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
arch/ia64/Kconfig | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 21aa4fc..8c39913 100644
--- a/arch/ia64/Kconfig
+++
On 8/9/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 09 Aug 2007 01:48:07 +0300
> > Avi Kivity <[EMAIL PROTECTED]> wrote:
> >
> >> Ingo Molnar wrote:
> >>
> >>> * Andrew Morton <[EMAIL PROTECTED]> wrote:
> >>>
> ia64 allmodconfig says
>
>
On 8/13/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 8/13/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Sun, 12 Aug 2007 23:37:08 -0700
> > [EMAIL PROTECTED] wrote:
> >
> > > Add file pattern to MAINTAINER entry
> > >
> > > Sig
On 8/13/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 12 Aug 2007 23:37:08 -0700
> [EMAIL PROTECTED] wrote:
>
> > Add file pattern to MAINTAINER entry
> >
> > Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index af16a17..7a7f837 100644
> > ---
On Mon, 13 Aug 2007, Alexey Dobriyan wrote:
> Andrew please drop
> introduce-strtol_check_range-fix.patch
> introduce-strtol_check_range.patch
> from -mm.
>
> strtol_check_range() semantics is broken, because caller can't distinguish
> -E from valid negative number if he wants to
On 8/13/07, Alan Cox [EMAIL PROTECTED] wrote:
On Sun, 12 Aug 2007 23:37:08 -0700
[EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index af16a17..7a7f837 100644
--- a/MAINTAINERS
+++
On Mon, 13 Aug 2007, Alexey Dobriyan wrote:
Andrew please drop
introduce-strtol_check_range-fix.patch
introduce-strtol_check_range.patch
from -mm.
strtol_check_range() semantics is broken, because caller can't distinguish
-E from valid negative number if he wants to negative
On 8/13/07, Satyam Sharma [EMAIL PROTECTED] wrote:
On 8/13/07, Alan Cox [EMAIL PROTECTED] wrote:
On Sun, 12 Aug 2007 23:37:08 -0700
[EMAIL PROTECTED] wrote:
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b
On 8/9/07, Avi Kivity [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 09 Aug 2007 01:48:07 +0300
Avi Kivity [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
ia64 allmodconfig says
drivers/kvm/Kconfig:14:warning: 'select' used by config
.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
---
arch/ia64/Kconfig | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 21aa4fc..8c39913 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -327,17 +327,7 @@ config
On Mon, 13 Aug 2007, Arjan van de Ven wrote:
On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
Hello,
I don't recall discusion about this so here are my 3 cents:
I like the idea.
I don't actually. It shows a central MAINTAINERS file is the wrong
approach;
Hi Jan,
On Fri, 3 Aug 2007, Jan Engelhardt wrote:
>
> On Aug 2 2007 05:16, Satyam Sharma wrote:
> >
> >BSD's strtonum(3) is a detestful, horrible shame.
> >
> >The strtol_check_range() I implemented here does _all_ that strtonum()
> >does, plus is generic
Hi Jan,
On Fri, 3 Aug 2007, Jan Engelhardt wrote:
On Aug 2 2007 05:16, Satyam Sharma wrote:
BSD's strtonum(3) is a detestful, horrible shame.
The strtol_check_range() I implemented here does _all_ that strtonum()
does, plus is generic w.r.t. base, and minus the tasteless errstr
On Thu, 2 Aug 2007, Jan Engelhardt wrote:
> On Aug 2 2007 21:55, Guennadi Liakhovetski wrote:
> > [...]
> >
> > struct {
> > char c[4];
> > int i;
> > } t;
> > t.i = 0x12345678;
> > strcpy(t.c, c);
> >
> >and t.i is silently corrupted. Just wanted to ask
ix
We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked
into the same mtd.ko module. Fix the Makefile to ensure this, and remove
duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
drivers/mtd/Mak
Hi,
On Thu, 2 Aug 2007, Stefan Walter wrote:
> Steve Dickson wrote:
> > Stefan Walter wrote:
> >>
> >> We do this on a much larger scale though. The bug we ran into is
> >> in line 96 in utils/mountd/auth.c. The strcpy can corrupt
> >> memory when it copies the string returned by
On Thu, 2 Aug 2007, Jarek Poplawski wrote:
> On Thu, Aug 02, 2007 at 04:02:21PM +0530, Satyam Sharma wrote:
> [...]
> How often "common" developer has to make such decisions in Kconfig?
> Probably no more than once per year. So, it's fair to blame anybody
> for
[ Read through the thread, looked at Kconfig files,
did some tests. Adding Kconfig experts to Cc: list. ]
> On Thu, 2 Aug 2007, Sam Ravnborg wrote:
>
> > > >
> > > > ...
> > > > endif # NETDEVICES
> > > >
> > > > config NETPOLL
> > > > depends on NETDEVICES
> > > > def_bool
On Thu, 2 Aug 2007, John Sigler wrote:
> Hello,
>
> I'm trying to build a 2.6.22.1-rt9 kernel for a P3.
>
> I used 'make xconfig' to create .config
> http://linux.kernel.free.fr/latency/config-2.6.22.1-rt9-adlink
>
> I get the following warning:
>
> LD vmlinux
> SYSMAP System.map
401 - 500 of 1619 matches
Mail list logo
