[PATCH 1/3] cifs: md5 cleanup - functions
Function names and return types on same line - conform to established
fs/cifs/ style.
Patch is also available at:
http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-funct.patch
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm2-orig/fs/cifs/md5.c 2005-03-02 08:38:12.0
+0100
+++ linux-2.6.12-rc2-mm2/fs/cifs/md5.c 2005-04-09 10:34:47.0 +0200
@@ -28,8 +28,7 @@ static void MD5Transform(__u32 buf[4], _
/*
* Note: this code is harmless on little-endian machines.
*/
-static void
-byteReverse(unsigned char *buf, unsigned longs)
+static void byteReverse(unsigned char *buf, unsigned longs)
{
__u32 t;
do {
@@ -44,8 +43,7 @@ byteReverse(unsigned char *buf, unsigned
* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
* initialization constants.
*/
-void
-MD5Init(struct MD5Context *ctx)
+void MD5Init(struct MD5Context *ctx)
{
ctx-buf[0] = 0x67452301;
ctx-buf[1] = 0xefcdab89;
@@ -60,8 +58,7 @@ MD5Init(struct MD5Context *ctx)
* Update context to reflect the concatenation of another buffer full
* of bytes.
*/
-void
-MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
+void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
{
register __u32 t;
@@ -109,8 +106,7 @@ MD5Update(struct MD5Context *ctx, unsign
* Final wrapup - pad to 64-byte boundary with the bit pattern
* 1 0* (64-bit count of bits processed, MSB-first)
*/
-void
-MD5Final(unsigned char digest[16], struct MD5Context *ctx)
+void MD5Final(unsigned char digest[16], struct MD5Context *ctx)
{
unsigned int count;
unsigned char *p;
@@ -168,8 +164,7 @@ MD5Final(unsigned char digest[16], struc
* reflect the addition of 16 longwords of new data. MD5Update blocks
* the data and converts bytes into longwords for this routine.
*/
-static void
-MD5Transform(__u32 buf[4], __u32 const in[16])
+static void MD5Transform(__u32 buf[4], __u32 const in[16])
{
register __u32 a, b, c, d;
@@ -255,9 +250,8 @@ MD5Transform(__u32 buf[4], __u32 const i
/***
the rfc 2104 version of hmac_md5 initialisation.
***/
-void
-hmac_md5_init_rfc2104(unsigned char *key, int key_len,
- struct HMACMD5Context *ctx)
+void hmac_md5_init_rfc2104(unsigned char *key, int key_len,
+ struct HMACMD5Context *ctx)
{
int i;
@@ -293,9 +287,8 @@ hmac_md5_init_rfc2104(unsigned char *key
/***
the microsoft version of hmac_md5 initialisation.
***/
-void
-hmac_md5_init_limK_to_64(const unsigned char *key, int key_len,
-struct HMACMD5Context *ctx)
+void hmac_md5_init_limK_to_64(const unsigned char *key, int key_len,
+ struct HMACMD5Context *ctx)
{
int i;
@@ -323,9 +316,8 @@ hmac_md5_init_limK_to_64(const unsigned
/***
update hmac_md5 inner buffer
***/
-void
-hmac_md5_update(const unsigned char *text, int text_len,
- struct HMACMD5Context *ctx)
+void hmac_md5_update(const unsigned char *text, int text_len,
+ struct HMACMD5Context *ctx)
{
MD5Update(ctx-ctx, text, text_len); /* then text of datagram */
}
@@ -333,8 +325,7 @@ hmac_md5_update(const unsigned char *tex
/***
finish off hmac_md5 inner buffer and generate outer one.
***/
-void
-hmac_md5_final(unsigned char *digest, struct HMACMD5Context *ctx)
+void hmac_md5_final(unsigned char *digest, struct HMACMD5Context *ctx)
{
struct MD5Context ctx_o;
@@ -350,9 +341,8 @@ hmac_md5_final(unsigned char *digest, st
single function to calculate an HMAC MD5 digest from data.
use the microsoft hmacmd5 init method because the key is 16 bytes.
/
-void
-hmac_md5(unsigned char key[16], unsigned char *data, int data_len,
-unsigned char *digest)
+void hmac_md5(unsigned char key[16], unsigned char *data, int data_len,
+ unsigned char *digest)
{
struct HMACMD5Context ctx;
hmac_md5_init_limK_to_64(key, 16, ctx);
-
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/3] cifs: md5 cleanup - spaces
clean up spacing, redundant blank lines etc.
patch is also at:
http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-spaces.patch
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm2/fs/cifs/md5.c.with_patch1 2005-04-09
10:36:44.0 +0200
+++ linux-2.6.12-rc2-mm2/fs/cifs/md5.c 2005-04-09 10:40:44.0 +0200
@@ -72,9 +72,8 @@ void MD5Update(struct MD5Context *ctx, u
t = (t 3) 0x3f;/* Bytes already in shsInfo-data */
/* Handle any leading odd-sized chunks */
-
if (t) {
- unsigned char *p = (unsigned char *) ctx-in + t;
+ unsigned char *p = (unsigned char *)ctx-in + t;
t = 64 - t;
if (len t) {
@@ -83,22 +82,20 @@ void MD5Update(struct MD5Context *ctx, u
}
memmove(p, buf, t);
byteReverse(ctx-in, 16);
- MD5Transform(ctx-buf, (__u32 *) ctx-in);
+ MD5Transform(ctx-buf, (__u32 *)ctx-in);
buf += t;
len -= t;
}
/* Process data in 64-byte chunks */
-
while (len = 64) {
memmove(ctx-in, buf, 64);
byteReverse(ctx-in, 16);
- MD5Transform(ctx-buf, (__u32 *) ctx-in);
+ MD5Transform(ctx-buf, (__u32 *)ctx-in);
buf += 64;
len -= 64;
}
/* Handle any remaining bytes of data. */
-
memmove(ctx-in, buf, len);
}
@@ -127,7 +124,7 @@ void MD5Final(unsigned char digest[16],
/* Two lots of padding: Pad the first block to 64 bytes */
memset(p, 0, count);
byteReverse(ctx-in, 16);
- MD5Transform(ctx-buf, (__u32 *) ctx-in);
+ MD5Transform(ctx-buf, (__u32 *)ctx-in);
/* Now fill the next block with 56 bytes */
memset(ctx-in, 0, 56);
@@ -138,11 +135,11 @@ void MD5Final(unsigned char digest[16],
byteReverse(ctx-in, 14);
/* Append length in bits and transform */
- ((__u32 *) ctx-in)[14] = ctx-bits[0];
- ((__u32 *) ctx-in)[15] = ctx-bits[1];
+ ((__u32 *)ctx-in)[14] = ctx-bits[0];
+ ((__u32 *)ctx-in)[15] = ctx-bits[1];
MD5Transform(ctx-buf, (__u32 *) ctx-in);
- byteReverse((unsigned char *) ctx-buf, 4);
+ byteReverse((unsigned char *)ctx-buf, 4);
memmove(digest, ctx-buf, 16);
memset(ctx, 0, sizeof(*ctx)); /* In case it's sensitive */
}
@@ -269,8 +266,8 @@ void hmac_md5_init_rfc2104(unsigned char
}
/* start out by storing key in pads */
- memset(ctx-k_ipad, 0, sizeof (ctx-k_ipad));
- memset(ctx-k_opad, 0, sizeof (ctx-k_opad));
+ memset(ctx-k_ipad, 0, sizeof(ctx-k_ipad));
+ memset(ctx-k_opad, 0, sizeof(ctx-k_opad));
memcpy(ctx-k_ipad, key, key_len);
memcpy(ctx-k_opad, key, key_len);
@@ -298,8 +295,8 @@ void hmac_md5_init_limK_to_64(const unsi
}
/* start out by storing key in pads */
- memset(ctx-k_ipad, 0, sizeof (ctx-k_ipad));
- memset(ctx-k_opad, 0, sizeof (ctx-k_opad));
+ memset(ctx-k_ipad, 0, sizeof(ctx-k_ipad));
+ memset(ctx-k_opad, 0, sizeof(ctx-k_opad));
memcpy(ctx-k_ipad, key, key_len);
memcpy(ctx-k_opad, key, key_len);
-
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: [ACPI] [2.6.12-rc2][suspend] Suspending Thinkpad: drive bay light in S3 mode stays on
On Mon, 2005-04-11 at 16:03 -0400, Shawn Starr wrote: I notice in Linux and in XP the drive bay light remains on while the laptop is in suspend-to-RAM. I know the ACPI thinkpad extras added to the kernel recently can turn this off. I wonder if we can/or need to write hooks to turn the light off so to conserve power when we're in S3 Just disable it in your suspend script. There's no reason to push that sort of policy into the kernel. -- Matthew Garrett | [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/
[PATCH 3/3] cifs: md5 cleanup - comments
clean up comments and make them conform to the style used in other cifs
files.
this patch can also be fetched from:
http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-comments.patch
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm2/fs/cifs/md5.c.with_patch2 2005-04-09
10:50:54.0 +0200
+++ linux-2.6.12-rc2-mm2/fs/cifs/md5.c 2005-04-09 10:51:00.0 +0200
@@ -15,9 +15,9 @@
* will fill a supplied 16-byte array with the digest.
*/
-/* This code slightly modified to fit into Samba by
- [EMAIL PROTECTED] Jun 2001
- and to fit the cifs vfs by
+/* This code slightly modified to fit into Samba by
+ [EMAIL PROTECTED] Jun 2001
+ and to fit the cifs vfs by
Steve French [EMAIL PROTECTED] */
#include linux/string.h
@@ -25,9 +25,7 @@
static void MD5Transform(__u32 buf[4], __u32 const in[16]);
-/*
- * Note: this code is harmless on little-endian machines.
- */
+/* Note: this code is harmless on little-endian machines. */
static void byteReverse(unsigned char *buf, unsigned longs)
{
__u32 t;
@@ -39,10 +37,8 @@ static void byteReverse(unsigned char *b
} while (--longs);
}
-/*
- * Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
- * initialization constants.
- */
+/* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
+ initialization constants. */
void MD5Init(struct MD5Context *ctx)
{
ctx-buf[0] = 0x67452301;
@@ -54,10 +50,8 @@ void MD5Init(struct MD5Context *ctx)
ctx-bits[1] = 0;
}
-/*
- * Update context to reflect the concatenation of another buffer full
- * of bytes.
- */
+/* Update context to reflect the concatenation of another buffer full of
+ bytes. */
void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
{
register __u32 t;
@@ -99,10 +93,8 @@ void MD5Update(struct MD5Context *ctx, u
memmove(ctx-in, buf, len);
}
-/*
- * Final wrapup - pad to 64-byte boundary with the bit pattern
- * 1 0* (64-bit count of bits processed, MSB-first)
- */
+/* Final wrapup - pad to 64-byte boundary with the bit pattern
+ 1 0* (64-bit count of bits processed, MSB-first) */
void MD5Final(unsigned char digest[16], struct MD5Context *ctx)
{
unsigned int count;
@@ -156,11 +148,9 @@ void MD5Final(unsigned char digest[16],
#define MD5STEP(f, w, x, y, z, data, s) \
( w += f(x, y, z) + data, w = ws | w(32-s), w += x )
-/*
- * The core of the MD5 algorithm, this alters an existing MD5 hash to
- * reflect the addition of 16 longwords of new data. MD5Update blocks
- * the data and converts bytes into longwords for this routine.
- */
+/* The core of the MD5 algorithm, this alters an existing MD5 hash to reflect
+ the addition of 16 longwords of new data. MD5Update blocks the data and
+ converts bytes into longwords for this routine. */
static void MD5Transform(__u32 buf[4], __u32 const in[16])
{
register __u32 a, b, c, d;
@@ -244,9 +234,7 @@ static void MD5Transform(__u32 buf[4], _
buf[3] += d;
}
-/***
- the rfc 2104 version of hmac_md5 initialisation.
-***/
+/* the rfc 2104 version of hmac_md5 initialisation. */
void hmac_md5_init_rfc2104(unsigned char *key, int key_len,
struct HMACMD5Context *ctx)
{
@@ -281,9 +269,7 @@ void hmac_md5_init_rfc2104(unsigned char
MD5Update(ctx-ctx, ctx-k_ipad, 64);
}
-/***
- the microsoft version of hmac_md5 initialisation.
-***/
+/* the microsoft version of hmac_md5 initialisation. */
void hmac_md5_init_limK_to_64(const unsigned char *key, int key_len,
struct HMACMD5Context *ctx)
{
@@ -310,18 +296,14 @@ void hmac_md5_init_limK_to_64(const unsi
MD5Update(ctx-ctx, ctx-k_ipad, 64);
}
-/***
- update hmac_md5 inner buffer
-***/
+/* update hmac_md5 inner buffer */
void hmac_md5_update(const unsigned char *text, int text_len,
struct HMACMD5Context *ctx)
{
MD5Update(ctx-ctx, text, text_len); /* then text of datagram */
}
-/***
- finish off hmac_md5 inner buffer and generate outer one.
-***/
+/* finish off hmac_md5 inner buffer and generate outer one. */
void hmac_md5_final(unsigned char *digest, struct HMACMD5Context *ctx)
{
struct MD5Context ctx_o;
@@ -334,10 +316,8 @@ void hmac_md5_final(unsigned char *diges
MD5Final(digest, ctx_o);
}
-/***
- single function to calculate an HMAC MD5
Re: [ACPI] [2.6.12-rc2][suspend] Suspending Thinkpad: drive bay light in S3 mode stays on
Sure, I suppose you can, but most suspend tools just echo stuff to /sys (or still /proc/acpi/sleep) which makes it harder to script it. Besides, when a laptop goes into suspend to RAM there should be no extra power on except a Moon or some other icon. That said, the ACPI thinkpad extras was designed to do all of this so why shouldn't the driver do S3 suspend if it hooks into it already? Shawn. --- Matthew Garrett [EMAIL PROTECTED] wrote: On Mon, 2005-04-11 at 16:03 -0400, Shawn Starr wrote: I notice in Linux and in XP the drive bay light remains on while the laptop is in suspend-to-RAM. I know the ACPI thinkpad extras added to the kernel recently can turn this off. I wonder if we can/or need to write hooks to turn the light off so to conserve power when we're in S3 Just disable it in your suspend script. There's no reason to push that sort of policy into the kernel. -- Matthew Garrett | [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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU
On Sun, Apr 10, 2005 at 12:47:42PM -0400, Derek Cheung wrote: Enclosed please find the updated patch that incorporates changes for all the comments I received. You did not cc: the sensors mailing list, nor fix all of the coding style issues. The volatile declaration in the m528xsim.h is needed because the declaration refers to the ColdFire 5282 register mapping. Shouldn't you be calling ioremap, and not directly accessing a specific register location through a pointer? That's how all other arches do this. 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: Do not misuse Coverity please
Hi! Jean Delvare [EMAIL PROTECTED] said: No, there is a third case: the pointer can be NULL, but the compiler happened to move the dereference down to after the check. Wow. Great point. I completely missed that possibility. In fact I didn't know that the compiler could possibly alter the order of the instructions. For one thing, I thought it was simply not allowed to. For another, I didn't know that it had been made so aware that it could actually figure out how to do this kind of things. What a mess. Let's just hope that the gcc folks know their business :) The compiler is most definitely /not/ allowed to change the results the code gives. I think that Andrew's point was that the compiler could change the order of the instructions *when this doesn't change the result*, not just in the general case, of course. In our example, The instructions: v = p-field; if (!p) return; can be seen as equivalent to if (!p) return; v = p-field; They are not. If p == NULL, the first gives an exception (SIGSEGV), the second one doesn't. Just as you can't optimize by switching: x = b / a; if (a == 0) return; Dereferencing NULL pointer is undefined. It *may* give SIGSEGV. That's what enables optimization above. You can't rely on dereferencing NULL to always give SIGSEGV. Sorry. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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] git: combo-blobs
On Mon, 11 Apr 2005, Linus Torvalds wrote: bk changes -R bk changes -L You'd dowload all the sha1 objects (they don't actually do anything to _your_ state - they only show the possible other states), and then it's a simple thing to generate a full tree of your local HEAD commit and compare it to a full tree of the remove HEAD commit. Ok, there's a rev-tree program there now to generate these things. If you control both ends, or have some other means of a smart communications protocol, you don't actually have to download the blobs themselves. Just download the rev-tree from the other side, and you can generate the differences by comparing your rev-tree against theirs. (And since they are sorted, the compare is very cheap). The downside? A revtree can get quite large. My rev-tree program allows you to cache previous state so that you don't have to follow the whole thing down, though, so it's possible to just send incrementals (since a commit _uniquely_ generates the whole rev-tree, you really can do reasonably smart things and create superset revtrees etc). So the change difference between two commits is literally rev-tree [commit-id1] commit1-revtree rev-tree [commit-id2] commit2-revtree join -t : commit1-revtree commit2-revtree common-revisions (this is also how to find the most common parent - you'd look at just the head revisions - the ones that aren't referred to by other revisions - in common-revision, and figure out the best one. I think.) Linus - 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/3] cifs: md5 cleanup - functions
Function names and return types on same line - conform to established
fs/cifs/ style.
-void
-MD5Init(struct MD5Context *ctx)
+void MD5Init(struct MD5Context *ctx)
{
ctx-buf[0] = 0x67452301;
ctx-buf[1] = 0xefcdab89;
@@ -60,8 +58,7 @@ MD5Init(struct MD5Context *ctx)
* Update context to reflect the concatenation of another buffer full
* of bytes.
*/
-void
-MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
+void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned
len)
{
Can anyone enlighten me why CIFS is not using crypto/md5?
Same question about md4
-
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] redundant NULL checks before kfree should go away...
(keeping me on CC when replying will be appreciated, thanks)
kfree() checks for NULL pointers. Checking prior to calling it is
reundant.
This patch removes such redundant checks from arch/ppc64/
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
diff -upr linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/lparcfg.c
linux-2.6.12-rc2-mm3/arch/ppc64/kernel/lparcfg.c
--- linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/lparcfg.c 2005-04-05
21:21:14.0 +0200
+++ linux-2.6.12-rc2-mm3/arch/ppc64/kernel/lparcfg.c2005-04-11
22:23:37.0 +0200
@@ -597,9 +597,7 @@ int __init lparcfg_init(void)
void __exit lparcfg_cleanup(void)
{
if (proc_ppc64_lparcfg) {
- if (proc_ppc64_lparcfg-data) {
- kfree(proc_ppc64_lparcfg-data);
- }
+ kfree(proc_ppc64_lparcfg-data);
remove_proc_entry(lparcfg, proc_ppc64_lparcfg-parent);
}
}
diff -upr linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/pSeries_reconfig.c
linux-2.6.12-rc2-mm3/arch/ppc64/kernel/pSeries_reconfig.c
--- linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/pSeries_reconfig.c
2005-04-05 21:21:14.0 +0200
+++ linux-2.6.12-rc2-mm3/arch/ppc64/kernel/pSeries_reconfig.c 2005-04-11
22:25:01.0 +0200
@@ -294,10 +294,8 @@ static struct property *new_property(con
return new;
cleanup:
- if (new-name)
- kfree(new-name);
- if (new-value)
- kfree(new-value);
+ kfree(new-name);
+ kfree(new-value);
kfree(new);
return NULL;
}
diff -upr linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/rtas_flash.c
linux-2.6.12-rc2-mm3/arch/ppc64/kernel/rtas_flash.c
--- linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/rtas_flash.c2005-04-05
21:21:14.0 +0200
+++ linux-2.6.12-rc2-mm3/arch/ppc64/kernel/rtas_flash.c 2005-04-11
22:25:49.0 +0200
@@ -565,8 +565,7 @@ static int validate_flash_release(struct
static void remove_flash_pde(struct proc_dir_entry *dp)
{
if (dp) {
- if (dp-data != NULL)
- kfree(dp-data);
+ kfree(dp-data);
dp-owner = NULL;
remove_proc_entry(dp-name, dp-parent);
}
diff -upr linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/scanlog.c
linux-2.6.12-rc2-mm3/arch/ppc64/kernel/scanlog.c
--- linux-2.6.12-rc2-mm3-orig/arch/ppc64/kernel/scanlog.c 2005-04-05
21:21:14.0 +0200
+++ linux-2.6.12-rc2-mm3/arch/ppc64/kernel/scanlog.c2005-04-11
22:26:11.0 +0200
@@ -234,8 +234,7 @@ int __init scanlog_init(void)
void __exit scanlog_cleanup(void)
{
if (proc_ppc64_scan_log_dump) {
- if (proc_ppc64_scan_log_dump-data)
- kfree(proc_ppc64_scan_log_dump-data);
+ kfree(proc_ppc64_scan_log_dump-data);
remove_proc_entry(scan-log-dump,
proc_ppc64_scan_log_dump-parent);
}
}
-
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: [ACPI] [2.6.12-rc2][suspend] Suspending Thinkpad: drive bay light in S3 mode stays on
On Mon, 2005-04-11 at 16:17 -0400, Shawn Starr wrote: Sure, I suppose you can, but most suspend tools just echo stuff to /sys (or still /proc/acpi/sleep) which makes it harder to script it. Besides, when a laptop goes into suspend to RAM there should be no extra power on except a Moon or some other icon. Most suspend tools are depressingly stupid. That's not a good reason to push functionality into the kernel. The vast majority of hardware won't work with that approach at the moment. That said, the ACPI thinkpad extras was designed to do all of this so why shouldn't the driver do S3 suspend if it hooks into it already? Because, well, strictly it wasn't. The LED control functionality in the IBM-acpi code exists because it exposes methods that are used by the BIOS in normal usage. It gives some degree of extra flexibility - there's no point in removing that for the sake of having one fewer line of shell in a suspend script. I might want the LEDs to be in different states depending on what triggered the suspend. -- Matthew Garrett | [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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: You could do that be means of a contract, but I don't think you could it do by means of a copyright license. The problem is that there is no right to control the distribution of derivative works for you to withhold from me. While you are may be reporting your thoughts accurately, this problem doesn't seem to be a legal issue. The GPL explicitly discusses this issue (section 5), and a number of people have already posted with similar commentary. Anyways, one thing to keep in mind here is that if copyright law doesn't allow the GPL's grant of permission to be conditional then copyright law would not allow other copyright grants to be conditional. Another way of looking at this is that the GPL is a copyright license -- it represents the terms and conditions under which copyrights are granted, and it also represents those permissions. -- Raul - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 11, 2005 at 12:31:53PM -0700, David Schwartz wrote: Perhaps you could cite the law that restricts to the copyright holder the right to restrict the distribution of derivative works. I can cite the laws that restrict all those other things and clearly *don't* mention distribution of derivative works. 17 USC 103 17 USC 106 -- Raul - 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 Monday, April 11, 2005 01:25:32 -0700 Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ - The anticipatory I/O scheduler has always been fairly useless with SCSI disks which perform tagged command queueing. There's a patch here from Jens which is designed to fix that up by constraining the number of requests which we'll leave pending in the device. The depth currently defaults to 1. Tunable in /sys/block/hdX/queue/iosched/queue_depth This patch hasn't been performance tested at all yet. If you think it is misbehaving (the usual symptom is processes stuck in D state) then please report it, then boot with `elevator=cfq' or `elevator=deadline' to work around it. - More CPU scheduler work. I hope someone is testing this stuff. Trying ... having some build problems that seem to be part test-harness, part bugs. Meanwhile on PPC64: fs/cifs/misc.c: In function `cifs_convertUCSpath': fs/cifs/misc.c:546: error: case label does not reduce to an integer constant fs/cifs/misc.c:549: error: case label does not reduce to an integer constant fs/cifs/misc.c:552: error: case label does not reduce to an integer constant fs/cifs/misc.c:561: error: case label does not reduce to an integer constant fs/cifs/misc.c:564: error: case label does not reduce to an integer constant fs/cifs/misc.c:567: error: case label does not reduce to an integer constant make[2]: *** [fs/cifs/misc.o] Error 1 make[1]: *** [fs/cifs] Error 2 make[1]: *** Waiting for unfinished jobs M. - 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 2.4.30-rc3 md/ext3 problems (ext3 gurus : please check)
Stephen C. Tweedie [EMAIL PROTECTED] wrote: Andrew, what was the exact illegal state of the pages you were seeing when fixing that recent leak? It looks like it's nothing more complex than dirty buffers on an anon page. Correct. I think that simply calling try_to_release_page() for all the remaining buffers at umount time will Presumably these pages have no -mapping, so try_to_release_page() will call try_to_free_buffers(). be enough to catch these; if that function fails, it tells us that the VM can't reclaim these pages. Yes, if the buffers are dirty then 2.4's try_to_free_buffers() won't free them. The only thing that would be required on top of that would be a check that the page is also on the VM LRU lists. Why do we have dirty buffers left over at umount 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/
read failed EINVAL with O_DIRECT flag
Hello,
Using O_DIRECT flag, read() failed and errno is EINVAL.
kernel 2.4.22
Filesystem Ext3 mount on /home
What's wrong ?
Thanks
Yves Crespin
#gcc -Wall -D_GNU_SOURCE direct.c -o direct
#cp direct d
#./direct d
#open failed [d] 040402 0666 errno 22
#
/* --- start code --- */
#include stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include errno.h
#define O_BINARY0
int main(int argc,char *argv[])
{
struct statsbuf;
charbuf[8192];
intopenFlags;
intfd;
intnb;
intsize;
if (argc!=2){
printf(Missing file name\n);
exit(2);
}
openFlags = O_RDWR|O_BINARY|O_NOCTTY;
openFlags |= O_DIRECT;/* Not POSIX */
fd = open(argv[1],openFlags,0666);
if (fd==-1){
printf(open failed [%s] %#o %#o errno
%d\n,argv[1],openFlags,0666,errno);
exit(1);
}
if (fstat(fd,sbuf)0){
printf(fstat failed\n);
exit(1);
}
size = sbuf.st_blksize;
if (size sizeof(buf)){
printf(Page size too big\n);
exit(3);
}
if (size sbuf.st_size){
printf(File too small\n);
exit(3);
}
nb = read(fd,buf,size);
if (nb != size){
printf(read failed fd %d size %d nb %d errno
%d\n,fd,size,nb,errno);
exit(1);
}
if (close(fd)){
printf(close failed\n);
exit(1);
}
return 0;
}
/* --- end code --- */
-
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] parisc: kfree cleanup in arch/parisc/
Get rid of redundant NULL pointer checks before kfree() in arch/parisc/ as well as a few blank lines. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] diff -upr linux-2.6.12-rc2-mm3-orig/arch/parisc/kernel/ioctl32.c linux-2.6.12-rc2-mm3/arch/parisc/kernel/ioctl32.c --- linux-2.6.12-rc2-mm3-orig/arch/parisc/kernel/ioctl32.c 2005-04-05 21:21:08.0 +0200 +++ linux-2.6.12-rc2-mm3/arch/parisc/kernel/ioctl32.c 2005-04-11 22:48:03.0 +0200 @@ -104,12 +104,9 @@ static int drm32_version(unsigned int fd } out: - if (kversion.name) - kfree(kversion.name); - if (kversion.date) - kfree(kversion.date); - if (kversion.desc) - kfree(kversion.desc); + kfree(kversion.name); + kfree(kversion.date); + kfree(kversion.desc); return ret; } @@ -166,9 +163,7 @@ static int drm32_getsetunique(unsigned i ret = -EFAULT; } - if (karg.unique != NULL) - kfree(karg.unique); - + kfree(karg.unique); return ret; } @@ -265,7 +260,6 @@ static int drm32_info_bufs(unsigned int } kfree(karg.list); - return ret; } @@ -305,7 +299,6 @@ static int drm32_free_bufs(unsigned int out: kfree(karg.list); - return ret; } @@ -494,15 +487,10 @@ static int drm32_dma(unsigned int fd, un } out: - if (karg.send_indices) - kfree(karg.send_indices); - if (karg.send_sizes) - kfree(karg.send_sizes); - if (karg.request_indices) - kfree(karg.request_indices); - if (karg.request_sizes) - kfree(karg.request_sizes); - + kfree(karg.send_indices); + kfree(karg.send_sizes); + kfree(karg.request_indices); + kfree(karg.request_sizes); return ret; } @@ -555,9 +543,7 @@ static int drm32_res_ctx(unsigned int fd ret = -EFAULT; } - if (karg.contexts) - kfree(karg.contexts); - + kfree(karg.contexts); return ret; } PS. If you reply to lists other than Linux-kernel, then please keep me on CC: - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 2005-04-11 at 18:25 +0200, Sven Luther wrote: On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote: [...] A - is the Author (or rights owner) of the software (GPL'ed); B - is an user, who got the a copy of the software from A; C - is another user, who got a copy indirectly, that is from a distributor; D - is the distributor C got the copy from. [...] Now. It seems to me that the relationship between D (distributor) and C (target of the distribution) is _not_ regulated by GPL at all. GPL is a license, the _owner_ of the rights (A) and the recipient of some rights (C, as an user) are the only subjects. D _owns_ no rights on the software, so can't grant any to C. There's no GPL between D and C. I think you are missing the point. D get's a licence from A, the GPL, and this licence includes a licence, not on use, but on redistribution, and the act of D distributing the copy to C is covered by it. In a sense A allows D to distribute the software under the GPL to C. Now, D is only allowed to do this distribution if he also distribute the source code of it, which he can't do for the firmware. I think only a lawyer can answer here. What I'm saying is that the license always comes from the copyright owner, that is A. Sublicensing is not covered by GPL. Distribution is not sublicensing. Quoting GPL itself: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. ... The wording is clear, the license is between A and C. There's no license between D and C. There's no way C can enforce anything on D (well, not on GPL basis). Notice also the fact that there are so many contributors to the linux kernel in effect means that there is nobody with the full rights as A, but only a multitude of people in the D case. In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Maybe mine it's only one interpretation. But I can't see any other. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. What is the risk for D, if D is distributing the source of the software _exactly_ in the form A publicly provides it? It's not up to D to produce the source, all D has to do is to provide verbatim copies of it to anyone D distributes the software to, on request. Imagine one of those companies got bought up by some predatory company who wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able to sue for damage or prejudice or whatever. And given what i have heard about the uncertainities of the Alteon ownership, this seems indeed like a plausible scenario, which could result in a SCO bis case. I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in the first place, it's not D's fault for sure. Do you really think the following scenario is likely: A to D: you must distribute the complete source, or the license will be terminated! D to A: gimme the complete source, and I'll distribute it. A to D: no, I'm not willing to give you the full source of my firmware, but you
Re: [2.6.12-rc2][suspend] resume occuring twice before suspend to suspend-to-disk
Hi, On Monday, 11 of April 2005 21:31, Shawn Starr wrote: I've noticed that when I do a suspend to disk. The machine suspends PCI devices once (I notice this because the ipw2200 wireless card shows its suspending, then it locks/parks the HD heads, but then all PCI devices are woken up and resume. The HD spins up and then dumps memory contents to swap partition, then it suspends all devices again? :) Is this the right behaviour? It is like that by design. The devices are suspened before we create the system image (so that they do not get in the way) and we should wake up some of them afterwards so that we can write the image to the swap partition. Currently, we wake up all devices, which is not very efficient, but it is simple enough to allow us to hunt bugs more easily. Finally, the system is just powered off. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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 encrypted swsusp 1/3] core functionality
Hi,
On Monday, 11 of April 2005 18:11, Andreas Steinmetz wrote:
Pavel Machek wrote:
Was it really neccessary to include union u? I don't like its name,
Here comes the patch with this reverted. I'm now using casts when
'abusing' the space for encryption. Furthermore the iv set up in the tfm
is used instead of the local copy.
I had no time to review your patch earlier, sorry. I'm inlining it so that I
can
comment it:
--- linux-2.6.11.2/kernel/power/swsusp.c.ast 2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c 2005-04-11 18:05:58.0
+0200
@@ -31,6 +31,9 @@
* Alex Badea [EMAIL PROTECTED]:
* Fixed runaway init
*
+ * Andreas Steinmetz [EMAIL PROTECTED]:
+ * Added encrypted suspend option
+ *
* More state savers are welcome. Especially for the scsi layer...
*
* For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -72,6 +75,16 @@
#include power.h
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include linux/random.h
+#include linux/crypto.h
+#include asm/scatterlist.h
+#endif
+
+#define CIPHER aes
+#define MAXKEY 32
+#define MAXIV 32
Why not to put these definitions under #ifdef?
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -104,7 +117,9 @@
#define SWSUSP_SIG S1SUSPEND
static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
I would add #ifdef here as well.
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key[MAXKEY];
+ u8 iv[MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -112,6 +127,11 @@
static struct swsusp_info swsusp_info;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -130,6 +150,52 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
I think it's better if this function returns an int error code and the
messages are printed where it's called from. This way, the essential
part of the code would be easier to grasp (Pavel?).
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!tfm) {
+ printk(KERN_ERR swsusp: no tfm, suspend not possible\n);
+ return NULL;
+ }
+
+ if(sizeof(key) crypto_tfm_alg_min_keysize(tfm)) {
+ printk(swsusp: key buffer too small, suspend not possible\n);
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (sizeof(iv) crypto_tfm_alg_ivsize(tfm)) {
+ printk(swsusp: iv buffer too small, suspend not possible\n);
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (mode) {
+ get_random_bytes(key, MAXKEY);
I hope you realize that this may give you a sequence of bits that you should
not use as a key ...
+ get_random_bytes(iv, MAXIV);
+ }
+
+ len = crypto_tfm_alg_max_keysize(tfm);
You have used this value earlier. Why don't you initialize len at that time?
+ if (len sizeof(key))
+ len = sizeof(key);
+
+ if (crypto_cipher_setkey(tfm, key, len)) {
+ printk(KERN_ERR swsusp: key setup failure, suspend not
possible\n);
+ crypto_free_tfm(tfm);
On any error, you call crypto_free_tfm(tfm) and return. I would use a common
error handling code, like that:
if (error)
goto Error;
/* some code */
Error:
crypto_free_tfm(tfm);
return error;
+ return NULL;
+ }
+
+ len = crypto_tfm_alg_blocksize(tfm);
+ crypto_cipher_set_iv(tfm, iv, len);
I would use crypto_tfm_alg_blocksize(tfm) here directly (shorter code).
+
+ return tfm;
+}
+#endif
+
static int mark_swapfiles(swp_entry_t prev)
{
int error;
@@ -141,6 +207,10 @@
If you used -p while making diffs, it would be easier to find out where the
changes actually started.
!memcmp(SWAPSPACE2,swsusp_header.sig, 10)) {
memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ memcpy(swsusp_header.key, key, MAXKEY);
+ memcpy(swsusp_header.iv, iv, MAXIV);
+#endif
swsusp_header.swsusp_info = prev;
error = rw_swap_page_sync(WRITE,
swp_entry(root_swap, 0),
@@ -294,6 +364,19 @@
This change will not apply to the current swsusp.c (eg as in 2.6.12-rc2).
int error = 0;
int i;
unsigned int mod = nr_copy_pages / 100;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ struct
Re: New SCM and commit list
On Sun, Apr 10, 2005 at 10:25:22PM -0500, James Bottomley wrote: On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote: On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote: If yes, then I would appreciate if you could either keep the same list, or if you want to change the list name, keep the subscriber list so those of us who actually archive it don't miss anything ;) I didn't even set up the list. I think it's Bottomley. I'm cc'ing him just so that he sees the message, but I don't actually expect him to do anything about it. I'm not even ready to start _testing_ real merges yet. But I hope that I can get non-conflicting merges done fairly soon, and maybe I can con James or Jeff or somebody to try out GIT then... Not guilty. If I remember correctly, the list was set up by the vger list maintainers (davem and company). It was tied to a trigger in one of your trees (which I think Larry did). It shouldn't be too difficult to add to git ... it just means traversing all the added patches on a merge and sending out mail. I can try out your source control tools ... I have some rc fixes ready ... when you're ready to try out merges... I have some rc fixes too, let us know when you are ready to accept them, and what format you want them in. I have a feeling that the kernel.org mirror system is just going to _love_ us using it to store temporary git trees :) 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/
2.6.12-rc2-mm3: CONFIG_MODULES=n MTD compile error
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote: ... Changes since 2.6.12-rc2-mm2: ... +remove-inter-module-mtd.patch Remove intermodule_foo() usage from mtd. ... This breaks the compilation with CONFIG_MODULES=n: -- snip -- ... CC drivers/mtd/devices/docprobe.o drivers/mtd/devices/docprobe.c: In function `DoC_Probe': drivers/mtd/devices/docprobe.c:311: warning: implicit declaration of function `__symbol_get' drivers/mtd/devices/docprobe.c:311: warning: assignment makes pointer from integer without a cast drivers/mtd/devices/docprobe.c:315: warning: implicit declaration of function `__symbol_put' ... LD .tmp_vmlinux1 drivers/built-in.o(.init.text+0x60f20): In function `DoC_Probe': : undefined reference to `__symbol_get' drivers/built-in.o(.init.text+0x60f3b): In function `DoC_Probe': : undefined reference to `__symbol_put' drivers/built-in.o(.init.text+0x610a4): In function `DoC_Probe': : undefined reference to `__symbol_get' make: *** [.tmp_vmlinux1] Error 1 -- snip -- 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 encrypted swsusp 1/3] core functionality
Hi!
I had no time to review your patch earlier, sorry. I'm inlining it so that I
can
comment it:
@@ -72,6 +75,16 @@
#include power.h
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include linux/random.h
+#include linux/crypto.h
+#include asm/scatterlist.h
+#endif
+
+#define CIPHER aes
+#define MAXKEY 32
+#define MAXIV 32
Why not to put these definitions under #ifdef?
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -104,7 +117,9 @@
#define SWSUSP_SIG S1SUSPEND
static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
I would add #ifdef here as well.
I think avoiding both ifdefs is actually right thing to do. Keep the
ifdef noise down.
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key[MAXKEY];
+ u8 iv[MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
@@ -112,6 +127,11 @@
static struct swsusp_info swsusp_info;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -130,6 +150,52 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
I think it's better if this function returns an int error code and the
messages are printed where it's called from. This way, the essential
part of the code would be easier to grasp (Pavel?).
Agreed. Actually I do not care where messages are printed, but
returning different code for different errors seems right.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-
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] I2C rtc8564.c remove duplicate include (whitespace fixed)
Hi Clemens, [PATCH] I2C rtc8564.c remove duplicate include Trivial fix: removes duplicate include line. Patch applies to: 2.6.11.x (This is my very first patch to the linux-kernel, so let me start with small things first...) Signed-off-by: Clemens Koller [EMAIL PROTECTED] Thanks for the patch, I added it to my stack. Greg, please pick it for your i2c tree. -- 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote: In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. Well, i am not sure with your interpretation, but even if you where right, we have no guarantee that A will continue being lenient, and no guarantee that A will not start suing D or whoever for illegally distributing his stuff without sources. So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A So, i get some random bit of GPLed software, i add a module or some code to it, i distribute that code in binary format only, and claim that i have used an hex editor to write it, or simply that it is the 'right' source. I have some serious doubts that i will not get sued by all the authors of the original GPLed work if i were to do that, and rightly so. says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Even in that case, you still need explicit permission of A, and all the other copyright holders of the rest of the GPLed work, to give you an explicit exception to link with this non-free bit of code. Maybe mine it's only one interpretation. But I can't see any other. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. No. The source code is clearly the prefered form of modification, not some random intermediate state A may be claiming is source. What is the risk for D, if D is distributing the source of the software _exactly_ in the form A publicly provides it? It's not up to D to produce the source, all D has to do is to provide verbatim copies of it to anyone D distributes the software to, on request. Imagine one of those companies got bought up by some predatory company who wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able to sue for damage or prejudice or whatever. And given what i have heard about the uncertainities of the Alteon ownership, this seems indeed like a plausible scenario, which could result in a SCO bis case. I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in the first place, it's not D's fault for sure. Do you really think the following scenario is likely: A to D: you must distribute the complete source, or the license will be terminated! D to A: gimme the complete source, and I'll distribute it. A to D: no, I'm not willing to give you the full source of my firmware, but you must distribute it anyway! The result is that the code in question has to be stopped from being distributed by D. But the case here is different, since A is not the sole copyright owner, so he doesn't get to set random interpretations of what is source code. That, in court? Is this really what you're afraid of? The outcome is, very likely A will be forced to release the full source. (and D forced to distribute it, but all D's we're talking of here are very happy with the full disclosure scenario, aren't they?) Imagine A refusing to give away the source code, and D is ordered to remove the incriminated code it is illegally distributing from all its servers, and recall all those thousands of CD and DVD isos containing the code it distributed, and being fined for each day it doesn't do so ? This is the scenario i want to avoid by explicitly stating the relationships
Re: [RFC][PATCH] Simple privacy enhancement for /proc/pid
Bodo Eggert schrieb:
On Sun, 10 Apr 2005, Rene Scharfe wrote:
First, configuring via kernel parameters is sufficient.
I don't remember: Would a mount option be equally easy to implement?
(Kernel parameters are OK for me, too.)
A mount option for procfs would be changable at remount, making
implementation a bit more involved.
I have another idea: let's keep the details of _every_ process owned by
user root readable by anyone.
What about SUID processes acting on behalf of users?
SUID root processes will we visible for all, too. That's fair enough, I
think. If it's a concern to you use proc.privacy=2.
- processor.max_cstate= [HW, ACPI]
- Limit processor to maximum C-state
- max_cstate=9 overrides any DMI blacklist limit.
-
This seems to belong into another patch
Strictly speaking, yes, but it's just a trivial cleanup near my own
change. And I guarantee it has zero impact on any built kernel image. :]
(in pid_revalidate:)
What about moving the things around? (just editing in the MUA)
+ if (IS_PID_DIR(proc_type(inode)) || task_dumpable(task)) {
inode-i_uid = task-euid;
+ inode-i_gid = proc_gid;
+ if (!proc_privacy || IS_PID_DIR(proc_type(inode)))
inode-i_gid = task-egid;
} else {
inode-i_uid = 0;
inode-i_gid = 0;
}
security_task_to_inode(task, inode);
return 1;
}
I suppose you could do that, but I don't see any gain. I also find my
version easier to read because it keeps the two conditionals (having
different intents and purposes) apart.
BTW: You might be able to cache IS_PID_DIR(). It looks like being a gain.
I'd rather let the compiler do that job. It's only a small macro, I
really doubt you would measure any speedup from putting it into a local
variable.
@@ -1454,6 +1468,11 @@ static struct dentry *proc_pident_lookup
+ if (proc_privacy == 2 || task-euid != 0)
^
redundand.
You're right and it's a matter of taste, I guess. By the way, this is
also what the FreeBSD crowd calls a bikeshed. :-)
Thanks for reviewing my patch!
Rene
-
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: New SCM and commit list
On Mon, 11 Apr 2005, Greg KH wrote: I have a feeling that the kernel.org mirror system is just going to _love_ us using it to store temporary git trees :) I don't think kernel.org mirrors the private home directories, so it you do _temporary_ trees, just make them readable in your private home directory rather than in /pub/linux/kernel/people. For people with kernel.org accounts, we can use that as the bkbits.net thing. For really public hosting, we need to find some other approach. Linus - 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] zero disk pages used by swsusp on resume
Hi, On Monday, 11 of April 2005 19:02, Andreas Steinmetz wrote: Rafael J. Wysocki wrote: Hi, On Monday, 11 of April 2005 12:37, Oliver Neukum wrote: Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek: Hi! Oliver Neukum wrote: What is the point in doing so after they've rested on the disk for ages? The point is not physical access to the disk but data gathering after resume or reboot. After resume or reboot normal access control mechanisms will work again. Those who can read a swap partition under normal circumstances can also read /dev/kmem. It seems to me like you are putting an extra lock on a window on the third floor while leaving the front door open. Andreas is right, his patches are needed. Currently, if your laptop is stolen after resume, they can still data in swsusp image. Zeroing the swsusp pages helps a lot here, because at least they are not getting swsusp image data without heavy tools. [Or think root compromise month after you used swsusp.] Encrypting swsusp image is of course even better, because you don't have to write large ammounts of zeros to your disks during resume ;-). Not only is it better, it completely supercedes wiping the image. Your laptop being stolen after resume is very much a corner case. You suspend your laptop while you are not around, don't you? Not necessarily. Some people use suspend instead of shutdown. :-) Now here's what I'm currently doing: I do usually suspend instead of shutdown. The suspend partition is the only unencrypted swap partition and it is disabled during regular operation so it is not used for regular swapping. Except for a small boot partition without any valuable data all other partitions are encrypted. The key for dm-crypt setup is stored on an ide flash disk which isn't inserted during travelling and which is transported separately. Now let's imagine the laptop gets stolen by an average thief which is the most common case.Thief needs to know if the laptop is working because thief wants to sell it so thief powers on the laptop. swsusp resumes and with the encryption patch renders the suspend image worthless. The suspend/resume script immediately checks for the presence of the ide flash disk with the correct key (match is done against the in-kernel dm-crypt key). If the ide flash disk is not present or if there is a key mismatch the script shuts the system immediately down, so the in-kernel key is lost. The only way for the thief now to access any data on the disk is to come back and steal the flash disk, too. Yes. And if you accidentally lose the flash disk, you are locked out of your own data. ;-) The same happens if the data on the flash disk is lost (which occurs, from time to time). You should be _really_ careful doing such things and IMO it's not to be tried by Joe User. OTOH, the encryption of the system image during suspend is generally a very good idea. IMO we should also check the integrity of the image at that time, which would require computing some checksums on suspend. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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: New SCM and commit list
On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote: I don't think kernel.org mirrors the private home directories, so it you do _temporary_ trees, just make them readable in your private home directory rather than in /pub/linux/kernel/people. For people with kernel.org accounts, we can use that as the bkbits.net thing. It's also going to be a slight problem for those of us who don't have a kernel.org account...although I think the hosting I use on the parisc website might actually be outside the HP firewall, so I can probably beg for it to run any protocol you need (like rsync). 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 encrypted swsusp 1/3] core functionality
Hi, On Monday, 11 of April 2005 23:08, Pavel Machek wrote: Hi! ]--snip--[ @@ -130,6 +150,52 @@ static unsigned short swapfile_used[MAX_SWAPFILES]; static unsigned short root_swap; +#ifdef CONFIG_SWSUSP_ENCRYPT +static struct crypto_tfm *crypto_init(int mode) I think it's better if this function returns an int error code and the messages are printed where it's called from. This way, the essential part of the code would be easier to grasp (Pavel?). Agreed. Actually I do not care where messages are printed, but returning different code for different errors seems right. Hm. You probably don't want suspend-related messages to be printed during resume (this function is called in two different places)? :-) Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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] net: remove redundant NULL pointer checks prior to kfree in drivers/net/slip.c
kfree() checks for NULL. Checking prior to calling it is redundant. This patch removes these redundant checks from drivers/net/slip.c Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- slip.c | 30 -- 1 files changed, 12 insertions(+), 18 deletions(-) --- linux-2.6.12-rc2-mm3-orig/drivers/net/slip.c2005-03-02 08:38:33.0 +0100 +++ linux-2.6.12-rc2-mm3/drivers/net/slip.c 2005-04-11 23:10:06.0 +0200 @@ -185,15 +185,12 @@ sl_alloc_bufs(struct slip *sl, int mtu) /* Cleanup */ err_exit: #ifdef SL_INCLUDE_CSLIP - if (cbuff) - kfree(cbuff); + kfree(cbuff); if (slcomp) slhc_free(slcomp); #endif - if (xbuff) - kfree(xbuff); - if (rbuff) - kfree(rbuff); + kfree(xbuff); + kfree(rbuff); return err; } @@ -204,13 +201,13 @@ sl_free_bufs(struct slip *sl) void * tmp; /* Free all SLIP frame buffers. */ - if ((tmp = xchg(sl-rbuff, NULL)) != NULL) - kfree(tmp); - if ((tmp = xchg(sl-xbuff, NULL)) != NULL) - kfree(tmp); + tmp = xchg(sl-rbuff, NULL); + kfree(tmp); + tmp = xchg(sl-xbuff, NULL); + kfree(tmp); #ifdef SL_INCLUDE_CSLIP - if ((tmp = xchg(sl-cbuff, NULL)) != NULL) - kfree(tmp); + tmp = xchg(sl-cbuff, NULL); + kfree(tmp); if ((tmp = xchg(sl-slcomp, NULL)) != NULL) slhc_free(tmp); #endif @@ -297,13 +294,10 @@ done_on_bh: spin_unlock_bh(sl-lock); done: - if (xbuff) - kfree(xbuff); - if (rbuff) - kfree(rbuff); + kfree(xbuff); + kfree(rbuff); #ifdef SL_INCLUDE_CSLIP - if (cbuff) - kfree(cbuff); + kfree(cbuff); #endif return err; } - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 11:24:10AM +0200, Giuseppe Bilotta wrote: AFAIK software only refers to programs, not to arbitrary sequences of bytes. An MP3 file isn't software. Although it surely isn't hardware either. This point is a controversial point. Different people make different claims. For example, http://www.answers.com/software -- the Computer Desktop Encyclopedia asserts that you are correct, while Wikipedia asserts that you are incorrect. The American Heritage Dictionary implies you are correct, and WordNet implies that you're incorrect. Usage is still evolving, so who knows where this issue will stand in five years. In the context of the linux kernel (which I presume you're talking about, given the message headers), I don't think it's plausible to suggest that the occasional use of the term software in the license means that the stuff under Documentation/ isn't covered by the license. -- Raul - 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] FUSE permission modell (Was: fuse review bits)
Miklos Szeredi wrote: That is exactly the intended effect. If I'm at my work machine (where I'm not an admin unfortunately) and I mount my home machine with sshfs (because FUSE is installed fortunately :), then I bloody well don't want the sysadmin or some automated script of his to go mucking under the mountpoint. I think that would be _much_ nicer implemented as a mount which is invisible to other users, rather than one which causes the admin's scripts to spew error messages. Is the namespace mechanism at all suitable for that? It would also be nice to generalise and have virtual filesystems which are able to present different views to different users. Can FUSE do that already - is the userspace part told which user is doing each operation? With that, the desire for virtual filesystems which cannot be read by your sysadmin (by accident) is easy to satisfy - and that kind of mechanism would probably be acceptable to all. -- Jamie - 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] usb: kfree() cleanups in drivers/usb/core/devio.c
Checking for NULL before calling kfree() is redundant. This patch removes
these redundant checks and also makes a few tiny whitespace changes.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
devio.c | 32
1 files changed, 12 insertions(+), 20 deletions(-)
--- linux-2.6.12-rc2-mm3-orig/drivers/usb/core/devio.c 2005-04-11
21:20:49.0 +0200
+++ linux-2.6.12-rc2-mm3/drivers/usb/core/devio.c 2005-04-11
23:49:41.0 +0200
@@ -213,12 +213,10 @@ static struct async *alloc_async(unsigne
static void free_async(struct async *as)
{
-if (as-urb-transfer_buffer)
-kfree(as-urb-transfer_buffer);
-if (as-urb-setup_packet)
-kfree(as-urb-setup_packet);
+ kfree(as-urb-transfer_buffer);
+ kfree(as-urb-setup_packet);
usb_free_urb(as-urb);
-kfree(as);
+ kfree(as);
}
static inline void async_newpending(struct async *as)
@@ -938,17 +936,13 @@ static int proc_do_submiturb(struct dev_
return -EINVAL;
}
if (!(as = alloc_async(uurb-number_of_packets))) {
- if (isopkt)
- kfree(isopkt);
- if (dr)
- kfree(dr);
+ kfree(isopkt);
+ kfree(dr);
return -ENOMEM;
}
if (!(as-urb-transfer_buffer = kmalloc(uurb-buffer_length,
GFP_KERNEL))) {
- if (isopkt)
- kfree(isopkt);
- if (dr)
- kfree(dr);
+ kfree(isopkt);
+ kfree(dr);
free_async(as);
return -ENOMEM;
}
@@ -967,8 +961,7 @@ static int proc_do_submiturb(struct dev_
as-urb-iso_frame_desc[u].length = isopkt[u].length;
totlen += isopkt[u].length;
}
- if (isopkt)
- kfree(isopkt);
+ kfree(isopkt);
as-ps = ps;
as-userurb = arg;
if (uurb-endpoint USB_DIR_IN)
@@ -1237,7 +1230,7 @@ static int proc_ioctl (struct dev_state
return -ENOMEM;
if ((_IOC_DIR(ctrl.ioctl_code) _IOC_WRITE)) {
if (copy_from_user (buf, ctrl.data, size)) {
- kfree (buf);
+ kfree(buf);
return -EFAULT;
}
} else {
@@ -1246,8 +1239,7 @@ static int proc_ioctl (struct dev_state
}
if (!connected(ps-dev)) {
- if (buf)
- kfree(buf);
+ kfree(buf);
return -ENODEV;
}
@@ -1309,8 +1301,8 @@ static int proc_ioctl (struct dev_state
size 0
copy_to_user (ctrl.data, buf, size) != 0)
retval = -EFAULT;
- if (buf != NULL)
- kfree (buf);
+
+ kfree(buf);
return retval;
}
-
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 Monday 11 April 2005 11:43, Andrew Morton wrote:
(Please do reply-to-all)
J.A. Magallon [EMAIL PROTECTED] wrote:
On 04.11, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
c2/2.6.12-rc2-mm3/
Is this not needed anymore ?
--- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix 2005-04-05
00:02:48.0 -0700 +++ 25-akpm/arch/i386/kernel/entry.S
2005-04-05
00:02:48.0 -0700
Hopefully not. fix-crash-in-entrys-restore_all.patch works around the
problem. -
Hello Andrew,
I don't know whether you remember the mysterious crashes I was telling you
about last week and me rookiesh-ly trying to debug them with kgdb over the
serial console. Well, today I tried for the n-th time again and after rc2-mm3
blocked again while loading, here's what I did:
snip
[ 12.335438] NET: Registered protocol family 17
[ 12.362483] Testing NMI watchdog ... OK.
[ 12.416195] Starting balanced_irq
[ 12.443099] VFS: Mounted root (ext2 filesystem) readonly.
[ 12.472490] Freeing unused kernel memory: 196k freed
[ 12.521004] logips2pp: Detected unknown logitech mouse model 1
[ 12.572581] Warning: unable to open an initial console.
[ 12.972518] input: PS/2 Logitech Mouse on isa0060/serio1
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0102ee7 in resume_kernelX () at atomic.h:175 --- this one is wrong for a
mysterious reason
175 {
(gdb) p $eip
$1 = (void *) 0xc0102ee7
(gdb) disas 0xc0102ee7
Dump of assembler code for function resume_kernelX:
0xc0102ee7 resume_kernelX+0: mov0x30(%esp),%eax
0xc0102eeb resume_kernelX+4: mov0x38(%esp),%ah
0xc0102eef resume_kernelX+8: mov0x2c(%esp),%al
0xc0102ef3 resume_kernelX+12: and$0x20403,%eax
0xc0102ef8 resume_kernelX+17: cmp$0x403,%eax
0xc0102efd resume_kernelX+22: je 0xc0102f0c ldt_ss
End of assembler dump.
(gdb)
And as we see, we're at the mov0x30(%esp),%eax which accesses above the
bottom of the stack. After applying nmi_stack_correct-fix.patch, rc2-mm3
booted just fine, so I IMHO think that we might still be needing this, after
all.
Regards,
Boris.
-
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] ppc32: refactor FPU exception handling
Andrew, Moved common FPU exception handling code out of head.S so it can be used by several of the sub-architectures that might of a full PowerPC FPU. Also, uses new CONFIG_PPC_FPU define to fix alignment exception handling for floating point load/store instructions to only occur if we have a hardware FPU. Signed-off-by: Jason McMullan [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- diff -Nru a/arch/ppc/Kconfig b/arch/ppc/Kconfig --- a/arch/ppc/Kconfig 2005-04-11 17:00:36 -05:00 +++ b/arch/ppc/Kconfig 2005-04-11 17:00:36 -05:00 @@ -53,6 +53,7 @@ config 6xx bool 6xx/7xx/74xx/52xx/82xx/83xx + select PPC_FPU help There are four types of PowerPC chips supported. The more common types (601, 603, 604, 740, 750, 7400), the Motorola embedded @@ -85,6 +86,9 @@ bool e500 endchoice + +config PPC_FPU + bool config BOOKE bool diff -Nru a/arch/ppc/Makefile b/arch/ppc/Makefile --- a/arch/ppc/Makefile 2005-04-11 17:00:36 -05:00 +++ b/arch/ppc/Makefile 2005-04-11 17:00:36 -05:00 @@ -53,6 +53,7 @@ head-$(CONFIG_6xx) += arch/ppc/kernel/idle_6xx.o head-$(CONFIG_POWER4) += arch/ppc/kernel/idle_power4.o +head-$(CONFIG_PPC_FPU) += arch/ppc/kernel/fpu.o core-y += arch/ppc/kernel/ arch/ppc/platforms/ \ arch/ppc/mm/ arch/ppc/lib/ arch/ppc/syslib/ diff -Nru a/arch/ppc/kernel/Makefile b/arch/ppc/kernel/Makefile --- a/arch/ppc/kernel/Makefile 2005-04-11 17:00:36 -05:00 +++ b/arch/ppc/kernel/Makefile 2005-04-11 17:00:36 -05:00 @@ -9,6 +9,7 @@ extra-$(CONFIG_8xx):= head_8xx.o extra-$(CONFIG_6xx)+= idle_6xx.o extra-$(CONFIG_POWER4) += idle_power4.o +extra-$(CONFIG_PPC_FPU)+= fpu.o extra-y+= vmlinux.lds obj-y := entry.o traps.o irq.o idle.o time.o misc.o \ diff -Nru a/arch/ppc/kernel/align.c b/arch/ppc/kernel/align.c --- a/arch/ppc/kernel/align.c 2005-04-11 17:00:36 -05:00 +++ b/arch/ppc/kernel/align.c 2005-04-11 17:00:36 -05:00 @@ -368,16 +368,24 @@ /* Single-precision FP load and store require conversions... */ case LD+F+S: +#ifdef CONFIG_PPC_FPU preempt_disable(); enable_kernel_fp(); cvt_fd(data.f, data.d, current-thread.fpscr); preempt_enable(); +#else + return 0; +#endif break; case ST+F+S: +#ifdef CONFIG_PPC_FPU preempt_disable(); enable_kernel_fp(); cvt_df(data.d, data.f, current-thread.fpscr); preempt_enable(); +#else + return 0; +#endif break; } diff -Nru a/arch/ppc/kernel/fpu.S b/arch/ppc/kernel/fpu.S --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/arch/ppc/kernel/fpu.S 2005-04-11 17:00:36 -05:00 @@ -0,0 +1,190 @@ +/* + * FPU support code, moved here from head.S so that it can be used + * by chips which use other head-whatever.S files. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + */ + +#include linux/config.h +#include asm/processor.h +#include asm/page.h +#include asm/mmu.h +#include asm/pgtable.h +#include asm/cputable.h +#include asm/cache.h +#include asm/thread_info.h +#include asm/ppc_asm.h +#include asm/offsets.h + +/* + * This task wants to use the FPU now. + * On UP, disable FP for the task which had the FPU previously, + * and save its floating-point registers in its thread_struct. + * Load up this task's FP registers from its thread_struct, + * enable the FPU for the current task and return to the task. + */ + .globl load_up_fpu +load_up_fpu: + mfmsr r5 + ori r5,r5,MSR_FP +#ifdef CONFIG_PPC64BRIDGE + clrldi r5,r5,1 /* turn off 64-bit mode */ +#endif /* CONFIG_PPC64BRIDGE */ + SYNC + MTMSRD(r5) /* enable use of fpu now */ + isync +/* + * For SMP, we don't do lazy FPU switching because it just gets too + * horrendously complex, especially when a task switches from one CPU + * to another. Instead we call giveup_fpu in switch_to. + */ +#ifndef CONFIG_SMP + tophys(r6,0)/* get __pa constant */ + addis r3,r6,[EMAIL PROTECTED] + lwz r4,[EMAIL PROTECTED](r3) + cmpwi 0,r4,0 + beq 1f + add r4,r4,r6 + addir4,r4,THREAD/* want last_task_used_math-thread */ + SAVE_32FPRS(0, r4) + mffsfr0 + stfdfr0,THREAD_FPSCR-4(r4) + lwz r5,PT_REGS(r4) + add r5,r5,r6 + lwz r4,_MSR-STACK_FRAME_OVERHEAD(r5) + li r10,MSR_FP|MSR_FE0|MSR_FE1 +
Re: [patch 4/5] sched: RCU sched domains
On Thu, Apr 07, 2005 at 05:58:40PM +1000, Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
At a minimum i think we need the fix+comment below.
Well if we say this is actually RCU, then yes. And we should
probably change the preempt_{dis|en}ables in other places to
rcu_read_lock.
OTOH, if we say we just want all running threads to process through a
preemption stage, then this would just be a preempt_disable/enable
pair.
In practice that makes no difference yet, but it looks like you and
Paul are working to distinguish these two cases in the RCU code, to
accomodate your low latency RCU stuff?
it doesnt impact PREEMPT_RCU/PREEMPT_RT directly, because the scheduler
itself always needs to be non-preemptible.
those few places where we currently do preempt_disable(), which should
thus be rcu_read_lock(), are never in codepaths that can take alot of
time.
but yes, in principle you are right, but in this particular (and
special) case it's not a big issue. We should document the RCU read-lock
dependencies cleanly and make all rcu-read-lock cases truly
rcu_read_lock(), but it's not a pressing issue even considering possible
future features like PREEMPT_RT.
the only danger in this area is to PREEMPT_RT: it is a bug on PREEMPT_RT
if kernel code has an implicit 'spinlock means preempt-off and thus
RCU-read-lock' assumption. Most of the time these get discovered via
PREEMPT_DEBUG. (preempt_disable() disables preemption on PREEMPT_RT too,
so that is not a problem either.)
OK thanks for the good explanation. So I'll keep it as is for now,
and whatever needs cleaning up later can be worked out as it comes
up.
Looking forward to the split of synchronize_kernel() into synchronize_rcu()
and synchronize_sched(), the two choices are:
o Use synchronize_rcu(), but insert rcu_read_lock()/rcu_read_unlock()
pairs on the read side.
o Use synchronize_sched(), and make sure all read-side code is
under preempt_disable().
Either way, there may also need to be some rcu_dereference()s when picking
up pointer and rcu_assign_pointer()s when updating the pointers.
For example, if traversing the domain parent list is to be RCU protected,
the for_each_domain() macro should change to something like:
#define for_each_domain(cpu, domain) \
for (domain = cpu_rq(cpu)-sd; domain; domain =
rcu_dereference(domain-parent))
Thanx, Paul
-
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] Fix SIGBUS handling
ARM wasn't raising a SIGBUS with a siginfo structure. Fix
__do_user_fault() to allow us to use it for SIGBUS conditions,
and arrange for the sigbus path to use this.
We need to prevent the siginfo code being called if we do
not have a user space context to call it, so consolidate the
user_mode() tests.
Thanks to Ian Campbell who spotted this oversight.
Signed-off-by: Russell King [EMAIL PROTECTED]
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej
orig/arch/arm/mm/fault.c linux/arch/arm/mm/fault.c
--- orig/arch/arm/mm/fault.cFri Nov 5 19:28:15 2004
+++ linux/arch/arm/mm/fault.c Fri Apr 8 14:24:50 2005
@@ -108,14 +108,15 @@ __do_kernel_fault(struct mm_struct *mm,
*/
static void
__do_user_fault(struct task_struct *tsk, unsigned long addr,
- unsigned int fsr, int code, struct pt_regs *regs)
+ unsigned int fsr, unsigned int sig, int code,
+ struct pt_regs *regs)
{
struct siginfo si;
#ifdef CONFIG_DEBUG_USER
if (user_debug UDBG_SEGV) {
- printk(KERN_DEBUG %s: unhandled page fault at 0x%08lx, code
0x%03x\n,
- tsk-comm, addr, fsr);
+ printk(KERN_DEBUG %s: unhandled page fault (%d) at 0x%08lx,
code 0x%03x\n,
+ tsk-comm, sig, addr, fsr);
show_pte(tsk-mm, addr);
show_regs(regs);
}
@@ -124,11 +125,11 @@ __do_user_fault(struct task_struct *tsk,
tsk-thread.address = addr;
tsk-thread.error_code = fsr;
tsk-thread.trap_no = 14;
- si.si_signo = SIGSEGV;
+ si.si_signo = sig;
si.si_errno = 0;
si.si_code = code;
si.si_addr = (void __user *)addr;
- force_sig_info(SIGSEGV, si, tsk);
+ force_sig_info(sig, si, tsk);
}
void
@@ -140,7 +141,7 @@ do_bad_area(struct task_struct *tsk, str
* have no context to handle this fault with.
*/
if (user_mode(regs))
- __do_user_fault(tsk, addr, fsr, SEGV_MAPERR, regs);
+ __do_user_fault(tsk, addr, fsr, SIGSEGV, SEGV_MAPERR, regs);
else
__do_kernel_fault(mm, addr, fsr, regs);
}
@@ -201,10 +202,11 @@ survive:
goto out;
/*
-* If we are out of memory for pid1,
-* sleep for a while and retry
+* If we are out of memory for pid1, sleep for a while and retry
*/
+ up_read(mm-mmap_sem);
yield();
+ down_read(mm-mmap_sem);
goto survive;
check_stack:
@@ -219,7 +221,7 @@ do_page_fault(unsigned long addr, unsign
{
struct task_struct *tsk;
struct mm_struct *mm;
- int fault;
+ int fault, sig, code;
tsk = current;
mm = tsk-mm;
@@ -242,55 +244,45 @@ do_page_fault(unsigned long addr, unsign
return 0;
/*
-* We had some memory, but were unable to
-* successfully fix up this page fault.
-*/
- if (fault == 0)
- goto do_sigbus;
-
- /*
* If we are in kernel mode at this point, we
* have no context to handle this fault with.
*/
if (!user_mode(regs))
goto no_context;
- if (fault == VM_FAULT_OOM) {
+ switch (fault) {
+ case VM_FAULT_OOM:
/*
-* We ran out of memory, or some other thing happened to
-* us that made us unable to handle the page fault gracefully.
+* We ran out of memory, or some other thing
+* happened to us that made us unable to handle
+* the page fault gracefully.
*/
printk(VM: killing process %s\n, tsk-comm);
do_exit(SIGKILL);
- } else
- __do_user_fault(tsk, addr, fsr, fault == VM_FAULT_BADACCESS ?
- SEGV_ACCERR : SEGV_MAPERR, regs);
- return 0;
+ return 0;
+ case 0:
+ /*
+* We had some memory, but were unable to
+* successfully fix up this page fault.
+*/
+ sig = SIGBUS;
+ code = BUS_ADRERR;
+ break;
-/*
- * We ran out of memory, or some other thing happened to us that made
- * us unable to handle the page fault gracefully.
- */
-do_sigbus:
- /*
-* Send a sigbus, regardless of whether we were in kernel
-* or user mode.
-*/
- tsk-thread.address = addr;
- tsk-thread.error_code = fsr;
- tsk-thread.trap_no = 14;
- force_sig(SIGBUS, tsk);
-#ifdef CONFIG_DEBUG_USER
- if (user_debug UDBG_BUS) {
- printk(KERN_DEBUG %s: sigbus at 0x%08lx, pc=0x%08lx\n,
- current-comm, addr, instruction_pointer(regs));
+ default:
+ /*
+* Something tried to access memory that
+* isn't in our memory map..
+*/
[PATCH] Add comment about max_low_pfn/max_pfn
Oddly, max_low_pfn/max_pfn end up being the number of pages in the system, rather than the maximum PFN on ARM. This doesn't seem to cause any problems, so just add a note about it. Signed-off-by: Russell King [EMAIL PROTECTED] diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r orig/arch/arm/mm/init.c linux/arch/arm/mm/init.c --- orig/arch/arm/mm/init.c Sat Mar 19 11:20:00 2005 +++ linux/arch/arm/mm/init.cMon Apr 11 14:06:10 2005 @@ -223,6 +223,9 @@ find_memend_and_nodes(struct meminfo *mi * This doesn't seem to be used by the Linux memory * manager any more. If we can get rid of it, we * also get rid of some of the stuff above as well. +* +* Note: max_low_pfn and max_pfn reflect the number +* of _pages_ in the system, not the maximum PFN. */ max_low_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); max_pfn = memend_pfn - O_PFN_DOWN(PHYS_OFFSET); - 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] Fix floppy disk dependencies
Both the RiscPC and (optionally) EBSA285 have floppy disk support. Allow this option to be selected on these ARM platforms again. Signed-off-by: Russell King [EMAIL PROTECTED] diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r orig/drivers/block/Kconfig linux/drivers/block/Kconfig --- orig/drivers/block/Kconfig Mon Apr 4 22:53:23 2005 +++ linux/drivers/block/Kconfig Mon Apr 4 23:42:07 2005 @@ -6,7 +6,7 @@ menu Block devices config BLK_DEV_FD tristate Normal floppy disk support - depends on (!ARCH_S390 !M68K !IA64 !UML) || Q40 || (SUN3X BROKEN) + depends on (!ARCH_S390 !M68K !IA64 !UML) || Q40 || (SUN3X BROKEN) || ARCH_RPC || ARCH_EBSA285 ---help--- If you want to use the floppy disk drive(s) of your PC under Linux, say Y. Information about this driver, especially important for IBM - 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] Priority Lists for the RT mutex
On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote: * Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote: Let me re-phrase then: it is a must have only on PI, to make sure you don't have a loop when doing it. Maybe is a consequence of the algorithm I chose. -However- it should be possible to disable it in cases where you are reasonably sure it won't happen (such as kernel code). In any case, AFAIR, I still did not implement it. are there cases where userspace wants to disable deadlock-detection for its own locks? I'd disable it for userspace locks. There might be folks that want to implement userspace drivers, but I can't imagine it being 'ok' to have the kernel call out to userspace and have it block correctly. I would expect them to do something else that's less drastic. the deadlock detector in PREEMPT_RT is pretty much specialized for debugging (it does all sorts of weird locking tricks to get the first deadlock out, and to really report it on the console), but it ought to be possible to make it usable for userspace-controlled locks as well. If I understand things correctly, I'd let that be an RT app issue and the app folks should decided what is appropriate for their setup. If they need a deadlock detector they should decide on their own protocol. The kernel debugging issues are completely different. That's my two cents. bill - 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] Fix comments in 8250.c
Fix the formatting of some comments in 8250.c, and add a note
that the register_serial / unregister_serial shouldn't be used
in new code.
We do this here in preference to adding to linux/serial.h, since
that is used by a number of non-8250 drivers which pretend to be
8250. It is not known whether it would be appropriate to do so.
Signed-off-by: Russell King [EMAIL PROTECTED]
diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r
orig/drivers/serial/8250.c linux/drivers/serial/8250.c
--- orig/drivers/serial/8250.c Mon Apr 4 22:54:05 2005
+++ linux/drivers/serial/8250.c Mon Apr 11 20:41:22 2005
@@ -1065,8 +1065,10 @@ receive_chars(struct uart_8250_port *up,
tty_flip_buffer_push(tty);
spin_lock(up-port.lock);
}
- /* If this failed then we will throw away the
- bytes but must do so to clear interrupts */
+ /*
+* If this failed then we will throw away the
+* bytes but must do so to clear interrupts
+*/
}
ch = serial_inp(up, UART_RX);
flag = TTY_NORMAL;
@@ -1106,7 +1108,7 @@ receive_chars(struct uart_8250_port *up,
up-port.icount.overrun++;
/*
-* Mask off conditions which should be ingored.
+* Mask off conditions which should be ignored.
*/
lsr = up-port.read_status_mask;
@@ -2570,6 +2572,9 @@ MODULE_ALIAS_CHARDEV_MAJOR(TTY_MAJOR);
* If this fails an error is returned.
*
* On success the port is ready to use and the line number is returned.
+ *
+ * Note: this function is deprecated - use serial8250_register_port
+ * instead.
*/
int register_serial(struct serial_struct *req)
{
@@ -2624,6 +2629,9 @@ EXPORT_SYMBOL(register_serial);
*
* Remove one serial port. This may not be called from interrupt
* context. We hand the port back to our local PM control.
+ *
+ * Note: this function is deprecated - use serial8250_unregister_port
+ * instead.
*/
void unregister_serial(int line)
{
-
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
Borislav Petkov [EMAIL PROTECTED] wrote:
On Monday 11 April 2005 11:43, Andrew Morton wrote:
(Please do reply-to-all)
J.A. Magallon [EMAIL PROTECTED] wrote:
On 04.11, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
c2/2.6.12-rc2-mm3/
Is this not needed anymore ?
--- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix2005-04-05
00:02:48.0 -0700 +++ 25-akpm/arch/i386/kernel/entry.S
2005-04-05
00:02:48.0 -0700
Hopefully not. fix-crash-in-entrys-restore_all.patch works around the
problem. -
Hello Andrew,
I don't know whether you remember the mysterious crashes I was telling you
about last week and me rookiesh-ly trying to debug them with kgdb over the
serial console. Well, today I tried for the n-th time again and after rc2-mm3
blocked again while loading, here's what I did:
snip
[ 12.335438] NET: Registered protocol family 17
[ 12.362483] Testing NMI watchdog ... OK.
[ 12.416195] Starting balanced_irq
[ 12.443099] VFS: Mounted root (ext2 filesystem) readonly.
[ 12.472490] Freeing unused kernel memory: 196k freed
[ 12.521004] logips2pp: Detected unknown logitech mouse model 1
[ 12.572581] Warning: unable to open an initial console.
[ 12.972518] input: PS/2 Logitech Mouse on isa0060/serio1
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0102ee7 in resume_kernelX () at atomic.h:175 --- this one is wrong for a
mysterious reason
175 {
(gdb) p $eip
$1 = (void *) 0xc0102ee7
(gdb) disas 0xc0102ee7
Dump of assembler code for function resume_kernelX:
0xc0102ee7 resume_kernelX+0: mov0x30(%esp),%eax
0xc0102eeb resume_kernelX+4: mov0x38(%esp),%ah
0xc0102eef resume_kernelX+8: mov0x2c(%esp),%al
0xc0102ef3 resume_kernelX+12: and$0x20403,%eax
0xc0102ef8 resume_kernelX+17: cmp$0x403,%eax
0xc0102efd resume_kernelX+22: je 0xc0102f0c ldt_ss
End of assembler dump.
(gdb)
And as we see, we're at the mov0x30(%esp),%eax which accesses above the
bottom of the stack. After applying nmi_stack_correct-fix.patch, rc2-mm3
booted just fine, so I IMHO think that we might still be needing this, after
all.
Interesting. It could be an interaction between the kgdb patch and the new
vm86 checking code. (looks. I don't think that's the case).
Stas, could you please take a look at 2.6.12-rc2-mm3's entry.S sometime,
see if you think my theory is correct?
It seems that you have CONFIG_TRAP_BAD_SYSCALL_EXITS enabled - I can't say
that I've ever used that, and I really should remove it. But I doubt if
that is the cause of this bug.
The above code is accessing esp+56, but Stas's patch only offsets the stack
pointer by 32 bytes, so I assume this, in copy_thread():
- p-thread.esp0 = (unsigned long) (childregs+1) - 8;
+ p-thread.esp0 = (unsigned long) (childregs+1) - 15;
fixes 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: [RFC] FUSE permission modell (Was: fuse review bits)
On Mon, Apr 11, 2005 at 09:56:29PM +0200, Miklos Szeredi wrote: Well the sanity check on the server side is always enforced. You can't trick sftp or ftp to not check permissions. So checking on the client side too (where the fuse daemon is running) makes no sense, does it? That argument doesn't make much sense to me. But we're at the end of my useful contributions to this discussion; I'm going to be quiet now and hope some folks who know more about filesystems have more useful responses. -- Daniel Jacobowitz CodeSourcery, LLC - 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 2.4.30-rc3 md/ext3 problems (ext3 gurus : please check)
Hi, On Mon, 2005-04-11 at 21:46, Andrew Morton wrote: Stephen C. Tweedie [EMAIL PROTECTED] wrote: Andrew, what was the exact illegal state of the pages you were seeing when fixing that recent leak? It looks like it's nothing more complex than dirty buffers on an anon page. Correct. Good --- I think I've got the debugging solid against 2.4 for that case, patching against 2.6 now. I think that simply calling try_to_release_page() for all the remaining buffers at umount time will Presumably these pages have no -mapping, so try_to_release_page() will call try_to_free_buffers(). Exactly. The only thing that would be required on top of that would be a check that the page is also on the VM LRU lists. Why do we have dirty buffers left over at umount time? In the leak case we're worried about, the buffers are dirty but the page is anon so there's nothing to clean them up. The buffers _will_ be destroyed by unmount, sure; invalidate_bdev() should see to that. But I'm doing the bh leak check before we get to the final invalidate_bdev(), so they should still be available for testing at that point. --Stephen - 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 Apr 11, 2005 10:46 PM, Martin J. Bligh [EMAIL PROTECTED] wrote: --On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ - The anticipatory I/O scheduler has always been fairly useless with SCSI disks which perform tagged command queueing. There's a patch here from Jens which is designed to fix that up by constraining the number of requests which we'll leave pending in the device. The depth currently defaults to 1. Tunable in /sys/block/hdX/queue/iosched/queue_depth This patch hasn't been performance tested at all yet. If you think it is misbehaving (the usual symptom is processes stuck in D state) then please report it, then boot with `elevator=cfq' or `elevator=deadline' to work around it. - More CPU scheduler work. I hope someone is testing this stuff. Trying ... having some build problems that seem to be part test-harness, part bugs. Meanwhile on PPC64: fs/cifs/misc.c: In function `cifs_convertUCSpath': fs/cifs/misc.c:546: error: case label does not reduce to an integer constant fs/cifs/misc.c:549: error: case label does not reduce to an integer constant fs/cifs/misc.c:552: error: case label does not reduce to an integer constant fs/cifs/misc.c:561: error: case label does not reduce to an integer constant fs/cifs/misc.c:564: error: case label does not reduce to an integer constant fs/cifs/misc.c:567: error: case label does not reduce to an integer constant make[2]: *** [fs/cifs/misc.o] Error 1 make[1]: *** [fs/cifs] Error 2 make[1]: *** Waiting for unfinished jobs See this patch from Steve French: http://cifs.bkbits.net:8080/linux-2.5cifs/[EMAIL PROTECTED] M. - 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/ - 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] Fix help text for ixdp465
For some reason, this help text was missed when the file was last audited by the documentation referencing folk. Fix this incorrect documentation reference. Signed-off-by: Russell King [EMAIL PROTECTED] diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x '*.orig' -x '*.rej' -r orig/arch/arm/mach-ixp4xx/Kconfig linux/arch/arm/mach-ixp4xx/Kconfig --- orig/arch/arm/mach-ixp4xx/Kconfig Sun Feb 6 11:37:44 2005 +++ linux/arch/arm/mach-ixp4xx/Kconfig Tue Feb 1 00:05:28 2005 @@ -41,7 +41,7 @@ config MACH_IXDP465 help Say 'Y' here if you want your kernel to support Intel's IXDP465 Development Platform (Also known as BMP). - For more information on this platform, see Documentation/arm/IXP4xx. + For more information on this platform, see file:Documentation/arm/IXP4xx. # - 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] Priority Lists for the RT mutex
From: Bill Huey (hui) [mailto:[EMAIL PROTECTED] On Mon, Apr 11, 2005 at 10:57:37AM +0200, Ingo Molnar wrote: * Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote: Let me re-phrase then: it is a must have only on PI, to make sure you don't have a loop when doing it. Maybe is a consequence of the algorithm I chose. -However- it should be possible to disable it in cases where you are reasonably sure it won't happen (such as kernel code). In any case, AFAIR, I still did not implement it. are there cases where userspace wants to disable deadlock-detection for its own locks? I'd disable it for userspace locks. There might be folks that want to implement userspace drivers, but I can't imagine it being 'ok' to have the kernel call out to userspace and have it block correctly. I would expect them to do something else that's less drastic. If you are exposing the kernel locks to userspace to implement mutexes (eg POSIX mutexes), deadlock checking is a feature you want to have to complain with POSIX. According to some off the record requirements I've been given, some applications badly need it (I have a hard time believing that they are so broken, but heck...). -- Inaky - 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/
Call to atention about using hash functions as content indexers (SCM saga)
Hi I had a quick look at the source of GIT tonight, I'd like to warn you about the use of hash functions as content indexers. As probably you are aware, hash functions such as SHA-1 are surjective not bijective (1-to-1 map), so they have collisions. Here one can argue about the low probability of such a collision, I won't get into subjetive valorations of what probability of collision is tolerable for me and what is not. I my humble opinion, choosing deliberately, as a design decision, a method such as this one, that in some cases could corrupt data in a silent and very hard to detect way, is not very good. One can also argue that the probability of data getting corrupted in the disk, or whatever could be higher than that of the collision, again this is not valid comparison, since the fact that indexing by hash functions without additional checking could make data corruption legal between the reasonable working parameters of the program is very dangerous. And by the way, I've read http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node15.html and I don't agree with it. Asides from the avalanche effect the properties of a good hash function is that distributes well the entropy between the output bits, so probably, although the inputs are not random, the pdf change in the outputs would be small, otherwise it would be easier to find collision by differential or statistical methods. Last, hash functions should be only used to check data integrity, and that's the reason of the avalanche effect, so even single bit errors are propagated and it's effect is very noticeable at the output. Regards. -- Pedro Larroy Tovar | Linux Network consultant | pedro%larroy.com Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/ * Las patentes de programación son nocivas para la innovación * http://proinnova.hispalinux.es/ - 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, I hope you like it better this way :-)] fix few remaining u32 vs. pm_message_t problems in -mm3
This fixes remaining u32 vs. pm_message_t confusions in
-rc2-mm3. [There are usb changes, too; they went to Greg on his
request.]
Signed-off-by: Pavel Machek [EMAIL PROTECTED]
--- clean-mm/drivers/macintosh/via-pmu.c2005-04-11 22:53:30.0
+0200
+++ linux-mm/drivers/macintosh/via-pmu.c2005-04-11 23:09:13.0
+0200
@@ -2371,7 +2371,7 @@
* use this but still... This will take care of sysdev's as well, so
* we exit from here with local irqs disabled and PIC off.
*/
- ret = device_power_down(PM_SUSPEND_MEM);
+ ret = device_power_down(PMSG_SUSPEND);
if (ret) {
wakeup_decrementer();
local_irq_enable();
-
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/3] Keys: Use RCU to manage session keyring pointer
On Wed, Mar 23, 2005 at 08:55:46PM +, David Howells wrote:
The attached patch uses RCU to manage the session keyring pointer in struct
signal_struct. This means that searching need not disable interrupts and get a
the sighand spinlock to access this pointer. Furthermore, by judicious use of
rcu_read_(un)lock(), this patch also avoids the need to take and put refcounts
on the session keyring itself, thus saving on even more atomic ops.
Signed-Off-By: David Howells [EMAIL PROTECTED]
This looks quite good! A few questions interspersed below.
Thanx, Paul
PS. Sorry to be so slow in getting to this one!
---
warthogdiffstat -p1 keys-rcu-session-2612rc1mm1.diff
security/keys/process_keys.c | 42
+-
security/keys/request_key.c |7 +++
2 files changed, 24 insertions(+), 25 deletions(-)
diff -uNrp linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/process_keys.c
linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/process_keys.c
--- linux-2.6.12-rc1-mm1-keys-umhelper/security/keys/process_keys.c
2005-03-23 17:22:46.0 +
+++ linux-2.6.12-rc1-mm1-keys-rcu-session/security/keys/process_keys.c
2005-03-23 18:27:12.055768099 +
@@ -1,6 +1,6 @@
/* process_keys.c: management of a process's keyrings
*
- * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
+ * Copyright (C) 2004-5 Red Hat, Inc. All Rights Reserved.
* Written by David Howells ([EMAIL PROTECTED])
*
* This program is free software; you can redistribute it and/or
@@ -181,7 +181,7 @@ static int install_process_keyring(struc
goto error;
}
- /* attach or swap keyrings */
+ /* attach keyring */
spin_lock_irqsave(tsk-sighand-siglock, flags);
if (!tsk-signal-process_keyring) {
tsk-signal-process_keyring = keyring;
@@ -227,12 +227,14 @@ static int install_session_keyring(struc
/* install the keyring */
spin_lock_irqsave(tsk-sighand-siglock, flags);
- old = tsk-signal-session_keyring;
- tsk-signal-session_keyring = keyring;
+ old = rcu_dereference(tsk-signal-session_keyring);
I don't understand why rcu_dereference() is needed in this case.
Since we are holding the lock, it should not be possible for
this to change, right? Or am I missing something? (Quite possible,
am not all that familiar with this code.)
+ rcu_assign_pointer(tsk-signal-session_keyring, keyring);
spin_unlock_irqrestore(tsk-sighand-siglock, flags);
ret = 0;
+ /* we're using RCU on the pointer */
+ synchronize_kernel();
This would want to become synchronize_rcu().
key_put(old);
error:
return ret;
@@ -245,8 +247,6 @@ static int install_session_keyring(struc
*/
int copy_thread_group_keys(struct task_struct *tsk)
{
- unsigned long flags;
-
key_check(current-thread_group-session_keyring);
key_check(current-thread_group-process_keyring);
@@ -254,10 +254,10 @@ int copy_thread_group_keys(struct task_s
tsk-signal-process_keyring = NULL;
/* same session keyring */
- spin_lock_irqsave(current-sighand-siglock, flags);
+ rcu_read_lock();
tsk-signal-session_keyring =
- key_get(current-signal-session_keyring);
- spin_unlock_irqrestore(current-sighand-siglock, flags);
+ key_get(rcu_dereference(current-signal-session_keyring));
+ rcu_read_unlock();
return 0;
@@ -381,8 +381,7 @@ struct key *search_process_keyrings_aux(
key_match_func_t match)
{
struct task_struct *tsk = current;
- unsigned long flags;
- struct key *key, *ret, *err, *tmp;
+ struct key *key, *ret, *err;
/* we want to return -EAGAIN or -ENOKEY if any of the keyrings were
* searchable, but we failed to find a key or we found a negative key;
@@ -436,17 +435,18 @@ struct key *search_process_keyrings_aux(
}
/* search the session keyring last */
- spin_lock_irqsave(tsk-sighand-siglock, flags);
-
- tmp = tsk-signal-session_keyring;
- if (!tmp)
- tmp = tsk-user-session_keyring;
- atomic_inc(tmp-usage);
-
- spin_unlock_irqrestore(tsk-sighand-siglock, flags);
+ if (tsk-signal-session_keyring) {
+ rcu_read_lock();
+ key = keyring_search_aux(
+ rcu_dereference(tsk-signal-session_keyring),
+ type, description, match);
+ rcu_read_unlock();
+ }
+ else {
+ key = keyring_search_aux(tsk-user-session_keyring,
+ type, description, match);
This one is constant, right? If not, I don't understand the locking design.
+ }
- key = keyring_search_aux(tmp, type, description, match);
-
Re: New SCM and commit list
On Sun, 10 Apr 2005, Linus Torvalds wrote: On Mon, 11 Apr 2005, Jeff Garzik wrote: But I hope that I can get non-conflicting merges done fairly soon, and maybe I can con James or Jeff or somebody to try out GIT then... I don't mind being a guinea pig as long as someone else does the hard work of finding a new way to merge :) So I can tell you what merges are going to be like, just to prepare you. First, the good news: I think we can make the workflow look like bk, ie pretty much like git pull and git push. And for well-behaved stuff (ie minimal changes to the same files on both sides) it will even be fast. I think. Then the bad news: the merge algorithm is going to suck. It's going to be just plain 3-way merge, the same RCS/CVS thing you've seen before. With no understanding of renames etc. I'll try to find the best parent to base the merge off of, although early testers may have to tell the piece of crud what the most recent common parent was. So anything that got modified in just one tree obviously merges to that version. Any file that got modified in two trees will end up just being passed to the merge program. See man merge and man diff3. The merger gets to fix up any conflicts by hand. If merge took trees instead of single files, and had some way of detecting renames (or it got additional information about the differences between files), would that give BK-quality performance? Or does BK also support cases like: orig --- first --- first-merge - |/ \ |-- second - - final |\ / |-- third --- third-merge - where the final merge requires, for complete cleanliness, a comparison of more than 3 states (since some changes will have orig as the common ancestor and some will have second). Does this happen in real life? It seems like sane development processes wouldn't have multiple mainline-candidate patch sets including the same patches, if for no other reason than that, should the merge fail, nobody with any clue about the original patches would be anywhere nearby. It seems better to throw something back to someone to rebase their diffs. Otherwise, the problem seems to boil down to finding the common ancestor well, getting trees instead of files to merge, and improving merge until it handles all of the tractible cases. -Daniel *This .sig left intentionally blank* - 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: Call to atention about using hash functions as content indexers (SCM saga)
Dear diary, on Tue, Apr 12, 2005 at 12:40:21AM CEST, I got a letter where Pedro Larroy [EMAIL PROTECTED] told me that... Hi Hello, I had a quick look at the source of GIT tonight, I'd like to warn you about the use of hash functions as content indexers. As probably you are aware, hash functions such as SHA-1 are surjective not bijective (1-to-1 map), so they have collisions. Here one can argue about the low probability of such a collision, I won't get into subjetive valorations of what probability of collision is tolerable for me and what is not. I my humble opinion, choosing deliberately, as a design decision, a method such as this one, that in some cases could corrupt data in a silent and very hard to detect way, is not very good. One can also argue that the probability of data getting corrupted in the disk, or whatever could be higher than that of the collision, again this is not valid comparison, since the fact that indexing by hash functions without additional checking could make data corruption legal between the reasonable working parameters of the program is very dangerous. (i) 1461501637330902918203684832716283019655932542976 possible SHA1 hashes. (ii) In git-pasky, there's (turnable off) detection of collisions. (iii) Your argument against comparing with the probability of a hardware error does not make sense to me. (iv) You fail to propose a better solution. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Processes stuck on D state on Dual Opteron
Claudio Martins wrote: Right. I'm using two Seagate ATA133 disks (ide controler is AMD-8111) each with 4 partitions, so I get 4 md Raid1 devices. The first one, md0, is for swap. The rest are ~$ df -h FilesystemSize Used Avail Use% Mounted on /dev/md1 4.6G 1.9G 2.6G 42% / tmpfs1005M 0 1005M 0% /dev/shm /dev/md3 32G 107M 30G 1% /home /dev/md2 31G 149M 29G 1% /var In these tests, /home on md3 is the working area for stress. The io scheduler used is the anticipatory. OK. OK, I'll try them in a few minutes and report back. I'm not overly hopeful. If they fix the problem, then it's likely that the real bug is hidden. I'm curious as whether increasing the vm.min_free_kbytes sysctl value would help or not in this case. But I guess it wouldn't since there is already some free memory and also the alloc failures are order 0, right? Yes. And the failures you were seeing with my first patch were coming from the mempool code anyway. We want those to fail early so they don't eat into the min_free_kbytes memory. You could try raising min_free_kbytes though. If that fixes it, then it indicates there might be some problem in a memory allocation failure path in software raid somewhere. Thanks -- 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/
[PATCH 2/3] mm/Kconfig: hide Memory Model selection menu
I got some feedback from users who think that the new Memory Model menu is a little invasive. This patch will hide that menu, except when CONFIG_EXPERIMENTAL is enabled *or* when an individual architecture wants it. An individual arch may want to enable it because they've removed their arch-specific DISCONTIG prompt in favor of the mm/Kconfig one. Signed-off-by: Dave Hansen [EMAIL PROTECTED] --- arch/i386/Kconfig |0 memhotplug-dave/mm/Kconfig | 21 + 2 files changed, 17 insertions(+), 4 deletions(-) diff -puN mm/Kconfig~A1-mm-Kconfig-hide-selection-menu mm/Kconfig --- memhotplug/mm/Kconfig~A1-mm-Kconfig-hide-selection-menu 2005-04-11 15:49:10.0 -0700 +++ memhotplug-dave/mm/Kconfig 2005-04-11 15:49:10.0 -0700 @@ -1,9 +1,14 @@ +config SELECT_MEMORY_MODEL + def_bool y + depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL + choice prompt Memory model - default DISCONTIGMEM if ARCH_DISCONTIGMEM_DEFAULT - default FLATMEM + depends on SELECT_MEMORY_MODEL + default DISCONTIGMEM_MANUAL if ARCH_DISCONTIGMEM_DEFAULT + default FLATMEM_MANUAL -config FLATMEM +config FLATMEM_MANUAL bool Flat Memory depends on !ARCH_DISCONTIGMEM_ENABLE || ARCH_FLATMEM_ENABLE help @@ -14,7 +19,7 @@ config FLATMEM If unsure, choose this option over any other. -config DISCONTIGMEM +config DISCONTIGMEM_MANUAL bool Discontigious Memory depends on ARCH_DISCONTIGMEM_ENABLE help @@ -22,6 +27,14 @@ config DISCONTIGMEM endchoice +config DISCONTIGMEM + def_bool y + depends on (!SELECT_MEMORY_MODEL ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL + +config FLATMEM + def_bool y + depends on !DISCONTIGMEM || FLATMEM_MANUAL + # # Both the NUMA code and DISCONTIGMEM use arrays of pg_data_t's # to represent different areas of memory. This variable allows diff -puN arch/i386/Kconfig~A1-mm-Kconfig-hide-selection-menu arch/i386/Kconfig _ - 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 1/3] mm/Kconfig: kill unused ARCH_FLATMEM_DISABLE
This used to be used to disable FLATMEM selection, but I decided to change it to be done generically when DISCONTIG is enabled. The option is unused, so this kills it. Signed-off-by: Dave Hansen [EMAIL PROTECTED] --- memhotplug-dave/./arch/mips/Kconfig |4 memhotplug-dave/./arch/parisc/Kconfig |4 memhotplug-dave/./arch/sh/Kconfig |4 3 files changed, 12 deletions(-) diff -puN ./arch/parisc/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE ./arch/parisc/Kconfig --- memhotplug/./arch/parisc/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE 2005-04-11 15:49:09.0 -0700 +++ memhotplug-dave/./arch/parisc/Kconfig 2005-04-11 15:49:09.0 -0700 @@ -153,10 +153,6 @@ config ARCH_DISCONTIGMEM_ENABLE or have huge holes in the physical address space for other reasons. See file:Documentation/vm/numa for more. -config ARCH_FLATMEM_DISABLE - def_bool y - depends on ARCH_DISCONTIGMEM_ENABLE - source mm/Kconfig config PREEMPT diff -puN ./arch/sh/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE ./arch/sh/Kconfig --- memhotplug/./arch/sh/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE 2005-04-11 15:49:09.0 -0700 +++ memhotplug-dave/./arch/sh/Kconfig 2005-04-11 15:49:09.0 -0700 @@ -496,10 +496,6 @@ config ARCH_DISCONTIGMEM_ENABLE or have huge holes in the physical address space for other reasons. See file:Documentation/vm/numa for more. -config ARCH_FLATMEM_DISABLE - def_bool y - depends on ARCH_DISCONTIGMEM_ENABLE - source mm/Kconfig config ZERO_PAGE_OFFSET diff -puN ./arch/mips/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE ./arch/mips/Kconfig --- memhotplug/./arch/mips/Kconfig~A0-mm-Kconfig-kill-ARCH_FLATMEM_DISABLE 2005-04-11 15:49:09.0 -0700 +++ memhotplug-dave/./arch/mips/Kconfig 2005-04-11 15:49:09.0 -0700 @@ -501,10 +501,6 @@ config ARCH_DISCONTIGMEM_ENABLE or have huge holes in the physical address space for other reasons. See file:Documentation/vm/numa for more. -config ARCH_FLATMEM_DISABLE - def_bool y - depends on ARCH_DISCONTIGMEM_ENABLE - config NUMA bool NUMA Support depends on SGI_IP27 _ - 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 3/3] mm/Kconfig: give DISCONTIG more help text
This gives DISCONTIGMEM a bit more help text to explain what it does, not just when to choose it. Signed-off-by: Dave Hansen [EMAIL PROTECTED] --- memhotplug-dave/mm/Kconfig | 10 ++ 1 files changed, 10 insertions(+) diff -puN mm/Kconfig~A2-mm-Kconfig-DISCONTIG-help-text mm/Kconfig --- memhotplug/mm/Kconfig~A2-mm-Kconfig-DISCONTIG-help-text 2005-04-11 15:49:10.0 -0700 +++ memhotplug-dave/mm/Kconfig 2005-04-11 15:49:10.0 -0700 @@ -23,6 +23,16 @@ config DISCONTIGMEM_MANUAL bool Discontigious Memory depends on ARCH_DISCONTIGMEM_ENABLE help + This option provides enhanced support for discontiguous + memory systems, over FLATMEM. These systems have holes + in their physical address spaces, and this option provides + more efficient handling of these holes. However, the vast + majority of hardware has quite flat address spaces, and + can have degraded performance from extra overhead that + this option imposes. + + Many NUMA configurations will have this as the only option. + If unsure, choose Flat Memory over this option. endchoice _ - 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] Priority Lists for the RT mutex
On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote: If you are exposing the kernel locks to userspace to implement mutexes (eg POSIX mutexes), deadlock checking is a feature you want to have to complain with POSIX. According to some off the record requirements I've been given, some applications badly need it (I have a hard time believing that they are so broken, but heck...). I'd like to read about those requirements, but, IMO a lot of the value of various priority protocols varies greatly on the context and size (N threads) of the application using it. If user/kernel space have to be coupled via some thread of execution, (IMO) then it's better to seperate them with some event notification queues like signals (wake a thread via an queue event) than to mix locks across the user/kernel space boundary. There's tons of abuse that can be opened up with various priority protocols with regard to RT apps and giving it a first class entry way without consideration is kind of scary. It's important to outline the requirements of the applications and then see what you can do using minimal synchronization objects before exploding that divide. Also, Posix isn't always politically neutral nor complete regarding various things. You have to consider the context of these things. I'll have to think about this a bit more and review your patch more carefully. I'm all ears if you think I'm wrong. bill - 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
Hi!
No, XFS is my root filesystem. :( (Now that I think about it, would
modularizing XFS and using an initrd be OK?)
Yes, loading xfs from initrd should help. [At least it did during
suse9.3 testing.]
Once I modularized xfs and switched to using an initrd, the problem
disappeared.
I reproduced it locally. Problem is that xfsbufd goes refrigerated,
but someone still tries to wake it up *very* often. Probably something
else in xfs needs refrigerating, too, but I'm not a XFS wizard...
Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)
There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).
Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help? (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (current-flags PF_FREEZE)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
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: Call to atention about using hash functions as content indexers (SCM saga)
On 4/12/05, Petr Baudis [EMAIL PROTECTED] wrote: (iv) You fail to propose a better solution. I would feel safer with back end storage filenames based on email and mtime together with an optional hash lookup that turns collisions into worse performance. But that's just me. / magnus - 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] Priority Lists for the RT mutex
From: Bill Huey (hui) [mailto:[EMAIL PROTECTED] On Mon, Apr 11, 2005 at 03:31:41PM -0700, Perez-Gonzalez, Inaky wrote: If you are exposing the kernel locks to userspace to implement mutexes (eg POSIX mutexes), deadlock checking is a feature you want to have to complain with POSIX. According to some off the record requirements I've been given, some applications badly need it (I have a hard time believing that they are so broken, but heck...). I'd like to read about those requirements, but, IMO a lot of the value More than a formal requirement is a practical one. Some company (leader in their field, of course) has this huge blobl of code they want to use in Linux and it has the typical API than once upon a time was made multithreaded by just adding a bunch of pthread_mutex_[un]lock() at the API entry point... without realizing that some of the top level API calls also called other top level API calls, so they'd deadlock. Quick fix: the usual. Enable deadlock detection and if it returns deadlock, assume it is locked already and proceed (or do a recursive mutex, or a trylock). And so on, and so forth... of various priority protocols varies greatly on the context and size (N threads) of the application using it. If user/kernel space have to be coupled via some thread of execution, (IMO) then it's better to seperate them with some event notification queues like signals (wake a thread via an queue event) than to mix locks across the user/kernel space ... I wonder if we are confusing apples and oranges here--I don't think we were considering cases about mixing kernel locks that are accessible both from kernel and user space. The focus is to have a kernel lock entity and that user space can use it for implementing the user space mutexes, but *not* mix them (like in user and kernel space sharing this lock for doing whatever). It is certainly something to explore, but I'd better drive your way than do it. It's cleaner. Hides implementation details. It's important to outline the requirements of the applications and then see what you can do using minimal synchronization objects before exploding that divide. I agree, but it doesn't work that well when talking about legacy systems...that's the problem. Also, Posix isn't always politically neutral nor complete regarding various things. You have to consider the context of these things. I'll have to think about this a bit more and review your patch more carefully. Sure--and because most was for legacy reasons that adhered to POSIX strictly, it was very simple: we need POSIX this, that and that (PI, proper adherence to scheduler policy wake up/rt-behaviour, deadlock detection, etc). Fortunately in those areas POSIX is not too gray; code to the book. Deal. Of course, selling it to the lkml is another story. -- Inaky - 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] LifeView FlyTV Platinum FM: Remote Control support
Greetings!
Subject says it ... this card's IR microcontroller design and attachment
are compatible to the company's previous designs, so the patch was as simple as
it gets.
Note that this patch goes on top of the other one I posted yesterday, thank you
very much.
regards,
Peter
--- linux-2.6.12-rc2/drivers/media/video/saa7134/saa7134-cards.c
2005-04-09 12:01:47.0 +0200
+++ video4linux/saa7134-cards.c 2005-04-12 00:58:57.0 +0200
@@ -1948,6 +1948,7 @@
dev-has_remote = 1;
board_flyvideo(dev);
break;
+ case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_CINERGY400:
case SAA7134_BOARD_CINERGY600:
case SAA7134_BOARD_CINERGY600_MK3:
--- linux-2.6.12-rc2/drivers/media/video/saa7134/saa7134-input.c 2005-04-09
12:01:47.0 +0200
+++ video4linux/saa7134-input.c 2005-04-12 01:15:11.0 +0200
@@ -379,6 +379,7 @@
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
+ case SAA7134_BOARD_FLYTVPLATINUM_FM:
ir_codes = flyvideo_codes;
mask_keycode = 0xEC0;
mask_keydown = 0x004;
-
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/
[Bug?] Keyboard Problem
I'm currently using a 2.6.10 kernel (on a Debian Sarge, i386). I've compiled a 2.6.11.5 and a 2.6.11.7 kernels and my keyboard (a sweex SILVER MULTIMEDIA KEYBOARD, SW-23 -- PS/2 105 keys -- a classical keyboard) doesn't work with these kernels. I asked for help and one said me it is probably a bug in the kernel since a normal keyboard must always work with the kernel. I can give more informations if you need, say me. Please send a copy of your replies, I'm not a subscriber for this list. P.S.: English is not my native language, I'm doing the best I can. :) Bye. -- Manuel Dahmen 181 Avenue des Coteaux 4030 Grivegnée 04/367 46 48 MSN: [EMAIL PROTECTED] http://stagiaires.ressource-toi.org/~rst237/ config-2.6.11.7 Description: Binary data
Re: Processes stuck on D state on Dual Opteron
On Monday April 11, [EMAIL PROTECTED] wrote:
Neil, have you had a look at the traces? Do they mean much to you?
Just looked.
bio_alloc_bioset seems implicated, as does sync_page_io.
sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe
change it to use bio_alloc (don't know why..) and I should have
checked the change better.
sync_page_io can be called on the write out path, so it should use
GFP_NOIO rather than GFP_KERNEL.
See if this helps Actually this patch is against 2.6.12-rc2-mm1
which uses md_super_write instead of sync_page_io (which is now only
used for read). So if you are using a non-mm kernel (which seems to
be the case) you'll need to apply the patch by hand.
Thanks,
NeilBrown
---
Avoid deadlock in sync_page_io by using GFP_NOIO
..as sync_page_io can be called on the write-out path.
Ditto for md_super_write
Signed-off-by: Neil Brown [EMAIL PROTECTED]
### Diffstat output
./drivers/md/md.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~ 2005-04-08 11:25:26.0 +1000
+++ ./drivers/md/md.c 2005-04-12 09:42:29.0 +1000
@@ -351,7 +351,7 @@ void md_super_write(mddev_t *mddev, mdk_
* if zero is reached.
* If an error occurred, call md_error
*/
- struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+ struct bio *bio = bio_alloc(GFP_NOIO, 1);
bio-bi_bdev = rdev-bdev;
bio-bi_sector = sector;
@@ -374,7 +374,7 @@ static int bi_complete(struct bio *bio,
int sync_page_io(struct block_device *bdev, sector_t sector, int size,
struct page *page, int rw)
{
- struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+ struct bio *bio = bio_alloc(GFP_NOIO, 1);
struct completion event;
int ret;
-
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: [discuss] [21/31] x86_64: Always use CPUID 80000008 to figure out MTRR address space size
On Mon, Apr 11, 2005 at 08:00:01PM +0200, Andi Kleen wrote: On Sun, Apr 10, 2005 at 11:25:23PM -0700, Siddha, Suresh B wrote: We need to use the size_and_mask in set_mtrr_var_ranges(which is called while programming MTRR's for AP's Patch is ok for me. But how did you find this out? Did you force a mapping high in the address space? No. It was through code inspection. thanks, suresh - 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Thanks Pavel - I've been reading the thread from the other side of the fence, not understanding the swsusp side of things. :) There are two ways the xfsbufd thread will wake up - either by its timer going off (for it to flush delayed write metadata buffers) or by being explicitly woken up when we're low on memory (in which case it also flushes out dirty metadata, such that pages can be cleaned and made available to the system). Since the refrigerator() call is in place in the main xfsbufd loop, I suspect we're hitting that second case here, where a low memory situation is resulting in someone attempting to wakeup xfsbufd -- I'm not sure if this is the right way to check if we're in that state, but does this patch help? (it would certainly prevent the spurious wakeups, but only if the caller has PF_FREEZE set - will that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Pavel -- Boycott Kodak -- for their patent abuse against Java. - 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 4/5] sched: RCU sched domains
Paul E. McKenney wrote: On Thu, Apr 07, 2005 at 05:58:40PM +1000, Nick Piggin wrote: OK thanks for the good explanation. So I'll keep it as is for now, and whatever needs cleaning up later can be worked out as it comes up. Looking forward to the split of synchronize_kernel() into synchronize_rcu() and synchronize_sched(), the two choices are: o Use synchronize_rcu(), but insert rcu_read_lock()/rcu_read_unlock() pairs on the read side. o Use synchronize_sched(), and make sure all read-side code is under preempt_disable(). Yep, I think we'll go for the second option initially (because that pretty closely matches the homebrew locking scheme that it used to use). Either way, there may also need to be some rcu_dereference()s when picking up pointer and rcu_assign_pointer()s when updating the pointers. For example, if traversing the domain parent list is to be RCU protected, the for_each_domain() macro should change to something like: Yes, I think you're right, because there's no barriers or synchronisation when attaching a new domain. Just a small point though: #define for_each_domain(cpu, domain) \ for (domain = cpu_rq(cpu)-sd; domain; domain = rcu_dereference(domain-parent)) This should probably be done like so? #define for_each_domain(cpu, domain) \ for (domain = rcu_dereference(cpu_rq(cpu)-sd); domain; domain = domain-parent) And I think it would be wise to use rcu_assign_pointer in the update too. Thanks Paul. -- 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/
[PATCH] scripts/patch-kernel: EXTRAVERSION patches are not incremental
On Tue, 15 Mar 2005 16:15:54 + David Greaves wrote:
| Old thread (!) but this is the last time I could find patch-kernel updated.
I found a little time to update patch-kernel if anyone wants
to use it. OTOH, using Matt Mackall's ketchup is OK too.
I also use 'kcurrent' to keep up with the latest kernel vesions
available -- as noted on www.kernel.org. It's also attached
and both scripts are available at
http://developer.osdl.org/rddunlap/scripts/
---
patch-kernel: support non-incremental 2.6.x.y 'stable' patches
# Add better support for (non-incremental) 2.6.x.y patches;
# If an ending version number if not specified, the script automatically
# increments the SUBLEVEL (x in 2.6.x.y) until no more patch files are found;
# however, EXTRAVERSION (y in 2.6.x.y) is never automatically incremented
# but must be specified fully.
#
# patch-kernel does not normally support reverse patching, but does so when
# applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to 2.6.11.z
# is easy and handled by the script (reverse 2.6.11.y and apply 2.6.11.z).
patch-kernel | 131 +--
1 files changed, 101 insertions(+), 30 deletions(-)
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
--- patch-kernel-0042004-08-18 12:12:19.0 -0700
+++ patch-kernel2005-04-11 17:02:38.0 -0700
@@ -46,6 +46,19 @@
# fix some whitespace damage;
# be smarter about stopping when current version is larger than requested;
# Randy Dunlap [EMAIL PROTECTED], 2004-AUG-18.
+#
+# Add better support for (non-incremental) 2.6.x.y patches;
+# If an ending version number if not specified, the script automatically
+# increments the SUBLEVEL (x in 2.6.x.y) until no more patch files are found;
+# however, EXTRAVERSION (y in 2.6.x.y) is never automatically incremented
+# but must be specified fully.
+#
+# patch-kernel does not normally support reverse patching, but does so when
+# applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to 2.6.11.z
+# is easy and handled by the script (reverse 2.6.11.y and apply 2.6.11.z).
+# Randy Dunlap [EMAIL PROTECTED], 2005-APR-08.
+
+PNAME=patch-kernel
# Set directories from arguments, or use defaults.
sourcedir=${1-/usr/src/linux}
@@ -54,7 +67,7 @@ stopvers=${3-default}
if [ $1 == -h -o $1 == --help -o ! -r $sourcedir/Makefile ]; then
cat USAGE
-usage: patch-kernel [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
+usage: $PNAME [-h] [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
source directory defaults to /usr/src/linux,
patch directory defaults to the current directory,
stopversion defaults to all in patchdir.
@@ -73,6 +86,19 @@ do
done
# ---
+# arg1 is filename
+noFile () {
+ echo cannot find patch file: ${patch}
+ exit 1
+}
+
+# ---
+backwards () {
+ echo $PNAME does not support reverse patching
+ exit 1
+}
+
+# ---
# Find a file, first parameter is basename of file
# it tries many compression mechanisms and sets variables to say how to get it
findFile () {
@@ -133,6 +159,28 @@ applyPatch () {
return 0;
}
+# ---
+# arg1 is patch filename
+reversePatch () {
+ echo -n Reversing $1 (${name}) ...
+ if $uncomp ${patchdir}/$1${ext} | patch -p1 -Rs -N -E -d $sourcedir
+ then
+ echo done.
+ else
+ echo failed. Clean it up.
+ exit 1
+ fi
+ if [ `find $sourcedir/ '(' -name '*.rej' -o -name '.*.rej' ')'
-print` ]
+ then
+ echo Aborting. Reject files found.
+ return 1
+ fi
+ # Remove backup files
+ find $sourcedir/ '(' -name '*.orig' -o -name '.*.orig' ')' -exec rm -f
{} \;
+
+ return 0
+}
+
# set current VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION
TMPFILE=`mktemp .tmpver.XX` || { echo cannot make temp file ; exit 1; }
grep -E ^(VERSION|PATCHLEVEL|SUBLEVEL|EXTRAVERSION) $sourcedir/Makefile
$TMPFILE
@@ -160,53 +208,57 @@ then
EXTRAVER=$EXTRAVERSION
fi
EXTRAVER=${EXTRAVER%%[[:punct:]]*}
- #echo patch-kernel: changing EXTRAVERSION from $EXTRAVERSION to
$EXTRAVER
+ #echo $PNAME: changing EXTRAVERSION from $EXTRAVERSION to $EXTRAVER
fi
#echo stopvers=$stopvers
if [ $stopvers != default ]; then
STOPSUBLEVEL=`echo $stopvers | cut -d. -f3`
STOPEXTRA=`echo $stopvers | cut -d. -f4`
- #echo STOPSUBLEVEL=$STOPSUBLEVEL, STOPEXTRA=$STOPEXTRA
+ #echo #___STOPSUBLEVEL=/$STOPSUBLEVEL/, STOPEXTRA=/$STOPEXTRA/
else
STOPSUBLEVEL=
STOPEXTRA=
fi
-while :# incrementing SUBLEVEL (s in v.p.s)
Re: 2.6.12-rc2-mm3
Jindrich Makovicka [EMAIL PROTECTED] wrote: Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ MPlayer randomly crashes in various pthread_* calls when using binary codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse fix-crash-in-entrys-restore_all.patch, but it didn't help. hm, could be anything. Does 2.6.12-rc2 also fail? - 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] Priority Lists for the RT mutex
On Mon, Apr 11, 2005 at 04:28:25PM -0700, Perez-Gonzalez, Inaky wrote: From: Bill Huey (hui) [mailto:[EMAIL PROTECTED] ... API than once upon a time was made multithreaded by just adding a bunch of pthread_mutex_[un]lock() at the API entry point... without realizing that some of the top level API calls also called other top level API calls, so they'd deadlock. Oh crap. Quick fix: the usual. Enable deadlock detection and if it returns deadlock, assume it is locked already and proceed (or do a recursive mutex, or a trylock). You have to be joking me ? geez. ... It is certainly something to explore, but I'd better drive your way than do it. It's cleaner. Hides implementation details. I agree, but it doesn't work that well when talking about legacy systems...that's the problem. Yeah, ok, I understand what's going on now. There isn't a notion of projecting priority across into the Unix/Linux kernel traditionally which is why it seemed so bizarre. Sure--and because most was for legacy reasons that adhered to POSIX strictly, it was very simple: we need POSIX this, that and that (PI, proper adherence to scheduler policy wake up/rt-behaviour, deadlock detection, etc). Some of this stuff sounds like recursive locking. Would this be a better expression to solve the top level API locking problem you're referring to ? Fortunately in those areas POSIX is not too gray; code to the book. Deal. I would think that there will have to be a graph discontinuity between user/kernel spaces at kernel entry and exit for the deadlock detector. Can't say about issues at fork time, but I would expect that those objects would have to be destroyed when the process exits. The current RT (Ingo's) lock isn't recursive nor is the deadlock detector the last time I looked. Do think that this is a problem for legacy apps if it gets overload for being the userspace futex as well ? (assuming I'm understanding all of this correctly) Of course, selling it to the lkml is another story. I would think that pushing as much of this into userspace would make the kernel hooks for it more acceptable. Don't know. /me thinks more bill - 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: Processes stuck on D state on Dual Opteron
On Monday 11 April 2005 23:59, Nick Piggin wrote: OK, I'll try them in a few minutes and report back. I'm not overly hopeful. If they fix the problem, then it's likely that the real bug is hidden. Well, the thing is, they do fix the problem. Or at least they hide it very well ;-) It has been running for more than 5 hours now with stress with no problems and no stuck processes. I think I'm going to give a try to Neil's patch, but I'll have to apply some patches from -mm. Thanks Claudio - 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: Processes stuck on D state on Dual Opteron
On Tuesday 12 April 2005 00:46, Neil Brown wrote: On Monday April 11, [EMAIL PROTECTED] wrote: Neil, have you had a look at the traces? Do they mean much to you? Just looked. bio_alloc_bioset seems implicated, as does sync_page_io. sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe change it to use bio_alloc (don't know why..) and I should have checked the change better. sync_page_io can be called on the write out path, so it should use GFP_NOIO rather than GFP_KERNEL. See if this helps Actually this patch is against 2.6.12-rc2-mm1 which uses md_super_write instead of sync_page_io (which is now only used for read). So if you are using a non-mm kernel (which seems to be the case) you'll need to apply the patch by hand. Hi Neil, I'll test this patch, but I'm wondering if I have to apply all the md-related patches from broken out directory of 2.6.12-rc2-mm1 or only some specific ones? Anyway I'm happy to test all those md updates, if you think they might help. Thanks Claudio - 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
Roland Dreier [EMAIL PROTECTED] wrote: Troy Do we even need the mlock in userspace then? Yes, because the kernel may go through and unmap pages from userspace while trying to swap. Since we have the page locked in the kernel, the physical page won't go anywhere, but userspace might end up with a different page mapped at the same virtual address. That shouldn't happen. If get_user_pages() has elevated the refcount on a page then the following can happen: - The VM may decide to add the page to swapcache (if it's not mmapped from a file). - Once the page is backed by either swapcache of a (mmapped) file, the VM may decide the unmap the application's pte's. A later minor fault by the app will cause the same physical page to be remapped. - The VM may decide to try to write the page to its backing file or swap. If it does, the page is still in core, but is now clean. - Once all pte's are unmapped and the page is clean, the VM may decide to try to reclaim the page. The VM will then see the elevated refcount and will bale out, leaving the page in core. - If your code was doing a read-from-disk (modifying memory), then your code should run set_page_dirty() or set_page_dirty_lock() against the page before dropping the refcount which get_user_pages() added. Once the page is dirty, the VM can't reclaim it until it has been been written to swap or mmapped backing file. IOW: while the page has an elevated refcount from get_user_pages(), that physical page is 100% pinned. Once you've done the set_page_dirty+put_page(), the page is again under control of the VM. There should be no need to run mlock() from userspace. - 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
Roland Yes, because the kernel may go through and unmap pages Roland from userspace while trying to swap. Since we have the Roland page locked in the kernel, the physical page won't go Roland anywhere, but userspace might end up with a different page Roland mapped at the same virtual address. Andrew That shouldn't happen. If get_user_pages() has elevated Andrew the refcount on a page then the following can happen: ... Andrew IOW: while the page has an elevated refcount from Andrew get_user_pages(), that physical page is 100% pinned. Andrew Once you've done the set_page_dirty+put_page(), the page Andrew is again under control of the VM. Hmm... I've never tested it first hand but Libor assures me there is a something like what I said. Libor, did I get the explanation right? - R. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
I should take some sleep now, so I can't test the patch, but I don't
think it will help. If someone has PF_FREEZE set, he should be in
refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track when its entering the refrigerator(), so that
other callers know that attempts to wake it are futile.
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 10:14:27.468202824 +1000
@@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon
STATIC struct task_struct *pagebuf_daemon_task;
STATIC int pagebuf_daemon_active;
STATIC int force_flush;
-
+STATIC int force_sleep;
STATIC int
pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (force_sleep)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
@@ -1778,7 +1780,12 @@ pagebuf_daemon(
INIT_LIST_HEAD(tmp);
do {
- try_to_freeze(PF_FREEZE);
+ if (unlikely(current-flags PF_FREEZE)) {
+ force_sleep = 1;
+ refrigerator(PF_FREEZE);
+ } else {
+ force_sleep = 0;
+ }
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100);
-
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] Priority Lists for the RT mutex
From: Bill Huey (hui) [mailto:[EMAIL PROTECTED] Quick fix: the usual. Enable deadlock detection and if it returns deadlock, assume it is locked already and proceed (or do a recursive mutex, or a trylock). You have to be joking me ? geez. ... This is way *more* common than you think--I've seen it around some big multithreaded OSS packages [can't remember which now]. Sure--and because most was for legacy reasons that adhered to POSIX strictly, it was very simple: we need POSIX this, that and that (PI, proper adherence to scheduler policy wake up/rt-behaviour, deadlock detection, etc). Some of this stuff sounds like recursive locking. Would this be a better expression to solve the top level API locking problem you're referring to ? Bingo. That's another way to fix it. Luckily, recursive locking can be safely and quickly done in user space (I own this lock, ergo I just inc the lock count). The problem with deadlocks is when the scenario gets more complex and you are trying to lock a mutex and the owner is waiting for a mutex whose owner is waiting for a mutex that you own...this more commonly happens when you don't know what the heck is going on in the code, which unfortunately is very common on people that inherits big pieces of stacks to maintain. Fortunately in those areas POSIX is not too gray; code to the book. Deal. I would think that there will have to be a graph discontinuity between user/kernel spaces at kernel entry and exit for the deadlock detector. Can't say about issues at fork time, but I would expect that those objects would have to be destroyed when the process exits. fork time is not an issue, as POSIX makes forks and thread incompatible (in a nutshell, only the thread calling fork() survives, all the mutexes are [IIRC] reinitialized or something like that...). The current RT (Ingo's) lock isn't recursive nor is the deadlock detector the last time I looked. Do think that this is a problem for legacy apps if it gets overload for being the userspace futex as well ? (assuming I'm understanding all of this correctly) Should be not on the recursive side; as I said, that is easy to do [currently NPTL does it with the futexes]. The deadlock stuff gets hairier, but it's not such a big of a deal when you have your data structures setup. It takes time, though. Of course, selling it to the lkml is another story. I would think that pushing as much of this into userspace would make the kernel hooks for it more acceptable. Don't know. Agreed. Deadlock checking though, has to be done in the kernel. For the generic case it is the only way to do it sanely. -- Inaky - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005, Sven Luther wrote: On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote: In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. Well, i am not sure with your interpretation, but even if you where right, we have no guarantee that A will continue being lenient, and no guarantee that A will not start suing D or whoever for illegally distributing his stuff without sources. Let's keep things separated. I'm saying that the only one that may sue D is A, not C. If we agree on this, we may abandon the case of a third party sueing D. As for threats coming from A, IMHO D is safe as long as he distributes what A claims the source is, even if it's a hex string. In no world A can publicly state this is the source and then sue D because no, that's not the source (assuming D is copying it verbatim). So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A So, i get some random bit of GPLed software, i add a module or some code to it, i distribute that code in binary format only, and claim that i have used an hex editor to write it, or simply that it is the 'right' source. I have some serious doubts that i will not get sued by all the authors of the original GPLed work if i were to do that, and rightly so. No. Please don't throw irrelevant matters in. D is not modifing the software at all. D is a mere distributor. We're not addressing issues related to modification, since no one is going to modify the firmware anyway. This is not a general discussion on GPL. Issues related to modification do not belong to this thread, which already very close to off topic on l-k. Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Even in that case, you still need explicit permission of A, and all the other copyright holders of the rest of the GPLed work, to give you an explicit exception to link with this non-free bit of code. Yes, but it does not apply to our case here. There's no all other copyright holders. _You_ stated that the firmware is included by mere aggregation, so there's no other holders involved. We're talking about the firmware case. A is one or two well identified subjects. And A wrote it is GPL'ed. Whether you agree or not, that's the licence A chose. A placed the copyright notice. The licence is a matter between A and D. A may sue D and D may (less likely) sue A, if conditions are not met. I'm not sure at all GPL is enforceable by D upon A. Let's assume it is, for sake of discussion, anyway. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. No. The source code is clearly the prefered form of modification, not some random intermediate state A may be claiming is source. In this context, it is. Only A may sue D for not distributing the source. Whatever D distributes, D has to make A happy. If A is happy with D distributing `dd if=/dev/random count=1` as source, no one can stop D from doing that. Keep in mind A is the copyright holder. He grants rights to third parties. No one but A can remove them. [...] I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in the
Re: Processes stuck on D state on Dual Opteron
Claudio Martins [EMAIL PROTECTED] wrote:
I think I'm going to give a try to Neil's patch, but I'll have to apply
some
patches from -mm.
Just this one if you're using 2.6.12-rc2:
--- 25/drivers/md/md.c~avoid-deadlock-in-sync_page_io-by-using-gfp_noio Mon Apr
11 16:55:07 2005
+++ 25-akpm/drivers/md/md.c Mon Apr 11 16:55:07 2005
@@ -332,7 +332,7 @@ static int bi_complete(struct bio *bio,
static int sync_page_io(struct block_device *bdev, sector_t sector, int size,
struct page *page, int rw)
{
- struct bio *bio = bio_alloc(GFP_KERNEL, 1);
+ struct bio *bio = bio_alloc(GFP_NOIO, 1);
struct completion event;
int ret;
_
-
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/3] cifs: md5 cleanup - functions
Alexander Nyberg [EMAIL PROTECTED] wrote on 04/11/2005 03:26:14 PM:
Function names and return types on same line - conform to
established
fs/cifs/ style.
-void
-MD5Init(struct MD5Context *ctx)
+void MD5Init(struct MD5Context *ctx)
{
ctx-buf[0] = 0x67452301;
ctx-buf[1] = 0xefcdab89;
@@ -60,8 +58,7 @@ MD5Init(struct MD5Context *ctx)
* Update context to reflect the concatenation of another buffer
full
* of bytes.
*/
-void
-MD5Update(struct MD5Context *ctx, unsigned char const *buf,
unsigned len)
+void MD5Update(struct MD5Context *ctx, unsigned char const *buf,
unsigned len)
{
Can anyone enlighten me why CIFS is not using crypto/md5?
Same question about md4
There was a patch suggested a year or so ago to remove the older cifs
md5 implementation and have cifsencrypt.c use the newer Linux crypto
API, but since it made the code considerably more complex it did not
make any sense. The current crypto API seems to be designed for much
more complex usage patterns than cifs needs it for. The key use for this
for CIFS is the following small function (to calculate the packet
signitures on cifs packets in fs/cifs/cifsencrypt.c)
38 static int cifs_calculate_signature(const struct smb_hdr * cifs_pdu,
const char * key, char * signature)
39 {
40 struct MD5Context context;
41
42 if((cifs_pdu == NULL) || (signature == NULL))
43 return -EINVAL;
44
45 MD5Init(context);
46 MD5Update(context,key,CIFS_SESSION_KEY_SIZE+16);
47
MD5Update(context,cifs_pdu-Protocol,cifs_pdu-smb_buf_length);
48 MD5Final(signature,context);
49 return 0;
50 }
The problem with moving this function to use crypto/md5.c is that the
three needed md5 functions (MD5Init, MD5Update, MD5Final) are not
exported (although they appear to be already implemented in close to the
right form already - but they are defined as static in crypto/md5.c) and
the only way to do the equivalent is much more complicated. I don't mind
using those equivalent three functions in crypto/md5.c directly if
someone could verify that they match the three functions of the same
name and could export them so cifs could call them - I would like to get
rid of cifs/md5.c
There was a similar issue IIRC with md4.c - the code gets more complex
rather than less complex moving to the crypto API.
-
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: [INFO] Kernel strict versioning
Adrian Bunk wrote: This has nothing to do with versioning. You are asking for ABI compatibility between different kernel versions. The problem is probably misunderstanding about what I intend by version. There is no stable ABI between different kernel versions and there will never be one. Please read Documentation/stable_api_nonsense.txt for details. I've read it. Assuming the fact that a kernel can be considered stable, my point of view implies an assumption: kernel and modules are distributed by a distro, and compiled with the same gcc. Of course, I'm not talking about different architectures and so on, since I'm talking about something different, I'm talking about the api involved in the developement. Distributions have to use a great care about compiler changes, and it's not kernel developers' problem. A kernel stable 2.X version should not differ much in the subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be possibly avoided by using a release versioning different from the one used now. Structues and exported functions should be almost the same, the implementation should be, and of course, must be different: bugs, improvements and so on. I see the point about continuous developement, that's why I'm using linux since 97, but I find interesting also the design of a stable infrastructure, that can be achieved. A data structure no longer in use by anyone, functions being unused for a long time, can be made harmless. Providing a binary compatibility makes recompiling all external modules (external to the official kernel I mean) not necessary, making life easier for any other person using linux (e.g. pwc module for my logitech pro 4000 webcam, every new kernel, new module compilation. Stability makes in this sense a real big improvement. An example of this care can be found in trolltech qt library. I use them since 1.x and it's a really good thing assuring the binary compatibility... of course they just screw it some day to day :) Everybody can be wrong. I find it an interesting point anyway. I know there would never be, as you said, but I don't find the document you've pointed me to, really convincing. Still have doubts... -- Sensei mailto:[EMAIL PROTECTED] pgp:8998A2DB icqnum:241572242 yahoo!:sensei_sen msn-id:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: bdflush/rpciod high CPU utilization, profile does not make sense
On Tue, 2005-04-12 at 01:42, Jakob Oestergaard wrote: Yes, as far as I know - the Broadcom Tigeon3 driver does not have the option of enabling/disabling RX polling (if we agree that is what we're talking about), but looking in tg3.c it seems that it *always* unconditionally uses NAPI... I've whined and moaned about this in the past, but for all its faults NAPI on tg3 doesn't lose packets. It does cause a huge increase in irq cpu time on multiple fast CPUs. What irq rate are you seeing? I did once post a patch to make NAPI for tg3 selectable at configure time. http://marc.theaimsgroup.com/?l=linux-netdevm=107183822710263w=2 No dropped packets... I wonder if the tg3 driver is being completely honest about this... At one point it wasn't, since this patch it is: http://marc.theaimsgroup.com/?l=linux-netdevm=108433829603319w=2 Greg. -- Greg Banks, RD Software Engineer, SGI Australian Software Group. I don't speak for SGI. - 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] sched: unlocked context-switches
On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar [EMAIL PROTECTED] said: Ingo * David S. Miller [EMAIL PROTECTED] wrote: Yes, of course. The deadlock was due to context-switching, not switch_mm() per se. Hopefully someone else beats me to remembering the details before Monday. Sparc64 has a deadlock because we hold mm-page_table_lock during switch_mm(). I bet IA64 did something similar, as I remember it had a very similar locking issue in this area. So the deadlock was, we held the runqueue locks over switch_mm(), switch_mm() spins on mm-page_table_lock, the cpu which does have mm- page_table_lock tries to do a wakeup on the first cpu's mm- runqueue. Classic AB-BA deadlock. Ingo yeah, i can see that happening - holding the runqueue lock and Ingo enabling interrupts. (it's basically never safe to enable irqs Ingo with the runqueue lock held.) Ingo the patch drops both the runqueue lock and enables interrupts, Ingo so this particular issue should not trigger. I had to refresh my memory with a quick Google search that netted [1] (look for Disable interrupts during context switch). Actually, it wasn't really a deadlock, but rather a livelock, since a CPU got stuck on an infinite page-not-present loop. Fundamentally, the issue was that doing the switch_mm() and switch_to() with interrupts enabled opened a window during which you could get a call to flush_tlb_mm() (as a result of an IPI). This, in turn, could end up activating the wrong MMU-context, since the action of flush_tlb_mm() depends on the value of current-active_mm. The problematic sequence was: 1) schedule() calls switch_mm() which calls activate_context() to switch to the new address-space 2) IPI comes in and flush_tlb_mm(mm) gets called 3) current still points to old task and if current-active_mm == mm, activate_mm() is called for the old address-space, resetting the address-space back to that of the old task Now, Ingo says that the order is reversed with his patch, i.e., switch_mm() happens after switch_to(). That means flush_tlb_mm() may now see a current-active_mm which hasn't really been activated yet. That should be OK since it would just mean that we'd do an early (and duplicate) activate_context(). While it does not give me a warm and fuzzy feeling to have this inconsistent state be observable by interrupt-handlers (and, in particular, IPI-handlers), I don't see any problem with it off hand. --david [1] http://www.gelato.unsw.edu.au/linux-ia64/0307/6109.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/
Policy question (was Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop)
On Wednesday 06 April 2005 05:22 pm, Shawn Starr wrote: --- Pavel Machek [EMAIL PROTECTED] wrote: Hi! So nobody minds if I make this into a CONFIG option marked as Deprecated? :) Actually it should probably go through Documentation/feature-removal-schedule.txt ...and give it *long* timeout, since it is API change. Pavel Shouldn't all deprecated features be in feature-removal-schedule.txt? There are four entries in feature-removal-schedule in 2.6.12-rc2, but `find . -name Kconfig | xargs grep -i deprecated` finds eight entries. (And there's more if the grep -i is for obsolete instead...) Just wondering... Rob - 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.6.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a
Hi Peter,
As per your suggestion, I switched do {} while(0) to ((void)(0))
for the dummy define, since it's an argumentless function.
Please let me know if it's okay now.
Thanks,
Jaya Kumar
---
I ran into a problem getting reboot working with 2.6.11 on an embedded
board. The board has a Geode GX1 with a CS5530A companion. What I observe on
reboot is the Restarting system printk, and then a cpu stall/hang. I think
the problem arises because the keyboard controller is disabled by the BIOS,
so the traditional mach_reboot()'s output to port 0x64 is ignored. Then the
386 triple fault issued after mach_reboot() results in a shutdown (because
the hardware doesn't have to detect the triple fault and issue a reset).
That then gives the end result of a stalled cpu/hang.
I found that the CS5530A in question has a issue system wide reset bit.
The reboot works cleanly if I write that bit rather than do mach_reboot().
So the following patch is my attempt to incorporate that change into 2.6.11
by adding a X86_REBOOTFIXUPS option. In order to keep reboot.c free of hw
specific fixups, I put it in another file, reboot_fixups.c. I tried to make
it a bit generic so that if there are other reboot related fixups for other
chipsets/boards, there'd be a clean place to put it. Please let me know what
you think.
Thanks,
Jaya Kumar
---
Signed-off-by: Jaya Kumar [EMAIL PROTECTED]
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/Kconfig
linux-2.6.11.7/arch/i386/Kconfig
--- linux-2.6.11.7-vanilla/arch/i386/Kconfig2005-04-08 02:57:18.0
+0800
+++ linux-2.6.11.7/arch/i386/Kconfig2005-04-11 14:21:05.0 +0800
@@ -645,6 +645,24 @@ config I8K
Say Y if you intend to run this kernel on a Dell Inspiron 8000.
Say N otherwise.
+config X86_REBOOTFIXUPS
+ bool Enable X86 board specific fixups for reboot
+ depends on X86
+ default n
+ ---help---
+ This enables chipset and/or board specific fixups to be done
+ in order to get reboot to work correctly. This is only needed on
+ some combinations of hardware and BIOS. The symptom, for which
+ this config is intended, is when reboot ends with a stalled/hung
+ system.
+
+ Currently, the only fixup is for the Geode GX1/CS5530A/TROM2.1.
+ combination.
+
+ Say Y if you want to enable the fixup. Currently, it's safe to
+ enable this option even if you don't need it.
+ Say N otherwise.
+
config MICROCODE
tristate /dev/cpu/microcode - Intel IA32 CPU microcode support
---help---
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/Makefile
linux-2.6.11.7/arch/i386/kernel/Makefile
--- linux-2.6.11.7-vanilla/arch/i386/kernel/Makefile2005-04-08
02:57:22.0 +0800
+++ linux-2.6.11.7/arch/i386/kernel/Makefile2005-04-11 13:10:31.0
+0800
@@ -23,6 +23,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoli
obj-$(CONFIG_X86_MPPARSE) += mpparse.o
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
obj-$(CONFIG_X86_IO_APIC) += io_apic.o
+obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups.o
obj-$(CONFIG_X86_NUMAQ)+= numaq.o
obj-$(CONFIG_X86_SUMMIT_NUMA) += summit.o
obj-$(CONFIG_KPROBES) += kprobes.o
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/reboot.c
linux-2.6.11.7/arch/i386/kernel/reboot.c
--- linux-2.6.11.7-vanilla/arch/i386/kernel/reboot.c2005-04-08
02:57:27.0 +0800
+++ linux-2.6.11.7/arch/i386/kernel/reboot.c2005-04-11 13:10:31.0
+0800
@@ -13,6 +13,7 @@
#include asm/uaccess.h
#include asm/apic.h
#include mach_reboot.h
+#include linux/reboot_fixups.h
/*
* Power off function, if any
@@ -348,6 +349,7 @@ void machine_restart(char * __unused)
/* rebooting needs to touch the page at absolute addr 0 */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
+ mach_reboot_fixups(); /* for board specific fixups */
mach_reboot();
/* That didn't work - force a triple fault.. */
__asm__ __volatile__(lidt %0: :m (no_idt));
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/reboot_fixups.c
linux-2.6.11.7/arch/i386/kernel/reboot_fixups.c
--- linux-2.6.11.7-vanilla/arch/i386/kernel/reboot_fixups.c 1970-01-01
07:30:00.0 +0730
+++ linux-2.6.11.7/arch/i386/kernel/reboot_fixups.c 2005-04-11
14:09:02.0 +0800
@@ -0,0 +1,56 @@
+/*
+ * linux/arch/i386/kernel/reboot_fixups.c
+ *
+ * This is a good place to put board specific reboot fixups.
+ *
+ * List of supported fixups:
+ * geode-gx1/cs5530a - Jaya Kumar [EMAIL PROTECTED]
+ *
+ */
+
+#include asm/delay.h
+#include linux/pci.h
+
+static void cs5530a_warm_reset(struct pci_dev *dev)
+{
+ /* writing 1 to the reset control register, 0x44 causes the
+ cs5530a to perform a system warm reset */
+
Re: Processes stuck on D state on Dual Opteron
On Tue, 2005-04-12 at 01:22 +0100, Claudio Martins wrote: On Monday 11 April 2005 23:59, Nick Piggin wrote: OK, I'll try them in a few minutes and report back. I'm not overly hopeful. If they fix the problem, then it's likely that the real bug is hidden. Well, the thing is, they do fix the problem. Or at least they hide it very well ;-) It has been running for more than 5 hours now with stress with no problems and no stuck processes. Well, that is good... I guess ;) Actually the patches I have sent you do fix real bugs, but they also make the block layer less likely to recurse into page reclaim, so it may be eg. hiding the problem that Neil's patch fixes. It may be that your fundamental problem is solved by my patches, but we need to be sure. I think I'm going to give a try to Neil's patch, but I'll have to apply some patches from -mm. Yep that would be good. Please test -rc2 with Andrew's patch, and obviously my patches backed out. Thanks for sticking with it. Nick - 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
Andrew Morton [EMAIL PROTECTED] writes: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ I'm getting frequent lockups on my PowerMac G5 with rc2-mm3. 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since -rc1-mm3) lock up randomly. The easiest way to reproduce the problem seems to be running Azareus. So it might be network related, but I'm not 100% sure about that, there was a least one deadlock with virtually no network usage. BTW, what's the SysRq key on recent Apple USB keyboards? Alt/Cmd-F13 doesn't work for me. Juergen CONFIG_64BIT=y CONFIG_MMU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_ISA_DMA=y CONFIG_HAVE_DEC_LOCK=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_FORCE_MAX_ZONEORDER=13 CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_KALLSYMS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_SYSVIPC_COMPAT=y CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_PMAC=y CONFIG_PPC=y CONFIG_PPC64=y CONFIG_PPC_OF=y CONFIG_ALTIVEC=y CONFIG_U3_DART=y CONFIG_PPC_PMAC64=y CONFIG_BOOTX_TEXT=y CONFIG_POWER4_ONLY=y CONFIG_IOMMU_VMERGE=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_FLATMEM=y CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_GENERIC_HARDIRQS=y CONFIG_SECCOMP=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_PCI_NAMES=y CONFIG_PROC_DEVICETREE=y CONFIG_NET=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_SYN_COOKIES=y CONFIG_IP_TCPDIAG=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_HCIUSB=m CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_INITRAMFS_SOURCE= CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDECD=y CONFIG_IDE_TASK_IOCTL=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDE_PMAC=y CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_BLK_DEV_IDEDMA_PMAC=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_SVW=y CONFIG_SCSI_QLA2XXX=y CONFIG_MD=y CONFIG_BLK_DEV_DM=y CONFIG_DM_CRYPT=y CONFIG_DM_SNAPSHOT=y CONFIG_DM_MIRROR=y CONFIG_DM_ZERO=y CONFIG_ADB_PMU=y CONFIG_THERM_PM72=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_SUNGEM=y CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1600 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1200 CONFIG_INPUT_EVDEV=m CONFIG_INPUT_KEYBOARD=y CONFIG_INPUT_MOUSE=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_RTC=y CONFIG_AGP=y CONFIG_AGP_UNINORTH=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_ALGOBIT=y CONFIG_I2C_KEYWEST=y CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SOFT_CURSOR=y CONFIG_FB_MACMODES=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_OF=y CONFIG_FB_RADEON=y CONFIG_FB_RADEON_I2C=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y CONFIG_SOUND=m CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_POWERMAC=m CONFIG_SND_USB_AUDIO=m CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB=y CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_STORAGE=m CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y CONFIG_USB_HIDDEV=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_JBD=y CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y CONFIG_INOTIFY=y CONFIG_DNOTIFY=y CONFIG_FUSE_FS=m CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y CONFIG_UDF_NLS=y CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=850
Re: Policy question (was Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop)
Well, of course. When I get around to figuring out the best way to do this. Since I don't want to bloat up sysfs ACPI stuff just to check if the echoed value is a number or string. We can just gradually phase it out by just marking it DEPRECATED and keep it ON in the Kbuild file so nobody looses the functionality until then. I'm thinking 2 years but some say thats too long :) Now that I look at it, I don't need to put it into a CONFIG option as its already a module :-) even better. Shawn. On April 11, 2005 20:09, Rob Landley wrote: On Wednesday 06 April 2005 05:22 pm, Shawn Starr wrote: --- Pavel Machek [EMAIL PROTECTED] wrote: Hi! So nobody minds if I make this into a CONFIG option marked as Deprecated? :) Actually it should probably go through Documentation/feature-removal-schedule.txt ...and give it *long* timeout, since it is API change. Pavel Shouldn't all deprecated features be in feature-removal-schedule.txt? There are four entries in feature-removal-schedule in 2.6.12-rc2, but `find . -name Kconfig | xargs grep -i deprecated` finds eight entries. (And there's more if the grep -i is for obsolete instead...) Just wondering... Rob - 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: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
On Mon, 11 Apr 2005 20:45:38 +0200, Peter Baudis wrote: Hello, please do not trim the cc list so agressively. Sorry. I read the list from a web site that does not show the cc lists. I'll try to cc more people from the relevant discussions though. On the other hand, I've dropped Linus from this message, as it just points to something he previously said. Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter where Adam J. Richter [EMAIL PROTECTED] told me that... ..snip.. Graydon Hoare. (By the way, I would prefer that git just punt to user level programs for diff and merge when all of the versions involved are different or at least have a very thin interface for extending the facility, because I would like to do some character based merge stuff.) ..snip.. But this is what git already does. I agree it could do it even better, by checking environment variables for the appropriate tools (then you could use that to pass diff e.g. -p etc.). This message from Linus seemed to imply that git was going to get its own 3-way merge code: | Then the bad news: the merge algorithm is going to suck. It's going to be | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no | understanding of renames etc. I'll try to find the best parent to base the | merge off of, although early testers may have to tell the piece of crud | what the most recent common parent was. ( from http://marc.theaimsgroup.com/?l=linux-kernelm=111320013100822w=2 ) __ __ Adam J. Richter\ / [EMAIL PROTECTED] | g g d r a s i l - 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: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter where Adam J. Richter [EMAIL PROTECTED] told me that... Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter where Adam J. Richter [EMAIL PROTECTED] told me that... ..snip.. Graydon Hoare. (By the way, I would prefer that git just punt to user level programs for diff and merge when all of the versions involved are different or at least have a very thin interface for extending the facility, because I would like to do some character based merge stuff.) ..snip.. But this is what git already does. I agree it could do it even better, by checking environment variables for the appropriate tools (then you could use that to pass diff e.g. -p etc.). This message from Linus seemed to imply that git was going to get its own 3-way merge code: | Then the bad news: the merge algorithm is going to suck. It's going to be | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no | understanding of renames etc. I'll try to find the best parent to base the | merge off of, although early testers may have to tell the piece of crud | what the most recent common parent was. Well, from what I can read it says just plain 3-way merge, the same RCS/CVS thing you've seen before. :-) Basically, when you look at merge(1) : SYNOPSIS merge [ options ] file1 file2 file3 DESCRIPTION merge incorporates all changes that lead from file2 to file3 into file1. The only big problem is how to guess the best file2 when you give it file3 and file1. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: [INFO] Kernel strict versioning
On Mon, Apr 11, 2005 at 08:02:55PM -0500, Franco Sensei wrote: Adrian Bunk wrote: This has nothing to do with versioning. You are asking for ABI compatibility between different kernel versions. The problem is probably misunderstanding about what I intend by version. There is no stable ABI between different kernel versions and there will never be one. Please read Documentation/stable_api_nonsense.txt for details. I've read it. Assuming the fact that a kernel can be considered stable, my point of view implies an assumption: kernel and modules are distributed by a distro, and compiled with the same gcc. Of course, I'm not talking about different architectures and so on, since I'm talking about something different, I'm talking about the api involved in the developement. Distributions have to use a great care about compiler changes, and it's not kernel developers' problem. A kernel stable 2.X version should not differ much in the subversioning (2.X.a ~= 2.X.b). Changing APIs in the kernel can be You say API but talk about ABI. possibly avoided by using a release versioning different from the one used now. Structues and exported functions should be almost the same, the implementation should be, and of course, must be different: bugs, improvements and so on. You said you've read stable_api_nonsense.txt . stable_api_nonsense.txt talks about exactly these issues. I see the point about continuous developement, that's why I'm using linux since 97, but I find interesting also the design of a stable infrastructure, that can be achieved. A data structure no longer in use by anyone, functions being unused for a long time, can be made harmless. Providing a binary compatibility makes recompiling all external modules (external to the official kernel I mean) not necessary, making life easier for any other person using linux (e.g. pwc module for my logitech pro 4000 webcam, every new kernel, new module compilation. Stability makes in this sense a real big improvement. An example of this care can The right solution for this issue is simple: Get the module into the kernel. Not that e.g. your pwc module will be in kernel 2.6.12. be found in trolltech qt library. I use them since 1.x and it's a really good thing assuring the binary compatibility... of course they just screw it some day to day :) Everybody can be wrong. ... Please check the facts: QT 1 is _not_ binary compatible with QT 3. There's a reason why the library changed the so-name... 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] MAINTAINERS: remove obsolete ACP/MWAVE MODEM entry
On Mon, Apr 11, 2005 at 05:39:32AM -0300, Marcelo Tosatti wrote: Adrian, Hi Marcelo, ./drivers/char/mwave/Makefile also references Paul's email address, at least in v2.4. I've given up on removing and correcting obsolete email addresses. This created more discussions than it was worth... Applied, thanks. Thanks. 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: [2.6 patch] drivers/block/ll_rw_blk.c: possible cleanups
On Mon, Apr 11, 2005 at 08:12:34AM +0200, Jens Axboe wrote: On Sun, Apr 10 2005, Adrian Bunk wrote: This patch contains the following possible cleanups: - make needlessly global code static - remove the following unused global functions: - blkdev_scsi_issue_flush_fn Kill the function completely, it is not used anymore. - __blk_attempt_remerge Normally I would say leave that since it's part of the API, but lets just kill it. I don't envision any further users of the remerging attempts. - remove the following unused EXPORT_SYMBOL's: - blk_phys_contig_segment - blk_hw_contig_segment - blkdev_scsi_issue_flush_fn - __blk_attempt_remerge Please review which of these changes make sense. Looks fine to me, thanks. Can you send a new patch that kills blkdev_scsi_issue_flush_fn()? I have a problem parsing your email. Which parts of my patch are OK and which shouldn't be applied? Or why do you want a separate blkdev_scsi_issue_flush_fn patch? Jens Axboe 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: 2.6.12-rc2-mm3
On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote: Andrew Morton [EMAIL PROTECTED] writes: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ I'm getting frequent lockups on my PowerMac G5 with rc2-mm3. 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since -rc1-mm3) lock up randomly. The easiest way to reproduce the problem seems to be running Azareus. So it might be network related, but I'm not 100% sure about that, there was a least one deadlock with virtually no network usage. BTW, what's the SysRq key on recent Apple USB keyboards? Alt/Cmd-F13 doesn't work for me. No idea about sysrq, i don't use it. However, I haven't experienced any such problem with the various G5s we have here (and no other G5 user reported such a problem). So it would be useful if you could provide a bit more informations here though. For example, what exact G5 model is this, do you have any 3rd party PCI card, what video card are you using, can you reproduce the crash in console mode, that sort of thing ... Also, did you run a memtest equivalent on the machine ? Finally, it would be useful if you could point out which specific patch or bk snapshot, or at least -mm rev. introduced the bug. As I said previously, you are the only one to report that and none of the G5s here is showing such a problem. 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] sched: unlocked context-switches
On Mon, 2005-04-11 at 18:06 -0700, David Mosberger wrote: I had to refresh my memory with a quick Google search that netted [1] (look for Disable interrupts during context switch). Actually, it wasn't really a deadlock, but rather a livelock, since a CPU got stuck on an infinite page-not-present loop. Fundamentally, the issue was that doing the switch_mm() and switch_to() with interrupts enabled opened a window during which you could get a call to flush_tlb_mm() (as a result of an IPI). This, in turn, could end up activating the wrong MMU-context, since the action of flush_tlb_mm() depends on the value of current-active_mm. The problematic sequence was: 1) schedule() calls switch_mm() which calls activate_context() to switch to the new address-space 2) IPI comes in and flush_tlb_mm(mm) gets called 3) current still points to old task and if current-active_mm == mm, activate_mm() is called for the old address-space, resetting the address-space back to that of the old task Now, Ingo says that the order is reversed with his patch, i.e., switch_mm() happens after switch_to(). That means flush_tlb_mm() may now see a current-active_mm which hasn't really been activated yet. If that did bother you, could you keep track of the actually activated mm in your arch code? Or would that involve more arch hooks and general ugliness in the scheduler? Could you alternatively just disable interrupts across the switch? I guess that would require a bit of #ifdefery in sched.c, which we are trying to move away from, but it would be pretty minimal. Much better than what is there now. That should be OK since it would just mean that we'd do an early (and duplicate) activate_context(). While it does not give me a warm and fuzzy feeling to have this inconsistent state be observable by interrupt-handlers (and, in particular, IPI-handlers), I don't see any problem with it off hand. IMO it *is* the direction we should move towards. That is, liberating context switching from scheduler locking, and providing a single set of semantics for the context switch hooks for all architectures. No rush, of course. But it would be good to get it in sooner or later. Nick - 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/
bkbits.net is down
Seems to have crashed, we don't know the cause yet. Is there anyone who is dependent on this tonight? If so I'll drive down and fix it (yeah, very lame of us, we moved it to a different rack which was too far away from our remote power so I can't power cycle it remotely. Our bad.) Let me know, if I don't hear from anyone we'll get it in about 14 hours. If that's too long I'll understand, it's 20 minutes away and I can go deal. --lm - 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] ppc32: refactor FPU exception handling
On Mon, 2005-04-11 at 17:02 -0500, Kumar Gala wrote: Andrew, Moved common FPU exception handling code out of head.S so it can be used by several of the sub-architectures that might of a full PowerPC FPU. Also, uses new CONFIG_PPC_FPU define to fix alignment exception handling for floating point load/store instructions to only occur if we have a hardware FPU. Signed-off-by: Jason McMullan [EMAIL PROTECTED] Signed-off-by: Kumar Gala [EMAIL PROTECTED] Andrew, please hold on this patch, it hasn't been properly discussed with the relevant maintainer, that is Paul Mackerras. I can see matter for debate in there, like the whole duplication of the fast exception return path... It's also touching quite sensitive bits of kernel code (head.S) that needs careful auditing and testing before beeing pushed upstream. 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/
[ANNOUNCE] open-iscsi and linux-iscsi project teams have merged!
The linux-iscsi and open-iscsi developers would like to announce that they have combined forces on a single iSCSI initiator effort! This mail gives an overview of this combined effort and will be followed by a set of iSCSI patches the combined team submits for review as a candidate for inclusion into the mainline kernel. Background After some dialog with the developers on each team, it was decided that although each team started out with independent code and some differences in architecture, it was worth considering the possibility of combining the two efforts into one. Alternatives were considered for the combined architecture of the two projects, including adding an option for a kernel control plane. After discussions, it was decided by consensus that the open-iscsi architecture and code would be the best starting point for the next gen linux-iscsi project. The advantages of this starting point include open-iscsi's optimized I/O paths that were built from scratch, as well as incorporation of well tested iscsi-sfnet components for the control plane and userspace components. The combined open-iscsi and linux-iscsi teams believe this will result in the highest performing and most stable iSCSI stack for Linux. Overview of Combined Project This new combined effort will consist of the open-iscsi code and developers moving over to the linux-iscsi project on sourceforge (http://sourceforge.net/projects/linux-iscsi/). The open-iscsi (http://www.open-iscsi.org) architecture will be the basis for the next gen of linux-iscsi, which will be numbered the linux-iscsi-5.x release series. Release Numbering If you were following the open-iscsi series, here is the mapping between the open-iscsi numbering and the linux-iscsi-5.x numbering: - open-iscsi-0.2 == linux-iscsi-5.0.0.2 Kernel Submission The kernel component of the first release in this linux-iscsi 5.x series will follow shortly, and the combined teams wish to submit this as a candidate for inclusion into the mainline kernel. If you've reviewed the previous open-iscsi patch set, you'll find that this patchset is very similar, with previous reviewer comments incorporated. Thanks. - The combined open-iscsi and linux-iscsi teams - 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: [INFO] Kernel strict versioning
Adrian Bunk wrote: You say API but talk about ABI. As long as we want to guarantee abi, we must use the same names. Api names, not implementation should be the same. You can't substitute get_namei with get_my_own_namei_version_I_know... You said you've read stable_api_nonsense.txt . stable_api_nonsense.txt talks about exactly these issues. Yes. The right solution for this issue is simple: Get the module into the kernel. Not that e.g. your pwc module will be in kernel 2.6.12. Of course not... I don't expect nobody doing that! :) Please check the facts: QT 1 is _not_ binary compatible with QT 3. There's a reason why the library changed the so-name... Yes! That's my point. I didn't mean to say that the library has the same classes as the first version. Qt 3 is *not* compatible with Qt 1. Qt 3.3.0 is binary compatible with qt 3.3.1, 3.3.2, and so on... unless someone makes an error. My point is that versioning should be, in come cases, less restrictive, letting the 2.4 kernel being not compatible with 2.6, but all 2.6.x series being binary compatible with each other. If versioning means something, the last number should be a revision, additions, but since they belong to 2.6 version, they would be compatible. Major kernel changes should probably result in major version change... I'm supposing it. Of course, note that ABI can be achieved stating that all the binaries must be compiled with the same gcc. So, the kernel module library could possibly be simply /lib/modules/2.6/. I'm probably (surely) not getting the point about this issue. It's not that bad... I don't see awkward issues in guaranteeing 2.6, 2.8 and so on compatibility with the ``major second number''. -- Sensei mailto:[EMAIL PROTECTED] pgp:8998A2DB icqnum:241572242 yahoo!:sensei_sen msn-id:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [Bug?] Keyboard Problem
Hi, On Monday 11 April 2005 18:45, Manu wrote: I'm currently using a 2.6.10 kernel (on a Debian Sarge, i386). I've compiled a 2.6.11.5 and a 2.6.11.7 kernels and my keyboard (a sweex SILVER MULTIMEDIA KEYBOARD, SW-23 -- PS/2 105 keys -- a classical keyboard) doesn't work with these kernels. ... CONFIG_EMBEDDED=y ... # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y # CONFIG_SERIO_I8042 is not set You need to enable i8042 support - that's your keyboard controller. Also, is there a specific reason why you enabled embedded mode? In normal mode i8042 would be selected automatically... -- Dmitry - 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/
USB on zx5405us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 USB isn't working on my zv5405us on a 2.6.10 ubuntu kernel. Or on gentoo. Or anything. It works in WindowsXP though. I can extract the error from dmesg. Here's ACPI first (ACPI works btw) Nvidia board detected. Ignoring ACPI timer override. ACPI: RSDP (v000 PTLTD ) @ 0x000f7260 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1ff7a87e ACPI: FADT (v001 NVIDIA CK8 0x0604 PTL_ 0x000f4240) @ 0x1ff7ee13 ACPI: MADT (v001 NVIDIA NV_APIC_ 0x0604 LTP 0x) @ 0x1ff7ee87 ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x0604 LTP 0x0001) @ 0x1ff7eee1 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1ff7ef09 ACPI: DSDT (v001 NVIDIA CK8 0x0604 MSFT 0x010e) @ 0x ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: IRQ9 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information ACPI wakeup devices: USB0 USB1 USB2 PS2K PS2M MAC0 ACPI: (supports S0 S3 S4 S5) NFORCE3-150: IDE controller at PCI slot :00:08.0 NFORCE3-150: chipset revision 165 NFORCE3-150: not 100% native mode: will probe irqs later NFORCE3-150: BIOS didn't set cable bits correctly. Enabling workaround. NFORCE3-150: :00:08.0 (rev a5) UDMA133 controller ide0: BM-DMA at 0x2080-0x2087, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x2088-0x208f, BIOS settings: hdc:DMA, hdd:pio Finally, the USB messages themselves: ohci_hcd :00:02.0: nVidia Corporation nForce3 USB 1.1 ohci_hcd :00:02.0: USB HC TakeOver failed! ohci_hcd :00:02.0: can't reset ohci_hcd :00:02.0: init :00:02.0 fail, -16 ohci_hcd: probe of :00:02.0 failed with error -16 lspci gives: :00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) :00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) :00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2) lsusb gives: Bus 001 Device 001: ID : Happens to be the USB2 stuff. /proc/bus/usb/devices: T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 2.06 S: Manufacturer=Linux 2.6.10-5-amd64-generic ehci_hcd S: Product=nVidia Corporation nForce3 USB 2.0 S: SerialNumber=:00:02.2 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms A mass storage device that works on my desktop doesn't work here. It works in Windows though. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. -- Eric Steven Raymond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCWz3chDd4aOud5P8RArB9AJ9AECG8+VrPUt8Zu7djzvl+Oi3lwgCfdD17 QbgPw+B1tbY66BjcFSpz9L4= =0WK/ -END PGP SIGNATURE- - 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/
