Re: [PATCH] introduce generic 64bit rotations and i386 asm optimized version
On Tuesday 19 April 2005 09:46, YOSHIFUJI Hideaki wrote:
> Please keep using __inline__, not inline.
Updated patch follows.
--
vda
diff -urpN 2.6.12-rc2.1.be/include/asm-i386/bitops.h 2.6.12-rc2.2.ror/include/asm-i386/bitops.h
--- 2.6.12-rc2.1.be/include/asm-i386/bitops.h Tue Oct 19 00:54:36 2004
+++ 2.6.12-rc2.2.ror/include/asm-i386/bitops.h Tue Apr 19 09:48:34 2005
@@ -7,6 +7,7 @@
#include
#include
+#include
/*
* These have to be done with inline assembly: that way the bit-setting
@@ -39,7 +40,7 @@
* Note that @nr may be almost arbitrarily large; this function is not
* restricted to acting on a single-word quantity.
*/
-static inline void set_bit(int nr, volatile unsigned long * addr)
+static __inline__ void set_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btsl %1,%0"
@@ -56,7 +57,7 @@ static inline void set_bit(int nr, volat
* If it's called on the same region of memory simultaneously, the effect
* may be that only one operation succeeds.
*/
-static inline void __set_bit(int nr, volatile unsigned long * addr)
+static __inline__ void __set_bit(int nr, volatile unsigned long * addr)
{
__asm__(
"btsl %1,%0"
@@ -74,7 +75,7 @@ static inline void __set_bit(int nr, vol
* you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()
* in order to ensure changes are visible on other processors.
*/
-static inline void clear_bit(int nr, volatile unsigned long * addr)
+static __inline__ void clear_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btrl %1,%0"
@@ -82,7 +83,7 @@ static inline void clear_bit(int nr, vol
:"Ir" (nr));
}
-static inline void __clear_bit(int nr, volatile unsigned long * addr)
+static __inline__ void __clear_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__(
"btrl %1,%0"
@@ -101,7 +102,7 @@ static inline void __clear_bit(int nr, v
* If it's called on the same region of memory simultaneously, the effect
* may be that only one operation succeeds.
*/
-static inline void __change_bit(int nr, volatile unsigned long * addr)
+static __inline__ void __change_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__(
"btcl %1,%0"
@@ -119,7 +120,7 @@ static inline void __change_bit(int nr,
* Note that @nr may be almost arbitrarily large; this function is not
* restricted to acting on a single-word quantity.
*/
-static inline void change_bit(int nr, volatile unsigned long * addr)
+static __inline__ void change_bit(int nr, volatile unsigned long * addr)
{
__asm__ __volatile__( LOCK_PREFIX
"btcl %1,%0"
@@ -136,7 +137,7 @@ static inline void change_bit(int nr, vo
* It may be reordered on other architectures than x86.
* It also implies a memory barrier.
*/
-static inline int test_and_set_bit(int nr, volatile unsigned long * addr)
+static __inline__ int test_and_set_bit(int nr, volatile unsigned long * addr)
{
int oldbit;
@@ -156,7 +157,7 @@ static inline int test_and_set_bit(int n
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static inline int __test_and_set_bit(int nr, volatile unsigned long * addr)
+static __inline__ int __test_and_set_bit(int nr, volatile unsigned long * addr)
{
int oldbit;
@@ -176,7 +177,7 @@ static inline int __test_and_set_bit(int
* It can be reorderdered on other architectures other than x86.
* It also implies a memory barrier.
*/
-static inline int test_and_clear_bit(int nr, volatile unsigned long * addr)
+static __inline__ int test_and_clear_bit(int nr, volatile unsigned long * addr)
{
int oldbit;
@@ -196,7 +197,7 @@ static inline int test_and_clear_bit(int
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr)
+static __inline__ int __test_and_clear_bit(int nr, volatile unsigned long *addr)
{
int oldbit;
@@ -208,7 +209,7 @@ static inline int __test_and_clear_bit(i
}
/* WARNING: non atomic and it can be reordered! */
-static inline int __test_and_change_bit(int nr, volatile unsigned long *addr)
+static __inline__ int __test_and_change_bit(int nr, volatile unsigned long *addr)
{
int oldbit;
@@ -227,7 +228,7 @@ static inline int __test_and_change_bit(
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static inline int test_and_change_bit(int nr, volatile unsigned long* addr)
+static __inline__ int test_and_change_bit(int nr, volatile unsigned long* addr)
{
int oldbit;
@@ -247,12 +248,12 @@ static inline int test_and_change_bit(in
static int test_bit(int nr, const volatile void * addr);
#endif
-static inline int constant_test_bit(int nr, const volatile unsigned long *addr)
+static __inline__ int constant_test_bit(int nr, const volati
Re: [PATCH] introduce generic 64bit rotations and i386 asm optimized version
In article <[EMAIL PROTECTED]> (at Tue, 19 Apr 2005 09:18:10 +0300), Denis
Vlasenko <[EMAIL PROTECTED]> says:
> diff -urpN 2.6.12-rc2.1.be/include/linux/bitops.h
> 2.6.12-rc2.2.ror/include/linux/bitops.h
> --- 2.6.12-rc2.1.be/include/linux/bitops.hMon Apr 18 22:55:10 2005
> +++ 2.6.12-rc2.2.ror/include/linux/bitops.h Tue Apr 19 00:25:28 2005
> @@ -41,7 +41,7 @@ static inline int generic_ffs(int x)
> * fls: find last bit set.
> */
>
> -static __inline__ int generic_fls(int x)
> +static inline int generic_fls(int x)
> {
> int r = 32;
>
> @@ -76,7 +76,7 @@ static __inline__ int generic_fls(int x)
> */
> #include
>
> -static __inline__ int get_bitmask_order(unsigned int count)
> +static inline int get_bitmask_order(unsigned int count)
> {
> int order;
>
Please keep using __inline__, not inline.
> +#ifndef ARCH_HAS_ROL64
> +static inline __u64 rol64(__u64 word, unsigned int shift)
> +{
> + return (word << shift) | (word >> (64 - shift));
> +}
> +#endif
:
> +#ifndef ARCH_HAS_ROR64
> +static inline __u64 ror64(__u64 word, unsigned int shift)
> +{
> + return (word >> shift) | (word << (64 - shift));
> +}
> +#endif
>
> #endif
please use __inline__, in header files.
--
Hideaki YOSHIFUJI @ USAGI Project <[EMAIL PROTECTED]>
Homepage: http://www.yoshifuji.org/~hideaki/
GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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] ia64: use 64bit rotations
Remove local 64bit rotation function, use generic one.
Patch is untested.
I believe there is no more 64bit rotations in the kernel.
--
vda
diff -urpN 2.6.12-rc2.3.ws/arch/ia64/kernel/ptrace.c 2.6.12-rc2.4.ia64/arch/ia64/kernel/ptrace.c
--- 2.6.12-rc2.3.ws/arch/ia64/kernel/ptrace.c Mon Apr 18 22:54:38 2005
+++ 2.6.12-rc2.4.ia64/arch/ia64/kernel/ptrace.c Tue Apr 19 00:44:30 2005
@@ -80,7 +80,7 @@ ia64_get_scratch_nat_bits (struct pt_reg
dist = 64 + bit - first; \
else \
dist = bit - first;\
- ia64_rotr(unat, dist) & mask;\
+ ror64(unat, dist) & mask;\
})
unsigned long val;
@@ -119,7 +119,7 @@ ia64_put_scratch_nat_bits (struct pt_reg
dist = 64 + bit - first; \
else \
dist = bit - first;\
- ia64_rotl(nat & mask, dist);\
+ rol64(nat & mask, dist);\
})
unsigned long scratch_unat;
diff -urpN 2.6.12-rc2.3.ws/include/asm-ia64/processor.h 2.6.12-rc2.4.ia64/include/asm-ia64/processor.h
--- 2.6.12-rc2.3.ws/include/asm-ia64/processor.h Thu Feb 3 11:40:06 2005
+++ 2.6.12-rc2.4.ia64/include/asm-ia64/processor.h Tue Apr 19 00:43:30 2005
@@ -652,14 +652,6 @@ ia64_get_dbr (__u64 regnum)
return retval;
}
-static inline __u64
-ia64_rotr (__u64 w, __u64 n)
-{
- return (w >> n) | (w << (64 - n));
-}
-
-#define ia64_rotl(w,n) ia64_rotr((w), (64) - (n))
-
/*
* Take a mapped kernel address and return the equivalent address
* in the region 7 identity mapped virtual area.
[PATCH] sha512: fix whitespace
While we're at it, fix inconsistent tab/space usage.
No code changes.
--
vda
diff -urpN 2.6.12-rc2.2.ror/crypto/sha512.c 2.6.12-rc2.3.ws/crypto/sha512.c
--- 2.6.12-rc2.2.ror/crypto/sha512.c Mon Apr 18 23:37:20 2005
+++ 2.6.12-rc2.3.ws/crypto/sha512.c Mon Apr 18 23:48:18 2005
@@ -35,42 +35,42 @@ struct sha512_ctx {
static inline u64 Ch(u64 x, u64 y, u64 z)
{
-return z ^ (x & (y ^ z));
+ return z ^ (x & (y ^ z));
}
static inline u64 Maj(u64 x, u64 y, u64 z)
{
-return (x & y) | (z & (x | y));
+ return (x & y) | (z & (x | y));
}
static const u64 sha512_K[80] = {
-0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL, 0xb5c0fbcfec4d3b2fULL,
-0xe9b5dba58189dbbcULL, 0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
-0x923f82a4af194f9bULL, 0xab1c5ed5da6d8118ULL, 0xd807aa98a3030242ULL,
-0x12835b0145706fbeULL, 0x243185be4ee4b28cULL, 0x550c7dc3d5ffb4e2ULL,
-0x72be5d74f27b896fULL, 0x80deb1fe3b1696b1ULL, 0x9bdc06a725c71235ULL,
-0xc19bf174cf692694ULL, 0xe49b69c19ef14ad2ULL, 0xefbe4786384f25e3ULL,
-0x0fc19dc68b8cd5b5ULL, 0x240ca1cc77ac9c65ULL, 0x2de92c6f592b0275ULL,
-0x4a7484aa6ea6e483ULL, 0x5cb0a9dcbd41fbd4ULL, 0x76f988da831153b5ULL,
-0x983e5152ee66dfabULL, 0xa831c66d2db43210ULL, 0xb00327c898fb213fULL,
-0xbf597fc7beef0ee4ULL, 0xc6e00bf33da88fc2ULL, 0xd5a79147930aa725ULL,
-0x06ca6351e003826fULL, 0x142929670a0e6e70ULL, 0x27b70a8546d22ffcULL,
-0x2e1b21385c26c926ULL, 0x4d2c6dfc5ac42aedULL, 0x53380d139d95b3dfULL,
-0x650a73548baf63deULL, 0x766a0abb3c77b2a8ULL, 0x81c2c92e47edaee6ULL,
-0x92722c851482353bULL, 0xa2bfe8a14cf10364ULL, 0xa81a664bbc423001ULL,
-0xc24b8b70d0f89791ULL, 0xc76c51a30654be30ULL, 0xd192e819d6ef5218ULL,
-0xd69906245565a910ULL, 0xf40e35855771202aULL, 0x106aa07032bbd1b8ULL,
-0x19a4c116b8d2d0c8ULL, 0x1e376c085141ab53ULL, 0x2748774cdf8eeb99ULL,
-0x34b0bcb5e19b48a8ULL, 0x391c0cb3c5c95a63ULL, 0x4ed8aa4ae3418acbULL,
-0x5b9cca4f7763e373ULL, 0x682e6ff3d6b2b8a3ULL, 0x748f82ee5defb2fcULL,
-0x78a5636f43172f60ULL, 0x84c87814a1f0ab72ULL, 0x8cc702081a6439ecULL,
-0x90befffa23631e28ULL, 0xa4506cebde82bde9ULL, 0xbef9a3f7b2c67915ULL,
-0xc67178f2e372532bULL, 0xca273eceea26619cULL, 0xd186b8c721c0c207ULL,
-0xeada7dd6cde0eb1eULL, 0xf57d4f7fee6ed178ULL, 0x06f067aa72176fbaULL,
-0x0a637dc5a2c898a6ULL, 0x113f9804bef90daeULL, 0x1b710b35131c471bULL,
-0x28db77f523047d84ULL, 0x32caab7b40c72493ULL, 0x3c9ebe0a15c9bebcULL,
-0x431d67c49c100d4cULL, 0x4cc5d4becb3e42b6ULL, 0x597f299cfc657e2aULL,
-0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
+ 0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL, 0xb5c0fbcfec4d3b2fULL,
+ 0xe9b5dba58189dbbcULL, 0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
+ 0x923f82a4af194f9bULL, 0xab1c5ed5da6d8118ULL, 0xd807aa98a3030242ULL,
+ 0x12835b0145706fbeULL, 0x243185be4ee4b28cULL, 0x550c7dc3d5ffb4e2ULL,
+ 0x72be5d74f27b896fULL, 0x80deb1fe3b1696b1ULL, 0x9bdc06a725c71235ULL,
+ 0xc19bf174cf692694ULL, 0xe49b69c19ef14ad2ULL, 0xefbe4786384f25e3ULL,
+ 0x0fc19dc68b8cd5b5ULL, 0x240ca1cc77ac9c65ULL, 0x2de92c6f592b0275ULL,
+ 0x4a7484aa6ea6e483ULL, 0x5cb0a9dcbd41fbd4ULL, 0x76f988da831153b5ULL,
+ 0x983e5152ee66dfabULL, 0xa831c66d2db43210ULL, 0xb00327c898fb213fULL,
+ 0xbf597fc7beef0ee4ULL, 0xc6e00bf33da88fc2ULL, 0xd5a79147930aa725ULL,
+ 0x06ca6351e003826fULL, 0x142929670a0e6e70ULL, 0x27b70a8546d22ffcULL,
+ 0x2e1b21385c26c926ULL, 0x4d2c6dfc5ac42aedULL, 0x53380d139d95b3dfULL,
+ 0x650a73548baf63deULL, 0x766a0abb3c77b2a8ULL, 0x81c2c92e47edaee6ULL,
+ 0x92722c851482353bULL, 0xa2bfe8a14cf10364ULL, 0xa81a664bbc423001ULL,
+ 0xc24b8b70d0f89791ULL, 0xc76c51a30654be30ULL, 0xd192e819d6ef5218ULL,
+ 0xd69906245565a910ULL, 0xf40e35855771202aULL, 0x106aa07032bbd1b8ULL,
+ 0x19a4c116b8d2d0c8ULL, 0x1e376c085141ab53ULL, 0x2748774cdf8eeb99ULL,
+ 0x34b0bcb5e19b48a8ULL, 0x391c0cb3c5c95a63ULL, 0x4ed8aa4ae3418acbULL,
+ 0x5b9cca4f7763e373ULL, 0x682e6ff3d6b2b8a3ULL, 0x748f82ee5defb2fcULL,
+ 0x78a5636f43172f60ULL, 0x84c87814a1f0ab72ULL, 0x8cc702081a6439ecULL,
+ 0x90befffa23631e28ULL, 0xa4506cebde82bde9ULL, 0xbef9a3f7b2c67915ULL,
+ 0xc67178f2e372532bULL, 0xca273eceea26619cULL, 0xd186b8c721c0c207ULL,
+ 0xeada7dd6cde0eb1eULL, 0xf57d4f7fee6ed178ULL, 0x06f067aa72176fbaULL,
+ 0x0a637dc5a2c898a6ULL, 0x113f9804bef90daeULL, 0x1b710b35131c471bULL,
+ 0x28db77f523047d84ULL, 0x32caab7b40c72493ULL, 0x3c9ebe0a15c9bebcULL,
+ 0x431d67c49c100d4cULL, 0x4cc5d4becb3e42b6ULL, 0x597f299cfc657e2aULL,
+ 0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
};
#define e0(x) (ror64(x,28) ^ ror64(x,34) ^ ror64(x,39))
@@ -116,16 +116,16 @@ sha512_transform(u64 *state, u64 *W, con
int i;
/* load the input */
-for (i = 0; i < 16; i++)
-LOAD_OP(i, W, input);
+ for (i = 0; i < 16; i++)
+ LOAD_OP(i, W, input);
-for (i = 16; i < 80; i++)
-BLEND_OP(i, W);
+ for (i = 16; i < 80; i++)
+ BLEND_OP(i, W);
/* load the sta
[PATCH] sha512: use 64bit rotations
this results in following code size changes on i386:
# size sha512_org.o sha512_be.o sha512_ror.o
textdata bss dec hex filename
5339 364 057031647 sha512_org.o
5221 364 0558515d1 sha512_be.o
5122 364 05486156e sha512_ror.o
modprobe tcrypt:
testing sha384
test 1:
cb00753f45a35e8bb5a03d699ac65007272c32ab0eded1631a8b605a43ff5bed8086072ba1e7cc2358baeca134c825a7
pass
test 2:
3391fdddfc8dc7393707a65b1b4709397cf8b1d162af05abfe8f450de5f36bc6b0455a8520bc4e6f5fe95b1fe3c8452b
pass
test 3:
09330c33f71147e83d192fc782cd1b4753111b173b3b05d22fa08086e3b0f712fcc7c71a557e2db966c3e9fa91746039
pass
test 4:
3d208973ab3508dbbd7e2c2862ba290ad3010e4978c198dc4d8fd014e582823a89e16f9b2a7bbc1ac938e2d199e8bea4
pass
testing sha384 across pages
test 1:
3d208973ab3508dbbd7e2c2862ba290ad3010e4978c198dc4d8fd014e582823a89e16f9b2a7bbc1ac938e2d199e8bea4
pass
testing sha512
test 1:
ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a964b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f
pass
test 2:
204a8fc6dda82f0a0ced7beb8e08a41657c16ef468b228a8279be331a703c33596fd15c13b1b07f9aa1d3bea57789ca031ad85c7a71dd70354ec631238ca3445
pass
test 3:
8e959b75dae313da8cf4f72814fc143f8f7779c6eb9f7fa17299aeadb6889018501d289e4900f7e4331b99dec4b5433ac7d329eeb6dd26545e96e55b874be909
pass
test 4:
930d0cefcb30ff1133b6898121f1cf3d27578afcafe8677c5257cf069911f75d8f5831b56ebfda67b278e66dff8b84fe2b2870f742a580d8edb41987232850c9
pass
testing sha512 across pages
test 1:
930d0cefcb30ff1133b6898121f1cf3d27578afcafe8677c5257cf069911f75d8f5831b56ebfda67b278e66dff8b84fe2b2870f742a580d8edb41987232850c9
pass
--
vda
diff -urpN 2.6.12-rc2.1.be/crypto/sha512.c 2.6.12-rc2.2.ror/crypto/sha512.c
--- 2.6.12-rc2.1.be/crypto/sha512.c Mon Apr 18 23:31:54 2005
+++ 2.6.12-rc2.2.ror/crypto/sha512.c Mon Apr 18 23:37:20 2005
@@ -43,11 +43,6 @@ static inline u64 Maj(u64 x, u64 y, u64
return (x & y) | (z & (x | y));
}
-static inline u64 RORu64(u64 x, u64 y)
-{
-return (x >> y) | (x << (64 - y));
-}
-
static const u64 sha512_K[80] = {
0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL, 0xb5c0fbcfec4d3b2fULL,
0xe9b5dba58189dbbcULL, 0x3956c25bf348b538ULL, 0x59f111f1b605d019ULL,
@@ -78,10 +73,10 @@ static const u64 sha512_K[80] = {
0x5fcb6fab3ad6faecULL, 0x6c44198c4a475817ULL,
};
-#define e0(x) (RORu64(x,28) ^ RORu64(x,34) ^ RORu64(x,39))
-#define e1(x) (RORu64(x,14) ^ RORu64(x,18) ^ RORu64(x,41))
-#define s0(x) (RORu64(x, 1) ^ RORu64(x, 8) ^ (x >> 7))
-#define s1(x) (RORu64(x,19) ^ RORu64(x,61) ^ (x >> 6))
+#define e0(x) (ror64(x,28) ^ ror64(x,34) ^ ror64(x,39))
+#define e1(x) (ror64(x,14) ^ ror64(x,18) ^ ror64(x,41))
+#define s0(x) (ror64(x, 1) ^ ror64(x, 8) ^ (x >> 7))
+#define s1(x) (ror64(x,19) ^ ror64(x,61) ^ (x >> 6))
/* H* initial state for SHA-512 */
#define H0 0x6a09e667f3bcc908ULL
[PATCH] sha512: replace open-coded be64 conversions
This + next patch were "modprobe tcrypt" tested.
See next mail.
--
vda
diff -urpN 2.6.12-rc2.0.orig/crypto/sha512.c 2.6.12-rc2.1.be/crypto/sha512.c
--- 2.6.12-rc2.0.orig/crypto/sha512.c Tue Apr 19 00:20:12 2005
+++ 2.6.12-rc2.1.be/crypto/sha512.c Mon Apr 18 23:31:54 2005
@@ -105,7 +105,7 @@ static const u64 sha512_K[80] = {
static inline void LOAD_OP(int I, u64 *W, const u8 *input)
{
- W[I] = __be64_to_cpu( ((__be64*)(input))[I] );
+ W[I] = __be64_to_cpu( ((__be64*)input)[I] );
}
static inline void BLEND_OP(int I, u64 *W)
@@ -124,9 +124,8 @@ sha512_transform(u64 *state, u64 *W, con
for (i = 0; i < 16; i++)
LOAD_OP(i, W, input);
-for (i = 16; i < 80; i++) {
+for (i = 16; i < 80; i++)
BLEND_OP(i, W);
-}
/* load the state into our registers */
a=state[0]; b=state[1]; c=state[2]; d=state[3];
@@ -238,36 +237,17 @@ sha512_final(void *ctx, u8 *hash)
static u8 padding[128] = { 0x80, };
-u32 t;
- u64 t2;
u8 bits[128];
unsigned int index, pad_len;
- int i, j;
+ int i;
-index = pad_len = t = i = j = 0;
-t2 = 0;
+ index = pad_len = i = 0;
/* Save number of bits */
- t = sctx->count[0];
- bits[15] = t; t>>=8;
- bits[14] = t; t>>=8;
- bits[13] = t; t>>=8;
- bits[12] = t;
- t = sctx->count[1];
- bits[11] = t; t>>=8;
- bits[10] = t; t>>=8;
- bits[9 ] = t; t>>=8;
- bits[8 ] = t;
- t = sctx->count[2];
- bits[7 ] = t; t>>=8;
- bits[6 ] = t; t>>=8;
- bits[5 ] = t; t>>=8;
- bits[4 ] = t;
- t = sctx->count[3];
- bits[3 ] = t; t>>=8;
- bits[2 ] = t; t>>=8;
- bits[1 ] = t; t>>=8;
- bits[0 ] = t;
+ ((__be32*)bits)[3] = __cpu_to_be32(sctx->count[0]);
+ ((__be32*)bits)[2] = __cpu_to_be32(sctx->count[1]);
+ ((__be32*)bits)[1] = __cpu_to_be32(sctx->count[2]);
+ ((__be32*)bits)[0] = __cpu_to_be32(sctx->count[3]);
/* Pad out to 112 mod 128. */
index = (sctx->count[0] >> 3) & 0x7f;
@@ -278,17 +258,8 @@ sha512_final(void *ctx, u8 *hash)
sha512_update(sctx, bits, 16);
/* Store state in digest */
- for (i = j = 0; i < 8; i++, j += 8) {
- t2 = sctx->state[i];
- hash[j+7] = (char)t2 & 0xff; t2>>=8;
- hash[j+6] = (char)t2 & 0xff; t2>>=8;
- hash[j+5] = (char)t2 & 0xff; t2>>=8;
- hash[j+4] = (char)t2 & 0xff; t2>>=8;
- hash[j+3] = (char)t2 & 0xff; t2>>=8;
- hash[j+2] = (char)t2 & 0xff; t2>>=8;
- hash[j+1] = (char)t2 & 0xff; t2>>=8;
- hash[j ] = (char)t2 & 0xff;
- }
+ for (i = 0; i < 8; i++)
+ ((__be64*)hash)[i] = __cpu_to_be64(sctx->state[i]);
/* Zeroize sensitive information. */
memset(sctx, 0, sizeof(struct sha512_ctx));
[PATCH] introduce generic 64bit rotations and i386 asm optimized version
This is done because on 32bit arch gcc generates suboptimal code
from C implementation:
old:
40: 83 ea 80sub$0xff80,%edx
43: 89 95 50 ff ff ff mov%edx,0xff50(%ebp)
49: 8b bd 50 ff ff ff mov0xff50(%ebp),%edi
4f: 8b 4f f0mov0xfff0(%edi),%ecx
52: 8b 5f f4mov0xfff4(%edi),%ebx
55: 89 ce mov%ecx,%esi
57: 0f ac de 13 shrd $0x13,%ebx,%esi
5b: 31 c0 xor%eax,%eax
5d: 89 df mov%ebx,%edi
5f: 89 ca mov%ecx,%edx
61: c1 e2 0dshl$0xd,%edx
64: 09 c6 or %eax,%esi
66: c1 ef 13shr$0x13,%edi
69: 89 d8 mov%ebx,%eax
6b: 09 d7 or %edx,%edi
6d: c1 e8 1dshr$0x1d,%eax
70: 31 d2 xor%edx,%edx
72: 89 85 40 ff ff ff mov%eax,0xff40(%ebp)
78: 89 95 44 ff ff ff mov%edx,0xff44(%ebp)
new:
40: 83 ea 80sub$0xff80,%edx
43: 89 95 48 ff ff ff mov%edx,0xff48(%ebp)
49: 8b 9d 48 ff ff ff mov0xff48(%ebp),%ebx
4f: 8b 4b f0mov0xfff0(%ebx),%ecx
52: 8b 5b f4mov0xfff4(%ebx),%ebx
55: 89 c8 mov%ecx,%eax
57: 89 da mov%ebx,%edx
59: 0f ac d0 13 shrd $0x13,%edx,%eax
5d: 0f ac ca 13 shrd $0x13,%ecx,%edx
61: 89 45 a0mov%eax,0xffa0(%ebp)
64: 89 55 a4mov%edx,0xffa4(%ebp)
--
vda
diff -urpN 2.6.12-rc2.1.be/include/asm-i386/bitops.h 2.6.12-rc2.2.ror/include/asm-i386/bitops.h
--- 2.6.12-rc2.1.be/include/asm-i386/bitops.h Tue Oct 19 00:54:36 2004
+++ 2.6.12-rc2.2.ror/include/asm-i386/bitops.h Tue Apr 19 08:20:07 2005
@@ -7,6 +7,7 @@
#include
#include
+#include
/*
* These have to be done with inline assembly: that way the bit-setting
@@ -431,9 +432,81 @@ static inline int ffs(int x)
#define hweight16(x) generic_hweight16(x)
#define hweight8(x) generic_hweight8(x)
-#endif /* __KERNEL__ */
+/*
+ * 64bit rotations
+ * (gcc3 seems to be clever enough to do 32bit ones just fine)
+ *
+ * Why "i" and "I" constraints do not work? gcc says:
+ * "warning: asm operand 2 probably doesn't match constraints"
+ * "error: impossible constraint in 'asm'"
+ * Will use "Ic" for now. If gcc will fail to do const propagation
+ * and will try to stuff constant into ecx, shld %3,... will expand
+ * to shld %ecx,... and assembler will moan.
+ * Do not 'fix' by changing to shld %b3,...
+ *
+ * Have to stick to edx,eax pair only because
+ * gcc has limited support for 64bit asm parameters
+ */
+#define constant_rol64(v,c) \
+ ({ \
+ u64 vv = (v); \
+ if(!(c&63)) { \
+ } else if((c&63)==1) {\
+ asm ( \
+ " shldl $1,%%edx,%%eax \n" \
+ " rcll $1,%%edx \n" \
+ : "=&A" (vv)\
+ : "0" (vv)\
+ ); \
+ } else if((c&63)==63) {\
+ asm ( \
+ " shrdl $1,%%edx,%%eax \n" \
+ " rcrl $1,%%edx \n" \
+ : "=&A" (vv)\
+ : "0" (vv)\
+ ); \
+ } else if((c&63)<32) {\
+ asm ( \
+ " shldl %3,%%edx,%%eax \n" \
+ " shldl %3,%2,%%edx \n" \
+ : "=&A" (vv)\
+ : "0" (vv), "r" (vv), "Ic" (c&63) \
+ ); \
+ } else if((c&63)>32) {\
+ asm ( \
+ " shrdl %3,%%edx,%%eax \n" \
+ " shrdl %3,%2,%%edx \n" \
+ : "=&A" (vv)\
+ : "0" (vv), "r" (vv), "Ic" (64-(c&63)) \
+ ); \
+ } else /* (c&63)==32 */ { \
+ asm ( \
+ " xchgl %%edx,%%eax \n" \
+ : "=&A" (vv)\
+ : "0" (vv)\
+ ); \
+ } \
+ vv; \
+ })
+/*
+ * Unfortunately 64bit rotations with non-constant count
+ * have issues with cnt>=32. Using C code instead
+ */
+static inline u64 rol64(u64 x,int num) {
+ if(__builtin_constant_p(num))
+ return constant_rol64(x,num);
+ /* Hmmm... shall we do cnt&=63 here? */
+ return ((x<>(64-num)));
+}
+static inline u64 ror64(u64 x,int num) {
+ if(__builtin_constant_p(num))
+ return constant_rol64(x,(64-num));
+ return ((x>>num) | (x<<(64-num)));
+}
+
+#define ARCH_HAS_ROL64
+#define ARCH_HAS_ROR64
-#ifdef __KERNEL__
#define ext2_set_bit(nr,addr) \
__test_and_set_bit((nr),(unsigned long*)addr)
diff -urpN 2.6.12-rc2.1.be/include/linux/bitops.h 2.6.12-rc2.2.ror/include/linux/bitops.h
--- 2.6.12-rc2.1.be/include/linux/bitops.h Mon Apr 18 22:55:10 2005
+++ 2.6.12-rc2.2.ror/include/linux/bitops.h Tue Apr 19 00:25:28 2005
@@ -41,7 +41,7 @@ static inline int generic_ffs(int x)
* fls: find last bit set.
*/
-static __inline__ int generic_fls(int x)
+static
Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
On Mon, 2005-04-18 at 22:54 -0700, Paul Jackson wrote:
> Now, onto the real stuff.
>
> This same issue, in a strange way, comes up on the memory side,
> as well as on the cpu side.
>
> First, let me verify one thing. I understand that the _key_
> purpose of your patch is not so much to isolate cpus, as it
> is to allow for structuring scheduling domains to align with
> cpuset boundaries. I understand real isolated cpus to be ones
> that don't have a scheduling domain (have only the dummy one),
> as requested by the "isolcpus=..." boot flag.
>
Yes.
> The following code snippet from kernel/sched.c is what I derive
> this understanding from:
>
Correct. A better name instead of isolated cpusets may be
'partitioned cpusets' or somesuch.
On the other hand, it is more or less equivalent to a single
isolated CPU. Instead of an isolated cpu, you have an isolated
cpuset.
Though I imagine this becomes a complete superset of the
isolcpus= functionality, and it would actually be easier to
manage a single isolated CPU and its associated processes with
the cpusets interfaces after this.
> In both cases, we have an intermediate degree of partitioning
> of a system, neither at the most detailed leaf cpuset, nor at
> the all encompassing top cpuset. And in both cases, we want
> to partition the system, along cpuset boundaries.
>
Yep. This sched-domains partitioning only works when you have
more than one completely disjoint top level cpusets. That is,
you effectively partition the CPUs.
It doesn't work if you have *most* jobs bound to either
{0, 1, 2, 3} or {4, 5, 6, 7} but one which should be allowed
to use any CPU from 0-7.
> Here I use "partition" in the mathematical sense:
>
> ===
> A partition of a set X is a set of nonempty subsets of X such
> that every element x in X is in exactly one of these subsets.
>
> Equivalently, a set P of subsets of X, is a partition of X if
>
> 1. No element of P is empty.
> 2. The union of the elements of P is equal to X. (We say the
>elements of P cover X.)
> 3. The intersection of any two elements of P is empty. (We say
>the elements of P are pairwise disjoint.)
>
> http://www.absoluteastronomy.com/encyclopedia/p/pa/partition_of_a_set.htm
> ===
>
> In the case of cpus, we really do prefer the partitions to be
> disjoint, because it would be better not to confuse the domain
> scheduler with overlapping domains.
>
Yes. The domain scheduler can't handle this at all, it would
have to fall back on cpus_allowed, which in turn can create
big problems for multiprocessor balancing.
> For the cpu case, we would provide a scheduler domain for each
> subset of the cpu partitioning.
>
Yes.
[snip the rest, which I didn't finish reading :P]
>From what I gather, this partitioning does not exactly fit
the cpusets architecture. Because with cpusets you are specifying
on what cpus can a set of tasks run, not dividing the whole system.
Basically for the sched-domains code to be happy, there should be
some top level entity (whether it be cpusets or something else) which
records your current partitioning (the default being one set,
containing all cpus).
> As stated above, there is a single system wide partition of
> cpus, and another of mems. I suspect we should consider finding
> a way to nest partitions. My (shakey) understanding of what
> Nick is doing with scheduler domains is that for the biggest of
> systems, we will probably want little scheduler domains inside
> bigger ones.
The sched-domains setup code will take care of all that for you
already. It won't know or care about the partitions. If you
partition a 64-way system into 2 32-ways, the domain setup code
will just think it is setting up a 32-way system.
Don't worry about the sched-domains side of things at all, that's
pretty easy. Basically you just have to know that it has the
capability to partition the system in an arbitrary disjoint set
of sets of cpus.
If you can make use of that, then we're in business ;)
--
SUSE Labs, Novell Inc.
-
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: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe wrote: (B (B>Sorry, I may mistake the point, (B>Chris Wedgwood wrote: (B> (B> (B>>that would also be a problem for live patching too, if you have bad (B>>state, you have bad state --- live patching doesn't change that (B>> (B>> (B>What I want to say is takeover may makes memory unstable, because there (B>are extra operations to reserve current (unstable) status to memory. (B>Live patching never force target process to reserve status to memory. Is (B>this make sense? (B> (B> (BSorry, I misunderstand it, forget above comment, both methods are (Bpossible to destroy memory. (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
Hmmm ... interesting patch. My reaction to the changes in
kernel/cpuset.c are complicated:
* I'm supposed to be on vacation the rest of this month,
so trying (entirely unsuccessfully so far) not to think
about this.
* This is perhaps the first non-trivial cpuset patch to come
in the last many months from someone other than Simon or
myself - welcome.
* Some coding style and comment details will need working.
* The conceptual model for how to represent this in cpusets
needs some work.
Let me do two things in this reply. First I'll just shoot off
shotgun style the nit picking coding and comment details that
I notice, in a scan of the patch. Then I will step back to a
discussion of the conceptual model. I suspect that by the time
we nail the conceptual model, the code will be sufficiently
rewritten that most of the coding and comment nits will no
longer apply anyway.
But, since nit picking is easier than real thinking ...
* I'd probably ditch the all_cpus() macro, on the
concern that it obfuscates more than it helps.
* The need for _both_ a per-cpuset flag 'CS_CPU_ISOLATED'
and another per-cpuset mask 'isolated_map' concerns me.
I guess that the isolated_map is just a cache of the
set of CPUs isolated in child cpusets, not an independently
settable mask, but it needs to be clearly marked as such
if so.
* Some code lines go past column 80.
* The name 'isolated' probably won't work. There is already
a boottime option "isolcpus=..." for 'isolated' cpus which
is (I think ?) rather different. Perhaps a better name will
fall out of the conceptual discussion, below.
* The change to the output format of the special cpuset file
'cpus', to look like '0-3[4-7]' bothers me in a couple of
ways. It complicates the format from being a simple list.
And it means that the output format is not the same as the
input format (you can't just write back what you read from
such a file anymore).
* Several comments start with the word 'Set', as in:
Set isolated ON on a non exclusive cpuset
Such wording suggests to me that something is being set,
some bit or value changed or turned on. But in each case,
you are just testing for some condition that will return
or error out. Some phrasing such as "If ..." or other
conditional would be clearer.
* The update_sched_domains() routine is complicated, and
hence a primary clue that the conceptual model is not
clean yet.
* None of this was explained in Documentation/cpusets.txt.
* Too bad that cpuset_common_file_write() has to have special
logic for this isolated case. The other flag settings just
turn on and off the associated bit, and don't trigger any
kernel code to adapt to new cpu or memory settings. We
should make an exception to that behaviour only if we must,
and then we must be explicit about the exception.
Ok - enough nits.
Now, onto the real stuff.
This same issue, in a strange way, comes up on the memory side,
as well as on the cpu side.
First, let me verify one thing. I understand that the _key_
purpose of your patch is not so much to isolate cpus, as it
is to allow for structuring scheduling domains to align with
cpuset boundaries. I understand real isolated cpus to be ones
that don't have a scheduling domain (have only the dummy one),
as requested by the "isolcpus=..." boot flag.
The following code snippet from kernel/sched.c is what I derive
this understanding from:
===
static void __devinit arch_init_sched_domains(void)
{
...
/*
* Setup mask for cpus without special case scheduling requirements.
* For now this just excludes isolated cpus, but could be used to
* exclude other special cases in the future.
*/
cpus_complement(cpu_default_map, cpu_isolated_map);
cpus_and(cpu_default_map, cpu_default_map, cpu_online_map);
/*
* Set up domains. Isolated domains just stay on the dummy domain.
*/
for_each_cpu_mask(i, cpu_default_map) {
...
===
Second, let me describe how this same issue shows up on the
memory side.
Let's say, for example, someone has partitioned a large
system (100's of cpus and nodes) in two major halves
using cpusets, each half being used by a different
organization.
On one of the halves, they are running a large scientific
program that works on a huge data set that just fits in
the memory available on that half, and they are running
a set of related tools that run different passes over
that data.
Some of these tools might take several cpus, running
parallel threads, and using a little more data shared
by the threads in that tool. Each of these tools might
get its own cpuset, a child (subset) of the big cpuset
that defines the half of the system that this large
scientific program is running within.
The big dataset has to be constrained to the big cpus
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote: > What I want to say is takeover may makes memory unstable, because > there are extra operations to reserve current (unstable) status to > memory. mmap is coherent between processes > Live patching never force target process to reserve status to memory. Is > this make sense? Not really. I don't see how it makes it any better or easier, just different. > I think the point is how long does it takes to hand the fd off to > another process. (means how long time the network port is > unavailable??) Probably under 1 ms. Not long anyhow. > Please see and try http://pannus.sourceforge.net > There includes commands and some samples. pannus-sample.tgz contains some pretty contrived examples, nothing that anyone could really sensibly comment on > On live patching, you never need to use shared memory, just prepare > fixed code, and just compile it as shared ibject, that's all. pretty > easy and fast to replace the functions. it requires magic like a compiler and knowledge of the original application. if the application was written sensibly someone without access to the application code could change this live taking over the previous applications state even more easily --- and the code would be more straightforward. so i still fail to see why this is needed. - 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/
Whirlpool oopses in 2.6.11 and 2.6.12-rc2
modprobe tcrypt hangs the box on both kernels. The last printks are: testing wp384 NNUnable to handle kernel paging request at virtual address eXXX Nothing is printed after this and system locks up solid. No Sysrq-B. IIRC, 2.6.9 was okay. Just a heads-up. -- vda - 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/
Development Model
Greetings, For months I have been reading as much as I can about the current stable/unstable development model, but still have a question. Has the Linux Kernel reached a point where the majority of developers feel that (at least for now) no *MAJOR* "rip it out, stomp on it, burn it and start over" parts of the kernel exist any longer? In other words, do you feel that we're in a good place at this point and that incremental improvements will rule the day until $COOL_IDEA comes along and requires a refactoring of 2.x (where x is an odd number) porportions? Thank you, ..Chuck.. P.S. Please CC me on replies, as I am not subscribed at this time. -- http://www.quantumlinux.com Quantum Linux Laboratories, LLC. ACCELERATING Business with Open Technology "The measure of the restoration lies in the extent to which we apply social values more noble than mere monetary profit." - FDR - 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: [PATCH x86_64] Live Patching Function on 2.6.11.7
Sorry, I may mistake the point, (BChris Wedgwood wrote: (B (B>>For me, is seems very dangerous to estimate the primary copy is not (B>>broken through status takeover.. (B>> (B>> (B> (B>that would also be a problem for live patching too, if you have bad (B>state, you have bad state --- live patching doesn't change that (B> (B> (BWhat I want to say is takeover may makes memory unstable, because there (Bare extra operations to reserve current (unstable) status to memory. (BLive patching never force target process to reserve status to memory. Is (Bthis make sense? (B (B>>Some process use critical resources such as fixed network listen (B>>port can not speed up so. (B>> (B>> (B> (B>hand the fd off to another process (B> (B> (BI think the point is how long does it takes to hand the fd off to (Banother process.(means how long time the network port is unavailable??) (B (B>>More importantly, the only process who prepare to use this mechanism (B>>only allows to use quick process takeover. (B>> (B>> (B> (B>no, i can mmap state or similar, hand fd's off and switch to another (B>process in a context switch... hot patching i bet is going to be (B>slower (B> (B>how about you show up some code that needs this? (B> (B> (B>>This cause software development difficult. (B>> (B>> (B> (B>i honestly doubt in most cases you can hand live patch faster and more (B>easily than having the application sensibly written and passing it off (B> (B>please, prove me wrong, show us some code (B> (B> (BPlease see and try http://pannus.sourceforge.net (BThere includes commands and some samples. (BOn live patching, you never need to use shared memory, just prepare (Bfixed code, and just compile it as shared ibject, that's all. pretty (Beasy and fast to replace the functions. (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
RE: Fibre Channel state of the union
Christoph, FYI - Emulex is committed to completing the effort for creating a vendor-agnostic open-source hbaapi library for linux, including the thornier issues of performing CT passthru and RNID functionality. As soon as the library exists, an open-source SMI-S provider would become available as well. -- James > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Christoph Hellwig > Sent: Monday, April 18, 2005 11:40 AM > To: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Fibre Channel state of the union > > > > With the upcoming merge of the current SCSI development > branch (probably > after the 2.6.12 release), Linux will have more advanced Fibre Channel > support than any currently available operating system. > > The new Fibre Channel (FC) transport class offers two major advantages > over traditional standalone drivers: > > (1) It provides an easy to use library to deal with most > aspects of FC > remote port management and its integration into SAM and the Linux > SCSI layer. > > - a remote port object that sits between the host and the target > in the Linux SCSI layer object model > - support for remote port based LUN scanning, including live > rescanning on fabric topology changes and stable remove port to > SCSI target id mappings > - a queue freeze facility to handle temporary cable > unplugs without > generating I/O errors > > (2) a common userspace interface to transport specific and management > information in sysfs. The information provided is based > on a sane > subset of the SNIA HBA API specification. > > This reduces the burden of writing and maintaining an FC HBA driver > substantially, for example the recent conversion of the > qla2xxx driver to > use these facilities removes over 3000 lines of code (about > 1/5 of the overall > driver size) while adding new features and a userspace > management interface. > The FC transport class thus allows hardware vendors to concentrate on > interfacing with the hardware and support their unique > features, freeing > them from the burden of reimplementing basic infrastructure > in every driver > and designing ad hoc management interfaces. > > We now have two drivers supporting this infrastructure fully: > > - qla2xxx for Qlogic 2100/2200/23xx HBAs > - lpfc for all Emulex SLI2 HBAs > > Two drivers for modern hardware don't fully use this > infrastructure yet, > but we are working with the maintainers and expect the drivers to be > updated to take advantage of the new FC transport class soon. > > - zfcp for the Fibre Channel attachment on the IBM zSeries > mainframes > - mptfusion for the LSI "Fusion" 909/919(X)/929(X) HBAs > > Still missing is an Open Source tool application utilizing our APIs. > The currently available proprietary applications are > inflexible, available > only for very few of the architectures supported by Linux, and tied to > specific HBAs. The common API and hardware independence > provide a great > opportunity for the Hardware vendors to collaborate on a > single Open Source > management application and leverage the cost savings of an > open development > method. > > We are also looking forward to a bridge from the Linux > management interfaces to the "industry-standard" SNIA HBA API, > allowing various management applications to work out of the > box with our > stack. > > To make these new features available to Enterprise users and > reduce the > fragmentation in driver and management space we will be > working with the > major players in the Storage Industry and the Linux > Distribution vendors > to support and certify this stack in the near future. > > Special thanks go to Emulex and James Smart in particular for > implementing > the majority of the new Fibre Channel transport class. We > also want to > thank Andrew Vasquez at Qlogic for providing valuable input on the > transport class design and for updating the qla2xx driver to > use the new > facilities quickly. > > The Linux SCSI community plans to provide a similar framework for > Serial Attached SCSI (SAS) transports in the near future. > > > Thanks to Arjan van de Ven, Peter Jones, Randy Dunlap, Rik van Riel, > Nikita Danilov and James Bottomley for reviewing this document and > suggesting various improvements. > - > To unsubscribe from this list: send the line "unsubscribe > linux-scsi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > - 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/
[GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Alright, let's try some small i2c and w1 patches... Could you merge with: kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ It contains 4 small patches, 2 i2c and 2 w1 bugfixes, diffstat is below, I'll figure out how to send the individual patches later. thanks, greg k-h drivers/i2c/chips/it87.c|2 +- drivers/i2c/chips/via686a.c |7 ++- drivers/w1/w1.c |9 + drivers/w1/w1_smem.c|4 ++-- 4 files changed, 10 insertions(+), 12 deletions(-) - 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: Fortuna
Theodore Ts'o wrote: >For one, /dev/urandom and /dev/random don't use the same pool >(anymore). They used to, a long time ago, but certainly as of the >writing of the paper this was no longer true. This invalidates the >entire last paragraph of Section 5.3. Ok, you're right, this is a serious flaw, and one that I overlooked. Thanks for elaborating. (By the way, has anyone contacted to let them know about these two errors? Should I?) I see three remaining criticisms from their Section 5.3: 1) Due to the way the documentation describes /dev/random, many programmers will choose /dev/random by default. This default seems inappropriate and unfortunate. 2) There is a widespread perception that /dev/urandom's security is unproven and /dev/random's is proven. This perception is wrong. On a related topic, it is "not at all clear" that /dev/random provides information-theoretic security. 3) Other designs place less stress on the entropy estimator, and thus are more tolerant to failures of entropy estimation. A failure in the entropy estimator seems more likely than a failure in the cryptographic algorithms. These three criticisms look right to me. Apart from the merits or demerits of Section 5.3, the rest of the paper seemed to have some interesting ideas for how to simplify and possibly improve the /dev/random generator, which might be worth considering at some point. - 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: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote: > this makes software developer crazy are you serious? how is live patching of .text easier than some of the other suggestions which all are more or less sane and things like gdb, oprofile, etc. will deal with w/o problems? patching code in a running process is way complicated and messy, if you think this is the easier solution i guess i have little more to say > For me, is seems very dangerous to estimate the primary copy is not > broken through status takeover.. that would also be a problem for live patching too, if you have bad state, you have bad state --- live patching doesn't change that > Some process use critical resources such as fixed network listen > port can not speed up so. hand the fd off to another process > More importantly, the only process who prepare to use this mechanism > only allows to use quick process takeover. no, i can mmap state or similar, hand fd's off and switch to another process in a context switch... hot patching i bet is going to be slower how about you show up some code that needs this? > This cause software development difficult. i honestly doubt in most cases you can hand live patch faster and more easily than having the application sensibly written and passing it off please, prove me wrong, show us some code > The live patching does not require to implement such special > techniques on applications. this is like saying live patching is a complicated in-kernel solution for badly written userspace isn't it? - 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: Fortuna
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote: > Yes, that is a minor glitch, but I believe all their points remain > valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g > substitution, and re-read the paper to see what you can get out of it. > > The problem is not that the paper is shallow; it is not. The source > of the error is likely that this paper was written by theorists, not > implementors. There are important things we can learn from them, and I > think it is worth reading their paper carefully to understand what they > have to offer. Since the paper was written by theorists, it appears that they didn't bother to read the implementation, but instead made assumptions from the man pages, as well as making the assumption that the man page (which was not written as a specification from which the code was implemented, and indeed was not even written by the code authors) was in fact an accurate representation of drivers/char/random.c. So section 5.3 is essense a criticism of a straw man implementation based on a flawed reading of a flawed man page. Other than that, it's fine. :-) > I believe they raise substantial and deep questions in their Section 5.3. > I don't see why you say Section 5.3 is all wrong. Can you elaborate? > Can you explain one or two of the substantial errors you see? For one, /dev/urandom and /dev/random don't use the same pool (anymore). They used to, a long time ago, but certainly as of the writing of the paper this was no longer true. This invalidates the entire last paragraph of Section 5.3. The criticisms of the /dev/random man page do have some point, but the man page != the implementation. Also, the paper does not so much make an attack on the entropy estimator, so much as it casts asperions on it, while at the same time making the unspoken assumption that cryptographic primitives are iron-clad and unbreakable. So I don't see any particular substantial deep questions, unless you count, "It is not at all clear that /dev/random ... provides information-theoretic security. Indeed, we suspect it sometimes doesn't" as a deep question. I don't. - Ted - 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: a networking question
On Mon, 18 Apr 2005 00:33:57 -0700 Ashmi Bhanushali <[EMAIL PROTECTED]> wrote: > hi all.. > > i m a new bee in lunix kernel. and i m trying to implement "FIFO+" > queuing for packet forwarding in linux kernel by modifying the > original code for packet forwarding(FIFO). The more useful way to do this is to do it at the queue discipline layer outside of IP. Start out with sch_fifo.c and modify it for your new algorithm. > i m going to use fedora core 2 and the kernel version is 2.6.11-7. i > nned some help to locate the original code of queuing (FIFO). I looked > at some files like ip_input.c, ip_output.c and ip_forward.c in the > net/ipv4 directory of the kernel source code. but i m not sure if > these are the correct files to look for the original FIFO packet > queuing implemented in linux kernel. > > could someone please help me in locating the files which has the FIFO > queuing code. > > thanks in advance. > > -ashmi Networking stuff is discussed more on the netdev@oss.sgi.com list and routing on lartc@mailman.ds9a.nl - 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/
[2.6 patch] drivers/net/tokenring/: cleanups
This patch contains the follwing cleanups:
- make needlessly global code static
- remove obsolete Emacs settings
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/pcmcia/ibmtr_cs.c |3 --
drivers/net/tokenring/3c359.c |3 +-
drivers/net/tokenring/3c359_microcode.h |2 -
drivers/net/tokenring/abyss.c | 11 -
drivers/net/tokenring/ibmtr.c | 28
drivers/net/tokenring/madgemc.c | 14
drivers/net/tokenring/proteon.c | 11 -
drivers/net/tokenring/skisa.c | 11 -
drivers/net/tokenring/smctr.c |2 -
drivers/net/tokenring/smctr_firmware.h |2 -
drivers/net/tokenring/tms380tr.c| 13 ---
drivers/net/tokenring/tmspci.c | 11 -
12 files changed, 21 insertions(+), 90 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/ibmtr.c.old 2005-04-19
03:11:34.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/tokenring/ibmtr.c 2005-04-19
03:41:47.0 +0200
@@ -151,7 +151,7 @@
/* this allows displaying full adapter information */
-char *channel_def[] __devinitdata = { "ISA", "MCA", "ISA P&P" };
+static char *channel_def[] __devinitdata = { "ISA", "MCA", "ISA P&P" };
static char pcchannelid[] __devinitdata = {
0x05, 0x00, 0x04, 0x09,
@@ -171,7 +171,7 @@
0x03, 0x08, 0x02, 0x00
};
-char __devinit *adapter_def(char type)
+static char __devinit *adapter_def(char type)
{
switch (type) {
case 0xF: return "PC Adapter | PC Adapter II | Adapter/A";
@@ -184,7 +184,7 @@
#define TRC_INIT 0x01 /* Trace initialization & PROBEs */
#define TRC_INITV 0x02 /* verbose init trace points */
-unsigned char ibmtr_debug_trace = 0;
+static unsigned char ibmtr_debug_trace = 0;
static int ibmtr_probe(struct net_device *dev);
static int ibmtr_probe1(struct net_device *dev, int ioaddr);
@@ -192,20 +192,20 @@
static int trdev_init(struct net_device *dev);
static int tok_open(struct net_device *dev);
static int tok_init_card(struct net_device *dev);
-void tok_open_adapter(unsigned long dev_addr);
+static voidtok_open_adapter(unsigned long dev_addr);
static voidopen_sap(unsigned char type, struct net_device *dev);
static voidtok_set_multicast_list(struct net_device *dev);
static int tok_send_packet(struct sk_buff *skb, struct net_device *dev);
static int tok_close(struct net_device *dev);
-irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs);
+static irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs);
static voidinitial_tok_int(struct net_device *dev);
static voidtr_tx(struct net_device *dev);
static voidtr_rx(struct net_device *dev);
-void ibmtr_reset_timer(struct timer_list*tmr,struct net_device *dev);
+static voidibmtr_reset_timer(struct timer_list*tmr,struct net_device *dev);
static voidtok_rerun(unsigned long dev_addr);
-void ibmtr_readlog(struct net_device *dev);
+static voidibmtr_readlog(struct net_device *dev);
static struct net_device_stats *tok_get_stats(struct net_device *dev);
-intibmtr_change_mtu(struct net_device *dev, int mtu);
+static int ibmtr_change_mtu(struct net_device *dev, int mtu);
static voidfind_turbo_adapters(int *iolist);
static int ibmtr_portlist[IBMTR_MAX_ADAPTERS+1] __devinitdata = {
@@ -928,7 +928,7 @@
#define DLC_MAX_SAP_OFST32
#define DLC_MAX_STA_OFST33
-void tok_open_adapter(unsigned long dev_addr)
+static void tok_open_adapter(unsigned long dev_addr)
{
struct net_device *dev = (struct net_device *) dev_addr;
struct tok_info *ti;
@@ -1099,7 +1099,7 @@
return ti->sram_virt + index;
}
-void dir_open_adapter (struct net_device *dev)
+static void dir_open_adapter (struct net_device *dev)
{
struct tok_info *ti = (struct tok_info *) dev->priv;
unsigned char ret_code;
@@ -1172,7 +1172,7 @@
/**/
-irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t tok_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
unsigned char status;
/* unsigned char status_even ; */
@@ -1840,7 +1840,7 @@
/*/
-void ibmtr_reset_timer(struct timer_list *tmr, struct net_device *dev)
+static void ibmtr_reset_timer(struct timer_list *tmr, struct net_device *dev)
{
tmr->expires = jiffies + TR_RETRY_INTERVAL;
tmr->data = (unsigned long) dev;
@@ -1872,7 +1872,7 @@
/*/
-void ibmtr_readlog(struct net_device *dev)
+static void ibmtr_readlog(struct net_device *dev)
{
struct tok_info *ti;
@@ -
[2.6 patch] drivers/mmc/wbsd.c: possible cleanups
This patch contains the following possible cleanups:
- make some needlessly global code static
- remove the unneeded global function DBG_REG
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/mmc/wbsd.c | 30 --
drivers/mmc/wbsd.h |7 ---
2 files changed, 8 insertions(+), 29 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/mmc/wbsd.h.old2005-04-19
02:56:24.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/mmc/wbsd.h2005-04-19
02:57:17.0 +0200
@@ -8,13 +8,6 @@
* published by the Free Software Foundation.
*/
-const int config_ports[] = { 0x2E, 0x4E };
-const int unlock_codes[] = { 0x83, 0x87 };
-
-const int valid_ids[] = {
- 0x7112,
- };
-
#define LOCK_CODE 0xAA
#define WBSD_CONF_SWRST0x02
--- linux-2.6.12-rc2-mm3-full/drivers/mmc/wbsd.c.old2005-04-19
02:55:39.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/mmc/wbsd.c2005-04-19
02:57:06.0 +0200
@@ -52,32 +52,18 @@
#define DBGF(x...) do { } while (0)
#endif
+static const int config_ports[] = { 0x2E, 0x4E };
+static const int unlock_codes[] = { 0x83, 0x87 };
+
+static const int valid_ids[] = {
+ 0x7112,
+ };
+
+
static unsigned int io = 0x248;
static unsigned int irq = 6;
static int dma = 2;
-#ifdef CONFIG_MMC_DEBUG
-void DBG_REG(int reg, u8 value)
-{
- int i;
-
- printk(KERN_DEBUG "wbsd: Register %d: 0x%02X %3d '%c' ",
- reg, (int)value, (int)value, (value < 0x20)?'.':value);
-
- for (i = 7;i >= 0;i--)
- {
- if (value & (1 << i))
- printk("x");
- else
- printk(".");
- }
-
- printk("\n");
-}
-#else
-#define DBG_REG(r, v) do {} while (0)
-#endif
-
/*
* Basic functions
*/
-
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/
[2.6 patch] drivers/net/irda/irport.c: cleanups
This patch contains the following cleanups:
- make a needlessly global function static
- remove the unneeded global function irport_probe
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/irda/irport.c | 15 +--
1 files changed, 1 insertion(+), 14 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/net/irda/irport.c.old 2005-04-19
03:06:12.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/irda/irport.c 2005-04-19
03:06:45.0 +0200
@@ -286,19 +286,6 @@
}
/*
- * Function irport_probe (void)
- *
- *Start IO port
- *
- */
-int irport_probe(int iobase)
-{
- IRDA_DEBUG(4, "%s(), iobase=%#x\n", __FUNCTION__, iobase);
-
- return 0;
-}
-
-/*
* Function irport_get_fcr (speed)
*
*Compute value of fcr
@@ -383,7 +370,7 @@
*we cannot use schedule_timeout() when we are in interrupt context
*
*/
-int __irport_change_speed(struct irda_task *task)
+static int __irport_change_speed(struct irda_task *task)
{
struct irport_cb *self;
__u32 speed = (__u32) task->param;
-
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/
[2.6 patch] drivers/net/hamradio/: cleanups
This patch contains the following cleanups:
- mkiss.c: make a needlessly global variable static
- dmascc.c: remove the unused global function dmascc_setup
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/hamradio/dmascc.c | 10 --
drivers/net/hamradio/mkiss.c |2 +-
2 files changed, 1 insertion(+), 11 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/dmascc.c.old 2005-04-19
03:04:36.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/dmascc.c 2005-04-19
03:04:57.0 +0200
@@ -311,16 +311,6 @@
}
}
-#ifndef MODULE
-void __init dmascc_setup(char *str, int *ints)
-{
- int i;
-
- for (i = 0; i < MAX_NUM_DEVS && i < ints[0]; i++)
- io[i] = ints[i + 1];
-}
-#endif
-
static int __init dmascc_init(void)
{
int h, i, j, n;
--- linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/mkiss.c.old 2005-04-19
03:05:20.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/hamradio/mkiss.c 2005-04-19
03:05:30.0 +0200
@@ -65,7 +65,7 @@
static ax25_ctrl_t **ax25_ctrls;
-int ax25_maxdev = AX25_MAXDEV; /* Can be overridden with insmod! */
+static int ax25_maxdev = AX25_MAXDEV; /* Can be overridden with insmod! */
static struct tty_ldiscax_ldisc;
-
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/
[2,6 patch] drivers/net/arcnet/capmode.c: make a struct static
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c.old 2005-04-19
03:03:23.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/arcnet/capmode.c 2005-04-19
03:03:53.0 +0200
@@ -48,7 +48,7 @@
static int ack_tx(struct net_device *dev, int acked);
-struct ArcProto capmode_proto =
+static struct ArcProto capmode_proto =
{
'r',
XMTU,
-
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/
[2.6 patch] drivers/net/appletalk/: make 2 firmware images static const
This patch makes two needlessly global fimware images static const.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/appletalk/cops_ffdrv.h |2 +-
drivers/net/appletalk/cops_ltdrv.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ffdrv.h.old
2005-04-19 03:02:05.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ffdrv.h
2005-04-19 03:02:15.0 +0200
@@ -28,7 +28,7 @@
#ifdef CONFIG_COPS_DAYNA
-unsigned char ffdrv_code[] = {
+static const unsigned char ffdrv_code[] = {
58,3,0,50,228,149,33,255,255,34,226,149,
249,17,40,152,33,202,154,183,237,82,77,68,
11,107,98,19,54,0,237,176,175,50,80,0,
--- linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ltdrv.h.old
2005-04-19 03:02:27.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/net/appletalk/cops_ltdrv.h
2005-04-19 03:02:34.0 +0200
@@ -27,7 +27,7 @@
#ifdef CONFIG_COPS_TANGENT
-unsigned char ltdrv_code[] = {
+static const unsigned char ltdrv_code[] = {
58,3,0,50,148,10,33,143,15,62,85,119,
190,32,9,62,170,119,190,32,3,35,24,241,
34,146,10,249,17,150,10,33,143,15,183,237,
-
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: [PATCH x86_64] Live Patching Function on 2.6.11.7
Rik van Riel wrote: (B (B>On Mon, 18 Apr 2005, Takashi Ikebe wrote: (B> (B> (B> (B>>I believe process status copy consume more time, may be below sequences are (B>>needed; (B>>- Stop the service on ACT-process. (B>>- Copy on memory/on transaction status to shared memory. (B>> (B>> (B> (B>No need for this, the process could ALWAYS store its (B>status in a shared memory status. This is just as (B>fast as private memory, only more flexible (B> (B> (BI don't think so, because ACT process must stop service logic to (Btakeover, if the service use network listen port.(ACT process need to (Bstop service and close socket to take over.) (B (B>>- Takeover shared memory key to SBY process and release the shared memory (B>>- SBY process access to shared memory. (B>> (B>> (B> (B>Which means the SBY process can attach to the shared (B>memory region while the ACT process is running. It (B>can then communicate with the ACT process through a (B>socket ... (B> (B> (Bthis makes software developer crazy (B (B>>- SBY process checks the memory and reset broken sessions. (B>>- SBY process restart the service. (B>> (B>> (B> (B>... and the SBY process can take over immediately. (B>The state machine running the SBY software can (B>continue using the same data structures the ACT (B>process was using beforehand, since they're in a (B>shared memory region. (B> (B> (B>>Some part may be parallelize, but seems the more data make service (B>>disruption time longer...(It seems exceeds 100 milliseconds depends on (B>>data size..) and process will be more complicatedmakes more bugs... (B>> (B>> (B> (B>The data size should not be an issue, since the primary (B>copy of the state is in the shared memory area. (B> (B> (BFor me, is seems very dangerous to estimate the primary copy is not (Bbroken through status takeover.. (B (B>The state machine in the SBY process can directly run (B>using those data structures, so no copying is needed. (B> (B>The only overhead will be inter-process communication, (B>having the first process close file descriptors, yielding (B>the CPU to the second process, which then opens up the (B>devices again. We both know how long a context switch (B>and an open() syscall take - negligable. (B> (B>The old version of the program can shut itself down (B>after it knows the new version has taken over - in the (B>background, without disrupting the now active process. (B> (B> (B> (BI think your assumption works on some type of process, but not for all (Bthe process. (BSome process use critical resources such as fixed network listen port (Bcan not speed up so. (BMore importantly, the only process who prepare to use this mechanism (Bonly allows to use quick process takeover. This cause software (Bdevelopment difficult. (BThe live patching does not require to implement such special techniques (Bon applications. (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3: hostap: do not #include .c files
On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote: > drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c" > Please do not #include .c files. A tested patch would be appreciated.. ;-) > A proper separation in a .c file and a header file is the better > solution. Agreed and this is on my to-do list, but not very high on it. Some of these would be relatively easy to fix, but the hardware specific ones (different register offsets for PC Card/PLX/PCI) would require quite a bit of changes to get rid of this. -- Jouni MalinenPGP id EFC895FA - 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/
2.6.12-rc2-mm3: hostap: do not #include .c files
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote: >... > All 819 patches: >... > bk-netdev.patch >... drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_ap.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_info.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_ioctl.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_proc.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_80211_rx.c" drivers/net/wireless/hostap/hostap.c:#include "hostap_80211_tx.c" drivers/net/wireless/hostap/hostap_cs.c:#include "hostap_hw.c" drivers/net/wireless/hostap/hostap_hw.c:#include "hostap_download.c" drivers/net/wireless/hostap/hostap_hw.c:#include "hostap_callback.c" drivers/net/wireless/hostap/hostap_pci.c:#include "hostap_hw.c" drivers/net/wireless/hostap/hostap_plx.c:#include "hostap_hw.c" Please do not #include .c files. A proper separation in a .c file and a header file is the better solution. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: PATCH [PPC64]: dead processes never reaped
On Tue, 2005-04-19 at 11:07 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
> >
> > Hi,
> >
> > The patch below appears to fix a problem where a number of dead processes
> > linger on the system. On a highly loaded system, dozens of processes
> > were found stuck in do_exit(), calling thier very last schedule(), and
> > then being lost forever.
> >
> > Processes that are PF_DEAD are cleaned up *after* the context switch,
> > in a routine called finish_task_switch(task_t *prev). The "prev" gets
> > the value returned by _switch() in entry.S, but this value comes from
> >
> > __switch_to (struct task_struct *prev,
> > struct task_struct *new)
> > {
> >old_thread = ¤t->thread; ///XXX shouldn't this be prev, not
> > current?
> >last = _switch(old_thread, new_thread);
> >return last;
> > }
> >
> > The way I see it, "prev" and "current" are almost always going to be
> > pointing at the same thing; however, if a "need resched" happens,
> > or there's a pre-emept or some-such, then prev and current won't be
> > the same; in which case, finish_task_switch() will end up cleaning
> > up the old current, instead of prev. This will result in dead processes
> > hanging around, which will never be scheduled again, and will never
> > get a chance to have put_task_struct() called on them.
>
> Ok, thinking moer about this ... that will need maybe some help from
> Ingo so I fully understand where schedule's are allowed ... We are
> basically in the middle of the scheduler here, so I wonder how much of
> the scheduler itself can be preempted or so ...
>
Not much. schedule() has a small preempt window at the beginning
and end of the function.
The context switch is of course run with preempt disabled. Ie.
your switch_to should never get preempted.
> Basically, under which circumstances can prev and current be different ?
>
Depends on your context switch, really. prev == current before you
switch, and when you switch to 'new' it is different. However, I think
the 'new' current has *its* old prev on the stack (which == new
current). You just have to preserve the old 'prev' somehow (ie. the
thread you switched away from).
--
SUSE Labs, Novell Inc.
-
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: Relayfs Question: Use of relay_reset(). Potential race?
On Mon, Apr 18, 2005 at 10:56:57AM -0500, Tom Zanussi wrote: > Kingsley Cheung writes: > > On Wed, Mar 23, 2005 at 08:02:54PM +1100, [EMAIL PROTECTED] wrote: > > > Hi > > > > > > I'm using relayfs to relay data from a kernel module to user space on > > > a SuSE 2.6.5 kernel. I'm not absolutely sure what version of relayfs > > > has been back ported to it. > > > > Hi Tom, > > > > Could you please have a look at the following use of relay_reset() in > > a kernel module as follows (compiled against pre-redux relayfs): (snip) > > Is that legitimate? The reason I ask is because I've been seeing > > Yes, you should be able to reset the channel here, since at that point > it's been closed. > > > garbled oopses with keventd and I've narrowed it to two things: > > > > 1) Inadequate locking on my part in the kernel module, which I have > > addressed separately. > > > > 2) A race with relay_reset() and keventd, which is probably of > > interest to you if you're still maintaining the pre-redux patches. > > > > The race is due to the use of INIT_WORK in _reset_relay(): > > > > INIT_WORK(&rchan->wake_readers, NULL, NULL); > > INIT_WORK(&rchan->wake_writers, NULL, NULL); > > > > However, at the time relay_reset() is called, it is possible that > > these work structures are still being used by keventd when under heavy > > loads. The workaround I've used to fix this is to call > > flush_scheduled_work() before calling reset_relay() in the kernel > > module. Perhaps that needs to be called in relay_reset() or > > _relay_reset()? Tom, Thanks for the prompt response. > Yes, flush_scheduled_work() should probably be called from > __relay_reset() - thanks for catching this and suggesting the fix. My pleasure. > BTW, I've updated the old relayfs patch with your previous fixes and > ported it to 2.6.11 - it hasn't appeared yet on the opersys website, > so let me know if you want it and I'll send it, or I can just send you > a new version after I make these changes... Ok, good to hear. I've been using the old patch against an earlier version of the kernel, so I've no rush for a patch against 2.6.11 - you can take your time with these new changes :) > > As well I'm not sure about the uses of INIT_WORK in > > _relay_realloc_buffer() and relay_release() - perhaps they need > > attention too. I understand, however, that flush_schedule_work() > > I'll take a look at this too - looks like there might be a potential > problem if a channel was closed while a resize was in progress. I > don't think anyone's ever actually used resizing, but it should be > fixed nonetheless. > > Thanks, > > Tom > Right. Thanks again for looking at it. -- Kingsley - 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/
[GIT PATCH] USB updates for 2.6.12-rc2
Hm, I think I got this set up properly, but don't have an automated script to generate the changelog and diffstat messages yet, so bear with me... Could you merge with: kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ It should be against your latest git tree. It contains a number of USB patches (that I'm holding on to still, in case something happens to this...) that are bug fix only. The diffstat is below. I'll figure out how to send the patches out to the mailing list later on, if these "stick". And damm if git isn't fast on applying these patches, very nice job, I like it. thanks, greg k-h drivers/net/irda/stir4200.c |4 drivers/usb/class/audio.c | 48 +++--- drivers/usb/class/bluetty.c |4 drivers/usb/core/config.c |3 drivers/usb/core/devices.c|8 - drivers/usb/core/devio.c | 72 ++-- drivers/usb/core/file.c |2 drivers/usb/core/hcd-pci.c| 151 -- drivers/usb/core/hcd.h|4 drivers/usb/core/hub.c| 24 ++--- drivers/usb/core/inode.c |1 drivers/usb/core/message.c| 25 - drivers/usb/core/urb.c| 16 ++- drivers/usb/core/usb.c| 13 -- drivers/usb/core/usb.h|8 + drivers/usb/gadget/ether.c| 56 +--- drivers/usb/gadget/omap_udc.c | 12 +- drivers/usb/gadget/rndis.c| 40 - drivers/usb/gadget/rndis.h|4 drivers/usb/gadget/serial.c |5 - drivers/usb/host/ehci-dbg.c |2 drivers/usb/host/ehci-hcd.c |4 drivers/usb/host/ehci-mem.c |3 drivers/usb/host/ehci-sched.c |4 drivers/usb/host/ehci.h |2 drivers/usb/host/ohci-omap.c |4 drivers/usb/host/ohci-pci.c | 21 +++- drivers/usb/host/ohci-pxa27x.c|5 - drivers/usb/host/ohci-q.c | 13 ++ drivers/usb/host/ohci.h |2 drivers/usb/host/uhci-hcd.c |9 -- drivers/usb/input/aiptek.c|1 drivers/usb/input/hid-core.c |9 -- drivers/usb/media/dabusb.c|3 drivers/usb/media/ov511.c | 12 -- drivers/usb/media/se401.c | 15 +-- drivers/usb/media/usbvideo.c |6 - drivers/usb/media/w9968cf.c |6 - drivers/usb/misc/auerswald.c | 26 ++--- drivers/usb/misc/sisusbvga/sisusb.c |3 drivers/usb/net/pegasus.c | 22 drivers/usb/net/usbnet.c | 32 +-- drivers/usb/net/zd1201.c |3 drivers/usb/serial/belkin_sa.c|3 drivers/usb/serial/cypress_m8.c |5 - drivers/usb/serial/digi_acceleport.c | 10 +- drivers/usb/serial/empeg.c|6 - drivers/usb/serial/ftdi_sio.c | 10 -- drivers/usb/serial/io_edgeport.c | 24 + drivers/usb/serial/io_ti.c|5 - drivers/usb/serial/kl5kusb105.c |3 drivers/usb/serial/omninet.c |5 - drivers/usb/serial/pl2303.c | 56 drivers/usb/serial/pl2303.h |4 drivers/usb/serial/ti_usb_3410_5052.c |3 drivers/usb/serial/visor.c|6 + drivers/usb/serial/visor.h|4 drivers/usb/storage/sddr55.c | 24 + drivers/usb/storage/transport.c |2 drivers/usb/storage/unusual_devs.h| 13 ++ include/linux/usb.h |4 include/linux/usb_cdc.h |2 62 files changed, 467 insertions(+), 429 deletions(-) - 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: PATCH [PPC64]: dead processes never reaped
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
>
> Hi,
>
> The patch below appears to fix a problem where a number of dead processes
> linger on the system. On a highly loaded system, dozens of processes
> were found stuck in do_exit(), calling thier very last schedule(), and
> then being lost forever.
>
> Processes that are PF_DEAD are cleaned up *after* the context switch,
> in a routine called finish_task_switch(task_t *prev). The "prev" gets
> the value returned by _switch() in entry.S, but this value comes from
>
> __switch_to (struct task_struct *prev,
> struct task_struct *new)
> {
>old_thread = ¤t->thread; ///XXX shouldn't this be prev, not current?
>last = _switch(old_thread, new_thread);
>return last;
> }
>
> The way I see it, "prev" and "current" are almost always going to be
> pointing at the same thing; however, if a "need resched" happens,
> or there's a pre-emept or some-such, then prev and current won't be
> the same; in which case, finish_task_switch() will end up cleaning
> up the old current, instead of prev. This will result in dead processes
> hanging around, which will never be scheduled again, and will never
> get a chance to have put_task_struct() called on them.
Ok, thinking moer about this ... that will need maybe some help from
Ingo so I fully understand where schedule's are allowed ... We are
basically in the middle of the scheduler here, so I wonder how much of
the scheduler itself can be preempted or so ...
Basically, under which circumstances can prev and current be different ?
Ben.
-
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: PATCH [PPC64]: dead processes never reaped
On Mon, 2005-04-18 at 14:38 -0500, Linas Vepstas wrote:
>
> Hi,
>
> The patch below appears to fix a problem where a number of dead processes
> linger on the system. On a highly loaded system, dozens of processes
> were found stuck in do_exit(), calling thier very last schedule(), and
> then being lost forever.
>
> Processes that are PF_DEAD are cleaned up *after* the context switch,
> in a routine called finish_task_switch(task_t *prev). The "prev" gets
> the value returned by _switch() in entry.S, but this value comes from
>
> __switch_to (struct task_struct *prev,
> struct task_struct *new)
> {
>old_thread = ¤t->thread; ///XXX shouldn't this be prev, not current?
>last = _switch(old_thread, new_thread);
>return last;
> }
>
> The way I see it, "prev" and "current" are almost always going to be
> pointing at the same thing; however, if a "need resched" happens,
> or there's a pre-emept or some-such, then prev and current won't be
> the same; in which case, finish_task_switch() will end up cleaning
> up the old current, instead of prev. This will result in dead processes
> hanging around, which will never be scheduled again, and will never
> get a chance to have put_task_struct() called on them.
I wonder why we bother doing all that at all... we could just return
"prev" from __switch_to() no ? Like x86 does...
Ben.
-
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/
[RFC][PATCH] X86_64: no legacy HPET fix (v. A1)
On Wed, 2005-04-13 at 19:21 -0700, Venkatesh Pallipadi wrote:
>
> This adds another timer combination of PIT/HPET to go with
> HPET/HPET, HPET/TSC and PIT/TSC!
> This system that has HPET and doesn't have Legacy support, does it support
> routing HPET interrupts through IOAPIC in standard routing option? If yes,
> then I think adding support to route HPET interrupts in a non-legacy way
> (using IRQs other than IRQ 0) is another option here. I looked at that
> when adding initial HPET support on i386, but dropped that idea after looking
> at all the changes required and also due to the reason that all HPET capable
> systems I had also had Legacy Support.
Using HPET interrupts via the IOAPIC would be a possibility, but seems
more invasive then what I'm proposing.
> Some comments on the patch inlined below..
>
> On Tue, Apr 12, 2005 at 07:43:16PM -0700, john stultz wrote:
> >
> > Its likely a similar patch will be necessary for i386.
> Yes. Pretty much similar change will be required in i386 as well..
I've still got that on my list.
> > linux-2.6.12-rc2_hpet-nolegacy-fix_A0
> > =
> > diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
> > --- a/arch/x86_64/kernel/time.c 2005-04-12 19:31:50 -07:00
> > +++ b/arch/x86_64/kernel/time.c 2005-04-12 19:31:50 -07:00
> > @@ -373,8 +374,10 @@
> >
> > write_seqlock(&xtime_lock);
> >
> > - if (vxtime.hpet_address) {
> > - offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
> > + if (vxtime.hpet_address)
> > + offset = hpet_readl(HPET_COUNTER);
> > +
> > + if (hpet_use_timer) {
> > delay = hpet_readl(HPET_COUNTER) - offset;
>
> Probably this has to change to use HPET_T0_CMP for offset, when
> hpet_use_timer.
> Otherwise we will always have delay close to zero in case of hpet_use_timer,
> which is a change in behaviour.
Ok, done.
> > } else {
> > spin_lock(&i8253_lock);
> > @@ -732,7 +735,7 @@
> > struct hpet_datahd;
> > unsigned intntimer;
> >
> > - if (!vxtime.hpet_address)
> > + if (!hpet_use_timer)
> >return -1;
>
> We may need to do some initialization here even in case of !hpet_use_timer.
> Like reserving particular HPET timer for timer use. Otherwise, someone
> else (/dev/hpet) can overwrite the counter. I think we just need to skip
> setting the interupts part.
I just went back to leaving that change out, then.
Let me know if you have any further comments on the updated patch
(included below). If not I'll submit it to Andrew and the Distros.
thanks
-john
linux-2.6.12-rc2_hpet-nolegacy-fix_A1
=
diff -Nru a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
--- a/arch/x86_64/kernel/time.c 2005-04-18 10:00:44 -07:00
+++ b/arch/x86_64/kernel/time.c 2005-04-18 10:00:44 -07:00
@@ -60,6 +60,7 @@
unsigned int cpu_khz; /* TSC clocks / usec,
not used here */
static unsigned long hpet_period; /* fsecs / HPET clock */
unsigned long hpet_tick; /* HPET clocks /
interrupt */
+static int hpet_use_timer;
unsigned long vxtime_hz = PIT_TICK_RATE;
int report_lost_ticks; /* command line option */
unsigned long long monotonic_base;
@@ -297,7 +298,7 @@
last_offset = vxtime.last;
base = monotonic_base;
- this_offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+ this_offset = hpet_readl(HPET_COUNTER);
} while (read_seqretry(&xtime_lock, seq));
offset = (this_offset - last_offset);
@@ -373,7 +374,14 @@
write_seqlock(&xtime_lock);
- if (vxtime.hpet_address) {
+ if (vxtime.hpet_address)
+ offset = hpet_readl(HPET_COUNTER);
+
+ if (hpet_use_timer) {
+ /* if we're using the hpet timer functionality,
+* we can more accurately know the counter value
+* when the timer interrupt occured.
+*/
offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
delay = hpet_readl(HPET_COUNTER) - offset;
} else {
@@ -794,17 +802,18 @@
* Set up timer 0, as periodic with first interrupt to happen at hpet_tick,
* and period also hpet_tick.
*/
-
- hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
+ if (hpet_use_timer) {
+ hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
HPET_TN_32BIT, HPET_T0_CFG);
- hpet_writel(hpet_tick, HPET_T0_CMP);
- hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
-
+ hpet_writel(hpet_tick, HPET_T0_CMP);
+ hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */
+ cfg |= HPET_CFG_LEGACY;
+ }
/*
* Go!
*/
- cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
[2.6 patch] drivers/media/video/tveeprom.c: possible cleanups
This patch contains the following possible cleanups:
- make two needlessly global structs static
- #if 0 the EXPORT_SYMBOL'ed but unused function tveeprom_dump
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/tveeprom.c |6 --
include/media/tveeprom.h |1 -
2 files changed, 4 insertions(+), 3 deletions(-)
--- linux-2.6.12-rc2-mm3-full/include/media/tveeprom.h.old 2005-04-19
01:41:24.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/media/tveeprom.h 2005-04-19
01:41:28.0 +0200
@@ -20,4 +20,3 @@
unsigned char *eeprom_data);
int tveeprom_read(struct i2c_client *c, unsigned char *eedata, int len);
-int tveeprom_dump(unsigned char *eedata, int len);
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/tveeprom.c.old
2005-04-19 01:40:39.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/tveeprom.c2005-04-19
01:41:13.0 +0200
@@ -453,6 +453,7 @@
}
EXPORT_SYMBOL(tveeprom_read);
+#if 0
int tveeprom_dump(unsigned char *eedata, int len)
{
int i;
@@ -468,6 +469,7 @@
return 0;
}
EXPORT_SYMBOL(tveeprom_dump);
+#endif /* 0 */
/* --- */
/* needed for ivtv.sf.net at the moment. Should go away in the long */
@@ -484,7 +486,7 @@
};
I2C_CLIENT_INSMOD;
-struct i2c_driver i2c_driver_tveeprom;
+static struct i2c_driver i2c_driver_tveeprom;
static int
tveeprom_command(struct i2c_client *client,
@@ -556,7 +558,7 @@
return 0;
}
-struct i2c_driver i2c_driver_tveeprom = {
+static struct i2c_driver i2c_driver_tveeprom = {
.owner = THIS_MODULE,
.name = "tveeprom",
.id = I2C_DRIVERID_TVEEPROM,
-
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/
[2.6 patch] drivers/media/video/saa7134/saa7134-dvb.c: make a struct static
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/saa7134/saa7134-dvb.c.old
2005-04-19 01:39:58.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/saa7134/saa7134-dvb.c
2005-04-19 01:40:08.0 +0200
@@ -172,7 +172,7 @@
return request_firmware(fw, name, &dev->pci->dev);
}
-struct tda1004x_config medion_cardbus = {
+static struct tda1004x_config medion_cardbus = {
.demod_address = 0x08, /* not sure this is correct */
.invert= 0,
.invert_oclk = 0,
-
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/
[2.6 patch] drivers/media/common/saa7146_fops.c: make a function static
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.12-rc2-mm3-full/drivers/media/common/saa7146_fops.c.old
2005-04-19 01:21:37.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/common/saa7146_fops.c
2005-04-19 01:21:50.0 +0200
@@ -403,7 +403,7 @@
.llseek = no_llseek,
};
-void vv_callback(struct saa7146_dev *dev, unsigned long status)
+static void vv_callback(struct saa7146_dev *dev, unsigned long status)
{
u32 isr = status;
-
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/
[2.6 patch] drivers/md/: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/md/dm-hw-handler.c|2 +-
drivers/md/dm-path-selector.c |2 +-
drivers/md/dm-table.c |2 +-
drivers/md/dm-zero.c |4 ++--
drivers/md/md.c | 14 +++---
drivers/md/multipath.c|3 ++-
6 files changed, 14 insertions(+), 13 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/md/dm-hw-handler.c.old2005-04-19
00:46:32.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/md/dm-hw-handler.c2005-04-19
00:46:39.0 +0200
@@ -23,7 +23,7 @@
static LIST_HEAD(_hw_handlers);
static DECLARE_RWSEM(_hwh_lock);
-struct hwh_internal *__find_hw_handler_type(const char *name)
+static struct hwh_internal *__find_hw_handler_type(const char *name)
{
struct hwh_internal *hwhi;
--- linux-2.6.12-rc2-mm3-full/drivers/md/dm-path-selector.c.old 2005-04-19
00:47:18.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/md/dm-path-selector.c 2005-04-19
00:47:28.0 +0200
@@ -26,7 +26,7 @@
static LIST_HEAD(_path_selectors);
static DECLARE_RWSEM(_ps_lock);
-struct ps_internal *__find_path_selector_type(const char *name)
+static struct ps_internal *__find_path_selector_type(const char *name)
{
struct ps_internal *psi;
--- linux-2.6.12-rc2-mm3-full/drivers/md/dm-table.c.old 2005-04-19
00:48:00.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/md/dm-table.c 2005-04-19
00:48:07.0 +0200
@@ -242,7 +242,7 @@
}
}
-void table_destroy(struct dm_table *t)
+static void table_destroy(struct dm_table *t)
{
unsigned int i;
--- linux-2.6.12-rc2-mm3-full/drivers/md/dm-zero.c.old 2005-04-19
00:48:17.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/md/dm-zero.c 2005-04-19
00:48:37.0 +0200
@@ -55,7 +55,7 @@
.map= zero_map,
};
-int __init dm_zero_init(void)
+static int __init dm_zero_init(void)
{
int r = dm_register_target(&zero_target);
@@ -65,7 +65,7 @@
return r;
}
-void __exit dm_zero_exit(void)
+static void __exit dm_zero_exit(void)
{
int r = dm_unregister_target(&zero_target);
--- linux-2.6.12-rc2-mm3-full/drivers/md/md.c.old 2005-04-19
00:50:02.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/md/md.c 2005-04-19 00:51:12.0
+0200
@@ -1046,7 +1046,7 @@
}
-struct super_type super_types[] = {
+static struct super_type super_types[] = {
[0] = {
.name = "0.90.0",
.owner = THIS_MODULE,
@@ -2942,7 +2942,7 @@
.revalidate_disk= md_revalidate,
};
-int md_thread(void * arg)
+static int md_thread(void * arg)
{
mdk_thread_t *thread = arg;
@@ -3440,7 +3440,7 @@
}
}
-DECLARE_WAIT_QUEUE_HEAD(resync_wait);
+static DECLARE_WAIT_QUEUE_HEAD(resync_wait);
#define SYNC_MARKS 10
#defineSYNC_MARK_STEP (3*HZ)
@@ -3837,8 +3837,8 @@
}
}
-int md_notify_reboot(struct notifier_block *this,
- unsigned long code, void *x)
+static int md_notify_reboot(struct notifier_block *this,
+ unsigned long code, void *x)
{
struct list_head *tmp;
mddev_t *mddev;
@@ -3861,7 +3861,7 @@
return NOTIFY_DONE;
}
-struct notifier_block md_notifier = {
+static struct notifier_block md_notifier = {
.notifier_call = md_notify_reboot,
.next = NULL,
.priority = INT_MAX, /* before any real devices */
@@ -3878,7 +3878,7 @@
p->proc_fops = &md_seq_fops;
}
-int __init md_init(void)
+static int __init md_init(void)
{
int minor;
--- linux-2.6.12-rc2-mm3-full/drivers/md/multipath.c.old2005-04-19
00:51:23.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/md/multipath.c2005-04-19
00:51:36.0 +0200
@@ -103,7 +103,8 @@
mempool_free(mp_bh, conf->pool);
}
-int multipath_end_request(struct bio *bio, unsigned int bytes_done, int error)
+static int multipath_end_request(struct bio *bio, unsigned int bytes_done,
+int error)
{
int uptodate = test_bit(BIO_UPTODATE, &bio->bi_flags);
struct multipath_bh * mp_bh = (struct multipath_bh *)(bio->bi_private);
-
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/
[2.6 patch] drivers/isdn/: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/isdn/hardware/eicon/dadapter.c |2 +-
drivers/isdn/hisax/hfc4s8s_l1.c|4 ++--
drivers/isdn/hysdn/hycapi.c| 20 +++-
drivers/isdn/hysdn/hysdn_boot.c|4 ++--
drivers/isdn/hysdn/hysdn_defs.h| 12
drivers/isdn/hysdn/hysdn_init.c|2 +-
drivers/isdn/hysdn/hysdn_proclog.c |4 +++-
7 files changed, 20 insertions(+), 28 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/isdn/hisax/hfc4s8s_l1.c.old
2005-04-19 00:32:31.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/isdn/hisax/hfc4s8s_l1.c 2005-04-19
00:32:46.0 +0200
@@ -1464,7 +1464,7 @@
/**/
/* disable memory mapped ports / io ports */
/**/
-void
+static void
release_pci_ports(hfc4s8s_hw * hw)
{
pci_write_config_word(hw->pdev, PCI_COMMAND, 0);
@@ -1480,7 +1480,7 @@
/*/
/* enable memory mapped ports / io ports */
/*/
-void
+static void
enable_pci_ports(hfc4s8s_hw * hw)
{
#ifdef CONFIG_HISAX_HFC4S8S_PCIMEM
--- linux-2.6.12-rc2-mm3-full/drivers/isdn/hysdn/hysdn_defs.h.old
2005-04-19 00:33:51.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/isdn/hysdn/hysdn_defs.h 2005-04-19
00:38:25.0 +0200
@@ -227,7 +227,6 @@
/*/
/* exported vars */
/*/
-extern int cardmax;/* number of found cards */
extern hysdn_card *card_root; /* pointer to first card */
@@ -244,7 +243,6 @@
/* hysdn_proclog.c */
extern int hysdn_proclog_init(hysdn_card *); /* init proc log entry */
extern void hysdn_proclog_release(hysdn_card *); /* deinit proc log
entry */
-extern void put_log_buffer(hysdn_card *, char *); /* output log data */
extern void hysdn_addlog(hysdn_card *, char *,...);/* output data to log */
extern void hysdn_card_errlog(hysdn_card *, tErrLogEntry *, int); /*
output card log */
@@ -278,16 +276,6 @@
extern int hycapi_capi_create(hysdn_card *); /* create a new capi device */
extern int hycapi_capi_release(hysdn_card *); /* delete the device */
extern int hycapi_capi_stop(hysdn_card *card); /* suspend */
-extern int hycapi_load_firmware(struct capi_ctr *, capiloaddata *);
-extern void hycapi_reset_ctr(struct capi_ctr *);
-extern void hycapi_remove_ctr(struct capi_ctr *);
-extern void hycapi_register_appl(struct capi_ctr *, __u16 appl,
-capi_register_params *);
-extern void hycapi_release_appl(struct capi_ctr *, __u16 appl);
-extern u16 hycapi_send_message(struct capi_ctr *, struct sk_buff *skb);
-extern char *hycapi_procinfo(struct capi_ctr *);
-extern int hycapi_read_proc(char *page, char **start, off_t off,
- int count, int *eof, struct capi_ctr *card);
extern void hycapi_rx_capipkt(hysdn_card * card, uchar * buf, word len);
extern void hycapi_tx_capiack(hysdn_card * card);
extern struct sk_buff *hycapi_tx_capiget(hysdn_card *card);
--- linux-2.6.12-rc2-mm3-full/drivers/isdn/hysdn/hycapi.c.old 2005-04-19
00:34:05.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/isdn/hysdn/hycapi.c 2005-04-19
00:36:34.0 +0200
@@ -42,6 +42,8 @@
static hycapi_appl hycapi_applications[CAPI_MAXAPPL];
+static u16 hycapi_send_message(struct capi_ctr *ctrl, struct sk_buff *skb);
+
static inline int _hycapi_appCheck(int app_id, int ctrl_no)
{
if((ctrl_no <= 0) || (ctrl_no > CAPI_MAXCONTR) || (app_id <= 0) ||
@@ -57,7 +59,7 @@
Kernel-Capi callback reset_ctr
**/
-void
+static void
hycapi_reset_ctr(struct capi_ctr *ctrl)
{
hycapictrl_info *cinfo = ctrl->driverdata;
@@ -73,7 +75,7 @@
Kernel-Capi callback remove_ctr
**/
-void
+static void
hycapi_remove_ctr(struct capi_ctr *ctrl)
{
int i;
@@ -215,7 +217,7 @@
The application is recorded in the internal list.
*/
-void
+static void
hycapi_register_appl(struct capi_ctr *ctrl, __u16 appl,
capi_register_params *rp)
{
@@ -291,7 +293,7 @@
registration at controller-level
**/
-void
+static void
hycapi_release_appl(struct capi_ctr *ctrl, __u16 appl)
{
int chk;
@@ -364,7 +366,7 @@
***/
-u16 hycapi_send_message(struct capi_ctr *ctrl, struct sk_buff *skb)
+static u16 hycapi_send_message(struct capi_ctr *ctrl, struct sk_buff *skb)
{
__u16 appl_id;
int _len, _len2;
@@ -437,8 +439,8 @@
*/
-int hycapi_read_proc(char *page, char **start, off_t off
[2.6 patch] drivers/ieee1394/ieee1394_transactions.c: possible cleanups
This patch contains the following possible cleanups: - #if 0 the following unused global functions: - hpsb_lock - hpsb_send_gasp - ieee1394_transactions.h: remove the stale hpsb_lock64 prototype Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/ieee1394/ieee1394_transactions.c |3 +++ drivers/ieee1394/ieee1394_transactions.h |7 --- 2 files changed, 3 insertions(+), 7 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.h.old 2005-04-19 00:24:13.0 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.h 2005-04-19 00:25:00.0 +0200 @@ -53,12 +53,5 @@ u64 addr, quadlet_t *buffer, size_t length); int hpsb_write(struct hpsb_host *host, nodeid_t node, unsigned int generation, u64 addr, quadlet_t *buffer, size_t length); -int hpsb_lock(struct hpsb_host *host, nodeid_t node, unsigned int generation, - u64 addr, int extcode, quadlet_t *data, quadlet_t arg); -int hpsb_lock64(struct hpsb_host *host, nodeid_t node, unsigned int generation, - u64 addr, int extcode, octlet_t *data, octlet_t arg); -int hpsb_send_gasp(struct hpsb_host *host, int channel, unsigned int generation, - quadlet_t *buffer, size_t length, u32 specifier_id, - unsigned int version); #endif /* _IEEE1394_TRANSACTIONS_H */ --- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.c.old 2005-04-19 00:24:31.0 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_transactions.c 2005-04-19 00:24:51.0 +0200 @@ -535,6 +535,7 @@ return retval; } +#if 0 int hpsb_lock(struct hpsb_host *host, nodeid_t node, unsigned int generation, u64 addr, int extcode, quadlet_t *data, quadlet_t arg) @@ -599,3 +600,5 @@ return retval; } + +#endif /* 0 */ - 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/
[2.6 patch] drivers/media/dvb/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 the following unused global functions:
- dibusb/dvb-dibusb-usb.c: dibusb_set_streaming_mode
- frontends/mt352.c: mt352_read
- ttpci/av7110_hw.c: av7110_reset_arm
- ttpci/av7110_hw.c: av7110_send_ci_cmd
- remove the following unneeded EXPORT_SYMBOL:
- frontends/mt352.c: mt352_read
Please review which of these changes do make sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/dvb/dibusb/dvb-dibusb-usb.c |2 ++
drivers/media/dvb/dibusb/dvb-dibusb.h |1 -
drivers/media/dvb/frontends/mt352.c |3 ++-
drivers/media/dvb/frontends/mt352.h |1 -
drivers/media/dvb/ttpci/av7110.h |1 -
drivers/media/dvb/ttpci/av7110_hw.c | 12 +++-
drivers/media/dvb/ttpci/av7110_hw.h |5 -
drivers/media/dvb/ttpci/av7110_v4l.c |2 +-
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c |2 +-
drivers/media/dvb/ttusb-dec/ttusb_dec.c |8
10 files changed, 17 insertions(+), 20 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/media/dvb/dibusb/dvb-dibusb.h.old
2005-04-19 01:23:04.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/dvb/dibusb/dvb-dibusb.h
2005-04-19 01:23:09.0 +0200
@@ -230,7 +230,6 @@
int dibusb_hw_wakeup(struct dvb_frontend *);
int dibusb_hw_sleep(struct dvb_frontend *);
-int dibusb_set_streaming_mode(struct usb_dibusb *,u8);
int dibusb_streaming(struct usb_dibusb *,int);
int dibusb_urb_init(struct usb_dibusb *);
--- linux-2.6.12-rc2-mm3-full/drivers/media/dvb/dibusb/dvb-dibusb-usb.c.old
2005-04-19 01:23:17.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/dvb/dibusb/dvb-dibusb-usb.c
2005-04-19 01:23:30.0 +0200
@@ -139,11 +139,13 @@
return 0;
}
+#if 0
int dibusb_set_streaming_mode(struct usb_dibusb *dib,u8 mode)
{
u8 b[2] = { DIBUSB_REQ_SET_STREAMING_MODE, mode };
return dibusb_readwrite_usb(dib,b,2,NULL,0);
}
+#endif /* 0 */
static int dibusb_urb_kill(struct usb_dibusb *dib)
{
--- linux-2.6.12-rc2-mm3-full/drivers/media/dvb/frontends/mt352.h.old
2005-04-19 01:25:12.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/dvb/frontends/mt352.h
2005-04-19 01:25:18.0 +0200
@@ -61,7 +61,6 @@
struct i2c_adapter* i2c);
extern int mt352_write(struct dvb_frontend* fe, u8* ibuf, int ilen);
-extern int mt352_read(struct dvb_frontend *fe, u8 reg);
#endif // MT352_H
--- linux-2.6.12-rc2-mm3-full/drivers/media/dvb/frontends/mt352.c.old
2005-04-19 01:25:26.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/dvb/frontends/mt352.c
2005-04-19 01:44:26.0 +0200
@@ -102,10 +102,12 @@
return b1[0];
}
+#if 0
int mt352_read(struct dvb_frontend *fe, u8 reg)
{
return mt352_read_register(fe->demodulator_priv,reg);
}
+#endif /* 0 */
static int mt352_sleep(struct dvb_frontend* fe)
{
@@ -601,7 +603,6 @@
EXPORT_SYMBOL(mt352_attach);
EXPORT_SYMBOL(mt352_write);
-EXPORT_SYMBOL(mt352_read);
/*
* Local variables:
* c-basic-offset: 8
--- linux-2.6.12-rc2-mm3-full/drivers/media/dvb/ttpci/av7110_hw.h.old
2005-04-19 01:26:30.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/dvb/ttpci/av7110_hw.h
2005-04-19 01:29:15.0 +0200
@@ -364,7 +364,6 @@
-extern void av7110_reset_arm(struct av7110 *av7110);
extern int av7110_bootarm(struct av7110 *av7110);
extern int av7110_firmversion(struct av7110 *av7110);
#define FW_CI_LL_SUPPORT(arm_app) ((arm_app) & 0x8000)
@@ -373,12 +372,8 @@
extern int av7110_wait_msgstate(struct av7110 *av7110, u16 flags);
extern int av7110_fw_cmd(struct av7110 *av7110, int type, int com, int num,
...);
-extern int __av7110_send_fw_cmd(struct av7110 *av7110, u16* buf, int length);
-extern int av7110_send_fw_cmd(struct av7110 *av7110, u16* buf, int length);
-extern int av7110_send_ci_cmd(struct av7110 *av7110, u8 subcom, u8 *buf, u8
len);
extern int av7110_fw_request(struct av7110 *av7110, u16 *request_buf,
int request_buf_len, u16 *reply_buf, int
reply_buf_len);
-extern int av7110_fw_query(struct av7110 *av7110, u16 tag, u16* Buff, s16
length);
/* DEBI (saa7146 data extension bus interface) access */
--- linux-2.6.12-rc2-mm3-full/drivers/media/dvb/ttpci/av7110_hw.c.old
2005-04-19 01:27:14.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/dvb/ttpci/av7110_hw.c
2005-04-19 01:29:23.0 +0200
@@ -104,7 +104,7 @@
/* av7110 ARM core boot stuff */
-
+#if 0
void av7110_reset_arm(struct av7110 *av7110)
{
saa7146_setgpio(av7110->dev, RESET_LINE, SAA7146_GPIO_OUTLO);
@@ -124,7 +124,7 @@
av7110->arm_ready = 1;
dprintk(1, "reset ARM\n");
}
-
+#endif /* 0 */
static int waitdebi(struct av71
[2.6 patch] drivers/media/video/cx88/: possible cleanups
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unneeded EXPORT_SYMBOL:
- cx88-core.c: cx88_pci_irqs
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/cx88/cx88-core.c |5 ++---
drivers/media/video/cx88/cx88-dvb.c |4 ++--
drivers/media/video/cx88/cx88-i2c.c |4 ++--
drivers/media/video/cx88/cx88-vbi.c |6 +++---
drivers/media/video/cx88/cx88-video.c | 12 ++--
drivers/media/video/cx88/cx88.h |4
6 files changed, 15 insertions(+), 20 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88.h.old
2005-04-19 01:35:51.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88.h 2005-04-19
01:37:54.0 +0200
@@ -420,7 +420,6 @@
/* --- */
/* cx88-core.c */
-extern char *cx88_pci_irqs[32];
extern char *cx88_vid_irqs[32];
extern char *cx88_mpeg_irqs[32];
extern void cx88_print_irqbits(char *name, char *tag, char **strings,
@@ -472,9 +471,6 @@
/* cx88-vbi.c */
void cx8800_vbi_fmt(struct cx8800_dev *dev, struct v4l2_format *f);
-int cx8800_start_vbi_dma(struct cx8800_dev*dev,
-struct cx88_dmaqueue *q,
-struct cx88_buffer *buf);
int cx8800_stop_vbi_dma(struct cx8800_dev *dev);
int cx8800_restart_vbi_queue(struct cx8800_dev*dev,
struct cx88_dmaqueue *q);
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-core.c.old
2005-04-19 01:36:05.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-core.c
2005-04-19 01:36:30.0 +0200
@@ -429,7 +429,7 @@
/* -- */
/* debug helper code */
-int cx88_risc_decode(u32 risc)
+static int cx88_risc_decode(u32 risc)
{
static char *instr[16] = {
[ RISC_SYNC>> 28 ] = "sync",
@@ -542,7 +542,7 @@
core->name,cx_read(ch->cnt2_reg));
}
-char *cx88_pci_irqs[32] = {
+static char *cx88_pci_irqs[32] = {
"vid", "aud", "ts", "vip", "hst", "5", "6", "tm1",
"src_dma", "dst_dma", "risc_rd_err", "risc_wr_err",
"brdg_err", "src_dma_err", "dst_dma_err", "ipb_dma_err",
@@ -1206,7 +1206,6 @@
/* -- */
EXPORT_SYMBOL(cx88_print_ioctl);
-EXPORT_SYMBOL(cx88_pci_irqs);
EXPORT_SYMBOL(cx88_vid_irqs);
EXPORT_SYMBOL(cx88_mpeg_irqs);
EXPORT_SYMBOL(cx88_print_irqbits);
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-dvb.c.old
2005-04-19 01:36:39.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-dvb.c
2005-04-19 01:36:56.0 +0200
@@ -91,7 +91,7 @@
cx88_free_buffer(dev->pci, (struct cx88_buffer*)vb);
}
-struct videobuf_queue_ops dvb_qops = {
+static struct videobuf_queue_ops dvb_qops = {
.buf_setup= dvb_buf_setup,
.buf_prepare = dvb_buf_prepare,
.buf_queue= dvb_buf_queue,
@@ -191,7 +191,7 @@
return 0;
}
-struct or51132_config pchdtv_hd3000 = {
+static struct or51132_config pchdtv_hd3000 = {
.demod_address= 0x15,
.pll_address = 0x61,
.pll_desc = &dvb_pll_thomson_dtt7610,
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-i2c.c.old
2005-04-19 01:37:06.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-i2c.c
2005-04-19 01:37:23.0 +0200
@@ -45,7 +45,7 @@
/* --- */
-void cx8800_bit_setscl(void *data, int state)
+static void cx8800_bit_setscl(void *data, int state)
{
struct cx88_core *core = data;
@@ -57,7 +57,7 @@
cx_read(MO_I2C);
}
-void cx8800_bit_setsda(void *data, int state)
+static void cx8800_bit_setsda(void *data, int state)
{
struct cx88_core *core = data;
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-vbi.c.old
2005-04-19 01:38:02.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-vbi.c
2005-04-19 01:38:11.0 +0200
@@ -46,9 +46,9 @@
}
}
-int cx8800_start_vbi_dma(struct cx8800_dev*dev,
-struct cx88_dmaqueue *q,
-struct cx88_buffer *buf)
+static int cx8800_start_vbi_dma(struct cx8800_dev*dev,
+ struct cx88_dmaqueue *q,
+ struct cx88_buffer *buf)
{
struct cx88_core *core = dev->core;
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-video.c.old
2005-04-19 01:38:22.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/cx88/cx88-video.c
2005-04-19 01:39:19.0
[2.6 patch] drivers/media/video/bttv-driver.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/media/video/bttv-driver.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/bttv-driver.c.old
2005-04-19 01:32:53.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/bttv-driver.c 2005-04-19
01:33:31.0 +0200
@@ -3169,7 +3169,7 @@
/* --- */
/* some debug code */
-int bttv_risc_decode(u32 risc)
+static int bttv_risc_decode(u32 risc)
{
static char *instr[16] = {
[ BT848_RISC_WRITE >> 28 ] = "write",
@@ -3206,8 +3206,8 @@
return incr[risc >> 28] ? incr[risc >> 28] : 1;
}
-void bttv_risc_disasm(struct bttv *btv,
- struct btcx_riscmem *risc)
+static void bttv_risc_disasm(struct bttv *btv,
+struct btcx_riscmem *risc)
{
unsigned int i,j,n;
-
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/
[2.6 patch] drivers/net/seeq8005.c: cleanups
This patch contains the following cleanups:
- make the needlessly global function seeq8005_init static
- kill an ancient version variable
- remove some outdated Emacs settings
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 21 Feb 2005
drivers/net/seeq8005.c | 23 ++-
1 files changed, 2 insertions(+), 21 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/seeq8005.c.old2005-02-16
18:18:56.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/seeq8005.c2005-02-21
15:19:11.0 +0100
@@ -12,12 +12,6 @@
This file is a network device driver for the SEEQ 8005 chipset and
the Linux operating system.
-*/
-
-static const char version[] =
- "seeq8005.c:v1.00 8/07/95 Hamish Coleman ([EMAIL PROTECTED])\n";
-
-/*
Sources:
SEEQ 8005 databook
@@ -91,7 +85,7 @@
/* Example routines you must write ;->. */
#define tx_done(dev) (inw(SEEQ_STATUS) & SEEQSTAT_TX_ON)
static void hardware_send_packet(struct net_device *dev, char *buf, int
length);
-extern void seeq8005_init(struct net_device *dev, int startp);
+static void seeq8005_init(struct net_device *dev, int startp);
static inline void wait_for_buffer(struct net_device *dev);
@@ -150,7 +144,6 @@
static int __init seeq8005_probe1(struct net_device *dev, int ioaddr)
{
- static unsigned version_printed;
int i,j;
unsigned char SA_prom[32];
int old_cfg1;
@@ -291,9 +284,6 @@
}
#endif
- if (net_debug && version_printed++ == 0)
- printk(version);
-
printk("%s: %s found at %#3x, ", dev->name, "seeq8005", ioaddr);
/* Fill in the 'dev' fields. */
@@ -637,7 +627,7 @@
#endif
}
-void seeq8005_init(struct net_device *dev, int startp)
+static void seeq8005_init(struct net_device *dev, int startp)
{
struct net_local *lp = netdev_priv(dev);
int ioaddr = dev->base_addr;
@@ -758,12 +748,3 @@
}
#endif /* MODULE */
-
-/*
- * Local variables:
- * compile-command: "gcc -D__KERNEL__ -I/usr/src/linux/net/inet -Wall
-Wstrict-prototypes -O6 -m486 -c skeleton.c"
- * version-control: t
- * kept-new-versions: 5
- * tab-width: 4
- * End:
- */
-
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/
[2.6 patch] drivers/net/ne3210.c: cleanups
This patch contains the following cleanups:
- make two needlessly global functions static
- kill an ancient version variable
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/ne3210.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
--- linux-2.6.11-rc3-mm2-full/drivers/net/ne3210.c.old 2005-02-16
16:09:39.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/ne3210.c 2005-02-21
15:10:02.0 +0100
@@ -26,9 +26,6 @@
Updated to EISA probing API 5/2003 by Marc Zyngier.
*/
-static const char *version =
- "ne3210.c: Driver revision v0.03, 30/09/98\n";
-
#include
#include
#include
@@ -197,7 +194,7 @@
ei_status.priv = phys_mem;
if (ei_debug > 0)
- printk(version);
+ printk("ne3210 loaded.\n");
ei_status.reset_8390 = &ne3210_reset_8390;
ei_status.block_input = &ne3210_block_input;
@@ -359,12 +356,12 @@
MODULE_DESCRIPTION("NE3210 EISA Ethernet driver");
MODULE_LICENSE("GPL");
-int ne3210_init(void)
+static int ne3210_init(void)
{
return eisa_driver_register (&ne3210_eisa_driver);
}
-void ne3210_cleanup(void)
+static void ne3210_cleanup(void)
{
eisa_driver_unregister (&ne3210_eisa_driver);
}
-
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: [RFC 1 of 9] patches to add diskdump functionality to block layer
On Mon, Apr 18, 2005 at 12:14:06PM -0500, Miller, Mike (OS Dev) wrote: > > From: Christoph Hellwig [mailto:[EMAIL PROTECTED] > > > > This looks like a patch for Linux 2.4. Such major changes for the > > 2.4 tree don't make sense anymore, especially for > > functionality not even in Linux 2.6. > > > This is for 2.4, I should have specified that in the Subject line. We > did this work because of customer demand and a request from a vendor. > Marcelo, is this something that you be interested in adding to 2.4? If > not, I'll just submit this directly to the vendor. Mike, Nope, that does not look suitable for v2.4.x. - 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] Leadtek Winfast remote controls
Hi Andrew, This patch against kernel 2.6.12-rc2 adds missing button codes for the Leadtek Winfast remote controls. Concerning the KEY_* values, I tried to be coherent with the other remote controls supported by the kernel. Best regards, Nicolas -- Add missing button codes for the Leadtek Winfast remote controls. Signed-off-by: Nicolas Boichat <[EMAIL PROTECTED]> --- drivers/media/common/ir-common.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff -rpuN drivers/media.old/common/ir-common.c drivers/media/common/ir-common.c --- drivers/media.old/common/ir-common.c2005-04-05 00:24:57.0 +0200 +++ drivers/media/common/ir-common.c2005-04-07 15:52:22.0 +0200 @@ -131,10 +131,10 @@ IR_KEYTAB_TYPE ir_codes_winfast[IR_KEYTA [ 18 ] = KEY_KP0, [ 0 ] = KEY_POWER, -// [ 27 ] = MTS button +[ 27 ] = KEY_LANGUAGE, //MTS button [ 2 ] = KEY_TUNER, // TV/FM [ 30 ] = KEY_VIDEO, -// [ 22 ] = display button +[ 22 ] = KEY_INFO, //display button [ 4 ] = KEY_VOLUMEUP, [ 8 ] = KEY_VOLUMEDOWN, [ 12 ] = KEY_CHANNELUP, @@ -142,7 +142,7 @@ IR_KEYTAB_TYPE ir_codes_winfast[IR_KEYTA [ 3 ] = KEY_ZOOM, // fullscreen [ 31 ] = KEY_SUBTITLE, // closed caption/teletext [ 32 ] = KEY_SLEEP, -// [ 41 ] = boss key +[ 41 ] = KEY_SEARCH,//boss key [ 20 ] = KEY_MUTE, [ 43 ] = KEY_RED, [ 44 ] = KEY_GREEN, @@ -150,17 +150,17 @@ IR_KEYTAB_TYPE ir_codes_winfast[IR_KEYTA [ 46 ] = KEY_BLUE, [ 24 ] = KEY_KPPLUS,//fine tune + [ 25 ] = KEY_KPMINUS, //fine tune - -// [ 42 ] = picture in picture +[ 42 ] = KEY_ANGLE, //picture in picture [ 33 ] = KEY_KPDOT, [ 19 ] = KEY_KPENTER, -// [ 17 ] = recall +[ 17 ] = KEY_AGAIN, //recall [ 34 ] = KEY_BACK, [ 35 ] = KEY_PLAYPAUSE, [ 36 ] = KEY_NEXT, -// [ 37 ] = time shifting +[ 37 ] = KEY_T, //time shifting [ 38 ] = KEY_STOP, - [ 39 ] = KEY_RECORD -// [ 40 ] = snapshot + [ 39 ] = KEY_RECORD, +[ 40 ] = KEY_SHUFFLE//snapshot }; EXPORT_SYMBOL_GPL(ir_codes_winfast); - 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/
2.6 kernel panics and hangs at boot (due to IDE DMA issues?)
Hello. I've been trying to run Fedora Core 3 on dual P3 machine (Asus P2B-DS board, Intel BX chipset), but every time I try to boot it, it hangs moments after mounting local filesystems. It doesn't really matter if I boot SMP or non-SMP kernel and I've tried several, from 2.6.9 to latest 2.6.11-1 fresh from yum update. All I can do is boot rescue CD and chroot... Only once I got it to spit something that looked like this (sorry, I did not write it down at that time so it's just what I remember): kernel panic - not syncing: drivers/ide/pci/piix.c::spin-lock (drivers/ide/ide.c:) already locked by drivers/ide/dma.c After few hours of trials and errors (and Google help) I finally got it running by adding ide=nodma to boot command line and by changing USE_DMA to =0 in /etc/sysconfig/harddisks. Now it boots every kernel it didn't before, SMP works fine, gcc recompiled kernel sources several time without single core dump, it's just without DMA disk data transfers are down to few MB/sec. Burning DVDs is short of impossible. >From what I found this is a well-known problem with FC 2 & 3, Suse 9.1 and >some other distributions based on recent 2.6 kernels and not-so-new hardware. >So far I've failed to properly compile a vanilla 2.6.11.7 kernel (hangs just >before INIT) so I can't say anything about that one... If this is a known >problem then please don't flame me. I have been looking for possible solutions >and posting here is my last resort at getting one. If someone can just point >me to some explanation I'll be on my way. And please do CC to me directly as I >have not subscribed... If this is a new problem then I'll be happy to assist and provide with logs and /proc infromations, it's just I wasn't sure I should include all that if this is perhaps some silly mistake on my behalf... Looking forward to an answer Radek - 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: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
Dinakar Guniguntala wrote:
Here's an attempt at dynamic sched domains aka isolated cpusets
Very good, I was wondering when someone would try to implement this ;)
It needs some work. A few initial comments on the kernel/sched.c change
- sorry, don't have too much time right now...
--- linux-2.6.12-rc1-mm1.orig/kernel/sched.c 2005-04-18 00:46:40.0 +0530
+++ linux-2.6.12-rc1-mm1/kernel/sched.c 2005-04-18 00:47:55.0 +0530
@@ -4895,40 +4895,41 @@ static void check_sibling_maps(void)
}
#endif
-/*
- * Set up scheduler domains and groups. Callers must hold the hotplug lock.
- */
-static void __devinit arch_init_sched_domains(void)
+static void attach_domains(cpumask_t cpu_map)
{
This shouldn't be needed. There should probably just be one place that
attaches all domains. It is a bit difficult to explain what I mean when
you have 2 such places below.
[...]
+void rebuild_sched_domains(cpumask_t change_map, cpumask_t span1, cpumask_t
span2)
+{
Interface isn't bad. It would seem to be able to handle everything, but
I think it can be made a bit simpler.
fn_name(cpumask_t span1, cpumask_t span2)
Yeah? The change_map is implicitly the union of the 2 spans. Also I don't
really like the name. It doesn't rebuild so much as split (or join). I
can't think of anything good off the top of my head.
+ unsigned long flags;
+ int i;
+
+ local_irq_save(flags);
+
+ for_each_cpu_mask(i, change_map)
+ spin_lock(&cpu_rq(i)->lock);
+
Locking is wrong. And it has changed again in the latest -mm kernel.
Please diff against that.
+ if (!cpus_empty(span1))
+ build_sched_domains(span1);
+ if (!cpus_empty(span2))
+ build_sched_domains(span2);
+
You also can't do this - you have to 'offline' the domains first before
building new ones. See the CPU hotplug code that handles this.
[...]
@@ -5046,13 +5082,13 @@ static int update_sched_domains(struct n
unsigned long action, void *hcpu)
{
int i;
+ cpumask_t temp_map, hotcpu = cpumask_of_cpu((long)hcpu);
switch (action) {
case CPU_UP_PREPARE:
case CPU_DOWN_PREPARE:
- for_each_online_cpu(i)
- cpu_attach_domain(&sched_domain_dummy, i);
- arch_destroy_sched_domains();
+ cpus_andnot(temp_map, cpu_online_map, hotcpu);
+ rebuild_sched_domains(cpu_online_map, temp_map, CPU_MASK_NONE);
This makes a hotplug event destroy your nicely set up isolated domains,
doesn't it?
This looks like the most difficult problem to overcome. It needs some
external information to redo the cpuset splits at cpu hotplug time.
Probably a hotplug handler in the cpusets code might be the best way
to do that.
--
SUSE Labs, Novell Inc.
-
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: hot-addacpi-hotplug-decouple-slot-power-state-changes-from-physical-hotplug.patch
On Sat, Apr 16, 2005 at 11:46:13AM -0700, Paul Ionescu wrote: > > Was this setup supposed to work ? > Not yet, sorry. This patch was simply decoupling the power state of the device from its physical presence in the slot. It had nothing to do about programming p2p bridges and subordinate devices correctly. I know some folks from Fujitsu are working on this and should be sending out patches shortly. Not sure if these will support docking stations fully but even if they don't, we'll have a better starting base to build on. Rajesh - 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: [PATCH scsi-misc-2.6 02/07] scsi: make scsi_send_eh_cmnd use its own timer instead of scmd->eh_timeout
James Bottomley wrote: > On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote: > >> The original code also uses timer pending status as a signal that >>command completed normally in scsi_eh_done() function, and the same >>race also exists in the original code, no matter what we do, unless we >>make timer expiration and removal of the command atomic, there will be >>a window in which command completes normally but considered to have >>timed out as long as we use timer pending status as tie breaker. > > > True enough; it's a race between the driver calling scsi_done() and the > timer expiring. However, that's an acceptable race, since the timer > values are usually in the order of a few seconds and the command usually > completes in milliseconds. the done function is called in interrupt > context after command completion, so it's as close as possible to the > actual command completion > > >> The patch moves the test out of scsi_eh_done() into >>scsi_send_eh_cmnd() and this does widen the window by delaying removal >>of timer until after the original thread gets scheduled, but usually >>not by much and that's how timers are done in many cases (through out >>the kernel, timer removals are done with intervening scheduling and no >>one considers those incorrect). So... > > > The time between a thread being marked ready to run and actually running > has been measured in seconds on a heavily loaded system. That makes the > race window potentially as wide as the timer, which is unacceptable. Hmm, okay, agreed. I'll rework it. I think I can do it by just adding a private struct scsi_eh_timer_arg to pass along the timer and the cmd pointer. I'll repost the patchset soon. Thanks a lot. -- tejun - 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: Garbage on serial console after serial driver loads
On Wed, 2005-04-13 at 12:45 +, Paul Slootman wrote: > Phil Oester <[EMAIL PROTECTED]> wrote: > >On Sat, Mar 26, 2005 at 03:10:05PM +, Russell King wrote: > >> Doesn't matter. The problem is that dwmw2's NS16550A patch (from ages > >> ago) changes the prescaler setting for this device so we can use the > >> higher speed baud rates. This means any programmed divisor (programmed > >> at early serial console initialisation time) suddenly becomes wrong as > >> soon as we fiddle with the prescaler during normal UART initialisation > >> time. Hmm. Why aren't we recalculating the divisor when we change the prescaler? This used to work for serial consoles at the time -- even for serial consoles about 115200 baud, IIRC. -- dwmw2 - 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: [PATCH scsi-misc-2.6 02/07] scsi: make scsi_send_eh_cmnd use its own timer instead of scmd->eh_timeout
On Tue, 2005-04-19 at 07:31 +0900, Tejun Heo wrote: > The original code also uses timer pending status as a signal that > command completed normally in scsi_eh_done() function, and the same > race also exists in the original code, no matter what we do, unless we > make timer expiration and removal of the command atomic, there will be > a window in which command completes normally but considered to have > timed out as long as we use timer pending status as tie breaker. True enough; it's a race between the driver calling scsi_done() and the timer expiring. However, that's an acceptable race, since the timer values are usually in the order of a few seconds and the command usually completes in milliseconds. the done function is called in interrupt context after command completion, so it's as close as possible to the actual command completion > The patch moves the test out of scsi_eh_done() into > scsi_send_eh_cmnd() and this does widen the window by delaying removal > of timer until after the original thread gets scheduled, but usually > not by much and that's how timers are done in many cases (through out > the kernel, timer removals are done with intervening scheduling and no > one considers those incorrect). So... The time between a thread being marked ready to run and actually running has been measured in seconds on a heavily loaded system. That makes the race window potentially as wide as the timer, which is unacceptable. James - 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: [PATCH scsi-misc-2.6 02/07] scsi: make scsi_send_eh_cmnd use its own timer instead of scmd->eh_timeout
Hello, James. On Mon, Apr 18, 2005 at 10:33:21AM -0500, James Bottomley wrote: > On Mon, 2005-04-11 at 03:45 +0900, Tejun Heo wrote: > > scmd->eh_timeout is used to resolve the race between command > > completion and timeout. However, during error handling, > > scsi_send_eh_cmnd uses scmd->eh_timeout. This creates a race > > condition between eh and normal completion for a request which > > has timed out and in the process of error handling. If the > > request completes while scmd->eh_timeout is being used by eh, > > eh timeout is lost and the command will be handled by both eh > > and completion path. This patch fixes the race by making > > scsi_send_eh_cmnd() use its own timer. > > > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > > The logic is wrong in there. > > The problem is you cannot rely on the timer being pending as a signal > that the command completed normally. The kernel doesn't define the > elapsed time between the eh_action semaphore going up and the process > waiting for it being scheduled. If the timer fires within that > undefined interval, you'll think the command timed out when it, in fact, > completed normally. The original code also uses timer pending status as a signal that command completed normally in scsi_eh_done() function, and the same race also exists in the original code, no matter what we do, unless we make timer expiration and removal of the command atomic, there will be a window in which command completes normally but considered to have timed out as long as we use timer pending status as tie breaker. The patch moves the test out of scsi_eh_done() into scsi_send_eh_cmnd() and this does widen the window by delaying removal of timer until after the original thread gets scheduled, but usually not by much and that's how timers are done in many cases (through out the kernel, timer removals are done with intervening scheduling and no one considers those incorrect). So... * If you're worried about the race itself, it was there before, it shouldn't cause any problem, and we really can't help it. * If you're worried about the widening of the window, practically, it wouldn't cause problem, and it's how timers are done in many other places. But if you still don't like it, I can rework it (maybe I'll need to add a field to Scsi_Host or scsi_cmnd). So, please let me know. Thanks a lot. -- tejun - 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: 2.6.12-rc2-mm3
On Mon, 18 Apr 2005 11:56:15 +0200, Alexander Nyberg wrote: >> >This patch fixes the NMI checking problems in -mm x64 for me. It >> >> What problems? >> > >Sorry, in -mm on x64 check_nmi_watchdog() has started to be run as a >late_initcall(). Currently it reports the NMIs as stuck on a few systems >although they are not, both of mine are reported as stuck. This appears >to be because the current event mask uses don't appear to tick much >running mdelay() on opteron (in my case). Please provide a complete dmesg log up to and including the failure point where the kernel complains about stuck NMIs. I tried 2.6.12-rc2-mm3 SMP on UP amd64 and I immediately found a bug triggering bogus stuck NMI failures, and I want to check if what you're seeing is caused by the same bug. > Also in -mm because nmi_hz is >set to 1 in setup_k7_watchdog() the NMI watchdog checking takes 10 >seconds, a bit much. Orthogonal issue. Let's ignore this one for now. >Patch below uses RETIRED_UOPS for a more constant rate of NMI sending, This may or may not work as you intend. There is _no_ documented reason to assume that RETIRED_UOPS would provide a more steady stream of events than CYCLES_PROCESSOR_IS_RUNNING. Both events are likely to be idle in HLT states, for instance. The local APIC + performance counter driven NMI watchdog simply cannot provide wall-clock like behaviour. You need the I/O-APIC driven watchdog for that, or to prevent the kernel from using HLT when idle. >@@ -68,7 +69,7 @@ > #define K7_EVNTSEL_INT(1 << 20) > #define K7_EVNTSEL_OS (1 << 17) > #define K7_EVNTSEL_USR(1 << 16) >-#define K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING 0x76 >+#define K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING 0xC1 /* Retired uops */ > #define K7_NMI_EVENT K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING This is as bogus as "#define ONE 2". CYCLES_PROCESSOR_IS_RUNNING _is_ event 0x76 (AMD renamed it recently, but that's irrelevant). Using RETIRED_UOPS requires a new define, and a modification to the K7_NMI_EVENT #define. /Mikael - 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: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)
On Sun, Apr 17, 2005 at 10:26:43PM +0200, Daniel Ritz wrote:
> from your dmesg:
> PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: 00040, new:
> ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> :00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19
> PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: , new: 0003
>
> so the device is sent to D3 right after it is up. nice.
>
> and second boot:
> PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: 00040, new:
> PCI: Enabling device :00:0b.0 ( -> 0003)
> ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> :00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
> PCI: Setting latency timer of device :00:0b.0 to 64
> *** EEPROM MAC address is invalid.
> 3c59x: vortex_probe1 fails. Returns -22
> 3c59x: probe of :00:0b.0 failed with error -22
>
> to me it looks like during the second boot the device is in D3 and has
> troubles coming out of it. unfortunatley that is not made visible by the
> debugging patch. a hexdump of the device in a second boot without
> loading the 3c59x driver would tell us...
>
> the diff in the hexdumps of the config space proves that the device
> is programmed wrong:
> --- hexdump-2.6.12-rc2-mm3-withdebugpatch_1.txt 2005-04-17 21:27:28.0
> +0200
> +++ hexdump-2.6.12-rc2-mm3-withdebugpatch_2.txt 2005-04-17 21:27:32.0
> +0200
> @@ -1,7 +1,7 @@
> -000 10b7 9055 0007 0210 0024 0200 2008
> -010 ac01 2000 e800
> +000 10b7 9055 0003 0210 0024 0200 4000
> +010 0001
>
> so the I/O ports and the iomem are not set!
>
> 020 10b7 9055
> -030 00dc 010a 0a0a
> +030 00dc 0100 0a0a
> 040
> 050 0040
> 060
>
> but to make it short: i think it's a driver bug. the device doesn't seem to be
> correctly reprogrammed when it is in D3 initially. and then it shouldn't be
> put into D3 during the first boot. so please try with the attached patch.
>
> rgds
> -daniel
>
> PS: does somebody have a datasheet of a 3com chip around? i could need one.
>
> -
>
> [PATCH] 3c59x: only put the device into D3 when we're actually using WOL
>
> Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
>
> --- 1.77/drivers/net/3c59x.c 2005-03-03 06:00:42 +01:00
> +++ edited/drivers/net/3c59x.c2005-04-17 22:17:19 +02:00
> @@ -1581,7 +1581,8 @@
>
> if (VORTEX_PCI(vp)) {
> pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
> - pci_restore_state(VORTEX_PCI(vp));
> + if (vp->pm_state_valid)
> + pci_restore_state(VORTEX_PCI(vp));
> pci_enable_device(VORTEX_PCI(vp));
> }
>
> @@ -2741,6 +2742,7 @@
> outl(0, ioaddr + DownListPtr);
>
> if (final_down && VORTEX_PCI(vp)) {
> + vp->pm_state_valid = 1;
> pci_save_state(VORTEX_PCI(vp));
> acpi_set_WOL(dev);
> }
> @@ -3243,9 +3245,10 @@
> outw(RxEnable, ioaddr + EL3_CMD);
>
> pci_enable_wake(VORTEX_PCI(vp), 0, 1);
> +
> + /* Change the power state to D3; RxEnable doesn't take effect.
> */
> + pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
> }
> - /* Change the power state to D3; RxEnable doesn't take effect. */
> - pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
> }
>
The patch solved it. Thank you for your help.
-Peter Baumann
-
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: [Ext2-devel] Re: ext3 allocate-with-reservation latencies
On Mon, 2005-04-18 at 19:00 +0100, Stephen C. Tweedie wrote: > > > Note that there _is_ some additional complexity here. It's not entirely > > > free. Specifically, if we have other tasks waiting on our provisional > > > window, then we need to be very careful about the life expectancy of the > > > wait queues involved, so that if the first task fixes its window and > > > then deletes it before the waiters have woken up, they don't get > > > confused by the provisional window vanishing while being waited for. > > > This approach(provisional window) sounds interesting to me, but it's a > > little more complicated than I thought:( > > Yep. Once you have other tasks waiting on your window while it's not > locked, object lifetime becomes a much bigger problem. > > > alloc_new_reservation() > > retry: > > lock the tree > > search for a new space start from the given startblock > > found a new space > > if the new space is not a "provisional window" > I was thinking rather that we _start_ with the window, and _then_ look > for new space. > It seems I am lost here. Could you elaborate more here, please? What is "the window" you are referring to here? The old(stale) reservation window? I thought we are discussing the algorithm to how to allocate a new window. > So we'd start with: > > if we already have a window, > mark it provisional; > else, > do > search for a new window; > if the immediately preceding window is provisional, > wait for that window; > continue; > allocate the window and mark it provisional; > break > > At this point we have a provisional window, and we know that nobody else > is going to allocate either in it, or in the empty space following it > (because if they tried to, they'd bump into our own provisional window > as their predecessor and would wait for us.) So even if the window > doesn't occupy the _whole_ unreserved area, we can still keep searching > without fear of multiple tasks trying to do so in the same space at the > same time. > > --Stephen > > Hmm.. This thread was to address the latency of holding the global per-fs reservation lock while scanning the block group bitmap. And the whole point of the "provisional window" is to prevent other inodes being forced to put into other block groups when one inode hold/reserve the whole block group as a temporary window to do the bitmap scan. I clearly see it's a win if there are no multiple threads allocating blocks nearby at the same time. However the whole reservation is there to address the case where multiple allocations happen at the same time near the same place. With the provisional method, if multiple threads trying to allocate new windows in the same area, they are still have to wait for other new- window-allocation-and-bitmap-scan finish. After that the probably will compete the same window again and again:( I am worried that the latency is not being being improved than before (holding the lock for bitmap scan), and we have paid extra cpu time or context switches. Also the changes to the algorithm is no going to be trivial. Now we all agree that the right thing to fix the latency is to drop the lock and then scan the bitmap. Before that we need to reserve the open window in case someone else is trying to target at the same window. Question was should we reserve the whole free reservable space or just the window size we need. Now that we have explored and discussed so many possible solutions, I think the lest evil and less intrusive way to just lock the small window. We were worried about in the case the scanned free bit is not inside the temporary reserved window, it is possible we have to do many window unlink and link operations on the rb tree, however this is not avoidable with the provisional window proposal either. Probably we could start with that simple proposal first, and if there are benchmarks shows the cpu usage is really high and a concern, we could address that later? Thanks, Mingming - 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/
[2.6 patch] drivers/usb/media/pwc/: make code static
This patch lacked a small bit.
Updated patch below.
cu
Adrian
<-- snip -->
This patch makes needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/usb/media/pwc/pwc-ctrl.c | 78 +++
drivers/usb/media/pwc/pwc-if.c |2
drivers/usb/media/pwc/pwc.h |6 --
3 files changed, 41 insertions(+), 45 deletions(-)
--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc.h.old 2005-04-18
03:11:14.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc.h 2005-04-18
03:13:28.0 +0200
@@ -226,9 +226,8 @@
extern "C" {
#endif
-/* Global variables */
+/* Global variable */
extern int pwc_trace;
-extern int pwc_preferred_compression;
/** functions in pwc-if.c */
int pwc_try_video_mode(struct pwc_device *pdev, int width, int height, int
new_fps, int new_compression, int new_snapshot);
@@ -243,8 +242,6 @@
/** Functions in pwc-ctrl.c */
/* Request a certain video mode. Returns < 0 if not possible */
extern int pwc_set_video_mode(struct pwc_device *pdev, int width, int height,
int frames, int compression, int snapshot);
-/* Calculate the number of bytes per image (not frame) */
-extern void pwc_set_image_buffer_size(struct pwc_device *pdev);
/* Various controls; should be obvious. Value 0..65535, or < 0 on error */
extern int pwc_get_brightness(struct pwc_device *pdev);
@@ -256,7 +253,6 @@
extern int pwc_get_saturation(struct pwc_device *pdev);
extern int pwc_set_saturation(struct pwc_device *pdev, int value);
extern int pwc_set_leds(struct pwc_device *pdev, int on_value, int off_value);
-extern int pwc_get_leds(struct pwc_device *pdev, int *on_value, int
*off_value);
extern int pwc_get_cmos_sensor(struct pwc_device *pdev, int *sensor);
/* Power down or up the camera; not supported by all models */
--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc-ctrl.c.old
2005-04-18 03:11:29.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc-ctrl.c 2005-04-18
22:57:34.0 +0200
@@ -418,6 +418,44 @@
+static void pwc_set_image_buffer_size(struct pwc_device *pdev)
+{
+ int i, factor = 0, filler = 0;
+
+ /* for PALETTE_YUV420P */
+ switch(pdev->vpalette)
+ {
+ case VIDEO_PALETTE_YUV420P:
+ factor = 6;
+ filler = 128;
+ break;
+ case VIDEO_PALETTE_RAW:
+ factor = 6; /* can be uncompressed YUV420P */
+ filler = 0;
+ break;
+ }
+
+ /* Set sizes in bytes */
+ pdev->image.size = pdev->image.x * pdev->image.y * factor / 4;
+ pdev->view.size = pdev->view.x * pdev->view.y * factor / 4;
+
+ /* Align offset, or you'll get some very weird results in
+ YUV420 mode... x must be multiple of 4 (to get the Y's in
+ place), and y even (or you'll mixup U & V). This is less of a
+ problem for YUV420P.
+*/
+ pdev->offset.x = ((pdev->view.x - pdev->image.x) / 2) & 0xFFFC;
+ pdev->offset.y = ((pdev->view.y - pdev->image.y) / 2) & 0xFFFE;
+
+ /* Fill buffers with gray or black */
+ for (i = 0; i < MAX_IMAGES; i++) {
+ if (pdev->image_ptr[i] != NULL)
+ memset(pdev->image_ptr[i], filler, pdev->view.size);
+ }
+}
+
+
+
/**
@pdev: device structure
@width: viewport width
@@ -475,44 +513,6 @@
}
-void pwc_set_image_buffer_size(struct pwc_device *pdev)
-{
- int i, factor = 0, filler = 0;
-
- /* for PALETTE_YUV420P */
- switch(pdev->vpalette)
- {
- case VIDEO_PALETTE_YUV420P:
- factor = 6;
- filler = 128;
- break;
- case VIDEO_PALETTE_RAW:
- factor = 6; /* can be uncompressed YUV420P */
- filler = 0;
- break;
- }
-
- /* Set sizes in bytes */
- pdev->image.size = pdev->image.x * pdev->image.y * factor / 4;
- pdev->view.size = pdev->view.x * pdev->view.y * factor / 4;
-
- /* Align offset, or you'll get some very weird results in
- YUV420 mode... x must be multiple of 4 (to get the Y's in
- place), and y even (or you'll mixup U & V). This is less of a
- problem for YUV420P.
-*/
- pdev->offset.x = ((pdev->view.x - pdev->image.x) / 2) & 0xFFFC;
- pdev->offset.y = ((pdev->view.y - pdev->image.y) / 2) & 0xFFFE;
-
- /* Fill buffers with gray or black */
- for (i = 0; i < MAX_IMAGES; i++) {
- if (pdev->image_ptr[i] != NULL)
- memset(pdev->image_ptr[i], filler, pdev->view.size);
- }
-}
-
-
-
/* BRIGHTNESS */
int pwc_get_brightness(struct pwc_device *pdev)
@@ -949,7 +949,7 @@
return SendControlMsg(SET_STATUS_CTL, LED_FORMATTER, 2);
}
-int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value)
+static int pwc_get_leds(struct pwc_device *pdev, int *on_value
VFS: Cannot open root device (path_lookup failed)
hello, I'm trying to mount root filesystem on cramfs (2.6.11, compiled with mtd and CRAMFS support), however I get following well known error message: VFS: Cannot open root device "mtdblock1" or unknown-block(31,1) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1) I've found, that funtion "path_lookup" with "/root" fails with (-2) when called from mount_block_root--do_mount_root -- sys_mount(name, "/root", fs, flags, data); Could this be a problem with initramfs??? Do I need initramfs every time to mount later a real root fs? best regards Pawel __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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/
[2.6 patch] drivers/net/wan/: possible cleanups
On Mon, Apr 18, 2005 at 01:55:06PM +0100, Alan Cox wrote:
> On Llu, 2005-04-18 at 00:47, Adrian Bunk wrote:
> > Are there any external drivers using these exports, and if there are,
> > why aren't they in the kernel?
>
> Its a standard API
>
> > If there aren't and someone will at some time in the future need them,
> > re-adding the exports will be trivial.
>
> Really, you will spotaneously magically make them appear in old kernels
> that end users have just like that ?
>
> Your argument doesn't hold water. Its an API for drivers so that people
> can add 85x30 card drivers using DMA in this fashion. Its an API so they
> can add them to *EXISTING* kernels without users being forced to
> recompile/wait for the vendor to update their tree/upgrade to a new
> release.
OK, updated patch below.
> Alan
cu
Adrian
<-- snip -->
This patch contains possible cleanups including the following:
- make needlessly global code static
- #if 0 the following unused global function:
- sdladrv.c: sdla_intde
- remove the following unused global variable:
- lmc_media.c: lmc_t1_cables
- remove the following unneeded EXPORT_SYMBOL's:
- cycx_drv.c: cycx_inten
- sdladrv.c: sdla_inten
- sdladrv.c: sdla_intde
- sdladrv.c: sdla_intack
- sdladrv.c: sdla_intr
- syncppp.c: sppp_input
- syncppp.c: sppp_change_mtu
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/wan/cycx_drv.c |7 +-
drivers/net/wan/cycx_main.c |2
drivers/net/wan/dscc4.c | 14 ++---
drivers/net/wan/farsync.c | 24
drivers/net/wan/hdlc_fr.c |2
drivers/net/wan/lmc/lmc_debug.c | 10 +--
drivers/net/wan/lmc/lmc_media.c |8 --
drivers/net/wan/pc300.h | 16 -
drivers/net/wan/pc300_drv.c | 87
drivers/net/wan/pc300_tty.c | 18 +++---
drivers/net/wan/sdla.c | 20 +++
drivers/net/wan/sdladrv.c | 16 ++---
drivers/net/wan/syncppp.c | 10 +--
include/linux/cycx_drv.h|1
include/linux/sdladrv.h |4 -
include/net/syncppp.h |1
16 files changed, 101 insertions(+), 139 deletions(-)
--- linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h.old 2005-02-16
19:14:39.0 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/cycx_drv.h 2005-02-16
19:14:46.0 +0100
@@ -60,6 +60,5 @@
extern int cycx_poke(struct cycx_hw *hw, u32 addr, void *buf, u32 len);
extern int cycx_exec(void __iomem *addr);
-extern void cycx_inten(struct cycx_hw *hw);
extern void cycx_intr(struct cycx_hw *hw);
#endif /* _CYCX_DRV_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c.old2005-02-16
19:14:55.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_drv.c2005-02-16
19:15:35.0 +0100
@@ -110,7 +110,7 @@
* < 0 error.
* Context:process */
-int __init cycx_drv_init(void)
+static int __init cycx_drv_init(void)
{
printk(KERN_INFO "%s v%u.%u %s\n", fullname, MOD_VERSION, MOD_RELEASE,
copyright);
@@ -120,7 +120,7 @@
/* Module 'remove' entry point.
* o release all remaining system resources */
-void cycx_drv_cleanup(void)
+static void cycx_drv_cleanup(void)
{
}
@@ -185,8 +185,7 @@
}
/* Enable interrupt generation. */
-EXPORT_SYMBOL(cycx_inten);
-void cycx_inten(struct cycx_hw *hw)
+static void cycx_inten(struct cycx_hw *hw)
{
writeb(0, hw->dpmbase);
}
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c.old 2005-02-16
19:46:47.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/cycx_main.c 2005-02-16
19:47:00.0 +0100
@@ -103,7 +103,7 @@
* < 0 error.
* Context:process
*/
-int __init cycx_init(void)
+static int __init cycx_init(void)
{
int cnt, err = -ENOMEM;
--- linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c.old 2005-02-16
23:57:37.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/wan/farsync.c 2005-02-17
00:00:26.0 +0100
@@ -74,11 +74,11 @@
/*
* Modules parameters and associated varaibles
*/
-int fst_txq_low = FST_LOW_WATER_MARK;
-int fst_txq_high = FST_HIGH_WATER_MARK;
-int fst_max_reads = 7;
-int fst_excluded_cards = 0;
-int fst_excluded_list[FST_MAX_CARDS];
+static int fst_txq_low = FST_LOW_WATER_MARK;
+static int fst_txq_high = FST_HIGH_WATER_MARK;
+static int fst_max_reads = 7;
+static int fst_excluded_cards = 0;
+static int fst_excluded_list[FST_MAX_CARDS];
module_param(fst_txq_low, int, 0);
module_param(fst_txq_high, int, 0);
@@ -572,13 +572,13 @@
static void fst_process_tx_work_q(unsigned long work_q);
static void fst_process_int_work_q(unsigned long work_q);
-DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0);
-DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0);
+static DECLARE_TASKLET(fst_tx_task, fst_process_tx_work_q, 0);
+static DECLARE_TASKLET(fst_int_task, fst_process_int_work_q, 0);
-struct fst_card_info *fs
Re: Fortuna
Matt Mackall wrote: >On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote: >> http://eprint.iacr.org/2005/029 > >Unfortunately, this paper's analysis of /dev/random is so shallow that >they don't even know what hash it's using. Almost all of section 5.3 >is wrong (and was when I read it initially). Yes, that is a minor glitch, but I believe all their points remain valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g substitution, and re-read the paper to see what you can get out of it. The problem is not that the paper is shallow; it is not. The source of the error is likely that this paper was written by theorists, not implementors. There are important things we can learn from them, and I think it is worth reading their paper carefully to understand what they have to offer. I believe they raise substantial and deep questions in their Section 5.3. I don't see why you say Section 5.3 is all wrong. Can you elaborate? Can you explain one or two of the substantial errors you see? - 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: [PATCH 3/7] procfs privacy: misc. entries
Lorenzo Hernández García-Hierro wrote: >El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió: >> This is utterly absurd. You can find out anything thats in /proc/cpuinfo >> by calling cpuid instructions yourself. >> Please enlighten me as to what security gains we achieve >> by not allowing users to see this ? > >It's more obscurity than anything else. At least that's what privacy >means usually. Well, that's not what the word "privacy" means to me. It seems to me there are plenty of "privacy" issues that are real and legitimate and have nothing to do with obscurity. I agree with Dave Jones. Security through obscurity makes no sense. - 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: [PATCH] RLIMIT_NPROC enforcement during execve() calls
On Mon, 18 Apr 2005 20:07:04 +0200, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said: > The limit is only checked when process is created on a fork() call, but > during execution it's uid can change, thus, the limit for the new uid > could be exceed. The only two ways I can see this happening are (1) if the process is running as uid 0 (or capability-equivalent) at fork() time and have called set*uid() before execve(), or (2) we just exec'ed a set-UID binary. In both cases the "obvious" thing to do is to re-check the target UID's rlimit, but there may be some squirrelly corner case where this isn't true... pgpDRDLvzG749.pgp Description: PGP signature
Re: [PATCH 2.6.11.7 1/2] USB HID: Patch for Cherry CyMotion Linux keyboard
On 18 Apr 2005, at 19:14, Greg KH wrote: Care to redo them, add a signed-off-by: line and send them to the linux-usb-devel mailing list and CC: the hid maintainer? All done. Sorry for the inconvenience. -- Andy Armstrong, hexten.net - 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: [PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU
Hi Derek,
My comments on your code:
> +Changes:
> +v0.1 26 March 2005
> + Initial Release - developed on uClinux with 2.6.9 kernel
> +v0.2 11 April 2005
> + Coding style changes
> +
Changelogs are not welcome in kernel code.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "i2c-mcf5282.h"
I can't see that you need config.h, errno.h nor string.h.
> + /* printk(KERN_DEBUG "%s I2DR is %.2x \n", __FUNCTION__, *rxData); */
Please don't include dead code.
> + timeout = 500;
You use a timeout of 500 in various places. I wonder if you shouldn't
have a define for it - in case it needs to be altered later.
> + while (timeout-- && !(*MCF5282_I2C_I2SR & MCF5282_I2C_I2SR_IIF))
> + udelay(1);
> + if (timeout <= 0)
> + printk(KERN_WARNING "%s - I2C IIF never set \n", __FUNCTION__);
These constructs are error-prone. I personally prefer:
while(--timeout && ...)
...
if (!timeout)
...
> + rc += mcf5282_write_data(data->word & 0x00FF);
> + rc += mcf5282_write_data((data->word & 0x00FF) >> 8);
Looks like a bug to me.
> +static s32 mcf5282_i2c_access(struct i2c_adapter *adap, u16 addr,
> + unsigned short flags, char read_write,
> + u8 command, int size, union i2c_smbus_data *data)
> (...)
> + printk(KERN_WARNING "Not support I2C_SMBUS_PROC_CALL yet \n");
Don't use printk when you can user dev_{dbg,warn,info,err}. Also, please
no space before newline.
> +static u32 mcf5282_func(struct i2c_adapter *adapter)
> +{
> + return I2C_FUNC_SMBUS_QUICK |
> +I2C_FUNC_SMBUS_BYTE |
> +I2C_FUNC_SMBUS_PROC_CALL |
> +I2C_FUNC_SMBUS_BYTE_DATA |
> +I2C_FUNC_SMBUS_WORD_DATA |
> +I2C_FUNC_SMBUS_BLOCK_DATA;
> +};
Don't say you support I2C_FUNC_SMBUS_PROC_CALL and
I2C_FUNC_SMBUS_BLOCK_DATA when you in fact don't. Not supporting some
functions is no problem, just leave them out for now. You can always
submit patches later.
> --- linux-2.6.11.6/drivers/i2c/busses/i2c-mcf5282.h 1969-12-31
> 19:00:00.0 -0500
> +++ linux_dev/drivers/i2c/busses/i2c-mcf5282.h2005-04-12
> 20:45:00.0 -0400
I see no reason to have a separate .h file for this.
> --- linux-2.6.11.6/drivers/i2c/busses/Kconfig 2005-03-25 22:28:29.0
> -0500
> +++ linux_dev/drivers/i2c/busses/Kconfig 2005-04-12 20:45:24.0
> -0400
> @@ -39,6 +39,16 @@ config I2C_ALI15X3
> This driver can also be built as a module. If so, the module
> will be called i2c-ali15x3.
>
> +config I2C_MCF5282
Please keep the entries in somewhat alphabetical order.
> --- linux-2.6.11.6/drivers/i2c/busses/Makefile2005-03-25
> 22:28:39.0 -0500
> +++ linux_dev/drivers/i2c/busses/Makefile 2005-04-13 18:52:03.0
> -0400
> @@ -40,6 +40,7 @@ obj-$(CONFIG_I2C_VIAPRO)+= i2c-viapro.o
> obj-$(CONFIG_I2C_VOODOO3)+= i2c-voodoo3.o
> obj-$(CONFIG_SCx200_ACB) += scx200_acb.o
> obj-$(CONFIG_SCx200_I2C) += scx200_i2c.o
> +obj-$(CONFIG_I2C_MCF5282)+= i2c-mcf5282.o
Ditto.
> +#define MCF5282_I2C_I2CR_IEN(0x80) /* I2C enable */
> +#define MCF5282_I2C_I2CR_IIEN (0x40) /* interrupt enable */
> +#define MCF5282_I2C_I2CR_MSTA (0x20) /* master/slave mode */
> +#define MCF5282_I2C_I2CR_MTX(0x10) /* transmit/receive mode */
> +#define MCF5282_I2C_I2CR_TXAK (0x08) /* transmit acknowledge enable */
> +#define MCF5282_I2C_I2CR_RSTA (0x04) /* repeat start */
> +
> +#define MCF5282_I2C_I2SR_ICF(0x80) /* data transfer bit */
> +#define MCF5282_I2C_I2SR_IAAS (0x40) /* I2C addressed as a slave */
> +#define MCF5282_I2C_I2SR_IBB(0x20) /* I2C bus busy */
> +#define MCF5282_I2C_I2SR_IAL(0x10) /* aribitration lost */
> +#define MCF5282_I2C_I2SR_SRW(0x04) /* slave read/write */
> +#define MCF5282_I2C_I2SR_IIF(0x02) /* I2C interrupt */
> +#define MCF5282_I2C_I2SR_RXAK (0x01) /* received acknowledge */
Parentheses are not needed here.
Thanks,
--
Jean Delvare
-
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: [PATCH 1/2] new valid_signal function
On Mon, 18 Apr 2005, Jesper Juhl wrote: > This patch adds a new function valid_signal() that tests if its argument > is a valid signal number. > > The reasons for adding this new function are: > - some code currently testing _NSIG directly has off-by-one errors. Using > this function instead avoids such errors. > - some code currently tests unsigned signal numbers for <0 which is > pointless and generates warnings when building with gcc -W. Using this > function instead avoids such warnings. > Note to observers: I forgot to mention that the prelude to this patch can be found in the thread titled '[PATCH] fs/fcntl.c : don't test unsigned value for less than zero' -- Jesper - 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 2/2] new valid_signal function - convert code that currently tests _NSIG directly to use the new function instead
The patch below converts most of the current code that uses _NSIG directly to instead use the valid_signal() function added by the previous patch. This avoids gcc -W warnings and off-by-one errors and it's also nice and readable, no doubt about what the code tests. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- arch/alpha/kernel/ptrace.c |5 +++-- arch/arm/kernel/ptrace.c |5 +++-- arch/arm26/kernel/ptrace.c |5 +++-- arch/cris/arch-v10/kernel/ptrace.c |5 +++-- arch/frv/kernel/ptrace.c |5 +++-- arch/h8300/kernel/ptrace.c |5 +++-- arch/i386/kernel/ptrace.c |5 +++-- arch/ia64/kernel/ptrace.c |5 +++-- arch/m32r/kernel/ptrace.c |5 +++-- arch/m68k/kernel/ptrace.c |5 +++-- arch/m68knommu/kernel/ptrace.c |5 +++-- arch/mips/kernel/ptrace.c |3 ++- arch/mips/kernel/ptrace32.c|3 ++- arch/parisc/kernel/ptrace.c|7 --- arch/ppc/kernel/ptrace.c |5 +++-- arch/ppc64/kernel/ptrace.c |5 +++-- arch/ppc64/kernel/ptrace32.c |5 +++-- arch/s390/kernel/ptrace.c |5 +++-- arch/sh/kernel/ptrace.c|5 +++-- arch/sh64/kernel/ptrace.c |5 +++-- arch/sparc/kernel/ptrace.c |3 ++- arch/sparc64/kernel/ptrace.c |3 ++- arch/um/kernel/ptrace.c|4 ++-- arch/v850/kernel/ptrace.c |3 ++- arch/x86_64/kernel/ptrace.c|5 +++-- drivers/char/vt_ioctl.c|3 ++- fs/fcntl.c |3 ++- ipc/mqueue.c |4 ++-- kernel/exit.c |5 +++-- kernel/futex.c |3 ++- kernel/ptrace.c|3 ++- kernel/signal.c|9 + kernel/sys.c |3 ++- 33 files changed, 90 insertions(+), 59 deletions(-) --- linux-2.6.12-rc2-mm3-orig/arch/alpha/kernel/ptrace.c2005-03-02 08:38:25.0 +0100 +++ linux-2.6.12-rc2-mm3/arch/alpha/kernel/ptrace.c 2005-04-18 22:21:32.0 +0200 @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -335,7 +336,7 @@ do_sys_ptrace(long request, long pid, lo /* continue and stop at next (return from) syscall */ case PTRACE_CONT:/* restart after signal. */ ret = -EIO; - if ((unsigned long) data > _NSIG) + if (!valid_signal(data)) break; if (request == PTRACE_SYSCALL) set_tsk_thread_flag(child, TIF_SYSCALL_TRACE); @@ -365,7 +366,7 @@ do_sys_ptrace(long request, long pid, lo case PTRACE_SINGLESTEP: /* execute single instruction. */ ret = -EIO; - if ((unsigned long) data > _NSIG) + if (!valid_signal(data)) break; /* Mark single stepping. */ child->thread_info->bpt_nsaved = -1; --- linux-2.6.12-rc2-mm3-orig/arch/arm/kernel/ptrace.c 2005-04-05 21:21:05.0 +0200 +++ linux-2.6.12-rc2-mm3/arch/arm/kernel/ptrace.c 2005-04-18 22:21:45.0 +0200 @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -693,7 +694,7 @@ static int do_ptrace(int request, struct case PTRACE_SYSCALL: case PTRACE_CONT: ret = -EIO; - if ((unsigned long) data > _NSIG) + if (!valid_signal(data)) break; if (request == PTRACE_SYSCALL) set_tsk_thread_flag(child, TIF_SYSCALL_TRACE); @@ -728,7 +729,7 @@ static int do_ptrace(int request, struct */ case PTRACE_SINGLESTEP: ret = -EIO; - if ((unsigned long) data > _NSIG) + if (!valid_signal(data)) break; child->ptrace |= PT_SINGLESTEP; clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE); --- linux-2.6.12-rc2-mm3-orig/arch/arm26/kernel/ptrace.c2005-03-02 08:38:09.0 +0100 +++ linux-2.6.12-rc2-mm3/arch/arm26/kernel/ptrace.c 2005-04-18 22:21:58.0 +0200 @@ -18,6 +18,7 @@ #include #include #include +#include #include #include @@ -591,7 +592,7 @@ static int do_ptrace(int request, struct case PTRACE_SYSCALL: case PTRACE_CONT: ret = -EIO; - if ((unsigned long) data > _NSIG) + if (!valid_signal(data)) break; if (request == PTRACE_SYSCALL) set_tsk_thread_flag(child, TIF_SYSCALL_TRACE); @@ -626,7 +627,7 @@ static i
[PATCH 1/2] new valid_signal function
This patch adds a new function valid_signal() that tests if its argument
is a valid signal number.
The reasons for adding this new function are:
- some code currently testing _NSIG directly has off-by-one errors. Using
this function instead avoids such errors.
- some code currently tests unsigned signal numbers for <0 which is
pointless and generates warnings when building with gcc -W. Using this
function instead avoids such warnings.
I considered various places to add this function but eventually settled on
include/linux/signal.h as the most logical place for it. If there's some
reason this is a bad choice then please let me know (hints as to a better
location are then welcome of course).
A patch that converts most of the code that currently uses _NSIG directly
to call this function instead is [PATCH 2/2] coming shortly..
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
include/linux/signal.h |6 ++
1 files changed, 6 insertions(+)
--- linux-2.6.12-rc2-mm3-orig/include/linux/signal.h2005-04-11
21:20:56.0 +0200
+++ linux-2.6.12-rc2-mm3/include/linux/signal.h 2005-04-18 20:09:50.0
+0200
@@ -220,6 +220,12 @@
INIT_LIST_HEAD(&sig->list);
}
+/* Test if 'sig' is valid signal. Use this instead of testing _NSIG directly */
+static inline int valid_signal(unsigned long sig)
+{
+ return sig <= _NSIG ? 1 : 0;
+}
+
extern int group_send_sig_info(int sig, struct siginfo *info, struct
task_struct *p);
extern int __group_send_sig_info(int, struct siginfo *, struct task_struct *);
extern long do_sigpending(void __user *, unsigned long);
-
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: [PATCH 0/7] procfs privacy
On Mon, 2005-04-18 at 22:18 +0200, Lorenzo HernÃndez GarcÃa-Hierro wrote: > For this purpose I (re)submitted a patch originally made by Serge E. > Hallyn that adds a hook in order to catch task lookups, thus, providing > an easy way to handle and determine when a task can lookup'ed. > > It's at: > http://pearls.tuxedo-es.org/patches/lsm/lsm-task_lookup-hook.patch > > vSecurity currently provides support for it (optional). > > SELinux policy can handle in a much more fine-grained these > restrictions, just that it's still something that not all people can > deploy without some special effort and "tweak up" (if their system > doesn't provide support for it, of course, currently Red Hat has done a > great job in that terms). To be precise, SELinux assigns security labels to /proc inodes (/proc/pid inodes are labeled based on the associated task label, and other /proc inodes are labeled based on the policy configuration), and controls access based on the policy. It can e.g. prevent a process in one security domain from accessing anything under /proc/ for a process in a different domain, but not from seeing the top-level entry in /proc itself (as it doesn't do any kind of directory filtering). -- Stephen Smalley <[EMAIL PROTECTED]> National Security Agency - 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: [PATCH 3/7] procfs privacy: misc. entries
Dave Jones writes the following:
>
>On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hernández García-Hierro
>wrote:
> > This patch changes the permissions of the following procfs entries to
> > restrict non-root users from accessing them:
[snip]
> > - /proc/uptime
?!
[snip]
> > - /proc/cpuinfo
>
>This is utterly absurd. You can find out anything thats in /proc/cpuinfo
>by calling cpuid instructions yourself.
Also it's the backend of glibc's get_nprocs(), also known as
sysconf(_SC_NPROCESSORS_ONLN), a documented interface whose users are
probably not expecting it to suddenly become restricted to root.
>Please enlighten me as to what security gains we achieve
>by not allowing users to see this ?
>
>Restricting lots of the other files are equally absurd.
>
>I'd also be very surprised if various random bits of userspace
>broke subtley due to this nonsense.
Like uptime(1), a command which has existed basically unchanged since 3.0BSD
(note to observers: if you think that's a funny way of writing "FreeBSD 3.0",
you're off by at least a decade and a half).
-
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: [PATCH 0/7] procfs privacy
El lun, 18-04-2005 a las 16:01 -0400, Rik van Riel escribió: > On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > > > Adding a "trusted user group"-like configuration option could be useful, > > as it's done within grsecurity, among that the whole thing might be good > > to depend on a config. option, but that implies using weird ifdef's and > > the other folks. > > I'd rather see something like this implemented as an LSM > module - or better yet, an SELinux security policy. For this purpose I (re)submitted a patch originally made by Serge E. Hallyn that adds a hook in order to catch task lookups, thus, providing an easy way to handle and determine when a task can lookup'ed. It's at: http://pearls.tuxedo-es.org/patches/lsm/lsm-task_lookup-hook.patch vSecurity currently provides support for it (optional). SELinux policy can handle in a much more fine-grained these restrictions, just that it's still something that not all people can deploy without some special effort and "tweak up" (if their system doesn't provide support for it, of course, currently Red Hat has done a great job in that terms). > > There's no need to sprinkle security policy all over the > kernel. I completely agree. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: Garbage on serial console after serial driver loads
On Wed, Apr 13, 2005 at 12:45:51PM +, Paul Slootman wrote: > We have a variety of Dell rackmount systems, also on Cyclades, and see > this mess everywhere. > > I had reported this problem a little while ago, see > http://marc.theaimsgroup.com/?l=linux-kernel&m=111036598927105&w=2 > but unfortunately didn't get any response at that time. Read the remainder of the thread for a workaround. http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.3/1061.html Phil - 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: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
Arjan van de Ven wrote: you just said that you didn't care that it got munlock'd. So you don't care that it gets freed either. And then reused. Well, I can live with the app being able to call munlock(), because the apps that our customers use don't call munlock(). What I can't live with is a bug in the kernel that causes pinned pages to be swapped or moved. Obviously, I would rather call get_user_pages() instead of mlock(), but I can't, because get_user_pages doesn't work. The page doesn't stay pinned at the physical address, but it does if I call mlock() and get_user_pages(). Actually, in our tests, calling mlock() appears to be good enough, but I'll update our code to call get_user_pages() as well. -- Timur Tabi Staff Software Engineer [EMAIL PROTECTED] - 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: [PATCH 2/7] procfs privacy: tasks/processes lookup
El lun, 18-04-2005 a las 15:24 -0400, Rik van Riel escribió: > This looks like a very bad default to me! > > Your patch would force people to run system monitoring > applications as root, because otherwise they cannot get > some of the information they can get now. Forcing that > these applications run with root rights is a security > risk, not a benefit... Right, that's why I would say "fall back to the config. option" behavior, trusting in a certain user group defined in configuration-time or via sysctl, or just keeping it simple as it's right now, split up so anyone can decide what to apply and what shouldn't be applied. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
[RFC PATCH] Dynamic sched domains aka Isolated cpusets
Here's an attempt at dynamic sched domains aka isolated cpusets
o This functionality is on top of CPUSETs and provides a way to
completely isolate any set of CPUs dynamically.
o There is a new cpu_isolated flag that allows users to convert
an exclusive cpuset to an isolated one
o The isolated CPUs are part of their own sched domain.
This ensures that the rebalance code works within the domain,
prevents overhead due to a cpu trying to pull tasks only to find
that its cpus_allowed mask does not allow it to be pulled.
However it does not kick existing processes off the isolated domain
o There is very little code change in the scheduler sched domain
code. Most of it is just splitting up of the arch_init_sched_domains
code to be called dynamically instead of only at boot time.
It has only one API which takes in the map of all cpus affected
and the two new domains to be built
rebuild_sched_domains(cpumask_t change_map, cpumask_t span1, cpumask_t span2)
There are some things that may/will change
o This has been tested only on x86 [8 way -> 4 way with HT]. Still
needs work on other arch's
o I didn't get a chance to see Nick Piggin's RCU sched domains code
as yet, but I know there would be changes here because of that...
o This does not support CPU hotplug as yet
o Making a cpuset isolated manipulates its parent cpus_allowed
mask. When viewed from userspace this is represented as follows
[EMAIL PROTECTED] cpusets] cat cpus
0-3[4-7]
This indicates that CPUs 4-7 are isolated and is/are part of some
child cpuset/s
Appreciate any feedback.
Patch against linux-2.6.12-rc1-mm1.
include/linux/init.h |2
include/linux/sched.h |1
kernel/cpuset.c | 141 --
kernel/sched.c| 109 +-
4 files changed, 213 insertions(+), 40 deletions(-)
-Dinakar
diff -Naurp linux-2.6.12-rc1-mm1.orig/include/linux/init.h
linux-2.6.12-rc1-mm1/include/linux/init.h
--- linux-2.6.12-rc1-mm1.orig/include/linux/init.h 2005-03-18
07:03:49.0 +0530
+++ linux-2.6.12-rc1-mm1/include/linux/init.h 2005-04-18 00:48:26.0
+0530
@@ -217,7 +217,7 @@ void __init parse_early_param(void);
#define __initdata_or_module __initdata
#endif /*CONFIG_MODULES*/
-#ifdef CONFIG_HOTPLUG
+#if defined(CONFIG_HOTPLUG) || defined(CONFIG_CPUSETS)
#define __devinit
#define __devinitdata
#define __devexit
diff -Naurp linux-2.6.12-rc1-mm1.orig/include/linux/sched.h
linux-2.6.12-rc1-mm1/include/linux/sched.h
--- linux-2.6.12-rc1-mm1.orig/include/linux/sched.h 2005-04-18
00:46:40.0 +0530
+++ linux-2.6.12-rc1-mm1/include/linux/sched.h 2005-04-18 00:48:19.0
+0530
@@ -155,6 +155,7 @@ typedef struct task_struct task_t;
extern void sched_init(void);
extern void sched_init_smp(void);
extern void init_idle(task_t *idle, int cpu);
+extern void rebuild_sched_domains(cpumask_t change_map, cpumask_t span1,
cpumask_t span2);
extern cpumask_t nohz_cpu_mask;
diff -Naurp linux-2.6.12-rc1-mm1.orig/kernel/cpuset.c
linux-2.6.12-rc1-mm1/kernel/cpuset.c
--- linux-2.6.12-rc1-mm1.orig/kernel/cpuset.c 2005-04-18 00:46:40.0
+0530
+++ linux-2.6.12-rc1-mm1/kernel/cpuset.c2005-04-18 00:51:48.0
+0530
@@ -55,9 +55,17 @@
#define CPUSET_SUPER_MAGIC 0x27e0eb
+#define all_cpus(cs) \
+({ \
+ cpumask_t __tmp_map;\
+ cpus_or(__tmp_map, cs->cpus_allowed, cs->isolated_map); \
+ __tmp_map; \
+})
+
struct cpuset {
unsigned long flags;/* "unsigned long" so bitops work */
cpumask_t cpus_allowed; /* CPUs allowed to tasks in cpuset */
+ cpumask_t isolated_map; /* CPUs associated with a sched domain
*/
nodemask_t mems_allowed;/* Memory Nodes allowed to tasks */
atomic_t count; /* count tasks using this cpuset */
@@ -82,6 +90,7 @@ struct cpuset {
/* bits in struct cpuset flags field */
typedef enum {
CS_CPU_EXCLUSIVE,
+ CS_CPU_ISOLATED,
CS_MEM_EXCLUSIVE,
CS_REMOVED,
CS_NOTIFY_ON_RELEASE
@@ -93,6 +102,11 @@ static inline int is_cpu_exclusive(const
return !!test_bit(CS_CPU_EXCLUSIVE, &cs->flags);
}
+static inline int is_cpu_isolated(const struct cpuset *cs)
+{
+ return !!test_bit(CS_CPU_ISOLATED, &cs->flags);
+}
+
static inline int is_mem_exclusive(const struct cpuset *cs)
{
return !!test_bit(CS_MEM_EXCLUSIVE, &cs->flags);
@@ -127,8 +141,9 @@ static inline int notify_on_release(cons
static atomic_t cpuset_mems_generation = ATOMIC_INIT(1);
static struct cpuset top_cpuset = {
- .flags = ((1 << CS_CPU_EXCLUSIVE) | (1 << CS_MEM_EXCLUSIV
Re: [PATCH 2.6.11.7 1/2] USB HID: Patch for Cherry CyMotion Linux keyboard
On 18 Apr 2005, at 19:14, Greg KH wrote: Your patches are line-wrapped, and the tabs were stripped out :( Ah poop - sorry about that. I'm using the Mac mail client which managed to give me the impression it was going to send them clean. Care to redo them, add a signed-off-by: line and send them to the linux-usb-devel mailing list and CC: the hid maintainer? Yes, shall do, thanks. -- Andy Armstrong, hexten.net - 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: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, Apr 18, 2005 at 09:40:40PM +0200, Arjan van de Ven wrote: >On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote: >> Arjan van de Ven wrote: >> >> > this is a myth; linux is free to move the page about in physical memory >> > even if it's mlock()ed!! darn, yes, this is true. I know people who introduced #define VM_RESERVED 0x0008 /* Don't unmap it from swap_out */ to vm_flags just because of this. I'll just hold my breath and won't delve further. >> >> Then Linux has a very odd definition of the word "locked". >> >> > And even then, the user can munlock the memory from another thread etc >> > etc. Not a good idea. >> >> Well, that's okay, because then the app is doing something stupid, so we >> don't worry about >> that. > >you should since that physical page can be reused, say by a root >process, and you'd be majorly screwed - 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: [PATCH 2.6.11.7 1/2] USB HID: Patch for Cherry CyMotion Linux keyboard
On Mon, Apr 18, 2005 at 05:41:46PM +0100, Andy Armstrong wrote: > For those who haven't seen it the Cherry CyMotion Linux keyboard is a > decent quality keyboard with the Windows specific keys replaced with > Linux keys. It's got a nice little picture of Tux on it too. The > supplied patches aren't suitable for current kernels so I've bashed > their patches into a suitable form. Your patches are line-wrapped, and the tabs were stripped out :( Care to redo them, add a signed-off-by: line and send them to the linux-usb-devel mailing list and CC: the hid maintainer? thanks, greg k-h - 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: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, 2005-04-18 at 15:00 -0500, Timur Tabi wrote: > Arjan van de Ven wrote: > > > you should since that physical page can be reused, say by a root > > process, and you'd be majorly screwed > > I don't understand what you mean by "reused". The whole point behind pinning > the memory > is that it stays where it is. It doesn't get moved around and it doesn't get > swapped out. > you just said that you didn't care that it got munlock'd. So you don't care that it gets freed either. And then reused. - 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: [PATCH 0/7] procfs privacy
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > Adding a "trusted user group"-like configuration option could be useful, > as it's done within grsecurity, among that the whole thing might be good > to depend on a config. option, but that implies using weird ifdef's and > the other folks. I'd rather see something like this implemented as an LSM module - or better yet, an SELinux security policy. There's no need to sprinkle security policy all over the kernel. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
Arjan van de Ven wrote: you should since that physical page can be reused, say by a root process, and you'd be majorly screwed I don't understand what you mean by "reused". The whole point behind pinning the memory is that it stays where it is. It doesn't get moved around and it doesn't get swapped out. -- Timur Tabi Staff Software Engineer [EMAIL PROTECTED] - 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: Linux Alpha port: LVM
On Mon, Apr 18, 2005 at 02:48:41PM +0200, Rao Davide wrote: > Is LVM working on the alpha port 2.6 kernel series ? works fine for me. > If so where do I get libdevmapper so that I can build the userspace LVM > utils ? > > I tryied downloading > ftp://sources.redhat.com/pub/dm/multipath-toolsmultipath-tools-0.4.3.tar.bz2 what do you think the 'dm' in that url stands for, hm? > But I fail to compile it so I'm also unable tu build the userspace lvm > utils. 'userspace lvm utils' can be found here: ftp://sources.redhat.com/pub/lvm2 multipath tools might be something different ... :) > -- > Regards > Davide Rao > Client/server Unix > Atos Origin > Via C.Viola - Pont St. Martin (AO) Italy > Cell : +39 3357599151 > Tel : +39 125810433 > Email: [EMAIL PROTECTED] 73 Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED] | | Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany | | Ampr: [EMAIL PROTECTED], [EMAIL PROTECTED] [44.130.8.19] | - 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: [PATCH] TCP ipv4 source port randomization
El lun, 18-04-2005 a las 12:26 -0700, David S. Miller escribió: > Stephen Hemminger has already added TCP port randomization on > connect() to the 2.6.x tree. See > net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port > selection occurs. And unlike your patch, Stephen did add ipv6 > support (via net/ipv6/tcp_ipv6.c:tcp_v6_hash_connect()) for > port randomization as well. I missed Hemminger's bits there. I apologize for any inconvenience. > > 1) That you use netdev@oss.sgi.com for networking patches as that >is where the networking developers listen. OK. > 2) That you do some checking to see that the feature you're adding >is not already present in the tree. I do, just missed that ;) Among that I have the patch done since time ago, just didn't submitted it to the list, so, during the transition I forgot all about any change (nor I checked the CSETs). Thanks for the advice, Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/7] procfs privacy: misc. entries
El lun, 18-04-2005 a las 15:05 -0400, Dave Jones escribió: > This is utterly absurd. You can find out anything thats in /proc/cpuinfo > by calling cpuid instructions yourself. Right, it doesn't make it worthy enough to represent any risk. > Please enlighten me as to what security gains we achieve > by not allowing users to see this ? It's more obscurity than anything else. At least that's what privacy means usually. It doesn't assure at all the unavailability of your information to others, it just tries to hide it from the public eye. > Restricting lots of the other files are equally absurd. > > I'd also be very surprised if various random bits of userspace > broke subtley due to this nonsense. I agree, as an example, grsecurity allows the configuration of a group with rights over the restricted entries, that's why I split up the patch for these entries. Thanks for the comments. Cheers. -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/7] procfs privacy
El lun, 18-04-2005 a las 15:27 -0400, Rik van Riel escribió: > The same "this forces people to run system monitoring tasks > as root, potentially opening themselves up to security holes" > comment applies to this patch. That's because the patch is split up, those bits are on the proc_misc one. I agree, btw. ;) Adding a "trusted user group"-like configuration option could be useful, as it's done within grsecurity, among that the whole thing might be good to depend on a config. option, but that implies using weird ifdef's and the other folks. Cheers, -- Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] signature.asc Description: This is a digitally signed message part
Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
On Mon, 2005-04-18 at 11:25 -0500, Timur Tabi wrote: > Arjan van de Ven wrote: > > > this is a myth; linux is free to move the page about in physical memory > > even if it's mlock()ed!! > > Then Linux has a very odd definition of the word "locked". > > > And even then, the user can munlock the memory from another thread etc > > etc. Not a good idea. > > Well, that's okay, because then the app is doing something stupid, so we > don't worry about > that. you should since that physical page can be reused, say by a root process, and you'd be majorly screwed - 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: intercepting syscalls
On Mon, 2005-04-18 at 20:56 +0200, Terje Malmedal wrote: > [Arjan van de Ven] > >> > but also about doing things at the right layer. The syscall layer is > >> > almost NEVER the right layer. > >> > > >> > Can you explain exactly what you are trying to do (it's not a secret I > >> > assume, kernel modules are GPL and open source after all, esp such > >> > invasive ones) and I'll try to tell you why it's wrong to do it at the > >> > syscall intercept layer... deal ? > >> > >> now, when I need someone to tell I do something wrong, I know where to go > >> :) > > > ok i'll spice things up... I'll even suggest a better solution ;) > > Hi. The promise wasn't made to me, but I'm hoping you will find a nice > and clean solution: > > Every so often there is bug in the kernel, by patching the > syscall-table I have been able to fix bugs in ioperm and fsync without > rebooting the box. > > What do I do the next time I need to do something like this? use kprobes or so to actually replace the faulty lower level function.. you don't know from how many different angles the lower level function is called, so you're really best of by replacing it at the lowest possible level, eg closest to the bug. That *very* seldomly is the actual syscall function. - 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 [PPC64]: dead processes never reaped
Hi,
The patch below appears to fix a problem where a number of dead processes
linger on the system. On a highly loaded system, dozens of processes
were found stuck in do_exit(), calling thier very last schedule(), and
then being lost forever.
Processes that are PF_DEAD are cleaned up *after* the context switch,
in a routine called finish_task_switch(task_t *prev). The "prev" gets
the value returned by _switch() in entry.S, but this value comes from
__switch_to (struct task_struct *prev,
struct task_struct *new)
{
old_thread = ¤t->thread; ///XXX shouldn't this be prev, not current?
last = _switch(old_thread, new_thread);
return last;
}
The way I see it, "prev" and "current" are almost always going to be
pointing at the same thing; however, if a "need resched" happens,
or there's a pre-emept or some-such, then prev and current won't be
the same; in which case, finish_task_switch() will end up cleaning
up the old current, instead of prev. This will result in dead processes
hanging around, which will never be scheduled again, and will never
get a chance to have put_task_struct() called on them.
This patch fixes this.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
--- arch/ppc64/kernel/process.c.orig2005-04-18 14:26:42.0 -0500
+++ arch/ppc64/kernel/process.c 2005-04-18 14:27:54.0 -0500
@@ -204,7 +204,7 @@ struct task_struct *__switch_to(struct t
flush_tlb_pending();
new_thread = &new->thread;
- old_thread = ¤t->thread;
+ old_thread = &prev->thread;
local_irq_save(flags);
last = _switch(old_thread, new_thread);
-
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: [PATCH] TCP ipv4 source port randomization
Stephen Hemminger has already added TCP port randomization on connect() to the 2.6.x tree. See net/ipv4/tcp_ipv4.c:tcp_v4_hash_connect(), where randomized port selection occurs. And unlike your patch, Stephen did add ipv6 support (via net/ipv6/tcp_ipv6.c:tcp_v6_hash_connect()) for port randomization as well. I'd like to ask two things: 1) That you use netdev@oss.sgi.com for networking patches as that is where the networking developers listen. 2) That you do some checking to see that the feature you're adding is not already present in the tree. Thanks a lot. - 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: [PATCH 0/7] procfs privacy
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > - /proc/ioports > - /proc/iomem > - /proc/devices > - /proc/cmdline > - /proc/version > - /proc/uptime > - /proc/cpuinfo > - /proc/partitions > - /proc/stat > - /proc/interrupts > - /proc/slabinfo > - /proc/diskstats > - /proc/modules > - /proc/schedstat The same "this forces people to run system monitoring tasks as root, potentially opening themselves up to security holes" comment applies to this patch. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Re: [PATCH 5/7] procfs privacy: /proc/config.gz
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > This patch changes the permissions of the procfs entry config.gz, thus, > non-root users are restricted from accessing it. Why? What is the security benefit of doing this ? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Re: [PATCH 1/7] procfs privacy: /proc/bus/pci
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > This patch changes the permissions of the /proc/bus/pci directory entry, > so, non-root users are restricted of accessing it's content. > It's also available at: > http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_drivers_pci_ > proc.c.patch > -- > Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]> > [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org] > > > begin 600 proc-privacy-1_drivers_pci_proc.c.patch > M9&EF9B`M<'5.(&1R:79E M"TR+C8N,3$O9')I=F5R M8VDO<')O8RYC?G!R;V,M<')I=F%C>2TQ"3(P,#4M,#0M,3<@,3http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] procfs privacy: tasks/processes lookup
On Mon, 18 Apr 2005, Lorenzo Hernández García-Hierro wrote: > This patch restricts non-root users to view only their own processes. This looks like a very bad default to me! Your patch would force people to run system monitoring applications as root, because otherwise they cannot get some of the information they can get now. Forcing that these applications run with root rights is a security risk, not a benefit... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
Re: intercepting syscalls
Terje Malmedal wrote: Every so often there is bug in the kernel, by patching the syscall-table I have been able to fix bugs in ioperm and fsync without rebooting the box. What do I do the next time I need to do something like this? Nothing. You have to understand that the kernel developers don't want to add support for doing things the "wrong way", even if the "wrong way" is more convenient for YOU. In the long wrong, the "wrong way" will cause more trouble than it saves. Fixing kernels bugs without rebooting the computer is not something that the kernel developers want to support. Besides, that sounds like a ridiculous thing to do, anyway. I don't see how anyone can reasonably expect any OS to handle that. -- Timur Tabi Staff Software Engineer [EMAIL PROTECTED] - 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: Fortuna
[please reply to all when posting to lkml] On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote: > >First, a reminder that the design goal of /dev/random proper is > >information-theoretic security. That is, it should be secure against > >an attacker with infinite computational power. > > I am skeptical. > I have never seen any convincing evidence for this claim, > and I suspect that there are cases in which /dev/random fails > to achieve this standard. > > And it seems I am not the only one. See, e.g., Section 5.3 of: > http://eprint.iacr.org/2005/029 Unfortunately, this paper's analysis of /dev/random is so shallow that they don't even know what hash it's using. Almost all of section 5.3 is wrong (and was when I read it initially). -- Mathematics is the supreme nostalgia of our time. - 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] TCP ipv4 source port randomization
Hi,
"When source port is generated on the fly for the TCP protocol (ie. with
connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm."
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX & grsecurity-dependent get_random_long() function, we
use
the new randomization infrastructure introduced by Arjan van de Ven <[EMAIL
PROTECTED]>,
providing the helpers get_random_int() and randomize_range().
More information at:
http://people.redhat.com/arjanv/randomize/02-randomize-infrastructure
The patch is also available at:
http://pearls.tuxedo-es.org/patches/security/tcp-rand_src-ports.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
When source port is generated on the fly for the TCP protocol (ie. with connect() ) will
be altered so that the source port is generated at random, instead of a simple
incrementing algorithm.
Ported from grsecurity (http://www.grsecurity.net by Brad Spengler).
Instead of using the PaX & grsecurity-dependent get_random_long() function, we use
the new randomization infrastructure introduced by Arjan van de Ven <[EMAIL PROTECTED]>,
providing the helpers get_random_int() and randomize_range().
More information at:
http://people.redhat.com/arjanv/randomize/02-randomize-infrastructure
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <[EMAIL PROTECTED]>
---
linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c |5 +
1 files changed, 5 insertions(+)
diff -puN net/ipv4/tcp_ipv4.c~tcp-rand_src-ports net/ipv4/tcp_ipv4.c
--- linux-2.6.11/net/ipv4/tcp_ipv4.c~tcp-rand_src-ports 2005-04-17 17:31:27.233438208 +0200
+++ linux-2.6.11-lorenzo/net/ipv4/tcp_ipv4.c 2005-04-17 17:37:03.528313616 +0200
@@ -224,6 +224,9 @@ static int tcp_v4_get_port(struct sock *
spin_lock(&tcp_portalloc_lock);
rover = tcp_port_rover;
+ if (high > low)
+ rover = low + (get_random_int() % remaining);
+
do {
rover++;
if (rover < low || rover > high)
@@ -666,6 +669,8 @@ static inline int tcp_v4_hash_connect(st
struct hlist_node *node;
struct tcp_tw_bucket *tw = NULL;
+ offset = get_random_int();
+
local_bh_disable();
for (i = 1; i <= range; i++) {
port = low + (i + offset) % range;
_
signature.asc
Description: This is a digitally signed message part
Re: [RFC 1 of 9] patches to add diskdump functionality to block layer
On Mon, Apr 18, 2005 at 04:42:26PM +0100, Christoph Hellwig wrote: > This looks like a patch for Linux 2.4. Such major changes for the > 2.4 tree don't make sense anymore, especially for functionality not > even in Linux 2.6. Agreed. - 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: [PATCH 3/7] procfs privacy: misc. entries
On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hernández García-Hierro wrote: > This patch changes the permissions of the following procfs entries to > restrict non-root users from accessing them: > > - /proc/devices > - /proc/cmdline > - /proc/version > - /proc/uptime > - /proc/cpuinfo This is utterly absurd. You can find out anything thats in /proc/cpuinfo by calling cpuid instructions yourself. Please enlighten me as to what security gains we achieve by not allowing users to see this ? Restricting lots of the other files are equally absurd. I'd also be very surprised if various random bits of userspace broke subtley due to this nonsense. Dave - 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 7/7] procfs privacy: /proc/iomem & /proc/ioports
This patch changes the permissions of the procfs entries ioports and
iomem to restrict non-root users from accessing them.
It's also available at
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1_kernel_resource.c.patch.
(last patch from the procfs privacy patch-set)
The whole patch is available at:
http://pearls.tuxedo-es.org/patches/security/proc-privacy-1.patch
Cheers,
--
Lorenzo Hernández García-Hierro <[EMAIL PROTECTED]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
diff -puN kernel/resource.c~proc-privacy-1 kernel/resource.c
--- linux-2.6.11/kernel/resource.c~proc-privacy-1 2005-04-17 18:06:56.221782784 +0200
+++ linux-2.6.11-lorenzo/kernel/resource.c 2005-04-17 18:07:55.685742888 +0200
@@ -136,10 +136,10 @@ static int __init ioresources_init(void)
{
struct proc_dir_entry *entry;
- entry = create_proc_entry("ioports", 0, NULL);
+ entry = create_proc_entry("ioports", S_IRUSR, NULL);
if (entry)
entry->proc_fops = &proc_ioports_operations;
- entry = create_proc_entry("iomem", 0, NULL);
+ entry = create_proc_entry("iomem", S_IRUSR, NULL);
if (entry)
entry->proc_fops = &proc_iomem_operations;
return 0;
signature.asc
Description: This is a digitally signed message part
