RE: Bitops source problem
I have a CentOS 4.4 system with 2.6.9-42 kernel. I will update the kernel to the new one. Regards, Pravin -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 1:03 AM To: Pravin Nanaware Cc: John Hubbard; LKML Subject: Re: Bitops source problem > Yes, indeed none of the atomic bit operations functions has > LOCK_PREFIX in my version of Linux kernel. You have a broken source tree then. Where did your kernel source come from then? I'm not able to find any version of asm-i386/bitops.h where clear_bit() doesn't have LOCK_PREFIX in any of the trees I happen to have lying around (which includes some very old trees like 2.4.21) - R. -**Nihilent*** " *** All information contained in this communication is confidential, proprietary, privileged and is intended for the addressees only. If youhave received this E-mail in error please notify mail administrator by telephone on +91-20-39846100 or E-mail the sender by replying to this message, and then delete this E-mail and other copies of it from your computer system. Any unauthorized dissemination,publication, transfer or use of the contents of this communication, with or without modifications is punishable under the relevant law. Nihilent has scanned this mail with current virus checking technologies. However, Nihilent makes no representations or warranties to the effect that this communication is virus-free. Nihilent reserves the right to monitor all E-mail communications through its Corporate Network. *** " *- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
> Yes, indeed none of the atomic bit operations functions has > LOCK_PREFIX in my version of Linux kernel. You have a broken source tree then. Where did your kernel source come from then? I'm not able to find any version of asm-i386/bitops.h where clear_bit() doesn't have LOCK_PREFIX in any of the trees I happen to have lying around (which includes some very old trees like 2.4.21) - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Bitops source problem
Yes, indeed none of the atomic bit operations functions has LOCK_PREFIX in my
version of Linux kernel.
Regards,
Pravin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Roland Dreier
Sent: Thursday, January 17, 2008 12:15 PM
To: Pravin Nanaware
Cc: John Hubbard; LKML
Subject: Re: Bitops source problem
> Then, I think there is a problem with the function written below which is
> meant to be atomic.
>
> static __inline__ void change_bit(int nr, volatile void * addr)
> {
> __asm__ __volatile__(
> "btcl %1,%0"
> :"=m" (ADDR)
> :"Ir" (nr));
> }
If that is indeed the source of your change_bit function then there is
a problem. However in my kernel tree there is a LOCK_PREFIX in the
definition of the atomic version. I don't have your exact source tree
handy, but on a local RHEL4 system, the LOCK_PREFIX is still there:
static inline void change_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btcl %1,%0"
:"=m" (ADDR)
:"Ir" (nr));
}
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-**Nihilent***
" *** All information contained in this communication is confidential,
proprietary, privileged
and is intended for the addressees only. If youhave received this E-mail in
error please notify
mail administrator by telephone on +91-20-39846100 or E-mail the sender by
replying to
this message, and then delete this E-mail and other copies of it from your
computer system.
Any unauthorized dissemination,publication, transfer or use of the contents of
this communication,
with or without modifications is punishable under the relevant law.
Nihilent has scanned this mail with current virus checking technologies.
However, Nihilent makes no
representations or warranties to the effect that this communication is
virus-free.
Nihilent reserves the right to monitor all E-mail communications through its
Corporate Network. *** "
*-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
Yes, indeed none of the atomic bit operations functions has LOCK_PREFIX in my version of Linux kernel. You have a broken source tree then. Where did your kernel source come from then? I'm not able to find any version of asm-i386/bitops.h where clear_bit() doesn't have LOCK_PREFIX in any of the trees I happen to have lying around (which includes some very old trees like 2.4.21) - R. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Bitops source problem
I have a CentOS 4.4 system with 2.6.9-42 kernel. I will update the kernel to the new one. Regards, Pravin -Original Message- From: Roland Dreier [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 1:03 AM To: Pravin Nanaware Cc: John Hubbard; LKML Subject: Re: Bitops source problem Yes, indeed none of the atomic bit operations functions has LOCK_PREFIX in my version of Linux kernel. You have a broken source tree then. Where did your kernel source come from then? I'm not able to find any version of asm-i386/bitops.h where clear_bit() doesn't have LOCK_PREFIX in any of the trees I happen to have lying around (which includes some very old trees like 2.4.21) - R. -**Nihilent*** *** All information contained in this communication is confidential, proprietary, privileged and is intended for the addressees only. If youhave received this E-mail in error please notify mail administrator by telephone on +91-20-39846100 or E-mail the sender by replying to this message, and then delete this E-mail and other copies of it from your computer system. Any unauthorized dissemination,publication, transfer or use of the contents of this communication, with or without modifications is punishable under the relevant law. Nihilent has scanned this mail with current virus checking technologies. However, Nihilent makes no representations or warranties to the effect that this communication is virus-free. Nihilent reserves the right to monitor all E-mail communications through its Corporate Network. *** *- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
Hi
> If that is indeed the source of your change_bit function then there is
> a problem. However in my kernel tree there is a LOCK_PREFIX in the
> definition of the atomic version. I don't have your exact source tree
> handy, but on a local RHEL4 system, the LOCK_PREFIX is still there:
>
> static inline void change_bit(int nr, volatile unsigned long * addr)
> {
> __asm__ __volatile__( LOCK_PREFIX
> "btcl %1,%0"
> :"=m" (ADDR)
> :"Ir" (nr));
> }
2.6.24-rc6-mm1 have LOCK_PREFIX too :)
static inline void change_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX "btc %1,%0"
: ADDR : "Ir" (nr));
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
> Then, I think there is a problem with the function written below which is
> meant to be atomic.
>
> static __inline__ void change_bit(int nr, volatile void * addr)
> {
> __asm__ __volatile__(
> "btcl %1,%0"
> :"=m" (ADDR)
> :"Ir" (nr));
> }
If that is indeed the source of your change_bit function then there is
a problem. However in my kernel tree there is a LOCK_PREFIX in the
definition of the atomic version. I don't have your exact source tree
handy, but on a local RHEL4 system, the LOCK_PREFIX is still there:
static inline void change_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btcl %1,%0"
:"=m" (ADDR)
:"Ir" (nr));
}
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Bitops source problem
Thanks for the reply John.
Then, I think there is a problem with the function written below which is meant
to be atomic.
static __inline__ void change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
"btcl %1,%0"
:"=m" (ADDR)
:"Ir" (nr));
}
Regards,
Pravin
-Original Message-
From: John Hubbard [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 11:17 AM
To: Pravin Nanaware
Cc: LKML
Subject: Re: Bitops source problem
Pravin Nanaware wrote:
> Hi,
>
> I was just going through the include file in the /usr/include/asm/bitops.h
>
> The function description describes it as non-atomic but it seems it is not.
>
> static __inline__ void __change_bit(int nr, volatile void * addr)
> {
> __asm__ __volatile__(
> "btcl %1,%0"
> :"=m" (ADDR)
> :"Ir" (nr));
> }
>
> The kernel version I am using is 2.6.9-42. Is it right or am I missing
> something ?
>
> Thanks,
> Pravin
>
The bitops.h comments are correct: the btc IA-32 instruction is only
atomic if used with the lock prefix. The function above does not use the
lock prefix, so it is not atomic.
thanks,
John Hubbard
-**Nihilent***
" *** All information contained in this communication is confidential,
proprietary, privileged
and is intended for the addressees only. If youhave received this E-mail in
error please notify
mail administrator by telephone on +91-20-39846100 or E-mail the sender by
replying to
this message, and then delete this E-mail and other copies of it from your
computer system.
Any unauthorized dissemination,publication, transfer or use of the contents of
this communication,
with or without modifications is punishable under the relevant law.
Nihilent has scanned this mail with current virus checking technologies.
However, Nihilent makes no
representations or warranties to the effect that this communication is
virus-free.
Nihilent reserves the right to monitor all E-mail communications through its
Corporate Network. *** "
*-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
Pravin Nanaware wrote:
Hi,
I was just going through the include file in the /usr/include/asm/bitops.h
The function description describes it as non-atomic but it seems it is not.
static __inline__ void __change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
"btcl %1,%0"
:"=m" (ADDR)
:"Ir" (nr));
}
The kernel version I am using is 2.6.9-42. Is it right or am I missing something ?
Thanks,
Pravin
The bitops.h comments are correct: the btc IA-32 instruction is only
atomic if used with the lock prefix. The function above does not use the
lock prefix, so it is not atomic.
thanks,
John Hubbard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
Pravin Nanaware wrote:
Hi,
I was just going through the include file in the /usr/include/asm/bitops.h
The function description describes it as non-atomic but it seems it is not.
static __inline__ void __change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
The kernel version I am using is 2.6.9-42. Is it right or am I missing something ?
Thanks,
Pravin
The bitops.h comments are correct: the btc IA-32 instruction is only
atomic if used with the lock prefix. The function above does not use the
lock prefix, so it is not atomic.
thanks,
John Hubbard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Bitops source problem
Thanks for the reply John.
Then, I think there is a problem with the function written below which is meant
to be atomic.
static __inline__ void change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
Regards,
Pravin
-Original Message-
From: John Hubbard [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 11:17 AM
To: Pravin Nanaware
Cc: LKML
Subject: Re: Bitops source problem
Pravin Nanaware wrote:
Hi,
I was just going through the include file in the /usr/include/asm/bitops.h
The function description describes it as non-atomic but it seems it is not.
static __inline__ void __change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
The kernel version I am using is 2.6.9-42. Is it right or am I missing
something ?
Thanks,
Pravin
The bitops.h comments are correct: the btc IA-32 instruction is only
atomic if used with the lock prefix. The function above does not use the
lock prefix, so it is not atomic.
thanks,
John Hubbard
-**Nihilent***
*** All information contained in this communication is confidential,
proprietary, privileged
and is intended for the addressees only. If youhave received this E-mail in
error please notify
mail administrator by telephone on +91-20-39846100 or E-mail the sender by
replying to
this message, and then delete this E-mail and other copies of it from your
computer system.
Any unauthorized dissemination,publication, transfer or use of the contents of
this communication,
with or without modifications is punishable under the relevant law.
Nihilent has scanned this mail with current virus checking technologies.
However, Nihilent makes no
representations or warranties to the effect that this communication is
virus-free.
Nihilent reserves the right to monitor all E-mail communications through its
Corporate Network. ***
*-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
Then, I think there is a problem with the function written below which is
meant to be atomic.
static __inline__ void change_bit(int nr, volatile void * addr)
{
__asm__ __volatile__(
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
If that is indeed the source of your change_bit function then there is
a problem. However in my kernel tree there is a LOCK_PREFIX in the
definition of the atomic version. I don't have your exact source tree
handy, but on a local RHEL4 system, the LOCK_PREFIX is still there:
static inline void change_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
- R.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bitops source problem
Hi
If that is indeed the source of your change_bit function then there is
a problem. However in my kernel tree there is a LOCK_PREFIX in the
definition of the atomic version. I don't have your exact source tree
handy, but on a local RHEL4 system, the LOCK_PREFIX is still there:
static inline void change_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
btcl %1,%0
:=m (ADDR)
:Ir (nr));
}
2.6.24-rc6-mm1 have LOCK_PREFIX too :)
static inline void change_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX btc %1,%0
: ADDR : Ir (nr));
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
