ARP Bug?
Jan Engelhardt: >On Jan 30 2008 04:29, Matti Linnanvuori wrote: >Jan Engelhardt: >>> If you have the same subnet on multiple interfaces, only the >>> first interface will be served. >> >>Does that comply with the standard? > >What standard? ARP standard. I think it is RFC 826: An Ethernet Address Resolution Protocol Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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/
ARP Bug?
Jan Engelhardt: > If you have the same subnet on multiple interfaces, only the > first interface will be served. Does that comply with the standard? Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- 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/
ARP Bug?
Jan Engelhardt: On Jan 30 2008 04:29, Matti Linnanvuori wrote: Jan Engelhardt: If you have the same subnet on multiple interfaces, only the first interface will be served. Does that comply with the standard? What standard? ARP standard. I think it is RFC 826: An Ethernet Address Resolution Protocol Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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/
ARP Bug?
Jan Engelhardt: If you have the same subnet on multiple interfaces, only the first interface will be served. Does that comply with the standard? Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- 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/
PIT clocksource makes invalid assumptions
I thought the following bug might be caused by PIT: ifconfig eth1 showed UP and RUNNING even though traffic did not work. The following lines in dmesg look suspicious: [ 83.017954] Clocksource tsc unstable (delta = 111864067 ns) [ 83.018930] Time: pit clocksource has been installed. http://bugzilla.kernel.org/show_bug.cgi?id=9336 Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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/
PIT clocksource makes invalid assumptions
I thought the following bug might be caused by PIT: ifconfig eth1 showed UP and RUNNING even though traffic did not work. The following lines in dmesg look suspicious: [ 83.017954] Clocksource tsc unstable (delta = 111864067 ns) [ 83.018930] Time: pit clocksource has been installed. http://bugzilla.kernel.org/show_bug.cgi?id=9336 Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- 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/
/dev/urandom uses uninit bytes, leaks user data
From: Matti Linnanvuori <[EMAIL PROTECTED]>
/dev/urandom use no uninit bytes, leak no user data
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
+++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
@@ -689,7 +689,7 @@ static ssize_t extract_entropy(struct en
*/
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
- __u32 tmp[OUTPUT_POOL_WORDS];
+ static __u32 tmp[OUTPUT_POOL_WORDS];
if (r->pull && r->entropy_count < nbytes * 8 &&
r->entropy_count < r->poolinfo->POOLBITS) {
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
--
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/
/dev/urandom uses uninit bytes, leaks user data
From: Matti Linnanvuori [EMAIL PROTECTED]
/dev/urandom use no uninit bytes, leak no user data
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
--- a/drivers/char/random.c 2007-12-15 09:09:37.895414000 +0200
+++ b/drivers/char/random.c 2007-12-15 09:12:02.607831500 +0200
@@ -689,7 +689,7 @@ static ssize_t extract_entropy(struct en
*/
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
- __u32 tmp[OUTPUT_POOL_WORDS];
+ static __u32 tmp[OUTPUT_POOL_WORDS];
if (r-pull r-entropy_count nbytes * 8
r-entropy_count r-poolinfo-POOLBITS) {
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
--
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/
[PATCH] module: fix and elaborate comments
From: Matti Linnanvuori <[EMAIL PROTECTED]>
Fix and elaborate comments.
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- a/kernel/module.c2007-11-08 18:21:18.762437500 +0200
+++ b/kernel/module.c2007-11-08 18:25:57.961364500 +0200
@@ -81,7 +81,8 @@ int unregister_module_notifier(struct no
}
EXPORT_SYMBOL(unregister_module_notifier);
-/* We require a truly strong try_module_get() */
+/* We require a truly strong try_module_get(): 0 means failure due to
+ ongoing or failed initialization etc. */
static inline int strong_try_module_get(struct module *mod)
{
if (mod && mod->state == MODULE_STATE_COMING)
@@ -952,7 +953,8 @@ static unsigned long resolve_symbol(Elf_
ret = __find_symbol(name, , ,
!(mod->taints & TAINT_PROPRIETARY_MODULE));
if (ret) {
-/* use_module can fail due to OOM, or module unloading */
+/* use_module can fail due to OOM,
+ or module initialization or unloading */
if (!check_version(sechdrs, versindex, name, mod, crc) ||
!use_module(mod, owner))
ret = 0;
@@ -1369,7 +1371,7 @@ dup:
return ret;
}
-/* Change all symbols so that sh_value encodes the pointer directly. */
+/* Change all symbols so that st_value encodes the pointer directly. */
static int simplify_symbols(Elf_Shdr *sechdrs,
unsigned int symindex,
const char *strtab,
__ Ihre erste Baustelle? Wissenswertes
für Bastler und Hobby Handwerker. www.yahoo.de/clever
-
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/
[PATCH] module: fix and elaborate comments
From: Matti Linnanvuori [EMAIL PROTECTED]
Fix and elaborate comments.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
--- a/kernel/module.c2007-11-08 18:21:18.762437500 +0200
+++ b/kernel/module.c2007-11-08 18:25:57.961364500 +0200
@@ -81,7 +81,8 @@ int unregister_module_notifier(struct no
}
EXPORT_SYMBOL(unregister_module_notifier);
-/* We require a truly strong try_module_get() */
+/* We require a truly strong try_module_get(): 0 means failure due to
+ ongoing or failed initialization etc. */
static inline int strong_try_module_get(struct module *mod)
{
if (mod mod-state == MODULE_STATE_COMING)
@@ -952,7 +953,8 @@ static unsigned long resolve_symbol(Elf_
ret = __find_symbol(name, owner, crc,
!(mod-taints TAINT_PROPRIETARY_MODULE));
if (ret) {
-/* use_module can fail due to OOM, or module unloading */
+/* use_module can fail due to OOM,
+ or module initialization or unloading */
if (!check_version(sechdrs, versindex, name, mod, crc) ||
!use_module(mod, owner))
ret = 0;
@@ -1369,7 +1371,7 @@ dup:
return ret;
}
-/* Change all symbols so that sh_value encodes the pointer directly. */
+/* Change all symbols so that st_value encodes the pointer directly. */
static int simplify_symbols(Elf_Shdr *sechdrs,
unsigned int symindex,
const char *strtab,
__ Ihre erste Baustelle? Wissenswertes
für Bastler und Hobby Handwerker. www.yahoo.de/clever
-
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/
[PATCH] telephony: phonedev panics if unregistering device not registered [Bug 9266]
From: Matti Linnanvuori <[EMAIL PROTECTED]>
Remove panic from phonedev.
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- a/drivers/telephony/phonedev.c 2007-10-31 17:52:55.784817000 +0200
+++ linux-2.6.24/drivers/telephony/phonedev.c 2007-10-31 17:55:48.144879000
+0200
@@ -120,9 +120,8 @@ int phone_register_device(struct phone_d
void phone_unregister_device(struct phone_device *pfd)
{
mutex_lock(_lock);
- if (phone_device[pfd->minor] != pfd)
- panic("phone: bad unregister");
- phone_device[pfd->minor] = NULL;
+ if (likely(phone_device[pfd->minor] == pfd))
+ phone_device[pfd->minor] = NULL;
mutex_unlock(_lock);
}
Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s
mit dem neuen Yahoo! Mail. www.yahoo.de/mail
-
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/
[PATCH] telephony: phonedev panics if unregistering device not registered [Bug 9266]
From: Matti Linnanvuori [EMAIL PROTECTED]
Remove panic from phonedev.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
--- a/drivers/telephony/phonedev.c 2007-10-31 17:52:55.784817000 +0200
+++ linux-2.6.24/drivers/telephony/phonedev.c 2007-10-31 17:55:48.144879000
+0200
@@ -120,9 +120,8 @@ int phone_register_device(struct phone_d
void phone_unregister_device(struct phone_device *pfd)
{
mutex_lock(phone_lock);
- if (phone_device[pfd-minor] != pfd)
- panic(phone: bad unregister);
- phone_device[pfd-minor] = NULL;
+ if (likely(phone_device[pfd-minor] == pfd))
+ phone_device[pfd-minor] = NULL;
mutex_unlock(phone_lock);
}
Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s
mit dem neuen Yahoo! Mail. www.yahoo.de/mail
-
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/
[PATCH] include/linux/mutex.h: unclear reference to convention
If you want to maintain the convention of documenting the interface only in .c files, you should write the convention in so many places in .h files that no one could overlook it. But I think the convention is bad and it would be better to document the interface also in .h files where it is defined. The convention is bad because it requires people to jump to other files to understand .h files. __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - 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/
[PATCH] include/linux/mutex.h: unclear reference to convention
If you want to maintain the convention of documenting the interface only in .c files, you should write the convention in so many places in .h files that no one could overlook it. But I think the convention is bad and it would be better to document the interface also in .h files where it is defined. The convention is bad because it requires people to jump to other files to understand .h files. __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - 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/
[PATCH] include/linux/mutex.h: unclear reference to convention
Randy Dunlap <[EMAIL PROTECTED]>: > Another convention is that we put kernel-doc with the implementation > (i.e., in .c files) when possible, not with the function prototype. > Of course, for inline functions or macros in header files, that's > where the kernel-doc has to live. > > so we don't need this patch. You should not expect that every reader of the kernel files is aware of that convention. I was not and therefore I sought referenced files for some time. Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - 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/
[PATCH] include/linux/mutex.h: unclear reference to convention
Randy Dunlap [EMAIL PROTECTED]: Another convention is that we put kernel-doc with the implementation (i.e., in .c files) when possible, not with the function prototype. Of course, for inline functions or macros in header files, that's where the kernel-doc has to live. so we don't need this patch. You should not expect that every reader of the kernel files is aware of that convention. I was not and therefore I sought referenced files for some time. Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - 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/
[PATCH] include/linux/mutex.h: unclear reference to convention
From: Matti Linnanvuori <[EMAIL PROTECTED]> Reference to two different conventions is unnecessarily unclear unless you know them already and requires seeking and reading another file for understanding. Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> --- --- linux-2.6.23-rc7/include/linux/mutex.h2007-09-22 11:09:42.223763000 +0300 +++ linux-2.6.23/include/linux/mutex.h2007-09-22 11:11:19.416761000 +0300 @@ -132,9 +132,19 @@ extern int __must_check mutex_lock_inter # define mutex_lock_interruptible_nested(lock, subclass) mutex_lock_interruptible(lock) #endif -/* - * NOTE: mutex_trylock() follows the spin_trylock() convention, - * not the down_trylock() convention! +/*** + * mutex_trylock - try acquire the mutex, without waiting + * @lock: the mutex to be acquired + * + * Try to acquire the mutex atomically. Returns 1 if the mutex + * has been acquired successfully, and 0 on contention. + * + * NOTE: this function follows the spin_trylock() convention, so + * it is negated to the down_trylock() return values! Be careful + * about this when converting semaphore users to mutexes. + * + * This function must not be used in interrupt context. The + * mutex must be released by the same task that acquired it. */ extern int fastcall mutex_trylock(struct mutex *lock); extern void fastcall mutex_unlock(struct mutex *lock); Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - 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/
[PATCH] include/linux/mutex.h: unclear reference to convention
From: Matti Linnanvuori [EMAIL PROTECTED] Reference to two different conventions is unnecessarily unclear unless you know them already and requires seeking and reading another file for understanding. Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED] --- --- linux-2.6.23-rc7/include/linux/mutex.h2007-09-22 11:09:42.223763000 +0300 +++ linux-2.6.23/include/linux/mutex.h2007-09-22 11:11:19.416761000 +0300 @@ -132,9 +132,19 @@ extern int __must_check mutex_lock_inter # define mutex_lock_interruptible_nested(lock, subclass) mutex_lock_interruptible(lock) #endif -/* - * NOTE: mutex_trylock() follows the spin_trylock() convention, - * not the down_trylock() convention! +/*** + * mutex_trylock - try acquire the mutex, without waiting + * @lock: the mutex to be acquired + * + * Try to acquire the mutex atomically. Returns 1 if the mutex + * has been acquired successfully, and 0 on contention. + * + * NOTE: this function follows the spin_trylock() convention, so + * it is negated to the down_trylock() return values! Be careful + * about this when converting semaphore users to mutexes. + * + * This function must not be used in interrupt context. The + * mutex must be released by the same task that acquired it. */ extern int fastcall mutex_trylock(struct mutex *lock); extern void fastcall mutex_unlock(struct mutex *lock); Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - 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/
[PATCH] atomic_ops.txt has incorrect, misleading and insufficient information [Bug 9020]
From: Matti Linnanvuori <[EMAIL PROTECTED]>
atomic_ops.txt has incorrect, misleading and insufficient
information about semantics of initializer, atomic_set, atomic_read and
atomic_xchg.
It also incorrectly implies that operations mentioned above are not actual
atomic operations.
Included is most of the patch Document non-semantics of atomic_read() and
atomic_set() by Chris Snook,
except the word "assignment".
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc6/Documentation-atomic_ops.txt2007-09-14
23:49:20.126251500 +0300
+++ linux-2.6.23/Documentation-atomic_ops.txt2007-09-15 09:56:16.136312500
+0300
@@ -12,7 +12,11 @@ Also, it should be made opaque such that
C integer type will fail. Something like the following should
suffice:
-typedef struct { volatile int counter; } atomic_t;
+typedef struct { int counter; } atomic_t;
+
+Historically, counter has been declared volatile. This is now
+discouraged. See Documentation/volatile-considered-harmful.txt for the
+complete rationale.
The first operations to implement for atomic_t's are the
initializers and plain reads.
@@ -24,6 +28,13 @@ The first macro is used in definitions,
static atomic_t my_counter = ATOMIC_INIT(1);
+The initializer is atomic in that the return values of the atomic
+operations are guaranteed to be correct reflecting the initialized
+value if the initializer is used before runtime. If the initializer
+is used at runtime, a proper implicit or explicit read memory barrier
+is needed before reading the value with atomic_read from another
+thread.
+
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };
@@ -36,13 +47,45 @@ The second interface can be used at runt
return -ENOMEM;
atomic_set(>counter, 0);
+The setting is atomic in that the return values of the atomic
+operations by all threads are guaranteed to be correct reflecting
+either the value that has been set with this operation or set with
+another operation. A proper implicit or explicit memory barrier is
+needed before the value set with the operation is guaranteed to be
+readable with atomic_read from another thread.
+
Next, we have:
#define atomic_read(v)((v)->counter)
-which simply reads the current value of the counter.
+which simply reads the counter value currently visible to the calling
+thread. The read is atomic in that the return value is guaranteed to
+be one of the values initialized or modified with the interface
+operations if a proper implicit or explicit memory barrier is used
+after possible runtime initialization by any other thread and the
+value is modified only with the interface operations. atomic_read
+does not guarantee that the runtime initialization by any other
+thread is visible yet, so the user of the interface must take care of
+that with a proper implicit or explicit memory barrier.
+
+*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
+
+Some architectures may choose to use the volatile keyword, barriers, or
+inline assembly to guarantee some degree of immediacy for atomic_read()
+and atomic_set(). This is not uniformly guaranteed, and may change in
+the future, so all users of atomic_t should treat atomic_read() and
+atomic_set() as simple C statements that may be reordered or
+optimized away entirely by the compiler or processor, and explicitly
+invoke the appropriate compiler and/or memory barrier for each use case.
+Failure to do so will result in code that may suddenly break when used with
+different architectures or compiler optimizations, or even changes in
+unrelated code which changes how the compiler optimizes the section
+accessing atomic_t variables.
-Now, we move onto the actual atomic operation interfaces.
+*** YOU HAVE BEEN WARNED! ***
+
+Now, we move onto the atomic operation interfaces typically
+implemented with the help of assembly code.
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
@@ -117,6 +160,12 @@ operation.
Then:
+ int atomic_xchg(atomic_t *v, int new);
+
+This performs an atomic exchange operation on the atomic variable v,
+setting the given new value. It returns the old value that the atomic
+variable v had just before the operation.
+
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,
Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER
INTERNET-GURU! www.yahoo.de/clever
-
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/
[PATCH] atomic_ops.txt has incorrect, misleading and insufficient information [Bug 9020]
From: Matti Linnanvuori [EMAIL PROTECTED]
atomic_ops.txt has incorrect, misleading and insufficient
information about semantics of initializer, atomic_set, atomic_read and
atomic_xchg.
It also incorrectly implies that operations mentioned above are not actual
atomic operations.
Included is most of the patch Document non-semantics of atomic_read() and
atomic_set() by Chris Snook,
except the word assignment.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
--- linux-2.6.23-rc6/Documentation-atomic_ops.txt2007-09-14
23:49:20.126251500 +0300
+++ linux-2.6.23/Documentation-atomic_ops.txt2007-09-15 09:56:16.136312500
+0300
@@ -12,7 +12,11 @@ Also, it should be made opaque such that
C integer type will fail. Something like the following should
suffice:
-typedef struct { volatile int counter; } atomic_t;
+typedef struct { int counter; } atomic_t;
+
+Historically, counter has been declared volatile. This is now
+discouraged. See Documentation/volatile-considered-harmful.txt for the
+complete rationale.
The first operations to implement for atomic_t's are the
initializers and plain reads.
@@ -24,6 +28,13 @@ The first macro is used in definitions,
static atomic_t my_counter = ATOMIC_INIT(1);
+The initializer is atomic in that the return values of the atomic
+operations are guaranteed to be correct reflecting the initialized
+value if the initializer is used before runtime. If the initializer
+is used at runtime, a proper implicit or explicit read memory barrier
+is needed before reading the value with atomic_read from another
+thread.
+
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };
@@ -36,13 +47,45 @@ The second interface can be used at runt
return -ENOMEM;
atomic_set(k-counter, 0);
+The setting is atomic in that the return values of the atomic
+operations by all threads are guaranteed to be correct reflecting
+either the value that has been set with this operation or set with
+another operation. A proper implicit or explicit memory barrier is
+needed before the value set with the operation is guaranteed to be
+readable with atomic_read from another thread.
+
Next, we have:
#define atomic_read(v)((v)-counter)
-which simply reads the current value of the counter.
+which simply reads the counter value currently visible to the calling
+thread. The read is atomic in that the return value is guaranteed to
+be one of the values initialized or modified with the interface
+operations if a proper implicit or explicit memory barrier is used
+after possible runtime initialization by any other thread and the
+value is modified only with the interface operations. atomic_read
+does not guarantee that the runtime initialization by any other
+thread is visible yet, so the user of the interface must take care of
+that with a proper implicit or explicit memory barrier.
+
+*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
+
+Some architectures may choose to use the volatile keyword, barriers, or
+inline assembly to guarantee some degree of immediacy for atomic_read()
+and atomic_set(). This is not uniformly guaranteed, and may change in
+the future, so all users of atomic_t should treat atomic_read() and
+atomic_set() as simple C statements that may be reordered or
+optimized away entirely by the compiler or processor, and explicitly
+invoke the appropriate compiler and/or memory barrier for each use case.
+Failure to do so will result in code that may suddenly break when used with
+different architectures or compiler optimizations, or even changes in
+unrelated code which changes how the compiler optimizes the section
+accessing atomic_t variables.
-Now, we move onto the actual atomic operation interfaces.
+*** YOU HAVE BEEN WARNED! ***
+
+Now, we move onto the atomic operation interfaces typically
+implemented with the help of assembly code.
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
@@ -117,6 +160,12 @@ operation.
Then:
+ int atomic_xchg(atomic_t *v, int new);
+
+This performs an atomic exchange operation on the atomic variable v,
+setting the given new value. It returns the old value that the atomic
+variable v had just before the operation.
+
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,
Wissenswertes zum Thema PC, Zubehör oder Programme. BE A BETTER
INTERNET-GURU! www.yahoo.de/clever
-
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/
include/linux/mutex.h file is unclear about software interrupts and mutex_trylock
From: Matti Linnanvuori <[EMAIL PROTECTED]> include/linux/mutex.h file is unclear about software interrupts and the return value of mutex_trylock. Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> --- --- linux-2.6.23-rc6/include/linux/mutex.h2007-09-09 09:55:34.917468000 +0300 +++ linux-2.6.23/include/linux/mutex.h2007-09-15 11:49:28.353291500 +0300 @@ -29,7 +29,8 @@ * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers * * These semantics are fully enforced when DEBUG_MUTEXES is * enabled. Furthermore, besides enforcing the above rules, the mutex @@ -133,6 +134,7 @@ extern int __must_check mutex_lock_inter #endif /* + * mutex_trylock returns nonzero on success or 0 on failure to lock. * NOTE: mutex_trylock() follows the spin_trylock() convention, * not the down_trylock() convention! */ Die etwas anderen Infos rund um das Thema Reisen. BE A BETTER WELTENBUMMLER! www.yahoo.de/clever - 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/
[PATCH] [Bug 9020] atomic_ops.txt has incorrect, misleading and insufficient information
From: Matti Linnanvuori <[EMAIL PROTECTED]>
atomic_ops.txt has incorrect, misleading and insufficient
information about semantics of initializer, atomic_set, atomic_read and
atomic_xchg.
It also incorrectly implies that operations mentioned above are not actual
atomic operations.
Included is most of the patch Document non-semantics of atomic_read() and
atomic_set() by Chris Snook,
except the word "assignment".
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc6/Documentation-atomic_ops.txt2007-09-14
23:49:20.126251500 +0300
+++ linux-2.6.23/Documentation-atomic_ops.txt2007-09-15 09:56:16.136312500
+0300
@@ -12,7 +12,11 @@ Also, it should be made opaque such that
C integer type will fail. Something like the following should
suffice:
-typedef struct { volatile int counter; } atomic_t;
+typedef struct { int counter; } atomic_t;
+
+Historically, counter has been declared volatile. This is now
+discouraged. See Documentation/volatile-considered-harmful.txt for the
+complete rationale.
The first operations to implement for atomic_t's are the
initializers and plain reads.
@@ -24,6 +28,13 @@ The first macro is used in definitions,
static atomic_t my_counter = ATOMIC_INIT(1);
+The initializer is atomic in that the return values of the atomic
+operations are guaranteed to be correct reflecting the initialized
+value if the initializer is used before runtime. If the initializer
+is used at runtime, a proper implicit or explicit read memory barrier
+is needed before reading the value with atomic_read from another
+thread.
+
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };
@@ -36,13 +47,45 @@ The second interface can be used at runt
return -ENOMEM;
atomic_set(>counter, 0);
+The setting is atomic in that the return values of the atomic
+operations by all threads are guaranteed to be correct reflecting
+either the value before the setting or the value that has been set
+with this setting. A proper implicit or explicit memory barrier is
+needed before the value set with the operation is guaranteed to be
+readable with atomic_read from another thread.
+
Next, we have:
#define atomic_read(v)((v)->counter)
-which simply reads the current value of the counter.
+which simply reads the counter value currently visible to the calling
+thread. The read is atomic in that the return value is guaranteed to
+be one of the values initialized or modified with the interface
+operations if a proper implicit or explicit memory barrier is used
+after possible runtime initialization by any other thread and the
+value is modified only with the interface operations. atomic_read
+does not guarantee that the runtime initialization by any other
+thread is visible yet, so the user of the interface must take care of
+that with a proper implicit or explicit memory barrier.
+
+*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
+
+Some architectures may choose to use the volatile keyword, barriers, or
+inline assembly to guarantee some degree of immediacy for atomic_read()
+and atomic_set(). This is not uniformly guaranteed, and may change in
+the future, so all users of atomic_t should treat atomic_read() and
+atomic_set() as simple C statements that may be reordered or
+optimized away entirely by the compiler or processor, and explicitly
+invoke the appropriate compiler and/or memory barrier for each use case.
+Failure to do so will result in code that may suddenly break when used with
+different architectures or compiler optimizations, or even changes in
+unrelated code which changes how the compiler optimizes the section
+accessing atomic_t variables.
-Now, we move onto the actual atomic operation interfaces.
+*** YOU HAVE BEEN WARNED! ***
+
+Now, we move onto the atomic operation interfaces typically
+implemented with the help of assembly code.
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
@@ -117,6 +160,12 @@ operation.
Then:
+ int atomic_xchg(atomic_t *v, int new);
+
+This performs an atomic exchange operation on the atomic variable v,
+with the given new value. It returns the old value that the atomic
+variable v had just before the operation.
+
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
-
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/
[PATCH] [Bug 9020] atomic_ops.txt has incorrect, misleading and insufficient information
From: Matti Linnanvuori [EMAIL PROTECTED]
atomic_ops.txt has incorrect, misleading and insufficient
information about semantics of initializer, atomic_set, atomic_read and
atomic_xchg.
It also incorrectly implies that operations mentioned above are not actual
atomic operations.
Included is most of the patch Document non-semantics of atomic_read() and
atomic_set() by Chris Snook,
except the word assignment.
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
---
--- linux-2.6.23-rc6/Documentation-atomic_ops.txt2007-09-14
23:49:20.126251500 +0300
+++ linux-2.6.23/Documentation-atomic_ops.txt2007-09-15 09:56:16.136312500
+0300
@@ -12,7 +12,11 @@ Also, it should be made opaque such that
C integer type will fail. Something like the following should
suffice:
-typedef struct { volatile int counter; } atomic_t;
+typedef struct { int counter; } atomic_t;
+
+Historically, counter has been declared volatile. This is now
+discouraged. See Documentation/volatile-considered-harmful.txt for the
+complete rationale.
The first operations to implement for atomic_t's are the
initializers and plain reads.
@@ -24,6 +28,13 @@ The first macro is used in definitions,
static atomic_t my_counter = ATOMIC_INIT(1);
+The initializer is atomic in that the return values of the atomic
+operations are guaranteed to be correct reflecting the initialized
+value if the initializer is used before runtime. If the initializer
+is used at runtime, a proper implicit or explicit read memory barrier
+is needed before reading the value with atomic_read from another
+thread.
+
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };
@@ -36,13 +47,45 @@ The second interface can be used at runt
return -ENOMEM;
atomic_set(k-counter, 0);
+The setting is atomic in that the return values of the atomic
+operations by all threads are guaranteed to be correct reflecting
+either the value before the setting or the value that has been set
+with this setting. A proper implicit or explicit memory barrier is
+needed before the value set with the operation is guaranteed to be
+readable with atomic_read from another thread.
+
Next, we have:
#define atomic_read(v)((v)-counter)
-which simply reads the current value of the counter.
+which simply reads the counter value currently visible to the calling
+thread. The read is atomic in that the return value is guaranteed to
+be one of the values initialized or modified with the interface
+operations if a proper implicit or explicit memory barrier is used
+after possible runtime initialization by any other thread and the
+value is modified only with the interface operations. atomic_read
+does not guarantee that the runtime initialization by any other
+thread is visible yet, so the user of the interface must take care of
+that with a proper implicit or explicit memory barrier.
+
+*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! ***
+
+Some architectures may choose to use the volatile keyword, barriers, or
+inline assembly to guarantee some degree of immediacy for atomic_read()
+and atomic_set(). This is not uniformly guaranteed, and may change in
+the future, so all users of atomic_t should treat atomic_read() and
+atomic_set() as simple C statements that may be reordered or
+optimized away entirely by the compiler or processor, and explicitly
+invoke the appropriate compiler and/or memory barrier for each use case.
+Failure to do so will result in code that may suddenly break when used with
+different architectures or compiler optimizations, or even changes in
+unrelated code which changes how the compiler optimizes the section
+accessing atomic_t variables.
-Now, we move onto the actual atomic operation interfaces.
+*** YOU HAVE BEEN WARNED! ***
+
+Now, we move onto the atomic operation interfaces typically
+implemented with the help of assembly code.
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
@@ -117,6 +160,12 @@ operation.
Then:
+ int atomic_xchg(atomic_t *v, int new);
+
+This performs an atomic exchange operation on the atomic variable v,
+with the given new value. It returns the old value that the atomic
+variable v had just before the operation.
+
int atomic_cmpxchg(atomic_t *v, int old, int new);
This performs an atomic compare exchange operation on the atomic value v,
Machen Sie Yahoo! zu Ihrer Startseite. Los geht's:
http://de.yahoo.com/set
-
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/
include/linux/mutex.h file is unclear about software interrupts and mutex_trylock
From: Matti Linnanvuori [EMAIL PROTECTED] include/linux/mutex.h file is unclear about software interrupts and the return value of mutex_trylock. Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED] --- --- linux-2.6.23-rc6/include/linux/mutex.h2007-09-09 09:55:34.917468000 +0300 +++ linux-2.6.23/include/linux/mutex.h2007-09-15 11:49:28.353291500 +0300 @@ -29,7 +29,8 @@ * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers * * These semantics are fully enforced when DEBUG_MUTEXES is * enabled. Furthermore, besides enforcing the above rules, the mutex @@ -133,6 +134,7 @@ extern int __must_check mutex_lock_inter #endif /* + * mutex_trylock returns nonzero on success or 0 on failure to lock. * NOTE: mutex_trylock() follows the spin_trylock() convention, * not the down_trylock() convention! */ Die etwas anderen Infos rund um das Thema Reisen. BE A BETTER WELTENBUMMLER! www.yahoo.de/clever - 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/
Do not deprecate binary semaphore or do allow mutex in software interrupt contexts
The following code seems to me to be a valid example of a binary semaphore
(mutex) in a timer:
//timer called 10 times a second
static void status_timer(unsigned long device)
{
struct etp_device_private *dp = (struct etp_device_private *)device;
if (unlikely(dp->status_interface == 0))
dp->status_interface = INTERFACES_PER_DEVICE - 1;
else
dp->status_interface--;
//DBG_PRINT ("%s: In status timer, interface:0x%x.\n",etp_NAME,
dp->status_interface);
idt_los_interrupt_1(dp, dp->status_interface);
if (likely(!dp->reset))
// reset the timer:
mod_timer(>status_timer, jiffies + HZ / 10);
}
static inline void read_idt_register_interrupt(struct etp_device_private *dp,
unsigned reg)
{
DBG_PRINT("read_idt_register_interrupt to mutex_lock.\n");
if (unlikely(down_trylock(>semaphore)))
return;/* Do not read because failed to lock. */
if (likely
(!dp->status
&& !(inl((void *)(dp->ioaddr + REG_E1_CTRL)) & E1_ACCESS_ON))) {
outl(((reg << E1_REGISTER_SHIFT) & E1_REGISTER_MASK)
| E1_DIR_READ | E1_ACCESS_ON,
(void *)(dp->ioaddr + REG_E1_CTRL));
dp->status = 1;
DBG_PRINT("read_idt_register_interrupt set status read.\n");
} else
DBG_PRINT
("read_idt_register_interrupt did not set status %u read.\n",
dp->status);
DBG_PRINT
("read_idt_register_interrupt do not wait for result here, read in
tasklet.\n");
}
//for getting los information with interrupt:
void idt_los_interrupt_1(struct etp_device_private *dp, unsigned interface)
{
read_idt_register_if_interrupt(dp, E1_TRNCVR_LINE_STATUS0_REG,
interface);
}
static void e1_access_task(unsigned long data)//called after
e1_access_interrupt
{
struct etp_device_private *dp = (struct etp_device_private *)data;
struct etp_interface_private *ip;
unsigned int interface, error;
bool los;
//check if los status was read:
if (unlikely(!dp->status)) {
DBG_PRINT("e1_access_task wakes up user.\n");
wake_up(>e1_access_q);
return;
}
error =
idt_los_interrupt_2(dp->ioaddr, , ,
dp->pci_dev->device);
//DBG_PRINT ("%s: In e1 task, error:0x%x, interface:0x%x, los:0x%x.\n",
// etp_NAME, error, interface, los);
dp->status = 0;
up(>semaphore);
DBG_PRINT("e1_access_task got error %u.\n", error);
if (unlikely(error))
return;
//update los status:
ip = >interface_privates[interface];
ip->los = los;
//update status:
if ((ip->if_mode == IF_MODE_CLOSED) ||//interface closed or
(ip->los)) {//link down
set_led(LED_CTRL_OFF, ip);
if (netif_carrier_ok(ip->ch_priv.this_netdev))
netif_carrier_off(ip->ch_priv.this_netdev);
} else {//link up and interface opened
if (!netif_carrier_ok(ip->ch_priv.this_netdev))
netif_carrier_on(ip->ch_priv.this_netdev);
if (ip->if_mode == IF_MODE_HDLC) {
set_led(LED_CTRL_TRAFFIC, ip);
} else {//ip->if_mode == IF_MODE_TIMESLOT
set_led(LED_CTRL_ON, ip);
}
}
}
int idt_los_interrupt_2(u8 * ioaddr, unsigned *interface, bool * los,
unsigned pci_device_id)
{//returns 0 in success
unsigned int value = inl((void *)(ioaddr + REG_E1_CTRL));
//if access not ended:
if (value & E1_ACCESS_ON) {
return 1;
}
//if access not to los status register
if ((value & E1_REGISTER_MASK_NO_IF) !=
(E1_TRNCVR_LINE_STATUS0_REG << E1_REGISTER_SHIFT)) {
return 1;
}
//get interface
*interface =
idt_if_to_if((value & E1_REGISTER_MASK_IF) >>
E1_REGISTER_SHIFT_IF, pci_device_id);
*los = value & 0x1;
return 0;
}
int write_idt_register_lock(unsigned device, unsigned reg, u32 value)
{
struct etp_device_private *etp = get_dev_priv(device);
unsigned ctrl;
DBG_PRINT("write_idt_register_lock to mutex lock device %u.\n", device);
down(>semaphore);
if (unlikely(etp->reset)) {
up(>semaphore);
DBG_PRINT
("write_idt_register_lock device %u unusable.\n", device);
return -ENXIO;
}
DBG_PRINT("write_idt_register_lock mutex locked device %u.\n", device);
do {
DBG_PRINT
("write_idt_register_lock to wait_event_timeout device %u.\n",
device);
wait_event_timeout(etp->e1_access_q,
!((ctrl =
inl((void *)(etp->ioaddr + REG_E1_CTRL)))
& E1_ACCESS_ON), HZ / 500);
}
while (ctrl & E1_ACCESS_ON);
DBG_PRINT("write_idt_register_lock to outl device %u.\n", device);
outl(((reg << E1_REGISTER_SHIFT) & E1_REGISTER_MASK) |
E1_DIR_WRITE | E1_ACCESS_ON | (value & E1_DATA_MASK),
(void *)(etp->ioaddr +
Do not deprecate binary semaphore or do allow mutex in software interrupt contexts
Arjan van de Ven: > what do you do if the trylock fails? Just do not read the status variable now but modify the timer to run later. > to be honest, the scenario describe really smells of broken locking, in > fact it really sounds like it wants to use spinlocks instead No, I don't think it is broken. Spinlocks can be used, but I don't see them being obviously better in all cases. If access takes a long time, it is better to sleep during it. And if you sleep, you might just end up creating a new mutex implementation with a spinlock. Alan Cox: > For polling and timer based code its often simpler to do > >del_timer_sync(_timer); >FrobStuff >add_timer(_timer); > > especially if "FrobStuff" is likely to change when you next need to poll. In the scenario I presented, the timer modifies itself to run later. Therefore, simply calling del_timer_sync is not enough but you have to set an atomic variable to prevent the timer from adding itself again. Again, you end up creating a new mutex implementation, which is not good. __ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever - 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/
Do not deprecate binary semaphore or do allow mutex in software interrupt contexts
I thought of a scenario where it seems appropriate to use a binary semaphore or a mutex in a software interrupt context. If a device cannot interrupt when some important variable changes, it can be polled occasionally to update e.g. LEDs to indicate status. Such polling can be done most efficiently in timers that are software interrupts. Timers are more efficient than works because they do not have so much context switching overhead. If the access to the variables of the device must be serialized, a binary semaphore or a mutex is a natural choice. If user-space writing to the device is likely to change the status, it can make sense not to poll the status of the device at the same time. The timer could therefore sensibly call mutex_trylock. Therefore, it seems wrong to me to deprecate binary semaphores and disallow the use of mutexes in software interrupt contexts. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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/
Do not deprecate binary semaphore or do allow mutex in software interrupt contexts
I thought of a scenario where it seems appropriate to use a binary semaphore or a mutex in a software interrupt context. If a device cannot interrupt when some important variable changes, it can be polled occasionally to update e.g. LEDs to indicate status. Such polling can be done most efficiently in timers that are software interrupts. Timers are more efficient than works because they do not have so much context switching overhead. If the access to the variables of the device must be serialized, a binary semaphore or a mutex is a natural choice. If user-space writing to the device is likely to change the status, it can make sense not to poll the status of the device at the same time. The timer could therefore sensibly call mutex_trylock. Therefore, it seems wrong to me to deprecate binary semaphores and disallow the use of mutexes in software interrupt contexts. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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/
Do not deprecate binary semaphore or do allow mutex in software interrupt contexts
Arjan van de Ven: what do you do if the trylock fails? Just do not read the status variable now but modify the timer to run later. to be honest, the scenario describe really smells of broken locking, in fact it really sounds like it wants to use spinlocks instead No, I don't think it is broken. Spinlocks can be used, but I don't see them being obviously better in all cases. If access takes a long time, it is better to sleep during it. And if you sleep, you might just end up creating a new mutex implementation with a spinlock. Alan Cox: For polling and timer based code its often simpler to do del_timer_sync(my_timer); FrobStuff add_timer(my_timer); especially if FrobStuff is likely to change when you next need to poll. In the scenario I presented, the timer modifies itself to run later. Therefore, simply calling del_timer_sync is not enough but you have to set an atomic variable to prevent the timer from adding itself again. Again, you end up creating a new mutex implementation, which is not good. __ Yahoo! Clever - Der einfachste Weg, Fragen zu stellen und Wissenswertes mit Anderen zu teilen. www.yahoo.de/clever - 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/
Do not deprecate binary semaphore or do allow mutex in software interrupt contexts
The following code seems to me to be a valid example of a binary semaphore
(mutex) in a timer:
//timer called 10 times a second
static void status_timer(unsigned long device)
{
struct etp_device_private *dp = (struct etp_device_private *)device;
if (unlikely(dp-status_interface == 0))
dp-status_interface = INTERFACES_PER_DEVICE - 1;
else
dp-status_interface--;
//DBG_PRINT (%s: In status timer, interface:0x%x.\n,etp_NAME,
dp-status_interface);
idt_los_interrupt_1(dp, dp-status_interface);
if (likely(!dp-reset))
// reset the timer:
mod_timer(dp-status_timer, jiffies + HZ / 10);
}
static inline void read_idt_register_interrupt(struct etp_device_private *dp,
unsigned reg)
{
DBG_PRINT(read_idt_register_interrupt to mutex_lock.\n);
if (unlikely(down_trylock(dp-semaphore)))
return;/* Do not read because failed to lock. */
if (likely
(!dp-status
!(inl((void *)(dp-ioaddr + REG_E1_CTRL)) E1_ACCESS_ON))) {
outl(((reg E1_REGISTER_SHIFT) E1_REGISTER_MASK)
| E1_DIR_READ | E1_ACCESS_ON,
(void *)(dp-ioaddr + REG_E1_CTRL));
dp-status = 1;
DBG_PRINT(read_idt_register_interrupt set status read.\n);
} else
DBG_PRINT
(read_idt_register_interrupt did not set status %u read.\n,
dp-status);
DBG_PRINT
(read_idt_register_interrupt do not wait for result here, read in
tasklet.\n);
}
//for getting los information with interrupt:
void idt_los_interrupt_1(struct etp_device_private *dp, unsigned interface)
{
read_idt_register_if_interrupt(dp, E1_TRNCVR_LINE_STATUS0_REG,
interface);
}
static void e1_access_task(unsigned long data)//called after
e1_access_interrupt
{
struct etp_device_private *dp = (struct etp_device_private *)data;
struct etp_interface_private *ip;
unsigned int interface, error;
bool los;
//check if los status was read:
if (unlikely(!dp-status)) {
DBG_PRINT(e1_access_task wakes up user.\n);
wake_up(dp-e1_access_q);
return;
}
error =
idt_los_interrupt_2(dp-ioaddr, interface, los,
dp-pci_dev-device);
//DBG_PRINT (%s: In e1 task, error:0x%x, interface:0x%x, los:0x%x.\n,
// etp_NAME, error, interface, los);
dp-status = 0;
up(dp-semaphore);
DBG_PRINT(e1_access_task got error %u.\n, error);
if (unlikely(error))
return;
//update los status:
ip = dp-interface_privates[interface];
ip-los = los;
//update status:
if ((ip-if_mode == IF_MODE_CLOSED) ||//interface closed or
(ip-los)) {//link down
set_led(LED_CTRL_OFF, ip);
if (netif_carrier_ok(ip-ch_priv.this_netdev))
netif_carrier_off(ip-ch_priv.this_netdev);
} else {//link up and interface opened
if (!netif_carrier_ok(ip-ch_priv.this_netdev))
netif_carrier_on(ip-ch_priv.this_netdev);
if (ip-if_mode == IF_MODE_HDLC) {
set_led(LED_CTRL_TRAFFIC, ip);
} else {//ip-if_mode == IF_MODE_TIMESLOT
set_led(LED_CTRL_ON, ip);
}
}
}
int idt_los_interrupt_2(u8 * ioaddr, unsigned *interface, bool * los,
unsigned pci_device_id)
{//returns 0 in success
unsigned int value = inl((void *)(ioaddr + REG_E1_CTRL));
//if access not ended:
if (value E1_ACCESS_ON) {
return 1;
}
//if access not to los status register
if ((value E1_REGISTER_MASK_NO_IF) !=
(E1_TRNCVR_LINE_STATUS0_REG E1_REGISTER_SHIFT)) {
return 1;
}
//get interface
*interface =
idt_if_to_if((value E1_REGISTER_MASK_IF)
E1_REGISTER_SHIFT_IF, pci_device_id);
*los = value 0x1;
return 0;
}
int write_idt_register_lock(unsigned device, unsigned reg, u32 value)
{
struct etp_device_private *etp = get_dev_priv(device);
unsigned ctrl;
DBG_PRINT(write_idt_register_lock to mutex lock device %u.\n, device);
down(etp-semaphore);
if (unlikely(etp-reset)) {
up(etp-semaphore);
DBG_PRINT
(write_idt_register_lock device %u unusable.\n, device);
return -ENXIO;
}
DBG_PRINT(write_idt_register_lock mutex locked device %u.\n, device);
do {
DBG_PRINT
(write_idt_register_lock to wait_event_timeout device %u.\n,
device);
wait_event_timeout(etp-e1_access_q,
!((ctrl =
inl((void *)(etp-ioaddr + REG_E1_CTRL)))
E1_ACCESS_ON), HZ / 500);
}
while (ctrl E1_ACCESS_ON);
DBG_PRINT(write_idt_register_lock to outl device %u.\n, device);
outl(((reg E1_REGISTER_SHIFT) E1_REGISTER_MASK) |
E1_DIR_WRITE | E1_ACCESS_ON | (value E1_DATA_MASK),
(void *)(etp-ioaddr + REG_E1_CTRL));
up(etp-semaphore);
[PATCH] [Bug 8998] Mutex documentation is unclear about software interrupts, tasklets and timers in Linux 2.6.23-rc
diff -uprN linux-2.6.23/Documentation/mutex-design.txt linux-2.6.23-patched/Documentation/mutex-design.txt --- linux-2.6.23/Documentation/mutex-design.txt2007-09-09 21:47:10.545275000 +0300 +++ linux-2.6.23-patched/Documentation/mutex-design.txt2007-09-09 21:48:17.935493000 +0300 @@ -90,7 +90,8 @@ of advantages of mutexes: * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers furthermore, there are also convenience features in the debugging code: diff -uprN linux-2.6.23/include/linux/mutex.h linux-2.6.23-patched/include/linux/mutex.h --- linux-2.6.23/include/linux/mutex.h2007-09-09 21:49:04.531143500 +0300 +++ linux-2.6.23-patched/include/linux/mutex.h2007-09-09 21:49:44.946525500 +0300 @@ -29,7 +29,8 @@ * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers * * These semantics are fully enforced when DEBUG_MUTEXES is * enabled. Furthermore, besides enforcing the above rules, the mutex Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]> __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - 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/
[PATCH] [Bug 8998] Mutex documentation is unclear about software interrupts, tasklets and timers in Linux 2.6.23-rc
diff -uprN linux-2.6.23/Documentation/mutex-design.txt linux-2.6.23-patched/Documentation/mutex-design.txt --- linux-2.6.23/Documentation/mutex-design.txt2007-09-09 21:47:10.545275000 +0300 +++ linux-2.6.23-patched/Documentation/mutex-design.txt2007-09-09 21:48:17.935493000 +0300 @@ -90,7 +90,8 @@ of advantages of mutexes: * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers furthermore, there are also convenience features in the debugging code: diff -uprN linux-2.6.23/include/linux/mutex.h linux-2.6.23-patched/include/linux/mutex.h --- linux-2.6.23/include/linux/mutex.h2007-09-09 21:49:04.531143500 +0300 +++ linux-2.6.23-patched/include/linux/mutex.h2007-09-09 21:49:44.946525500 +0300 @@ -29,7 +29,8 @@ * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized - * - mutexes may not be used in irq contexts + * - mutexes may not be used in hardware or software interrupt + * contexts such as tasklets and timers * * These semantics are fully enforced when DEBUG_MUTEXES is * enabled. Furthermore, besides enforcing the above rules, the mutex Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED] __ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever - 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/
[PATCH] [Bugme-new] [Bug 8957] New: Exported functions and variables
This is a kernel/module.c
Linux 2.6.23-rc5 documentation patch that adds more explanation and corrects a
spelling error.
--- kernel/module.c 2007-09-01 14:15:06.131101500 +0300
+++ patched-kernel/module.c 2007-09-01 14:15:27.502780500 +0300
@@ -80,7 +80,8 @@ int unregister_module_notifier(struct no
}
EXPORT_SYMBOL(unregister_module_notifier);
-/* We require a truly strong try_module_get() */
+/* We require a truly strong try_module_get(): 0 means failure due to
+ ongoing or failed initialization etc. */
static inline int strong_try_module_get(struct module *mod)
{
if (mod && mod->state == MODULE_STATE_COMING)
@@ -957,7 +958,8 @@ static unsigned long resolve_symbol(Elf_
ret = __find_symbol(name, , ,
!(mod->taints & TAINT_PROPRIETARY_MODULE));
if (ret) {
-/* use_module can fail due to OOM, or module unloading */
+/* use_module can fail due to OOM, or module
+ initialization or unloading */
if (!check_version(sechdrs, versindex, name, mod, crc) ||
!use_module(mod, owner))
ret = 0;
@@ -1270,7 +1272,7 @@ dup:
return ret;
}
-/* Change all symbols so that sh_value encodes the pointer directly. */
+/* Change all symbols so that st_value encodes the pointer directly. */
static int simplify_symbols(Elf_Shdr *sechdrs,
unsigned int symindex,
const char *strtab,
Signed-off-by: Matti Linnanvuori <[EMAIL PROTECTED]>
Wissenswertes für Bastler und Hobby Handwerker. BE A BETTER HEIMWERKER!
www.yahoo.de/clever
-
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/
[PATCH] [Bugme-new] [Bug 8957] New: Exported functions and variables
This is a kernel/module.c
Linux 2.6.23-rc5 documentation patch that adds more explanation and corrects a
spelling error.
--- kernel/module.c 2007-09-01 14:15:06.131101500 +0300
+++ patched-kernel/module.c 2007-09-01 14:15:27.502780500 +0300
@@ -80,7 +80,8 @@ int unregister_module_notifier(struct no
}
EXPORT_SYMBOL(unregister_module_notifier);
-/* We require a truly strong try_module_get() */
+/* We require a truly strong try_module_get(): 0 means failure due to
+ ongoing or failed initialization etc. */
static inline int strong_try_module_get(struct module *mod)
{
if (mod mod-state == MODULE_STATE_COMING)
@@ -957,7 +958,8 @@ static unsigned long resolve_symbol(Elf_
ret = __find_symbol(name, owner, crc,
!(mod-taints TAINT_PROPRIETARY_MODULE));
if (ret) {
-/* use_module can fail due to OOM, or module unloading */
+/* use_module can fail due to OOM, or module
+ initialization or unloading */
if (!check_version(sechdrs, versindex, name, mod, crc) ||
!use_module(mod, owner))
ret = 0;
@@ -1270,7 +1272,7 @@ dup:
return ret;
}
-/* Change all symbols so that sh_value encodes the pointer directly. */
+/* Change all symbols so that st_value encodes the pointer directly. */
static int simplify_symbols(Elf_Shdr *sechdrs,
unsigned int symindex,
const char *strtab,
Signed-off-by: Matti Linnanvuori [EMAIL PROTECTED]
Wissenswertes für Bastler und Hobby Handwerker. BE A BETTER HEIMWERKER!
www.yahoo.de/clever
-
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/
[Bugme-new] [Bug 8957] New: Exported functions and variables
It seems to me that kernel/module.c allows the whole kernel to use exported symbols during the execution of the init function if they are weak: /* Ok if weak. */ if (ELF_ST_BIND(sym[i].st_info) == STB_WEAK) break; That seems a possible way to produce the scenario of this so-called bug. Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - 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/
[Bugme-new] [Bug 8957] New: Exported functions and variables
It seems to me that kernel/module.c allows the whole kernel to use exported symbols during the execution of the init function if they are weak: /* Ok if weak. */ if (ELF_ST_BIND(sym[i].st_info) == STB_WEAK) break; That seems a possible way to produce the scenario of this so-called bug. Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - 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/
[Bugme-new] [Bug 8957] New: Exported functions and variables
I thought I had seen that bug. Module init function execution does not seem serialized enough, so the init function of one module seems to be able to be called in parallel with several other modules in turn being loaded, executing their init functions and even becoming live first class citizens. Function sys_init_module in Linux 2.6.22.x and 2.6.23-rc4 kernel/module.c does not hold module_mutex when executing the init functions of the modules. __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - 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/
[Bugme-new] [Bug 8957] New: Exported functions and variables
I thought that the bug might happen when two kernel modules are being loaded. If module A is loaded and its code includes references to functions exported by module B, I thought module A could call those functions before the module_init function of module B has finished. I was not thinking about buggy calls to registering interface functions. I just thought that the kernel should not allow symbols exported by EXPORT_SYMBOLto be visible to other modules before the module_init function is finished. One could code the exported functions so that they could be safely called by anyone while the module_init function is being called but that would be an unnecessary burden for coders. I think that a module should expose its functions and variables only by calling registering interface functions before the module_init function is finished. So I think the design of the kernel modules is flawed if it allows anyone to call exported functions before the module_init function is finished. Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail - 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/
[Bugme-new] [Bug 8957] New: Exported functions and variables
I thought that the bug might happen when two kernel modules are being loaded. If module A is loaded and its code includes references to functions exported by module B, I thought module A could call those functions before the module_init function of module B has finished. I was not thinking about buggy calls to registering interface functions. I just thought that the kernel should not allow symbols exported by EXPORT_SYMBOLto be visible to other modules before the module_init function is finished. One could code the exported functions so that they could be safely called by anyone while the module_init function is being called but that would be an unnecessary burden for coders. I think that a module should expose its functions and variables only by calling registering interface functions before the module_init function is finished. So I think the design of the kernel modules is flawed if it allows anyone to call exported functions before the module_init function is finished. Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail - 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/
[Bugme-new] [Bug 8957] New: Exported functions and variables
I thought I had seen that bug. Module init function execution does not seem serialized enough, so the init function of one module seems to be able to be called in parallel with several other modules in turn being loaded, executing their init functions and even becoming live first class citizens. Function sys_init_module in Linux 2.6.22.x and 2.6.23-rc4 kernel/module.c does not hold module_mutex when executing the init functions of the modules. __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/clever - 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/
