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 st
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
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
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
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.
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.
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.607
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
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
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
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.1448
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
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
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
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
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
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/i
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
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.
In
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
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.9174
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.
In
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
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
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))
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
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
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
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
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))
+ * - 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 PROTEC
+ * - 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
t 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]>
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
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)
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)
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
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
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
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
40 matches
Mail list logo
