[PATCH 0/16] Assorted patches

[PATCH 0/16] Assorted patches

[Jan Engelhardt]

Hello list,


People collect stamps, etc. and I do patches. It is April 01, but let ye 
know that even the patch that would get the most naks is not really 
meant as an April joke.
Most of them are independent, but I'll let `quilt graph` judge their 
dependencies.

	[01/] vt-sysfs-for-colors.diff
	[02/] vt-pure-colors.diff
	[03/] vt-underline-color.diff
	[04/] vt-printk-color.diff
	[05/] fix-kthread-niceness.diff
	[06/] isofs-add-write-bit.diff
	[07/] kconfig-dynamic-frequency.diff
	[08/] console-printk-level.diff
	[09/] zlib-decompression-status.diff
	[10/] show-partitions-on-mount-error.diff
	[11/] samba-eintr-fix.diff
	[12/] cifs-use-mutex.diff
	[13/] show-pipesize-in-stat.diff
	[14/] kconfig-allow-override.diff
	[15/] use-regular-eth-suffix.diff
	[16/] warn-on-kthread-name-truncation.diff

(`quilt graph` says the order of the vt-* ones is important.)


Jan
-- 

[PATCH 1/16] vt-sysfs-for-colors.diff

[Jan Engelhardt]

Allow for the palette to be exposed and changed via sysfs. A call to
/usr/bin/reset will slurp the new definitions in for the current
console.

Already posted at http://lkml.org/lkml/2006/1/15/149

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 vt.c |    4 ++++
 1 file changed, 4 insertions(+)

Index: linux-2.6.21-rc5/drivers/char/vt.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/char/vt.c
+++ linux-2.6.21-rc5/drivers/char/vt.c
@@ -934,6 +934,10 @@ int default_grn[] = {0x00,0x00,0xaa,0x55
 int default_blu[] = {0x00,0x00,0x00,0x00,0xaa,0xaa,0xaa,0xaa,
     0x55,0x55,0x55,0x55,0xff,0xff,0xff,0xff};
 
+module_param_array(default_red, int, NULL, S_IRUGO | S_IWUSR);
+module_param_array(default_grn, int, NULL, S_IRUGO | S_IWUSR);
+module_param_array(default_blu, int, NULL, S_IRUGO | S_IWUSR);
+
 /*
  * gotoxy() must verify all boundaries, because the arguments
  * might also be negative. If the given position is out of
#<EOF>

[PATCH 2/16] vt-pure-colors.diff

[Jan Engelhardt]

Have the Linux kernel set a new VGA palette for the first 16 colors.
The new values reduce the saturation (white component) and therefore
increase contrast.

Already posted once: http://lkml.org/lkml/2006/1/15/149

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 vt.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Index: linux-2.6.21-rc5/drivers/char/vt.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/char/vt.c
+++ linux-2.6.21-rc5/drivers/char/vt.c
@@ -927,12 +927,12 @@ unsigned char color_table[] = { 0, 4, 2,
 				       8,12,10,14, 9,13,11,15 };
 
 /* the default colour table, for VGA+ colour systems */
-int default_red[] = {0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,
-    0x55,0xff,0x55,0xff,0x55,0xff,0x55,0xff};
-int default_grn[] = {0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,
-    0x55,0x55,0xff,0xff,0x55,0x55,0xff,0xff};
-int default_blu[] = {0x00,0x00,0x00,0x00,0xaa,0xaa,0xaa,0xaa,
-    0x55,0x55,0x55,0x55,0xff,0xff,0xff,0xff};
+int default_red[] =
+{0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,0x55,0xff,0x00,0xff,0x00,0xff,0x00,0xff};
+int default_grn[] =
+{0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,0x55,0x00,0xff,0xff,0x00,0x00,0xff,0xff};
+int default_blu[] =
+{0x00,0x00,0x00,0x00,0x90,0xaa,0xaa,0xaa,0x55,0x00,0x00,0x00,0xff,0xff,0xff,0xff};
 
 module_param_array(default_red, int, NULL, S_IRUGO | S_IWUSR);
 module_param_array(default_grn, int, NULL, S_IRUGO | S_IWUSR);
#<EOF>

[PATCH 3/16] vt-underline-color.diff

[Jan Engelhardt]

Add color support to the "underline" and "italic" attributes as in
OpenBSD/NetBSD-style (vt220) and xterm.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 drivers/char/vt.c               |   34 ++++++++++++++++++++++++++++------
 drivers/video/console/mdacon.c  |    3 ++-
 drivers/video/console/promcon.c |    3 ++-
 drivers/video/console/sticon.c  |    2 +-
 drivers/video/console/vgacon.c  |   12 ++++++++----
 include/linux/console.h         |    2 +-
 include/linux/console_struct.h  |    3 +++
 7 files changed, 45 insertions(+), 14 deletions(-)

Index: linux-2.6.21-rc5/drivers/char/vt.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/char/vt.c
+++ linux-2.6.21-rc5/drivers/char/vt.c
@@ -348,10 +348,12 @@ void update_region(struct vc_data *vc, u
 
 /* Structure of attributes is hardware-dependent */
 
-static u8 build_attr(struct vc_data *vc, u8 _color, u8 _intensity, u8 _blink, u8 _underline, u8 _reverse)
+static u8 build_attr(struct vc_data *vc, u8 _color, u8 _intensity, u8 _blink,
+    u8 _underline, u8 _reverse, u8 _italic)
 {
 	if (vc->vc_sw->con_build_attr)
-		return vc->vc_sw->con_build_attr(vc, _color, _intensity, _blink, _underline, _reverse);
+		return vc->vc_sw->con_build_attr(vc, _color, _intensity,
+		       _blink, _underline, _reverse, _italic);
 
 #ifndef VT_BUF_VRAM_ONLY
 /*
@@ -368,10 +370,13 @@ static u8 build_attr(struct vc_data *vc,
 	u8 a = vc->vc_color;
 	if (!vc->vc_can_do_color)
 		return _intensity |
+		       (_italic ? 2 : 0) |
 		       (_underline ? 4 : 0) |
 		       (_reverse ? 8 : 0) |
 		       (_blink ? 0x80 : 0);
-	if (_underline)
+	if (_italic)
+		a = (a & 0xF0) | vc->vc_itcolor;
+	else if (_underline)
 		a = (a & 0xf0) | vc->vc_ulcolor;
 	else if (_intensity == 0)
 		a = (a & 0xf0) | vc->vc_ulcolor;
@@ -392,8 +397,10 @@ static u8 build_attr(struct vc_data *vc,
 
 static void update_attr(struct vc_data *vc)
 {
-	vc->vc_attr = build_attr(vc, vc->vc_color, vc->vc_intensity, vc->vc_blink, vc->vc_underline, vc->vc_reverse ^ vc->vc_decscnm);
-	vc->vc_video_erase_char = (build_attr(vc, vc->vc_color, 1, vc->vc_blink, 0, vc->vc_decscnm) << 8) | ' ';
+	vc->vc_attr = build_attr(vc, vc->vc_color, vc->vc_intensity,
+	              vc->vc_blink, vc->vc_underline,
+	              vc->vc_reverse ^ vc->vc_decscnm, vc->vc_italic);
+	vc->vc_video_erase_char = (build_attr(vc, vc->vc_color, 1, vc->vc_blink, 0, vc->vc_decscnm, 0) << 8) | ' ';
 }
 
 /* Note: inverting the screen twice should revert to the original state */
@@ -1136,6 +1143,7 @@ static void csi_X(struct vc_data *vc, in
 static void default_attr(struct vc_data *vc)
 {
 	vc->vc_intensity = 1;
+	vc->vc_italic = 0;
 	vc->vc_underline = 0;
 	vc->vc_reverse = 0;
 	vc->vc_blink = 0;
@@ -1158,6 +1166,9 @@ static void csi_m(struct vc_data *vc)
 			case 2:
 				vc->vc_intensity = 0;
 				break;
+			case 3:
+				vc->vc_italic = 1;
+				break;
 			case 4:
 				vc->vc_underline = 1;
 				break;
@@ -1198,6 +1209,9 @@ static void csi_m(struct vc_data *vc)
 			case 22:
 				vc->vc_intensity = 1;
 				break;
+			case 23:
+				vc->vc_italic = 0;
+				break;
 			case 24:
 				vc->vc_underline = 0;
 				break;
@@ -1458,6 +1472,7 @@ static void save_cur(struct vc_data *vc)
 	vc->vc_saved_x		= vc->vc_x;
 	vc->vc_saved_y		= vc->vc_y;
 	vc->vc_s_intensity	= vc->vc_intensity;
+	vc->vc_s_italic         = vc->vc_italic;
 	vc->vc_s_underline	= vc->vc_underline;
 	vc->vc_s_blink		= vc->vc_blink;
 	vc->vc_s_reverse	= vc->vc_reverse;
@@ -1472,6 +1487,7 @@ static void restore_cur(struct vc_data *
 {
 	gotoxy(vc, vc->vc_saved_x, vc->vc_saved_y);
 	vc->vc_intensity	= vc->vc_s_intensity;
+	vc->vc_italic		= vc->vc_s_italic;
 	vc->vc_underline	= vc->vc_s_underline;
 	vc->vc_blink		= vc->vc_s_blink;
 	vc->vc_reverse		= vc->vc_s_reverse;
@@ -2585,6 +2601,11 @@ static void con_close(struct tty_struct 
 	mutex_unlock(&tty_mutex);
 }
 
+static int default_italic_color    = 2; // green (ASCII)
+static int default_underline_color = 3; // cyan (ASCII)
+module_param_named(italic, default_italic_color, int, S_IRUGO | S_IWUSR);
+module_param_named(underline, default_underline_color, int, S_IRUGO | S_IWUSR);
+
 static void vc_init(struct vc_data *vc, unsigned int rows,
 		    unsigned int cols, int do_clear)
 {
@@ -2604,7 +2625,8 @@ static void vc_init(struct vc_data *vc, 
 		vc->vc_palette[k++] = default_blu[j] ;
 	}
 	vc->vc_def_color       = 0x07;   /* white */
-	vc->vc_ulcolor		= 0x0f;   /* bold white */
+	vc->vc_ulcolor         = default_underline_color;
+	vc->vc_itcolor         = default_italic_color;
 	vc->vc_halfcolor       = 0x08;   /* grey */
 	init_waitqueue_head(&vc->paste_wait);
 	reset_terminal(vc, do_clear);
Index: linux-2.6.21-rc5/drivers/video/console/mdacon.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/video/console/mdacon.c
+++ linux-2.6.21-rc5/drivers/video/console/mdacon.c
@@ -384,7 +384,7 @@ static inline u16 mda_convert_attr(u16 c
 }
 
 static u8 mdacon_build_attr(struct vc_data *c, u8 color, u8 intensity, 
-			    u8 blink, u8 underline, u8 reverse)
+			    u8 blink, u8 underline, u8 reverse, u8 italic)
 {
 	/* The attribute is just a bit vector:
 	 *
@@ -397,6 +397,7 @@ static u8 mdacon_build_attr(struct vc_da
 	return (intensity & 3) |
 		((underline & 1) << 2) |
 		((reverse   & 1) << 3) |
+		(!!italic << 4) |
 		((blink     & 1) << 7);
 }
 
Index: linux-2.6.21-rc5/drivers/video/console/promcon.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/video/console/promcon.c
+++ linux-2.6.21-rc5/drivers/video/console/promcon.c
@@ -548,7 +548,8 @@ promcon_scroll(struct vc_data *conp, int
 }
 
 #if !(PROMCON_COLOR)
-static u8 promcon_build_attr(struct vc_data *conp, u8 _color, u8 _intensity, u8 _blink, u8 _underline, u8 _reverse)
+static u8 promcon_build_attr(struct vc_data *conp, u8 _color, u8 _intensity,
+    u8 _blink, u8 _underline, u8 _reverse, u8 _italic)
 {
 	return (_reverse) ? 0xf : 0x7;
 }
Index: linux-2.6.21-rc5/drivers/video/console/sticon.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/video/console/sticon.c
+++ linux-2.6.21-rc5/drivers/video/console/sticon.c
@@ -314,7 +314,7 @@ static unsigned long sticon_getxy(struct
 }
 
 static u8 sticon_build_attr(struct vc_data *conp, u8 color, u8 intens,
-			    u8 blink, u8 underline, u8 reverse)
+			    u8 blink, u8 underline, u8 reverse, u8 italic)
 {
     u8 attr = ((color & 0x70) >> 1) | ((color & 7));
 
Index: linux-2.6.21-rc5/drivers/video/console/vgacon.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/video/console/vgacon.c
+++ linux-2.6.21-rc5/drivers/video/console/vgacon.c
@@ -87,7 +87,7 @@ static void vgacon_save_screen(struct vc
 static int vgacon_scroll(struct vc_data *c, int t, int b, int dir,
 			 int lines);
 static u8 vgacon_build_attr(struct vc_data *c, u8 color, u8 intensity,
-			    u8 blink, u8 underline, u8 reverse);
+			    u8 blink, u8 underline, u8 reverse, u8);
 static void vgacon_invert_region(struct vc_data *c, u16 * p, int count);
 static unsigned long vgacon_uni_pagedir[2];
 
@@ -577,12 +577,14 @@ static void vgacon_deinit(struct vc_data
 }
 
 static u8 vgacon_build_attr(struct vc_data *c, u8 color, u8 intensity,
-			    u8 blink, u8 underline, u8 reverse)
+			    u8 blink, u8 underline, u8 reverse, u8 italic)
 {
 	u8 attr = color;
 
 	if (vga_can_do_color) {
-		if (underline)
+		if (italic)
+			attr = (attr & 0xF0) | c->vc_itcolor;
+		else if (underline)
 			attr = (attr & 0xf0) | c->vc_ulcolor;
 		else if (intensity == 0)
 			attr = (attr & 0xf0) | c->vc_halfcolor;
@@ -596,7 +598,9 @@ static u8 vgacon_build_attr(struct vc_da
 	if (intensity == 2)
 		attr ^= 0x08;
 	if (!vga_can_do_color) {
-		if (underline)
+		if (italic)
+			attr = (attr & 0xF8) | 0x02;
+		else if (underline)
 			attr = (attr & 0xf8) | 0x01;
 		else if (intensity == 0)
 			attr = (attr & 0xf0) | 0x08;
Index: linux-2.6.21-rc5/include/linux/console.h
===================================================================
--- linux-2.6.21-rc5.orig/include/linux/console.h
+++ linux-2.6.21-rc5/include/linux/console.h
@@ -51,7 +51,7 @@ struct consw {
 	int	(*con_scrolldelta)(struct vc_data *, int);
 	int	(*con_set_origin)(struct vc_data *);
 	void	(*con_save_screen)(struct vc_data *);
-	u8	(*con_build_attr)(struct vc_data *, u8, u8, u8, u8, u8);
+	u8	(*con_build_attr)(struct vc_data *, u8, u8, u8, u8, u8, u8);
 	void	(*con_invert_region)(struct vc_data *, u16 *, int);
 	u16    *(*con_screen_pos)(struct vc_data *, int);
 	unsigned long (*con_getxy)(struct vc_data *, unsigned long, int *, int *);
Index: linux-2.6.21-rc5/include/linux/console_struct.h
===================================================================
--- linux-2.6.21-rc5.orig/include/linux/console_struct.h
+++ linux-2.6.21-rc5/include/linux/console_struct.h
@@ -37,6 +37,7 @@ struct vc_data {
 	unsigned char	vc_color;		/* Foreground & background */
 	unsigned char	vc_s_color;		/* Saved foreground & background */
 	unsigned char	vc_ulcolor;		/* Color for underline mode */
+	unsigned char   vc_itcolor;
 	unsigned char	vc_halfcolor;		/* Color for half intensity mode */
 	/* cursor */
 	unsigned int	vc_cursor_type;
@@ -71,10 +72,12 @@ struct vc_data {
 	unsigned int	vc_deccolm	: 1;	/* 80/132 Column Mode */
 	/* attribute flags */
 	unsigned int	vc_intensity	: 2;	/* 0=half-bright, 1=normal, 2=bold */
+	unsigned int    vc_italic:1;
 	unsigned int	vc_underline	: 1;
 	unsigned int	vc_blink	: 1;
 	unsigned int	vc_reverse	: 1;
 	unsigned int	vc_s_intensity	: 2;	/* saved rendition */
+	unsigned int    vc_s_italic:1;
 	unsigned int	vc_s_underline	: 1;
 	unsigned int	vc_s_blink	: 1;
 	unsigned int	vc_s_reverse	: 1;
#<EOF>

[PATCH 4/16] vt-printk-color.diff

[Jan Engelhardt]

Colored kernel message output

Gives kernel messages on the console an OpenBSD-esque color to distinguish
them from regular tty (as long as that's not colored too) text.

Inspired by cko (iirc http://freshmeat.net/p/cko/), but better
implementation done by myself (handles newlines correctly).

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 Kconfig |   28 ++++++++++++++++++++++++++++
 vt.c    |   22 ++++++++++++++++++++++
 2 files changed, 50 insertions(+)

Index: linux-2.6.21-rc5/drivers/char/Kconfig
===================================================================
--- linux-2.6.21-rc5.orig/drivers/char/Kconfig
+++ linux-2.6.21-rc5/drivers/char/Kconfig
@@ -57,6 +57,34 @@ config VT_CONSOLE
 
 	  If unsure, say Y.
 
+config VT_CKO
+	hex "Colored kernel message output"
+	range 0x00 0xFF
+	depends on VT_CONSOLE
+	default 0x17
+	---help---
+	This option will give you ability to change the color of
+	kernel messages.
+
+	The value you need to enter here is the ASCII color value
+	composed (OR'ed) by one foreground color, one background
+	color and any number of attributes as follows:
+
+	Foreground:     Background:    Attributes:
+	0x01 blue       0x10 blue      0x08 highlight foreground
+	0x02 green      0x20 green     0x80 blinking foreground
+	0x03 cyan       0x30 cyan
+	0x04 red        0x40 red
+	0x05 magenta    0x50 red
+	0x06 brown      0x60 brown
+	0x07 gray       0x70 gray
+
+	Thus, 0x17 will yield gray-on-blue like you can see in
+	OpenBSD, 0x02 the green-on-black like on NetBSD.
+	Using "highlight foreground" does not work when you use
+	VGA Console and fonts with 512 glyphs.
+	VGA Framebuffer is not affected.
+
 config HW_CONSOLE
 	bool
 	depends on VT && !S390 && !UML
Index: linux-2.6.21-rc5/drivers/char/vt.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/char/vt.c
+++ linux-2.6.21-rc5/drivers/char/vt.c
@@ -73,6 +73,7 @@
  */
 
 #include <linux/module.h>
+#include <linux/moduleparam.h>
 #include <linux/types.h>
 #include <linux/sched.h>
 #include <linux/tty.h>
@@ -2234,6 +2235,17 @@ struct tty_driver *console_driver;
 
 #ifdef CONFIG_VT_CONSOLE
 
+static unsigned int cko_color = CONFIG_VT_CKO;
+
+static __init int set_cko(char *str)
+{
+	cko_color = simple_strtoul(str, NULL, 0);
+	return 1;
+}
+
+__setup("cko=", set_cko);
+module_param(cko_color, uint, S_IRUGO | S_IWUSR);
+
 /*
  *	Console on virtual terminal
  *
@@ -2274,12 +2286,16 @@ static void vt_console_print(struct cons
 		hide_cursor(vc);
 
 	start = (ushort *)vc->vc_pos;
+	vc->vc_color = cko_color;
+	update_attr(vc);
 
 	/* Contrived structure to try to emulate original need_wrap behaviour
 	 * Problems caused when we have need_wrap set on '\n' character */
 	while (count--) {
 		c = *b++;
 		if (c == 10 || c == 13 || c == 8 || vc->vc_need_wrap) {
+			vc->vc_color = vc->vc_def_color;
+			update_attr(vc);
 			if (cnt > 0) {
 				if (CON_IS_VISIBLE(vc))
 					vc->vc_sw->con_putcs(vc, start, cnt, vc->vc_y, vc->vc_x);
@@ -2292,6 +2308,8 @@ static void vt_console_print(struct cons
 				bs(vc);
 				start = (ushort *)vc->vc_pos;
 				myx = vc->vc_x;
+				vc->vc_color = cko_color;
+				update_attr(vc);
 				continue;
 			}
 			if (c != 13)
@@ -2299,6 +2317,8 @@ static void vt_console_print(struct cons
 			cr(vc);
 			start = (ushort *)vc->vc_pos;
 			myx = vc->vc_x;
+			vc->vc_color = cko_color;
+			update_attr(vc);
 			if (c == 10 || c == 13)
 				continue;
 		}
@@ -2320,6 +2340,8 @@ static void vt_console_print(struct cons
 			vc->vc_need_wrap = 1;
 		}
 	}
+	vc->vc_color = vc->vc_def_color;
+	update_attr(vc);
 	set_cursor(vc);
 
 quit:
#<EOF>

[PATCH 5/16] fix-kthread-niceness.diff

[Jan Engelhardt]

Fix kevent's childs priority greedy-ness. Such tasks were always scheduled
at nice level -5 and, at that time, udev stole us the CPU time with -5.

Already posted at http://lkml.org/lkml/2005/1/10/85

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Chris Wright <chrisw@sous-sol.org>

 kmod.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.21-rc5/kernel/kmod.c
===================================================================
--- linux-2.6.21-rc5.orig/kernel/kmod.c
+++ linux-2.6.21-rc5/kernel/kmod.c
@@ -165,6 +165,7 @@ static int ____call_usermodehelper(void 
 
 	/* We can run anywhere, unlike our parent keventd(). */
 	set_cpus_allowed(current, CPU_MASK_ALL);
+	set_user_nice(current, 0);
 
 	retval = -EPERM;
 	if (current->fs->root)
#<EOF>

[PATCH 06/16] isofs-add-write-bit.diff

[Jan Engelhardt]

Add %S_IWUGO bit for isofs. Makes it easier to poke on files after
they have been copied from an ISO-9660 filesystem because they are
ofte copied in `cp -p` or perhaps `rsync -p` mode.
They are still not writable though, and isofs will continue to
correctly return -EROFS for writes.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 inode.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.21-rc5/fs/isofs/inode.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/isofs/inode.c
+++ linux-2.6.21-rc5/fs/isofs/inode.c
@@ -362,7 +362,7 @@ static int parse_options(char *options, 
 	popt->check = 'u';		/* unset */
 	popt->nocompress = 0;
 	popt->blocksize = 1024;
-	popt->mode = S_IRUGO | S_IXUGO; /* r-x for all.  The disc could
+	popt->mode = S_IRUGO | S_IWUSR | S_IXUGO; /* rwx for all.  The disc could
 					   be shared with DOS machines so
 					   virtually anything could be
 					   a valid executable. */
@@ -1221,7 +1221,7 @@ static void isofs_read_inode(struct inod
 	ei->i_file_format = isofs_file_normal;
 
 	if (de->flags[-high_sierra] & 2) {
-		inode->i_mode = S_IRUGO | S_IXUGO | S_IFDIR;
+		inode->i_mode = S_IRUGO | S_IWUSR | S_IXUGO | S_IFDIR;
 		inode->i_nlink = 1; /* Set to 1.  We know there are 2, but
 				       the find utility tries to optimize
 				       if it is 2, and it screws up.  It is
#<EOF>

[PATCH 07/16] kconfig-dynamic-frequency.diff

[Jan Engelhardt]

Make HZ fully configurable through menuconfig.

Already posted at http://lkml.org/lkml/2006/6/18/111

Signed-off-by: Jan Engelhardt
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> (http://lkml.org/lkml/2006/11/8/307)
Cc: Sam Ravnborg <sam@ravnborg.org>

 Kconfig.hz |   70 +++++++++++++++++++++++--------------------------------------
 1 file changed, 27 insertions(+), 43 deletions(-)

Index: linux-2.6.21-rc5/kernel/Kconfig.hz
===================================================================
--- linux-2.6.21-rc5.orig/kernel/Kconfig.hz
+++ linux-2.6.21-rc5/kernel/Kconfig.hz
@@ -2,50 +2,34 @@
 # Timer Interrupt Frequency Configuration
 #
 
-choice
-	prompt "Timer frequency"
-	default HZ_250
-	help
-	 Allows the configuration of the timer frequency. It is customary
-	 to have the timer interrupt run at 1000 Hz but 100 Hz may be more
-	 beneficial for servers and NUMA systems that do not need to have
-	 a fast response for user interaction and that may experience bus
-	 contention and cacheline bounces as a result of timer interrupts.
-	 Note that the timer interrupt occurs on each processor in an SMP
-	 environment leading to NR_CPUS * HZ number of timer interrupts
-	 per second.
-
-
-	config HZ_100
-		bool "100 HZ"
-	help
-	  100 Hz is a typical choice for servers, SMP and NUMA systems
-	  with lots of processors that may show reduced performance if
-	  too many timer interrupts are occurring.
-
-	config HZ_250
-		bool "250 HZ"
-	help
-	 250 Hz is a good compromise choice allowing server performance
-	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems. If you are going to be using NTSC video
-	 or multimedia, selected 300Hz instead.
-
-	config HZ_300
-		bool "300 HZ"
-	help
-	 300 Hz is a good compromise choice allowing server performance
-	 while also showing good interactive responsiveness even
-	 on SMP and NUMA systems and exactly dividing by both PAL and
-	 NTSC frame rates for video and multimedia work.
-
-	config HZ_1000
-		bool "1000 HZ"
-	help
-	 1000 Hz is the preferred choice for desktop systems and other
-	 systems requiring fast interactive responses to events.
+config HZ
+    int "Timer frequency"
+    default 100
+    ---help---
+        Allows the configuration of the timer frequency. It is customary
+        to have the timer interrupt run at 1000 Hz but 100 Hz may be more
+        beneficial for servers and NUMA systems that do not need to have
+        a fast response for user interaction and that may experience bus
+        contention and cacheline bounces as a result of timer interrupts.
+        Note that the timer interrupt occurs on each processor in an SMP
+        environment leading to NR_CPUS * HZ number of timer interrupts
+        per second.
+
+        100 Hz is a typical choice for servers, SMP and NUMA systems
+        with lots of processors that may show reduced performance if
+        too many timer interrupts are occurring.
+
+        250 Hz is a good compromise choice allowing server performance
+        while also showing good interactive responsiveness even on SMP
+        and NUMA systems.
+
+        300 Hz is a good compromise choice allowing server performance
+        while also showing good interactive responsiveness even
+        on SMP and NUMA systems and exactly dividing by both PAL and
+        NTSC frame rates for video and multimedia work.
 
-endchoice
+        1000 Hz is the preferred choice for desktop systems and other
+        systems requiring fast interactive responses to events.
 
 config HZ
 	int
#<EOF>

[PATCH 08/16] console-printk-level.diff

[Jan Engelhardt]

Allow the printk level to be set using a "conlevel=" parameter.
(Or is there already a different bootoption that does the same thing?)

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 printk.c |    9 +++++++++
 1 file changed, 9 insertions(+)

Index: linux-2.6.21-rc5/kernel/printk.c
===================================================================
--- linux-2.6.21-rc5.orig/kernel/printk.c
+++ linux-2.6.21-rc5/kernel/printk.c
@@ -747,6 +747,15 @@ void resume_console(void)
 }
 #endif /* CONFIG_DISABLE_CONSOLE_SUSPEND */
 
+static __init int set_conlevel(char *str)
+{
+	if(*str >= '0' && *str <= '9')
+		*console_printk = *str - '0';
+	return 1;
+}
+
+__setup("conlevel=", set_conlevel);
+
 /**
  * acquire_console_sem - lock the console system for exclusive use.
  *
#<EOF>

[PATCH 09/16] zlib-decompression-status.diff

[Jan Engelhardt]

Shows some stars during decompression. This is particularly useful on 
old 386s where one asterisk is probably printed every second - making 
the long linux and initramfs uncompress progress more evident.

Not compile tested outside {i386, x86_64} - don't have other machines.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 arch/alpha/boot/misc.c                    |    2 +-
 arch/arm/boot/compressed/misc.c           |    4 ++--
 arch/arm26/boot/compressed/misc.c         |    4 ++--
 arch/cris/arch-v10/boot/compressed/misc.c |    2 +-
 arch/cris/arch-v32/boot/compressed/misc.c |    2 +-
 arch/i386/boot/compressed/misc.c          |    2 +-
 arch/m32r/boot/compressed/misc.c          |    2 +-
 arch/sh/boot/compressed/misc.c            |    2 +-
 arch/sh64/boot/compressed/misc.c          |    2 +-
 arch/x86_64/boot/compressed/misc.c        |    2 +-
 init/do_mounts_rd.c                       |    7 ++++++-
 init/initramfs.c                          |    7 ++++++-
 lib/inflate.c                             |    9 +++++----
 13 files changed, 29 insertions(+), 18 deletions(-)

Index: linux-2.6.21-rc5/arch/alpha/boot/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/alpha/boot/misc.c
+++ linux-2.6.21-rc5/arch/alpha/boot/misc.c
@@ -201,7 +201,7 @@ decompress_kernel(void *output_start,
 
 	makecrc();
 /*	puts("Uncompressing Linux..."); */
-	gunzip();
+	gunzip(NULL);
 /*	puts(" done, booting the kernel.\n"); */
 	return output_ptr;
 }
Index: linux-2.6.21-rc5/arch/arm/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/arm/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/arm/boot/compressed/misc.c
@@ -355,7 +355,7 @@ decompress_kernel(ulg output_start, ulg 
 
 	makecrc();
 	putstr("Uncompressing Linux...");
-	gunzip();
+	gunzip(putstr);
 	putstr(" done, booting the kernel.\n");
 	return output_ptr;
 }
@@ -369,7 +369,7 @@ int main()
 
 	makecrc();
 	putstr("Uncompressing Linux...");
-	gunzip();
+	gunzip(putstr);
 	putstr("done.\n");
 	return 0;
 }
Index: linux-2.6.21-rc5/arch/arm26/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/arm26/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/arm26/boot/compressed/misc.c
@@ -294,7 +294,7 @@ decompress_kernel(ulg output_start, ulg 
 
 	makecrc();
 	puts("Uncompressing Linux...");
-	gunzip();
+	gunzip(puts);
 	puts(" done, booting the kernel.\n");
 	return output_ptr;
 }
@@ -308,7 +308,7 @@ int main()
 
 	makecrc();
 	puts("Uncompressing Linux...");
-	gunzip();
+	gunzip(puts);
 	puts("done.\n");
 	return 0;
 }
Index: linux-2.6.21-rc5/arch/cris/arch-v10/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/cris/arch-v10/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/cris/arch-v10/boot/compressed/misc.c
@@ -267,6 +267,6 @@ decompress_kernel()
 	}
 
 	puts("Uncompressing Linux...\n");
-	gunzip();
+	gunzip(puts);
 	puts("Done. Now booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/cris/arch-v32/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/cris/arch-v32/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/cris/arch-v32/boot/compressed/misc.c
@@ -312,6 +312,6 @@ decompress_kernel()
 	}
 
 	puts("Uncompressing Linux...\n");
-	gunzip();
+	gunzip(puts);
 	puts("Done. Now booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/i386/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/i386/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/i386/boot/compressed/misc.c
@@ -373,7 +373,7 @@ asmlinkage void decompress_kernel(void *
 
 	makecrc();
 	putstr("Uncompressing Linux... ");
-	gunzip();
+	gunzip(putstr);
 	putstr("Ok, booting the kernel.\n");
 	return;
 }
Index: linux-2.6.21-rc5/arch/m32r/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/m32r/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/m32r/boot/compressed/misc.c
@@ -204,6 +204,6 @@ decompress_kernel(int mmu_on, unsigned c
 
 	makecrc();
 	puts("Uncompressing Linux... ");
-	gunzip();
+	gunzip(puts);
 	puts("Ok, booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/sh/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/sh/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/sh/boot/compressed/misc.c
@@ -236,6 +236,6 @@ void decompress_kernel(void)
 
 	makecrc();
 	puts("Uncompressing Linux... ");
-	gunzip();
+	gunzip(puts);
 	puts("Ok, booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/sh64/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/sh64/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/sh64/boot/compressed/misc.c
@@ -218,7 +218,7 @@ void decompress_kernel(void)
 	makecrc();
 	puts("Uncompressing Linux... ");
 	cache_control(CACHE_ENABLE);
-	gunzip();
+	gunzip(puts);
 	puts("\n");
 
 #if 0
Index: linux-2.6.21-rc5/arch/x86_64/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/x86_64/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/x86_64/boot/compressed/misc.c
@@ -351,7 +351,7 @@ int decompress_kernel(struct moveparams 
 
 	makecrc();
 	putstr(".\nDecompressing Linux...");
-	gunzip();
+	gunzip(putstr);
 	putstr("done.\nBooting the kernel.\n");
 	if (high_loaded) close_output_buffer_if_we_run_high(mv);
 	return high_loaded;
Index: linux-2.6.21-rc5/init/do_mounts_rd.c
===================================================================
--- linux-2.6.21-rc5.orig/init/do_mounts_rd.c
+++ linux-2.6.21-rc5/init/do_mounts_rd.c
@@ -393,6 +393,11 @@ static void __init error(char *x)
 	unzip_error = 1;
 }
 
+static inline void putstr(const char *s) {
+    printk("%s", s);
+    return;
+}
+
 static int __init crd_load(int in_fd, int out_fd)
 {
 	int result;
@@ -418,7 +423,7 @@ static int __init crd_load(int in_fd, in
 		return -1;
 	}
 	makecrc();
-	result = gunzip();
+	result = gunzip(putstr);
 	if (unzip_error)
 		result = 1;
 	kfree(inbuf);
Index: linux-2.6.21-rc5/init/initramfs.c
===================================================================
--- linux-2.6.21-rc5.orig/init/initramfs.c
+++ linux-2.6.21-rc5/init/initramfs.c
@@ -441,6 +441,11 @@ static void __init flush_window(void)
 	outcnt = 0;
 }
 
+static inline void putstr(const char *s) {
+    printk("%s", s);
+    return;
+}
+
 static char * __init unpack_to_rootfs(char *buf, unsigned len, int check_only)
 {
 	int written;
@@ -477,7 +482,7 @@ static char * __init unpack_to_rootfs(ch
 		bytes_out = 0;
 		crc = (ulg)0xffffffffL; /* shift register contents */
 		makecrc();
-		gunzip();
+		gunzip(putstr);
 		if (state != Reset)
 			error("junk in gzipped archive");
 		this_header = saved_offset + inptr;
Index: linux-2.6.21-rc5/lib/inflate.c
===================================================================
--- linux-2.6.21-rc5.orig/lib/inflate.c
+++ linux-2.6.21-rc5/lib/inflate.c
@@ -151,7 +151,7 @@ STATIC int INIT inflate_stored OF((void)
 STATIC int INIT inflate_fixed OF((void));
 STATIC int INIT inflate_dynamic OF((void));
 STATIC int INIT inflate_block OF((int *));
-STATIC int INIT inflate OF((void));
+STATIC int INIT inflate OF((void (*)(const char *)));
 
 
 /* The inflate algorithm uses a sliding 32 K byte window on the uncompressed
@@ -983,7 +983,7 @@ STATIC int INIT inflate_block(
 
 
 
-STATIC int INIT inflate(void)
+STATIC int INIT inflate(void (*putstr)(const char *))
 /* decompress an inflated entry */
 {
   int e;                /* last block flag */
@@ -1000,6 +1000,7 @@ STATIC int INIT inflate(void)
   /* decompress until the last block */
   h = 0;
   do {
+    if(putstr != NULL) putstr("*");
     hufts = 0;
     gzip_mark(&ptr);
     if ((r = inflate_block(&e)) != 0) {
@@ -1093,7 +1094,7 @@ makecrc(void)
 /*
  * Do the uncompression!
  */
-static int INIT gunzip(void)
+static int INIT gunzip(void (*putstr)(const char *))
 {
     uch flags;
     unsigned char magic[2]; /* magic header */
@@ -1157,7 +1158,7 @@ static int INIT gunzip(void)
     }
 
     /* Decompress */
-    if ((res = inflate())) {
+    if ((res = inflate(putstr))) {
 	    switch (res) {
 	    case 0:
 		    break;
#<EOF>

[PATCH 10/16] show-partitions-on-mount-error.diff

[Jan Engelhardt]

Display all possible partitions when the root filesystem is not mounted.
This helps to track spell'o's and missing drivers.

From: David Alan Gilbert, http://lkml.org/lkml/2005/2/26/92

Updated to work with newer kernels.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 block/genhd.c         |   54 ++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/genhd.h |    1 
 init/do_mounts.c      |    7 +++++-
 3 files changed, 61 insertions(+), 1 deletion(-)

Index: linux-2.6.21-rc5/block/genhd.c
===================================================================
--- linux-2.6.21-rc5.orig/block/genhd.c
+++ linux-2.6.21-rc5/block/genhd.c
@@ -215,6 +215,60 @@ struct gendisk *get_gendisk(dev_t dev, i
 	return  kobj ? to_disk(kobj) : NULL;
 }
 
+/*
+ * printk a full list of all partitions - intended for
+ * places where the root filesystem can't be mounted and thus
+ * to give the victim some idea of what went wrong
+ */
+void printk_all_partitions(void)
+{
+	int n;
+        struct gendisk* sgp;
+	mutex_lock(&block_subsys_lock);
+
+        /* For each block device... */
+	list_for_each_entry(sgp, &block_subsys.kset.list, kobj.entry) {
+		char buf[BDEVNAME_SIZE];
+	  	/*
+	  	 * Don't show empty devices or things that have been surpressed
+	  	 */
+		if (get_capacity(sgp) &&
+		  !(sgp->flags & GENHD_FL_SUPPRESS_PARTITION_INFO)) {
+			/*
+			 * Note, unlike /proc/partitions I am showing the
+			 * numbers in hex in the same format as the root=
+			 * option
+			 */
+			printk("%02x%02x %10llu %s",
+			       sgp->major, sgp->first_minor,
+			       (unsigned long long)get_capacity(sgp) >> 1,
+			       disk_name(sgp, 0, buf));
+			if ((sgp->driverfs_dev) &&
+			  (sgp->driverfs_dev->driver)) {
+				printk(" driver: %s\n",
+				       sgp->driverfs_dev->driver->name);
+			} else {
+				printk(" (driver?)\n");
+			}
+
+			/* now show the partitions */
+			for (n = 0; n < sgp->minors - 1; ++n) {
+				if (!sgp->part[n])
+					continue;
+				if (sgp->part[n]->nr_sects == 0)
+					continue;
+				printk("  %02x%02x %10llu %s\n",
+				       sgp->major, n + 1 + sgp->first_minor,
+				       (unsigned long long)sgp->part[n]->nr_sects >> 1 ,
+				       disk_name(sgp, n + 1, buf));
+			} /* partition subloop */
+		} /* Non 0 size, not surpressed */
+	} /* Block device loop */
+
+	mutex_unlock(&block_subsys_lock);
+	return;
+}
+
 #ifdef CONFIG_PROC_FS
 /* iterator */
 static void *part_start(struct seq_file *part, loff_t *pos)
Index: linux-2.6.21-rc5/include/linux/genhd.h
===================================================================
--- linux-2.6.21-rc5.orig/include/linux/genhd.h
+++ linux-2.6.21-rc5/include/linux/genhd.h
@@ -413,6 +413,7 @@ char *disk_name (struct gendisk *hd, int
 extern int rescan_partitions(struct gendisk *disk, struct block_device *bdev);
 extern void add_partition(struct gendisk *, int, sector_t, sector_t, int);
 extern void delete_partition(struct gendisk *, int);
+extern void printk_all_partitions(void);
 
 extern struct gendisk *alloc_disk_node(int minors, int node_id);
 extern struct gendisk *alloc_disk(int minors);
Index: linux-2.6.21-rc5/init/do_mounts.c
===================================================================
--- linux-2.6.21-rc5.orig/init/do_mounts.c
+++ linux-2.6.21-rc5/init/do_mounts.c
@@ -7,6 +7,7 @@
 #include <linux/root_dev.h>
 #include <linux/security.h>
 #include <linux/delay.h>
+#include <linux/genhd.h>
 #include <linux/mount.h>
 #include <linux/device.h>
 
@@ -307,17 +308,21 @@ retry:
 	        /*
 		 * Allow the user to distinguish between failed sys_open
 		 * and bad superblock on root device.
+		 * and give them a list of the available devices
 		 */
 #ifdef CONFIG_BLOCK
 		__bdevname(ROOT_DEV, b);
 #endif
 		printk("VFS: Cannot open root device \"%s\" or %s\n",
 				root_device_name, b);
-		printk("Please append a correct \"root=\" boot option\n");
+		printk("Please append a correct \"root=\" boot option; here are the available partitions:\n");
 
+		printk_all_partitions();
 		panic("VFS: Unable to mount root fs on %s", b);
 	}
 
+	printk("List of all partitions:\n");
+	printk_all_partitions();
 	printk("No filesystem could mount root, tried: ");
 	for (p = fs_names; *p; p += strlen(p)+1)
 		printk(" %s", p);
#<EOF>

[PATCH 11/16] samba-eintr-fix.diff

[Jan Engelhardt]

From: Dave Jones
Already posted at http://lkml.org/lkml/2005/7/7/255

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Dave Jones <Dave Jones <davej@redhat.com>

 request.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.21-rc5/fs/smbfs/request.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/smbfs/request.c
+++ linux-2.6.21-rc5/fs/smbfs/request.c
@@ -347,6 +347,7 @@ int smb_add_request(struct smb_request *
 			smb_rput(req);
 		}
 		smb_unlock_server(server);
+		return -EINTR;
 	}
 
 	if (!timeleft) {
#<EOF>

[PATCH 12/16] cifs-use-mutex.diff

[Jan Engelhardt]

Verbatim copy of original mail:

*>>>
>From http://lkml.org/lkml/2006/9/2/86

The recent change to "allow Windows blocking locks to be cancelled
via a CANCEL_LOCK call" introduced a new semaphore in struct
cifsFileInfo, lock_sem.  However, semaphores used as mutexes are
deprecated these days, and there's no reason to add a new one to the
kernel. Therefore, convert lock_sem to a struct mutex (and also fix
one indentation glitch on one of the lines changed anyway).

Compile tested only, since I don't use CIFS.

Signed-off-by: Roland Dreier <roland@digitalvampire.org>
*<<<


My 2¢:
Compile tested. Runtime tested. Did not break.

From: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Roland Dreier <roland@digitalvampire.org>

 cifsglob.h |    2 +-
 dir.c      |    2 +-
 file.c     |   14 +++++++-------
 3 files changed, 9 insertions(+), 9 deletions(-)

Index: linux-2.6.21-rc5/fs/cifs/cifsglob.h
===================================================================
--- linux-2.6.21-rc5.orig/fs/cifs/cifsglob.h
+++ linux-2.6.21-rc5/fs/cifs/cifsglob.h
@@ -311,7 +311,7 @@ struct cifsFileInfo {
 	/* lock scope id (0 if none) */
 	struct file * pfile; /* needed for writepage */
 	struct inode * pInode; /* needed for oplock break */
-	struct semaphore lock_sem;
+	struct mutex lock_mutex;
 	struct list_head llist; /* list of byte range locks we have. */
 	unsigned closePend:1;	/* file is marked to close */
 	unsigned invalidHandle:1;  /* file closed via session abend */
Index: linux-2.6.21-rc5/fs/cifs/dir.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/cifs/dir.c
+++ linux-2.6.21-rc5/fs/cifs/dir.c
@@ -274,7 +274,7 @@ cifs_create(struct inode *inode, struct 
 			pCifsFile->invalidHandle = FALSE;
 			pCifsFile->closePend     = FALSE;
 			init_MUTEX(&pCifsFile->fh_sem);
-			init_MUTEX(&pCifsFile->lock_sem);
+			mutex_init(&pCifsFile->lock_mutex);
 			INIT_LIST_HEAD(&pCifsFile->llist);
 			atomic_set(&pCifsFile->wrtPending,0);
 
Index: linux-2.6.21-rc5/fs/cifs/file.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/cifs/file.c
+++ linux-2.6.21-rc5/fs/cifs/file.c
@@ -48,7 +48,7 @@ static inline struct cifsFileInfo *cifs_
 	private_data->netfid = netfid;
 	private_data->pid = current->tgid;	
 	init_MUTEX(&private_data->fh_sem);
-	init_MUTEX(&private_data->lock_sem);
+	mutex_init(&private_data->lock_mutex);
 	INIT_LIST_HEAD(&private_data->llist);
 	private_data->pfile = file; /* needed for writepage */
 	private_data->pInode = inode;
@@ -508,12 +508,12 @@ int cifs_close(struct inode *inode, stru
 
 		/* Delete any outstanding lock records.
 		   We'll lose them when the file is closed anyway. */
-		down(&pSMBFile->lock_sem);
+		mutex_lock(&pSMBFile->lock_mutex);
 		list_for_each_entry_safe(li, tmp, &pSMBFile->llist, llist) {
 			list_del(&li->llist);
 			kfree(li);
 		}
-		up(&pSMBFile->lock_sem);
+		mutex_unlock(&pSMBFile->lock_mutex);
 
 		write_lock(&GlobalSMBSeslock);
 		list_del(&pSMBFile->flist);
@@ -598,9 +598,9 @@ static int store_file_lock(struct cifsFi
 	li->offset = offset;
 	li->length = len;
 	li->type = lockType;
-	down(&fid->lock_sem);
+	mutex_lock(&fid->lock_mutex);
 	list_add(&li->llist, &fid->llist);
-	up(&fid->lock_sem);
+	mutex_unlock(&fid->lock_mutex);
 	return 0;
 }
 
@@ -757,7 +757,7 @@ int cifs_lock(struct file *file, int cmd
 			struct cifsLockInfo *li, *tmp;
 
 			rc = 0;
-			down(&fid->lock_sem);
+			mutex_lock(&fid->lock_mutex);
 			list_for_each_entry_safe(li, tmp, &fid->llist, llist) {
 				if (pfLock->fl_start <= li->offset &&
 						length >= li->length) {
@@ -771,7 +771,7 @@ int cifs_lock(struct file *file, int cmd
 					kfree(li);
 				}
 			}
-			up(&fid->lock_sem);
+			mutex_unlock(&fid->lock_mutex);
 		}
 	}
 
#<EOF>

[PATCH 13/16] show-pipesize-in-stat.diff

[Jan Engelhardt]

Show the fill status of a pipe (in bytes) when stat'ing one.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 fs/stat.c             |   31 ++++++++++++++++++++++++++++++-
 include/linux/un.h    |    2 ++
 include/net/af_unix.h |    3 +++
 net/unix/af_unix.c    |   10 ++++++++++
 4 files changed, 45 insertions(+), 1 deletion(-)

Index: linux-2.6.21-rc5/fs/stat.c
===================================================================
--- linux-2.6.21-rc5.orig/fs/stat.c
+++ linux-2.6.21-rc5/fs/stat.c
@@ -14,6 +14,10 @@
 #include <linux/namei.h>
 #include <linux/security.h>
 #include <linux/syscalls.h>
+#include <linux/blkdev.h>
+#include <linux/genhd.h>
+#include <linux/pipe_fs_i.h>
+#include <net/af_unix.h>
 #include <linux/pagemap.h>
 
 #include <asm/uaccess.h>
@@ -31,7 +35,32 @@ void generic_fillattr(struct inode *inod
 	stat->atime = inode->i_atime;
 	stat->mtime = inode->i_mtime;
 	stat->ctime = inode->i_ctime;
-	stat->size = i_size_read(inode);
+	stat->size = 0;
+	if (S_ISFIFO(inode->i_mode)) {
+		const struct pipe_inode_info *info = inode->i_pipe;
+		int i;
+		stat->size = 0;
+		if (info != NULL) {
+			for (i = 0; i < PIPE_BUFFERS; ++i) {
+				const struct pipe_buffer *buf = &info->bufs[i];
+				if (buf != NULL && buf->page != NULL)
+					stat->size += buf->len;
+			}
+		}
+	} else if (S_ISSOCK(inode->i_mode)) {
+#ifdef CONFIG_UNIX_MODULE
+		loff_t (*uxsize)(struct inode *) = __symbol_get("unixsock_size");
+		if (uxsize != NULL) {
+			stat->size = uxsize(inode);
+			symbol_put("unixsock_size");
+		}
+#endif
+#if defined(CONFIG_UNIX) && !defined(CONFIG_UNIX_MODULE)
+		stat->size = unixsock_size(inode);
+#endif
+	} else {
+		stat->size = i_size_read(inode);
+	}
 	stat->blocks = inode->i_blocks;
 	stat->blksize = (1 << inode->i_blkbits);
 }
Index: linux-2.6.21-rc5/include/linux/un.h
===================================================================
--- linux-2.6.21-rc5.orig/include/linux/un.h
+++ linux-2.6.21-rc5/include/linux/un.h
@@ -3,6 +3,8 @@
 
 #define UNIX_PATH_MAX	108
 
+#include <linux/socket.h>
+
 struct sockaddr_un {
 	sa_family_t sun_family;	/* AF_UNIX */
 	char sun_path[UNIX_PATH_MAX];	/* pathname */
Index: linux-2.6.21-rc5/include/net/af_unix.h
===================================================================
--- linux-2.6.21-rc5.orig/include/net/af_unix.h
+++ linux-2.6.21-rc5/include/net/af_unix.h
@@ -2,6 +2,7 @@
 #define __LINUX_NET_AFUNIX_H
 
 #include <linux/socket.h>
+#include <linux/types.h>
 #include <linux/un.h>
 #include <linux/mutex.h>
 #include <net/sock.h>
@@ -88,6 +89,8 @@ struct unix_sock {
 };
 #define unix_sk(__sk) ((struct unix_sock *)__sk)
 
+extern loff_t unixsock_size(struct inode *);
+
 #ifdef CONFIG_SYSCTL
 extern int sysctl_unix_max_dgram_qlen;
 extern void unix_sysctl_register(void);
Index: linux-2.6.21-rc5/net/unix/af_unix.c
===================================================================
--- linux-2.6.21-rc5.orig/net/unix/af_unix.c
+++ linux-2.6.21-rc5/net/unix/af_unix.c
@@ -744,6 +744,16 @@ fail:
 	return NULL;
 }
 
+loff_t unixsock_size(struct inode *inode) {
+    struct sock *sk = unix_find_socket_byinode(inode);
+    loff_t eax;
+
+    if(sk == NULL) { return 0; }
+    eax = sk->sk_rcvbuf;
+    sock_put(sk);
+    return eax;
+}
+EXPORT_SYMBOL(unixsock_size);
 
 static int unix_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
 {
#<EOF>

[PATCH 14/16] kconfig-allow-override.diff

[Jan Engelhardt]

Allow config variables in .config to override earlier ones in the same
file. In other words,

	# CONFIG_SECURITY is not defined
	CONFIG_SECURITY=y

will activate it. This makes it a bit easier to do

	(cat original-config myconfig myconfig2 ... >.config)

and run menuconfig as expected.

Already posted at http://lkml.org/lkml/2006/10/25/81
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Sam Ravnborg <sam@ravnborg.org>

 confdata.c |   14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

Index: linux-2.6.21-rc5/scripts/kconfig/confdata.c
===================================================================
--- linux-2.6.21-rc5.orig/scripts/kconfig/confdata.c
+++ linux-2.6.21-rc5/scripts/kconfig/confdata.c
@@ -170,8 +170,7 @@ load:
 					sym->type = S_BOOLEAN;
 			}
 			if (sym->flags & def_flags) {
-				conf_warning("trying to reassign symbol %s", sym->name);
-				break;
+				conf_warning("override: reassigning to symbol %s", sym->name);
 			}
 			switch (sym->type) {
 			case S_BOOLEAN:
@@ -210,8 +209,7 @@ load:
 					sym->type = S_OTHER;
 			}
 			if (sym->flags & def_flags) {
-				conf_warning("trying to reassign symbol %s", sym->name);
-				break;
+				conf_warning("override: reassigning to symbol %s", sym->name);
 			}
 			switch (sym->type) {
 			case S_TRISTATE:
@@ -288,11 +286,9 @@ load:
 				}
 				break;
 			case yes:
-				if (cs->def[def].tri != no) {
-					conf_warning("%s creates inconsistent choice state", sym->name);
-					cs->flags &= ~def_flags;
-				} else
-					cs->def[def].val = sym;
+				if(cs->def[def].tri != no)
+					conf_warning("override: %s turns state choice", sym->name);
+				cs->def[def].val = sym;
 				break;
 			}
 			cs->def[def].tri = E_OR(cs->def[def].tri, sym->def[def].tri);
#<EOF>

[PATCH 15/16] use-regular-eth-suffix.diff

[Jan Engelhardt]

Some radio adapter drivers wrongly(?) name their devices "wlan%d"
instead of "eth%d" (if you ask me, it should be %u - but not today).

Technically, they operate like Ethernet, and in fact, running
`/sbin/ip a` shows "link/ether" instead of "link/ieee80211".
This patch renames them back, but I would appreciate some comment,
explanation or at least link why they actually have wlan%d there.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Jouni Malinen <jkmaline@cc.hut.fi> (hostap)
Cc: Jeroen Vreeken <pe1rxq@amsat.org> (zd1201)

 hostap/hostap_hw.c |    4 ++--
 zd1201.c           |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/net/wireless/hostap/hostap_hw.c
+++ linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c
@@ -81,10 +81,10 @@ static int dtim_period[MAX_PARM_DEVICES]
 module_param_array(dtim_period, int, NULL, 0444);
 MODULE_PARM_DESC(dtim_period, "DTIM period");
 
-static char dev_template[16] = "wlan%d";
+static char dev_template[16] = "eth%d";
 module_param_string(dev_template, dev_template, sizeof(dev_template), 0444);
 MODULE_PARM_DESC(dev_template, "Prefix for network device name (default: "
-		 "wlan%d)");
+		 "eth%d)");
 
 #ifdef final_version
 #define EXTRA_EVENTS_WTERR 0
Index: linux-2.6.21-rc5/drivers/net/wireless/zd1201.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/net/wireless/zd1201.c
+++ linux-2.6.21-rc5/drivers/net/wireless/zd1201.c
@@ -1787,7 +1787,7 @@ static int zd1201_probe(struct usb_inter
 	zd->dev->tx_timeout = zd1201_tx_timeout;
 	zd->dev->set_multicast_list = zd1201_set_multicast;
 	zd->dev->set_mac_address = zd1201_set_mac_address;
-	strcpy(zd->dev->name, "wlan%d");
+	strcpy(zd->dev->name, "eth%d");
 
 	err = zd1201_getconfig(zd, ZD1201_RID_CNFOWNMACADDR, 
 	    zd->dev->dev_addr, zd->dev->addr_len);
#<EOF>

[PATCH 16/16] warn-on-kthread-name-truncation.diff

[Jan Engelhardt]

Andrew Morton noted in http://lkml.org/lkml/2006/6/30/247

	"""We do occasionally hit task_struct.comm[] truncation, when people
	use "too-long-a-name%d" for their kernel thread names."""

This patch warns when such a truncation happens.

Already posted on http://lkml.org/lkml/2006/7/3/93

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Andrew Morton <akpm@linux-foundation.org>

 kthread.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: linux-2.6.21-rc5/kernel/kthread.c
===================================================================
--- linux-2.6.21-rc5.orig/kernel/kthread.c
+++ linux-2.6.21-rc5/kernel/kthread.c
@@ -176,8 +176,11 @@ struct task_struct *kthread_create(int (
 	if (!IS_ERR(create.result)) {
 		va_list args;
 		va_start(args, namefmt);
-		vsnprintf(create.result->comm, sizeof(create.result->comm),
-			  namefmt, args);
+		if(vsnprintf(create.result->comm, sizeof(create.result->comm),
+		  namefmt, args) != strlen(create.result->comm))
+			printk(KERN_WARNING "kthread_create: command name of "
+			  "pid %d truncated to \"%s\"\n", create.result->pid,
+			  create.result->comm);
 		va_end(args);
 	}
 
#<EOF>

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Kyle Moffett]

On Apr 01, 2007, at 14:15:20, Jan Engelhardt wrote:
>
> Make HZ fully configurable through menuconfig.
>
> Already posted at http://lkml.org/lkml/2006/6/18/111

Instead of that, what about something like this instead:  NOTE: I  
know my mailer mangles diffs and this one was hand-edited based on  
Jan's diff from within my mailer so it probably doesn't apply, but  
it's enough to point out the idea:

diff --fast -Ndpru linux-2.6.17-rc6~/kernel/Kconfig.hz linux-2.6.17- 
rc6+/kernel/Kconfig.hz
--- linux-2.6.17-rc6~/kernel/Kconfig.hz	2006-06-06 02:57:02.000000000  
+0200
+++ linux-2.6.17-rc6+/kernel/Kconfig.hz	2006-06-16 17:15:46.884794000  
+0200
@@ -36,10 +36,17 @@
  	 1000 HZ is the preferred choice for desktop systems and other
  	 systems requiring fast interactive responses to events.

+	config HZ_CUSTOM
+		bool "Custom HZ"
+	help
+	 This allows you to specify your own custom timer frequency, if
+	 the default options are not satisfactory for your use.
+
  endchoice

  config HZ
-	int
+	int if !HZ_CUSTOM
+	int "Customized HZ value" if HZ_CUSTOM
  	default 100 if HZ_100
  	default 250 if HZ_250
  	default 1000 if HZ_1000

Re: [PATCH 2/16] vt-pure-colors.diff

[James Bruce]

Jan Engelhardt wrote:
> Have the Linux kernel set a new VGA palette for the first 16 colors.
> The new values reduce the saturation (white component) and therefore
> increase contrast.
<snip>

While the patch seems fine, this comment is not correct.  The patch is 
decreasing the *brightness* in order to *increase* saturation. 
Saturation[1] is the deepness of a color, not the white component 
(brightness, lightness).

  - Jim Bruce

[1] http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC6

Re: [PATCH 15/16] use-regular-eth-suffix.diff

[Kyle Moffett]

On Apr 01, 2007, at 14:18:12, Jan Engelhardt wrote:
> Some radio adapter drivers wrongly(?) name their devices "wlan%d"  
> instead of "eth%d" (if you ask me, it should be %u - but not today).
>
> Technically, they operate like Ethernet, and in fact, running `/ 
> sbin/ip a` shows "link/ether" instead of "link/ieee80211". This  
> patch renames them back, but I would appreciate some comment,  
> explanation or at least link why they actually have wlan%d there.

NACK.  This has the potential to significantly break backwards- 
compatibility for users of those cards who are not using udev to  
maintain consistent device naming (because they only have a single  
card, for example).  I would recommend against applying it for that  
reason.

Cheers,
Kyle Moffett

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Jan Engelhardt]

On Apr 1 2007 14:39, Kyle Moffett wrote:
>> 
>> Make HZ fully configurable through menuconfig.
>> 
>> Already posted at http://lkml.org/lkml/2006/6/18/111
>
> Instead of that, what about something like this instead:  NOTE: I know my
> mailer mangles diffs and this one was hand-edited based on Jan's diff from
> within my mailer so it probably doesn't apply, but it's enough to point out the
> idea:

> config HZ
> -	int
> +	int if !HZ_CUSTOM
> +	int "Customized HZ value" if HZ_CUSTOM
> default 100 if HZ_100
> default 250 if HZ_250
> default 1000 if HZ_1000

People always come up with new complexities I never thought kconfig
would be able to do. Nice stuff. I'll take up on your idea and
incorporate it right away.

But I would have to ask: Why do we need 100/250/300/1000 if there is
anyway an input field for the user to enter - s/he should read the
help text for Known Good values, should not s/he?


Jan
-- 

Re: [PATCH 14/16] kconfig-allow-override.diff

[Sam Ravnborg]

This part of kconfig is taken care of by Roman Zippel.
Kept the full mail for his reference.

	Sam

On Sun, Apr 01, 2007 at 08:17:32PM +0200, Jan Engelhardt wrote:
> 
> Allow config variables in .config to override earlier ones in the same
> file. In other words,
> 
> 	# CONFIG_SECURITY is not defined
> 	CONFIG_SECURITY=y
> 
> will activate it. This makes it a bit easier to do
> 
> 	(cat original-config myconfig myconfig2 ... >.config)
> 
> and run menuconfig as expected.
> 
> Already posted at http://lkml.org/lkml/2006/10/25/81
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> 
>  confdata.c |   14 +++++---------
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> Index: linux-2.6.21-rc5/scripts/kconfig/confdata.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/scripts/kconfig/confdata.c
> +++ linux-2.6.21-rc5/scripts/kconfig/confdata.c
> @@ -170,8 +170,7 @@ load:
>  					sym->type = S_BOOLEAN;
>  			}
>  			if (sym->flags & def_flags) {
> -				conf_warning("trying to reassign symbol %s", sym->name);
> -				break;
> +				conf_warning("override: reassigning to symbol %s", sym->name);
>  			}
>  			switch (sym->type) {
>  			case S_BOOLEAN:
> @@ -210,8 +209,7 @@ load:
>  					sym->type = S_OTHER;
>  			}
>  			if (sym->flags & def_flags) {
> -				conf_warning("trying to reassign symbol %s", sym->name);
> -				break;
> +				conf_warning("override: reassigning to symbol %s", sym->name);
>  			}
>  			switch (sym->type) {
>  			case S_TRISTATE:
> @@ -288,11 +286,9 @@ load:
>  				}
>  				break;
>  			case yes:
> -				if (cs->def[def].tri != no) {
> -					conf_warning("%s creates inconsistent choice state", sym->name);
> -					cs->flags &= ~def_flags;
> -				} else
> -					cs->def[def].val = sym;
> +				if(cs->def[def].tri != no)
> +					conf_warning("override: %s turns state choice", sym->name);
> +				cs->def[def].val = sym;
>  				break;
>  			}
>  			cs->def[def].tri = E_OR(cs->def[def].tri, sym->def[def].tri);
> #<EOF>

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Kyle Moffett]

On Apr 01, 2007, at 14:42:59, Jan Engelhardt wrote:
> But I would have to ask: Why do we need 100/250/300/1000 if there  
> is anyway an input field for the user to enter - s/he should read  
> the help text for Known Good values, should not s/he?

Actually, probably what should be done is make the "HZ_CUSTOM" option  
depend on EXPERIMENTAL/ 
EMBEDDED/"EXPERT"/"I_KNOW_WHAT_THE_HELL_IM_DOING" or some other  
equivalent option, because a wrong choice for HZ has the potential to  
really screw up a system.  For example, 10000+ would make most  
systems spend a significant portion of their time processing timer  
interrupts and context switches, and less than 100 or so would make  
the system seem jerky.  The point is to encourage the average kernel  
builder not to change from one of the default options unless they  
really know what they're doing.

Cheers,
Kyle Moffett

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Jan Engelhardt]

On Apr 1 2007 14:52, Kyle Moffett wrote:
>
> On Apr 01, 2007, at 14:42:59, Jan Engelhardt wrote:
>> But I would have to ask: Why do we need 100/250/300/1000 if there
>> is anyway an input field for the user to enter - s/he should read
>> the help text for Known Good values, should not s/he?
>
> Actually, probably what should be done is make the "HZ_CUSTOM"
> option depend on EXPERIMENTAL / EMBEDDED / "EXPERT" /
> "I_KNOW_WHAT_THE_HELL_IM_DOING" or some other equivalent option,

EXPERIMENTAL is most often enabled by distributors.
And we are still missing our much-needed CONFIG_EXPERT :-(

> because a wrong choice for HZ has the potential to really screw up
> a system.  For example, 10000+ would make most systems spend a
> significant portion of their time processing timer interrupts and

Point taken. Ehm, I already once tried making a 10000-Hz kernel
around 2.6.13-15 or so. It did not compile because some header files had
#error directives for HZ >= 1536. (jiffies.h:33 if you want
to know.) IIRC there also was another place somewhere in networking
code that #errors out at >8192.


Jan
-- 

Re: [PATCH 08/16] console-printk-level.diff

[Randy Dunlap]

On Sun, 1 Apr 2007 20:15:27 +0200 (MEST) Jan Engelhardt wrote:

> 
> Allow the printk level to be set using a "conlevel=" parameter.
> (Or is there already a different bootoption that does the same thing?)

Yes, there's "loglevel", as well as
"debug", "quiet", and "ignore_loglevel".


> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> 
>  printk.c |    9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> Index: linux-2.6.21-rc5/kernel/printk.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/kernel/printk.c
> +++ linux-2.6.21-rc5/kernel/printk.c
> @@ -747,6 +747,15 @@ void resume_console(void)
>  }
>  #endif /* CONFIG_DISABLE_CONSOLE_SUSPEND */
>  
> +static __init int set_conlevel(char *str)
> +{
> +	if(*str >= '0' && *str <= '9')
> +		*console_printk = *str - '0';

s/*console_printk/console_loglevel/


> +	return 1;
> +}
> +
> +__setup("conlevel=", set_conlevel);

s/conlevel/loglevel/

> +
>  /**
>   * acquire_console_sem - lock the console system for exclusive use.
>   *

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 11/16] samba-eintr-fix.diff

[Dave Jones]

On Sun, Apr 01, 2007 at 08:16:22PM +0200, Jan Engelhardt wrote:
 > 
 > From: Dave Jones
 > Already posted at http://lkml.org/lkml/2005/7/7/255

I had to stop and think if this was an April 1st :)
Back in 2005 it seemed I had a strong enough stomach
to wade through smbfs for some unknown reason.
These days like many others, I wish someone would
just put the thing out of its misery.

In Fedora we switched it off (in about 2005 iirc)
in favor of using cifs, which for the most part
is a drop-in replacement.  There still remain 1-2
corner cases where it doesn't work iirc, but
the situation is a lot better than it used to be.

As to whether the patch is worthwhile/correct..
I really don't know.  I posted it back then in the hopes
that someone smbfs-savvy would pop up and review it.
As you can see from the archive, no-one did.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH 14/16] kconfig-allow-override.diff

[Randy Dunlap]

On Sun, 1 Apr 2007 20:44:41 +0200 Sam Ravnborg wrote:

> This part of kconfig is taken care of by Roman Zippel.
> Kept the full mail for his reference.
> 
> 	Sam

I certainly want this.


> On Sun, Apr 01, 2007 at 08:17:32PM +0200, Jan Engelhardt wrote:
> > 
> > Allow config variables in .config to override earlier ones in the same
> > file. In other words,
> > 
> > 	# CONFIG_SECURITY is not defined
> > 	CONFIG_SECURITY=y
> > 
> > will activate it. This makes it a bit easier to do
> > 
> > 	(cat original-config myconfig myconfig2 ... >.config)
> > 
> > and run menuconfig as expected.
> > 
> > Already posted at http://lkml.org/lkml/2006/10/25/81
> > Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > 
> >  confdata.c |   14 +++++---------
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> > 
> > Index: linux-2.6.21-rc5/scripts/kconfig/confdata.c
> > ===================================================================
> > --- linux-2.6.21-rc5.orig/scripts/kconfig/confdata.c
> > +++ linux-2.6.21-rc5/scripts/kconfig/confdata.c
> > @@ -170,8 +170,7 @@ load:
> >  					sym->type = S_BOOLEAN;
> >  			}
> >  			if (sym->flags & def_flags) {
> > -				conf_warning("trying to reassign symbol %s", sym->name);
> > -				break;
> > +				conf_warning("override: reassigning to symbol %s", sym->name);
> >  			}
> >  			switch (sym->type) {
> >  			case S_BOOLEAN:
> > @@ -210,8 +209,7 @@ load:
> >  					sym->type = S_OTHER;
> >  			}
> >  			if (sym->flags & def_flags) {
> > -				conf_warning("trying to reassign symbol %s", sym->name);
> > -				break;
> > +				conf_warning("override: reassigning to symbol %s", sym->name);
> >  			}
> >  			switch (sym->type) {
> >  			case S_TRISTATE:
> > @@ -288,11 +286,9 @@ load:
> >  				}
> >  				break;
> >  			case yes:
> > -				if (cs->def[def].tri != no) {
> > -					conf_warning("%s creates inconsistent choice state", sym->name);
> > -					cs->flags &= ~def_flags;
> > -				} else
> > -					cs->def[def].val = sym;
> > +				if(cs->def[def].tri != no)
> > +					conf_warning("override: %s turns state choice", sym->name);
> > +				cs->def[def].val = sym;
> >  				break;
> >  			}
> >  			cs->def[def].tri = E_OR(cs->def[def].tri, sym->def[def].tri);
> > #<EOF>


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 11/16] samba-eintr-fix.diff

[Jan Engelhardt]

On Apr 1 2007 15:09, Dave Jones wrote:
>On Sun, Apr 01, 2007 at 08:16:22PM +0200, Jan Engelhardt wrote:

> > From: Dave Jones
> > Already posted at http://lkml.org/lkml/2005/7/7/255
>
>I had to stop and think if this was an April 1st :)

Read the mail entitled "[PATCH 0/16] Assorted patches".

>As to whether the patch is worthwhile/correct..
>I really don't know.  I posted it back then in the hopes
>that someone smbfs-savvy would pop up and review it.
>As you can see from the archive, no-one did.

It seems to have been resent once, 7 days after you:
	http://lkml.org/lkml/2005/7/15/231

At that time, I had experienced strange copy failures ("No such file or 
directory") while the directory being copied was not modified. With the 
patch, I at least got EINTR instead of ENOENT, which I think made cp 
think once more to retry.


Jan
-- 

[PATCH]

[Kyle Moffett]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really  
strong
warning attached to it (and a shorter CONFIG_EXPERT variable for use in
Kconfig files where it's a PITA to type out the full name)

Signed-off-by: Kyle Moffett <mrmacman_g4@mac.com>

---

Since my mailer tends to mangle patches I've attached this one


[-- Attachment #2: config_expert.patch.txt --]
[-- Type: text/plain, Size: 1609 bytes --]

Index: linux-2.6.20.1/init/Kconfig
===================================================================
--- linux-2.6.20.1.orig/init/Kconfig
+++ linux-2.6.20.1/init/Kconfig
@@ -40,6 +40,35 @@
 	you say Y here, you will be offered the choice of using features or
 	drivers that are currently considered to be in the alpha-test phase.
 
+config I_KNOW_WHAT_THE_HELL_I_AM_DOING
+	bool "Prompt for config options which will break your computer"
+	---help---
+	  Some kernel developers sometimes need to tune kernel parameters
+	  outside of their normal limits.  Without complete knowledge of
+	  exactly what you are doing you are likely to corrupt the laws of
+	  physics and destroy the universe (well, not quite, but you'll
+	  certainly corrupt your data and crash your box).  If you really
+	  know what you're doing and accept that if it breaks you get to
+	  keep the pieces, then go ahead and enable this option.
+	  
+	  NOTICE:  Bug reports where this option is turned on in the kernel
+	  config will be: (not necessarily in this order)
+	    1)  Laughed at hysterically
+	    2)  Made much fun of
+	    3)  Ridiculed until we're red in the face
+	    4)  Ignored
+	  
+	  WARNING:  If you are building a kernel for a distribution, DO NOT
+	  TURN THIS OPTION ON!!!  Instead you should submit a patch which
+	  adds a new safe value to the list of possibilities for the config
+	  option you're interested in.  Otherwise your users might have a
+	  hard time getting kernel support on the LKML.
+
+config EXPERT
+	bool
+	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING
+	default y
+
 config BROKEN
 	bool
 

Re: [PATCH 11/16] samba-eintr-fix.diff

[Dave Jones]

On Sun, Apr 01, 2007 at 09:28:03PM +0200, Jan Engelhardt wrote:
 > 
 > On Apr 1 2007 15:09, Dave Jones wrote:
 > >On Sun, Apr 01, 2007 at 08:16:22PM +0200, Jan Engelhardt wrote:
 > 
 > > > From: Dave Jones
 > > > Already posted at http://lkml.org/lkml/2005/7/7/255
 > >
 > >I had to stop and think if this was an April 1st :)
 > 
 > Read the mail entitled "[PATCH 0/16] Assorted patches".

That's what happens when you read inbox before mailing list folders :)

 > >As to whether the patch is worthwhile/correct..
 > >I really don't know.  I posted it back then in the hopes
 > >that someone smbfs-savvy would pop up and review it.
 > >As you can see from the archive, no-one did.
 > 
 > It seems to have been resent once, 7 days after you:
 > 	http://lkml.org/lkml/2005/7/15/231

Hmm, with no changelog. I wonder if JA was hitting that bug
and independantly came up with that patch, or was just
resubmitting on my behalf.

 > At that time, I had experienced strange copy failures ("No such file or 
 > directory") while the directory being copied was not modified. With the 
 > patch, I at least got EINTR instead of ENOENT, which I think made cp 
 > think once more to retry.

I suppose we could throw it in -mm and see if anyone screams. Andrew?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH]

[Jan Engelhardt]

On Apr 1 2007 15:42, Kyle Moffett wrote:

>Date: Sun, 1 Apr 2007 15:42:09 -0400
>From: Kyle Moffett <mrmacman_g4@mac.com>
>To: Jan Engelhardt <jengelh@linux01.gwdg.de>
>Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
>    Alan Cox <alan@lxorguk.ukuu.org.uk>, Sam Ravnborg <sam@ravnborg.org>,
>    Andrew Morton <akpm@osdl.org>
>Subject: [PATCH]
>
> Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really strong
> warning attached to it (and a shorter CONFIG_EXPERT variable for use in
> Kconfig files where it's a PITA to type out the full name)

Do it like Linus Torvalds and Marissa Mayer and get a better mailer :-D

Index: linux-2.6.20.1/init/Kconfig
===================================================================
--- linux-2.6.20.1.orig/init/Kconfig
+++ linux-2.6.20.1/init/Kconfig
@@ -40,6 +40,35 @@
 	you say Y here, you will be offered the choice of using features or
 	drivers that are currently considered to be in the alpha-test phase.
 
+config I_KNOW_WHAT_THE_HELL_I_AM_DOING

Let's just hope kconfig does not bust the stack.
Perhaps we could shorten that: I_KNOW_WTF_I_AM_DOING

+	bool "Prompt for config options which will break your computer"

s/will break (.*)/could break $1 if done wrong/;

+	---help---
+	  Some kernel developers sometimes need to tune kernel parameters
+	  outside of their normal limits.  Without complete knowledge of
+	  exactly what you are doing you are likely to corrupt the laws of
+	  physics and destroy the universe (well, not quite, but you'll
+	  certainly corrupt your data and crash your box).  If you really
+	  know what you're doing and accept that if it breaks you get to
+	  keep the pieces, then go ahead and enable this option.
+	  
+	  NOTICE:  Bug reports where this option is turned on in the kernel
+	  config will be: (not necessarily in this order)
+	    1)  Laughed at hysterically
+	    2)  Made much fun of
+	    3)  Ridiculed until we're red in the face
+	    4)  Ignored
+	  
+	  WARNING:  If you are building a kernel for a distribution, DO NOT
+	  TURN THIS OPTION ON!!!  Instead you should submit a patch which
+	  adds a new safe value to the list of possibilities for the config
+	  option you're interested in.  Otherwise your users might have a
+	  hard time getting kernel support on the LKML.
+
+config EXPERT
+	bool
+	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING
+	default y
+
 config BROKEN
 	bool

Given that, I hope the number of options dependent on CONFIG_EXPERT will 
outnumber those depending on CONFIG_I_KNOW_WTF_I_AM_DOING.

If you want my answer: not-so-ACK, move the text to CONFIG_EXPERT and 
let's stay sane for the next 366 days until next April 01.



Jan
-- 

Re: [PATCH] Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable

[Kyle Moffett]

On Apr 01, 2007, at 15:42:09, Kyle Moffett wrote:
> Since my mailer tends to mangle patches I've attached this one

Gah, I complain about my mailer mangling patches and then it's me  
that mangles the patch.  Sorry for forgetting a subject line.

Cheers,
Kyle Moffett

Re: [PATCH]

[Kyle Moffett]

On Apr 01, 2007, at 15:47:18, Jan Engelhardt wrote:
> +config I_KNOW_WHAT_THE_HELL_I_AM_DOING
>
> Let's just hope kconfig does not bust the stack.
> Perhaps we could shorten that: I_KNOW_WTF_I_AM_DOING

Ah, good point, but I think it fits.

> +	bool "Prompt for config options which will break your computer"
>
> s/will break (.*)/could break $1 if done wrong/;

Well, we've had problems in the past where people turn on options  
under CONFIG_EXPERIMENTAL or CONFIG_EMBEDDED and it breaks in exactly  
the specified fashion and they complain on LKML.  The point of this  
is to expose kconfig tunables which a "normal" kconfig user would get  
wrong 99% of the time and would break in obscure ways.  For example,  
the "CONFIG_MULTITHREAD_PCI_PROBE" option, if it was re-added for  
more tinkering, could go under this option.

> +config EXPERT
> +	bool
> +	depends on I_KNOW_WHAT_THE_HELL_I_AM_DOING
> +	default y
>
> Given that, I hope the number of options dependent on CONFIG_EXPERT  
> will outnumber those depending on CONFIG_I_KNOW_WTF_I_AM_DOING.

Ah, see, due to the magic of kconfig language this does not show up  
as a separate option (no text for the "bool") identifier.  It's just  
an alias for I_KNOW_WHAT_THE_HELL_I_AM_DOING to make it easier to use  
in other Kconfig files ("depends EXPERT && SOME_OPTION!=n &&  
ANOTHER_OPTION") instead of s/EXPERT/I_KNOW_WHAT_THE_HELL_I_AM_DOING/g.

> If you want my answer: not-so-ACK, move the text to CONFIG_EXPERT  
> and let's stay sane for the next 366 days until next April 01.

:-D

Cheers,
Kyle Moffett

Re: [PATCH 07/16] kconfig-dynamic-frequency.diff

[Robert P. J. Day]

On Sun, 1 Apr 2007, Kyle Moffett wrote:

> On Apr 01, 2007, at 14:42:59, Jan Engelhardt wrote:

> ... The point is to encourage the average kernel builder not to
> change from one of the default options unless they really know what
> they're doing.

conversely, if someone truly wants to set a kernel config option to
some outrageous value, they should have that freedom.  it's called
"playing."

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: [PATCH]

[Andi Kleen]

Kyle Moffett <mrmacman_g4@mac.com> writes:

> Add a CONFIG_I_KNOW_WHAT_THE_HELL_I_AM_DOING variable with a really
> strong
> warning attached to it (and a shorter CONFIG_EXPERT variable for use in
> Kconfig files where it's a PITA to type out the full name)

When you know what you're doing you can just patch then Kconfig files.
IMHO that's better than this.

-Andi

Re: [PATCH 15/16] use-regular-eth-suffix.diff

[Jouni Malinen]

On Sun, Apr 01, 2007 at 08:18:12PM +0200, Jan Engelhardt wrote:

> Some radio adapter drivers wrongly(?) name their devices "wlan%d"
> instead of "eth%d" (if you ask me, it should be %u - but not today).

> Technically, they operate like Ethernet, and in fact, running
> `/sbin/ip a` shows "link/ether" instead of "link/ieee80211".

The address may look like wired Ethernet (both are based on IEEE 802
standards), but IEEE 802.11 does not behave like IEEE 802.3. For
example, one cannot send frames with a foreign source address in client
mode when using IEEE 802.11 which is clearly different from wired
Ethernet. IEEE 802.11 interfaces (in client mode) cannot be bridged at
layer 2 in the same way as wired Ethernet interfaces could.

> This patch renames them back, but I would appreciate some comment,
> explanation or at least link why they actually have wlan%d there.

Renames _back_? No it doesn't. Host AP driver has never used eth%d as
the interface name template

> Index: linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c
> -static char dev_template[16] = "wlan%d";
> +static char dev_template[16] = "eth%d";

NAK. Host AP driver has been using wlan%d for close to seven years and I
see no reason to change it now. This will just cause problems for users.
If someone wants to rename the interface to something else, they can do
it with number of different ways from user space. The kernel default
should not be changed at this point.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 12/16] cifs-use-mutex.diff

[Roland Dreier]

Thanks for resurrecting this.  My original email to the CIFS
maintainer got dropped somewhere, but I think this patch is probably
still a good idea.
-- 
Roland Dreier  <roland@digitalvampire.org>  GPG Key: 1024D/E0EEFAC0
Fingerprint:     A89F B5E9 C185 F34D BD50  4009 37E2 25CC E0EE FAC0

 Sending >500KB attachments is forbidden by the Geneva Convention.
        Your country may be at risk if you fail to comply.

Re: [PATCH 3/16] vt-underline-color.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:14:14 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

>  static u8 vgacon_build_attr(struct vc_data *c, u8 color, u8 intensity,
> -			    u8 blink, u8 underline, u8 reverse);
> +			    u8 blink, u8 underline, u8 reverse, u8);

ug.  It's better to include the names of the parameters, IMO.  But mixing
the two styles like this is nuts.

Happily, the declaration is unneeded anyway, so I'll just delete it.

Re: [PATCH 5/16] fix-kthread-niceness.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:14:40 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> Fix kevent's childs priority greedy-ness. Such tasks were always scheduled
> at nice level -5 and, at that time, udev stole us the CPU time with -5.
> 
> Already posted at http://lkml.org/lkml/2005/1/10/85
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> Cc: Chris Wright <chrisw@sous-sol.org>
> 
>  kmod.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6.21-rc5/kernel/kmod.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/kernel/kmod.c
> +++ linux-2.6.21-rc5/kernel/kmod.c
> @@ -165,6 +165,7 @@ static int ____call_usermodehelper(void 
>  
>  	/* We can run anywhere, unlike our parent keventd(). */
>  	set_cpus_allowed(current, CPU_MASK_ALL);
> +	set_user_nice(current, 0);
>  
>  	retval = -EPERM;
>  	if (current->fs->root)
> #<EOF>

-ETOOOBSCURE.

--- a/kernel/kmod.c~fix-kthread-nicenessdiff-fix
+++ a/kernel/kmod.c
@@ -163,6 +163,11 @@ static int ____call_usermodehelper(void 
 
 	/* We can run anywhere, unlike our parent keventd(). */
 	set_cpus_allowed(current, CPU_MASK_ALL);
+
+	/*
+	 * Our parent is keventd, which runs with elevated scheduling priority.
+	 * Avoid propagating that into the userspace child.
+	 */
 	set_user_nice(current, 0);
 
 	retval = -EPERM;
_

Re: [PATCH 10/16] show-partitions-on-mount-error.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:15:53 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> 
> Display all possible partitions when the root filesystem is not mounted.
> This helps to track spell'o's and missing drivers.
> 
> From: David Alan Gilbert, http://lkml.org/lkml/2005/2/26/92
> 
> Updated to work with newer kernels.
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> 
> +void printk_all_partitions(void)

I made this __init.

Re: [PATCH 10/16] show-partitions-on-mount-error.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:15:53 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> Display all possible partitions when the root filesystem is not mounted.
> This helps to track spell'o's and missing drivers.

It would be nice to include a sample of the resulting output for people
to review.

Re: [PATCH 11/16] samba-eintr-fix.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:16:22 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> 
> From: Dave Jones
> Already posted at http://lkml.org/lkml/2005/7/7/255
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> Cc: Dave Jones <Dave Jones <davej@redhat.com>
> 
>  request.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6.21-rc5/fs/smbfs/request.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/fs/smbfs/request.c
> +++ linux-2.6.21-rc5/fs/smbfs/request.c
> @@ -347,6 +347,7 @@ int smb_add_request(struct smb_request *
>  			smb_rput(req);
>  		}
>  		smb_unlock_server(server);
> +		return -EINTR;
>  	}
>  
>  	if (!timeleft) {
> #<EOF>

This can return -EINTR if timeleft == 0 && !signal_pending(), which seems
wrong.

Re: [PATCH 13/16] show-pipesize-in-stat.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:17:24 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> 
> Show the fill status of a pipe (in bytes) when stat'ing one.
> 

Is this useful?  It seems rather an obscure thing, and we generally need a
good reason to go adding Linux-specific goodies to standard system calls
like this.  What do "other operating systems" do here?

> -	stat->size = i_size_read(inode);
> +	stat->size = 0;
> +	if (S_ISFIFO(inode->i_mode)) {
> +		const struct pipe_inode_info *info = inode->i_pipe;
> +		int i;
> +		stat->size = 0;
> +		if (info != NULL) {
> +			for (i = 0; i < PIPE_BUFFERS; ++i) {
> +				const struct pipe_buffer *buf = &info->bufs[i];
> +				if (buf != NULL && buf->page != NULL)
> +					stat->size += buf->len;
> +			}
> +		}
> +	} else if (S_ISSOCK(inode->i_mode)) {
> +#ifdef CONFIG_UNIX_MODULE
> +		loff_t (*uxsize)(struct inode *) = __symbol_get("unixsock_size");
> +		if (uxsize != NULL) {
> +			stat->size = uxsize(inode);
> +			symbol_put("unixsock_size");
> +		}
> +#endif
> +#if defined(CONFIG_UNIX) && !defined(CONFIG_UNIX_MODULE)
> +		stat->size = unixsock_size(inode);
> +#endif
> +	} else {
> +		stat->size = i_size_read(inode);
> +	}

That's a bit fugly.

> +loff_t unixsock_size(struct inode *inode) {
> +    struct sock *sk = unix_find_socket_byinode(inode);
> +    loff_t eax;
> +
> +    if(sk == NULL) { return 0; }
> +    eax = sk->sk_rcvbuf;
> +    sock_put(sk);
> +    return eax;
> +}
> +EXPORT_SYMBOL(unixsock_size);

That's wildly incorrect coding style, and it doesn't use tabs.

Re: [PATCH 16/16] warn-on-kthread-name-truncation.diff

[Andrew Morton]

On Sun, 1 Apr 2007 20:18:22 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> Andrew Morton noted in http://lkml.org/lkml/2006/6/30/247
> 
> 	"""We do occasionally hit task_struct.comm[] truncation, when people
> 	use "too-long-a-name%d" for their kernel thread names."""
> 
> This patch warns when such a truncation happens.
> 
> Already posted on http://lkml.org/lkml/2006/7/3/93
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> 
>  kthread.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.21-rc5/kernel/kthread.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/kernel/kthread.c
> +++ linux-2.6.21-rc5/kernel/kthread.c
> @@ -176,8 +176,11 @@ struct task_struct *kthread_create(int (
>  	if (!IS_ERR(create.result)) {
>  		va_list args;
>  		va_start(args, namefmt);
> -		vsnprintf(create.result->comm, sizeof(create.result->comm),
> -			  namefmt, args);
> +		if(vsnprintf(create.result->comm, sizeof(create.result->comm),
> +		  namefmt, args) != strlen(create.result->comm))
> +			printk(KERN_WARNING "kthread_create: command name of "
> +			  "pid %d truncated to \"%s\"\n", create.result->pid,
> +			  create.result->comm);
>  		va_end(args);
>  	}

I'm not sure that it's a big enough problem to go adding code for, really.

Re: [PATCH 13/16] show-pipesize-in-stat.diff

[Jan Engelhardt]

On Apr 1 2007 22:58, Andrew Morton wrote:
>On Sun, 1 Apr 2007 20:17:24 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
>> Show the fill status of a pipe (in bytes) when stat'ing one.
>
>Is this useful?  It seems rather an obscure thing, and we generally need a
>good reason to go adding Linux-specific goodies to standard system calls
>like this.  What do "other operating systems" do here?

Other OS seem to always show 0, as Linux does usually. So I do not think
programs actually rely on it having any specific value.
I thought adding pipesize might be helpful in dianosing pipe cases, akin to
Miklos's procfs-fdinfo patch for regular files.

>> +		}
>> +	} else if (S_ISSOCK(inode->i_mode)) {
>> +#ifdef CONFIG_UNIX_MODULE
>> +		loff_t (*uxsize)(struct inode *) = __symbol_get("unixsock_size");
>> +		if (uxsize != NULL) {
>> +			stat->size = uxsize(inode);
>> +			symbol_put("unixsock_size");
>> +		}
>> +#endif
>> +#if defined(CONFIG_UNIX) && !defined(CONFIG_UNIX_MODULE)
>> +		stat->size = unixsock_size(inode);
>> +#endif
>> +	} else {
>> +		stat->size = i_size_read(inode);
>> +	}
>
>That's a bit fugly.

Drop for now.

>> +loff_t unixsock_size(struct inode *inode) {
>> +    struct sock *sk = unix_find_socket_byinode(inode);
>> +    loff_t eax;
>> +
>> +    if(sk == NULL) { return 0; }
>> +    eax = sk->sk_rcvbuf;
>> +    sock_put(sk);
>> +    return eax;
>> +}
>> +EXPORT_SYMBOL(unixsock_size);
>
>That's wildly incorrect coding style, and it doesn't use tabs.

Which means I something really went wrong, because I knew I went through it for
cleanup.

Re: [PATCH 2/16] vt-pure-colors.diff

[Antonino A. Daplas]

On Sun, 2007-04-01 at 20:14 +0200, Jan Engelhardt wrote:
> Have the Linux kernel set a new VGA palette for the first 16 colors.
> The new values reduce the saturation (white component) and therefore
> increase contrast.
> 
> Already posted once: http://lkml.org/lkml/2006/1/15/149
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> 
>  vt.c |   12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> Index: linux-2.6.21-rc5/drivers/char/vt.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/drivers/char/vt.c
> +++ linux-2.6.21-rc5/drivers/char/vt.c
> @@ -927,12 +927,12 @@ unsigned char color_table[] = { 0, 4, 2,
>  				       8,12,10,14, 9,13,11,15 };
>  
>  /* the default colour table, for VGA+ colour systems */
> -int default_red[] = {0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,
> -    0x55,0xff,0x55,0xff,0x55,0xff,0x55,0xff};
> -int default_grn[] = {0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,
> -    0x55,0x55,0xff,0xff,0x55,0x55,0xff,0xff};
> -int default_blu[] = {0x00,0x00,0x00,0x00,0xaa,0xaa,0xaa,0xaa,
> -    0x55,0x55,0x55,0x55,0xff,0xff,0xff,0xff};
> +int default_red[] =
> +{0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,0x55,0xff,0x00,0xff,0x00,0xff,0x00,0xff};
> +int default_grn[] =
> +{0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,0x55,0x00,0xff,0xff,0x00,0x00,0xff,0xff};
> +int default_blu[] =
> +{0x00,0x00,0x00,0x00,0x90,0xaa,0xaa,0xaa,0x55,0x00,0x00,0x00,0xff,0xff,0xff,0xff};
>  

Not too sure about this, the default palette is based on ANSI/ECMA
standards (at least for the first 8 colors). Also, this will have subtle
effects on the 16-color logo. Since your first patch already allows us
to change the palette, let's leave the default alone.

 
Tony

Re: [PATCH 1/16] vt-sysfs-for-colors.diff

[Antonino A. Daplas]

On Sun, 2007-04-01 at 20:13 +0200, Jan Engelhardt wrote:
> Allow for the palette to be exposed and changed via sysfs. A call to
> /usr/bin/reset will slurp the new definitions in for the current
> console.
> 

I like this. The escape sequences to change the palette does not stay
permanently.

Tony

Re: [PATCH 16/16] warn-on-kthread-name-truncation.diff

[Jan Engelhardt]

On Apr 1 2007 23:00, Andrew Morton wrote:
>On Sun, 1 Apr 2007 20:18:22 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
>I'm not sure that it's a big enough problem to go adding code for, really.

No, not really. If there are any kthread spawners that do exceed the limit,
I would have probably gotten a message by now over the last handful of kernel
releases. So everything seems clear.


Jan
-- 

Re: [PATCH 3/16] vt-underline-color.diff

[Antonino A. Daplas]

On Sun, 2007-04-01 at 20:14 +0200, Jan Engelhardt wrote:
> Add color support to the "underline" and "italic" attributes as in
> OpenBSD/NetBSD-style (vt220) and xterm.

The italic attribute is indeed part of ANSI standard, though not widely
implemented. Fbcon (monochrome mode) already supports inverse,
underline, and bold. I'll try to implement italics (if I can) too if
this gets in.

> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Acked-by: Antonino Daplas <adaplas@gmail.com>

Tony

Re: [PATCH 10/16] show partitions on mount error

[Jan Engelhardt]

Hi,


On Apr 1 2007 22:47, Andrew Morton wrote:
>On Sun, 1 Apr 2007 20:15:53 +0200 (MEST) Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>> 
>> Display all possible partitions when the root filesystem is not mounted.
>> This helps to track spell'o's and missing drivers.
>> 
>> +void printk_all_partitions(void)
>
>I made this __init.

Seems reasonable.
I have done some additional cleanups, see patch below.


>It would be nice to include a sample of the resulting output for people
>to review.

Loaded with PXELINUX...

	LABEL l
		KERNEL bzImage
		APPEND root=/dev/foobar

or root=/dev/sdb both produce:

[...]
VFS: Cannot open root device "foobar" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
0800    8388608 sda driver: sd
  0801     192748 sda1
  0802    8193150 sda2
0810    4194304 sdb driver: sd
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

With root=/dev/sdb, the list of possible filesystems is also displayed
(a patch that was merged a (long)while back).


---

Integrated __init annotation, and deindented the loop by one level.
Replaces original patch.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

Index: linux-2.6.21-rc5/block/genhd.c
===================================================================
--- linux-2.6.21-rc5.orig/block/genhd.c
+++ linux-2.6.21-rc5/block/genhd.c
@@ -215,6 +215,59 @@ struct gendisk *get_gendisk(dev_t dev, i
 	return  kobj ? to_disk(kobj) : NULL;
 }
 
+/*
+ * printk a full list of all partitions - intended for
+ * places where the root filesystem can't be mounted and thus
+ * to give the victim some idea of what went wrong
+ */
+void __init printk_all_partitions(void)
+{
+	int n;
+	struct gendisk *sgp;
+	mutex_lock(&block_subsys_lock);
+
+	/* For each block device... */
+	list_for_each_entry(sgp, &block_subsys.kset.list, kobj.entry) {
+		char buf[BDEVNAME_SIZE];
+		/*
+		 * Don't show empty devices or things that have been surpressed
+		 */
+		if (get_capacity(sgp) == 0 ||
+		  (sgp->flags & GENHD_FL_SUPPRESS_PARTITION_INFO))
+			continue;
+
+		/*
+		 * Note, unlike /proc/partitions, I am showing the numbers in
+		 * hex - the same format as the root= option takes.
+		 */
+		printk("%02x%02x %10llu %s",
+		       sgp->major, sgp->first_minor,
+		       (unsigned long long)get_capacity(sgp) >> 1,
+		       disk_name(sgp, 0, buf));
+		if (sgp->driverfs_dev != NULL &&
+		  sgp->driverfs_dev->driver != NULL)
+			printk(" driver: %s\n",
+			       sgp->driverfs_dev->driver->name);
+		else
+			printk(" (driver?)\n");
+
+		/* now show the partitions */
+		for (n = 0; n < sgp->minors - 1; ++n) {
+			if (sgp->part[n] == NULL)
+				continue;
+			if (sgp->part[n]->nr_sects == 0)
+				continue;
+			printk("  %02x%02x %10llu %s\n",
+			       sgp->major, n + 1 + sgp->first_minor,
+			       (unsigned long long)sgp->part[n]->nr_sects >> 1,
+			       disk_name(sgp, n + 1, buf));
+		} /* partition subloop */
+	} /* Block device loop */
+
+	mutex_unlock(&block_subsys_lock);
+	return;
+}
+
 #ifdef CONFIG_PROC_FS
 /* iterator */
 static void *part_start(struct seq_file *part, loff_t *pos)
Index: linux-2.6.21-rc5/include/linux/genhd.h
===================================================================
--- linux-2.6.21-rc5.orig/include/linux/genhd.h
+++ linux-2.6.21-rc5/include/linux/genhd.h
@@ -413,6 +413,7 @@ char *disk_name (struct gendisk *hd, int
 extern int rescan_partitions(struct gendisk *disk, struct block_device *bdev);
 extern void add_partition(struct gendisk *, int, sector_t, sector_t, int);
 extern void delete_partition(struct gendisk *, int);
+extern void printk_all_partitions(void);
 
 extern struct gendisk *alloc_disk_node(int minors, int node_id);
 extern struct gendisk *alloc_disk(int minors);
Index: linux-2.6.21-rc5/init/do_mounts.c
===================================================================
--- linux-2.6.21-rc5.orig/init/do_mounts.c
+++ linux-2.6.21-rc5/init/do_mounts.c
@@ -7,6 +7,7 @@
 #include <linux/root_dev.h>
 #include <linux/security.h>
 #include <linux/delay.h>
+#include <linux/genhd.h>
 #include <linux/mount.h>
 #include <linux/device.h>
 
@@ -307,17 +308,21 @@ retry:
 	        /*
 		 * Allow the user to distinguish between failed sys_open
 		 * and bad superblock on root device.
+		 * and give them a list of the available devices
 		 */
 #ifdef CONFIG_BLOCK
 		__bdevname(ROOT_DEV, b);
 #endif
 		printk("VFS: Cannot open root device \"%s\" or %s\n",
 				root_device_name, b);
-		printk("Please append a correct \"root=\" boot option\n");
+		printk("Please append a correct \"root=\" boot option; here are the available partitions:\n");
 
+		printk_all_partitions();
 		panic("VFS: Unable to mount root fs on %s", b);
 	}
 
+	printk("List of all partitions:\n");
+	printk_all_partitions();
 	printk("No filesystem could mount root, tried: ");
 	for (p = fs_names; *p; p += strlen(p)+1)
 		printk(" %s", p);
#<EOF>

Re: [PATCH 2/16] vt-pure-colors.diff

[Jan Engelhardt]

On Apr 2 2007 14:49, Antonino A. Daplas wrote:
>
>Not too sure about this, the default palette is based on ANSI/ECMA
>standards (at least for the first 8 colors). Also, this will have subtle
>effects on the 16-color logo. Since your first patch already allows us
>to change the palette, let's leave the default alone.

Ok.
But to note: xterm and anything graphical (including MS Windows)
uses the anti-pale color (255,0,0) instead of (255,170,170).


Jan
-- 

[PATCH 17/16] Do not reset UTF8 on terminal reset

[Jan Engelhardt]

On Apr 2 2007 14:49, Antonino A. Daplas wrote:
>On Sun, 2007-04-01 at 20:13 +0200, Jan Engelhardt wrote:
>
>> Allow for the palette to be exposed and changed via sysfs. A call to
>> /usr/bin/reset will slurp the new definitions in for the current
>> console.
>
>I like this. The escape sequences to change the palette does not stay
>permanently.

As much as you like it, there is a slight problem with it. Linux will
currently throw virtual consoles out of UTF8 mode when reset is called.

Also see:
	http://lkml.org/lkml/2005/5/17/289
	http://lkml.org/lkml/2005/5/17/297

These posts argue about terminfo being the culprit. But how can terminfo 
be at fault, when `echo -en "\ec"` triggers it too?

Since I am in a patch mood, here's my stance/patch, which is compile and 
run tested and behaves as expected (both with `echo` and `reset`).

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Daniel Jacobowitz <dan@debian.org>
Cc: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
Obsoletes: https://bugzilla.novell.com/show_bug.cgi?id=225853

Index: linux-2.6.21-rc5/drivers/char/vt.c
===================================================================
--- linux-2.6.21-rc5.orig/drivers/char/vt.c
+++ linux-2.6.21-rc5/drivers/char/vt.c
@@ -1518,7 +1518,6 @@ static void reset_terminal(struct vc_dat
 	vc->vc_charset		= 0;
 	vc->vc_need_wrap	= 0;
 	vc->vc_report_mouse	= 0;
-	vc->vc_utf		= 0;
 	vc->vc_utf_count	= 0;
 
 	vc->vc_disp_ctrl	= 0;
#<EOF>

Re: [PATCH 2/16] vt-pure-colors.diff

[Antonino A. Daplas]

On Mon, 2007-04-02 at 09:04 +0200, Jan Engelhardt wrote:
> On Apr 2 2007 14:49, Antonino A. Daplas wrote:
> >
> >Not too sure about this, the default palette is based on ANSI/ECMA
> >standards (at least for the first 8 colors). Also, this will have subtle
> >effects on the 16-color logo. Since your first patch already allows us
> >to change the palette, let's leave the default alone.
> 
> Ok.
> But to note: xterm and anything graphical (including MS Windows)
> uses the anti-pale color (255,0,0) instead of (255,170,170).

Actually, what threw me off was index 4 in default_blu, which has a
value of 0x90.  This looks weird to me, but I guess that is a typo. I
really have nothing against using 0, 0, 255 instead of 170, 170, 255 in
the intense version of the first 8.

Tony 

Re: [PATCH 2/16] vt-pure-colors.diff

[Jan Engelhardt]

On Apr 2 2007 15:50, Antonino A. Daplas wrote:
>On Mon, 2007-04-02 at 09:04 +0200, Jan Engelhardt wrote:
>> On Apr 2 2007 14:49, Antonino A. Daplas wrote:
>> >
>> >Not too sure about this, the default palette is based on ANSI/ECMA
>> >standards (at least for the first 8 colors). Also, this will have subtle
>> >effects on the 16-color logo. Since your first patch already allows us
>> >to change the palette, let's leave the default alone.
>> 
>> Ok.
>> But to note: xterm and anything graphical (including MS Windows)
>> uses the anti-pale color (255,0,0) instead of (255,170,170).
>
>Actually, what threw me off was index 4 in default_blu, which has a
>value of 0x90.  This looks weird to me, but I guess that is a typo. I
>really have nothing against using 0, 0, 255 instead of 170, 170, 255 in
>the intense version of the first 8.

That one is a psychological thing. :-) People like blue backgrounds, because a
green or red one would not really fit as a bg color for Midnight Commander,
pine and your-favorite-editor. So you choose blue because it fits nicely. (See
http://img81.imageshack.us/img81/8858/blueqj6.png for an example, and compare
with http://img81.imageshack.us/img81/7498/reddm1.png and
http://img142.imageshack.us/img142/8470/greennq2.png for counterexamples. Even
a bright blue (0,0,192) is still better than red/green, the reason being that
blue is much less percepted by the eye than green or red. You will find various
formulas on the 'net that will convert from color to grayscale - these formulas
have the 'perception' levels, which are, summarized, 76*r, 151*g, 26*b on a 255
scale.) Personally I find the regular blue (0,0,170/0xA0) a little too bright
so I turned it down to 0x90. Adjust for your preference.


Jan
-- 

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Antonino A. Daplas]

On Mon, 2007-04-02 at 09:31 +0200, Jan Engelhardt wrote:
> On Apr 2 2007 14:49, Antonino A. Daplas wrote:
> >On Sun, 2007-04-01 at 20:13 +0200, Jan Engelhardt wrote:
> >
> >> Allow for the palette to be exposed and changed via sysfs. A call to
> >> /usr/bin/reset will slurp the new definitions in for the current
> >> console.
> >
> >I like this. The escape sequences to change the palette does not stay
> >permanently.
> 
> As much as you like it, there is a slight problem with it. Linux will
> currently throw virtual consoles out of UTF8 mode when reset is called.
> 
> Also see:
> 	http://lkml.org/lkml/2005/5/17/289
> 	http://lkml.org/lkml/2005/5/17/297
> 
> These posts argue about terminfo being the culprit. But how can terminfo 
> be at fault, when `echo -en "\ec"` triggers it too?
> 
> Since I am in a patch mood, here's my stance/patch, which is compile and 
> run tested and behaves as expected (both with `echo` and `reset`).

Tested and works here too.

Tony

Re: [PATCH 13/16] show-pipesize-in-stat.diff

[Eric Dumazet]

On Sun, 1 Apr 2007 20:17:24 +0200 (MEST)
Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:

> 
> Show the fill status of a pipe (in bytes) when stat'ing one.
> 
> Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
> 
>  fs/stat.c             |   31 ++++++++++++++++++++++++++++++-
>  include/linux/un.h    |    2 ++
>  include/net/af_unix.h |    3 +++
>  net/unix/af_unix.c    |   10 ++++++++++
>  4 files changed, 45 insertions(+), 1 deletion(-)

Please dont do that, adding uggly tests in generic_fillattr()

The following patch does the right thing for pipes, I let you doing the same for sockets...

[PATCH] : fill the size of pipes

Instead of reporting 0 in size when stating() a pipe, we give the number of queued bytes. This might avoid using ioctl(FIONREAD) to get this information.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
---
--- linux-2.6.21-rc5-mm3/fs/pipe.c
+++ linux-2.6.21-rc5-mm3/fs/pipe.c
@@ -570,27 +570,34 @@ bad_pipe_w(struct file *filp, const char
 	return -EBADF;
 }
 
+static int pipe_size(struct inode *inode)
+{
+	struct pipe_inode_info *pipe;
+	int count, buf, nrbufs;
+
+	mutex_lock(&inode->i_mutex);
+	pipe = inode->i_pipe;
+	count = 0;
+	buf = pipe->curbuf;
+	nrbufs = pipe->nrbufs;
+	while (--nrbufs >= 0) {
+		count += pipe->bufs[buf].len;
+		buf = (buf+1) & (PIPE_BUFFERS-1);
+	}
+	mutex_unlock(&inode->i_mutex);
+	return count;
+}
+
 static int
 pipe_ioctl(struct inode *pino, struct file *filp,
 	   unsigned int cmd, unsigned long arg)
 {
 	struct inode *inode = filp->f_path.dentry->d_inode;
-	struct pipe_inode_info *pipe;
-	int count, buf, nrbufs;
+	int count;
 
 	switch (cmd) {
 		case FIONREAD:
-			mutex_lock(&inode->i_mutex);
-			pipe = inode->i_pipe;
-			count = 0;
-			buf = pipe->curbuf;
-			nrbufs = pipe->nrbufs;
-			while (--nrbufs >= 0) {
-				count += pipe->bufs[buf].len;
-				buf = (buf+1) & (PIPE_BUFFERS-1);
-			}
-			mutex_unlock(&inode->i_mutex);
-
+			count = pipe_size(inode);
 			return put_user(count, (int __user *)arg);
 		default:
 			return -EINVAL;
@@ -908,6 +915,20 @@ static struct dentry_operations pipefs_d
 	.d_dname	= pipefs_dname,
 };
 
+int pipe_getattr(struct vfsmount *mnt, struct dentry *dentry,
+		   struct kstat *stat)
+{
+	struct inode *inode = dentry->d_inode;
+
+	generic_fillattr(inode, stat);
+	stat->size = pipe_size(inode);
+	return 0;
+}
+
+const struct inode_operations pipe_inode_operations = {
+	.getattr = pipe_getattr,
+};
+
 static struct inode * get_pipe_inode(void)
 {
 	struct inode *inode = new_inode(pipe_mnt->mnt_sb);
@@ -921,6 +942,7 @@ static struct inode * get_pipe_inode(voi
 		goto fail_iput;
 	inode->i_pipe = pipe;
 
+	inode->i_op = &pipe_inode_operations;
 	pipe->readers = pipe->writers = 1;
 	inode->i_fop = &rdwr_pipe_fops;
 

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Paul LeoNerd Evans]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

On Mon, Apr 02, 2007 at 09:31:37AM +0200, Jan Engelhardt wrote:
> Also see:
> 	http://lkml.org/lkml/2005/5/17/289
> 	http://lkml.org/lkml/2005/5/17/297
> 
> These posts argue about terminfo being the culprit. But how can terminfo 
> be at fault, when `echo -en "\ec"` triggers it too?
> 
> Since I am in a patch mood, here's my stance/patch, which is compile and 
> run tested and behaves as expected (both with `echo` and `reset`).

...

> Index: linux-2.6.21-rc5/drivers/char/vt.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/drivers/char/vt.c
> +++ linux-2.6.21-rc5/drivers/char/vt.c
> @@ -1518,7 +1518,6 @@ static void reset_terminal(struct vc_dat
>  	vc->vc_charset		= 0;
>  	vc->vc_need_wrap	= 0;
>  	vc->vc_report_mouse	= 0;
> -	vc->vc_utf		= 0;
>  	vc->vc_utf_count	= 0;
>  
>  	vc->vc_disp_ctrl	= 0;
> #<EOF>

Is it OK to do that? I recall when I was originally looking at the code
I didn't want to just remove that line, because it looked like that was
being used to first initialise the vc* structure when it is created, as
well as reset it every time. Doesn't this leave vc->vc_utf uninitialised
when a new VC is allocated?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Mon, 2007-04-02 at 12:26 +0100, Paul LeoNerd Evans wrote:
> On Mon, Apr 02, 2007 at 09:31:37AM +0200, Jan Engelhardt wrote:
> > Also see:
> > 	http://lkml.org/lkml/2005/5/17/289
> > 	http://lkml.org/lkml/2005/5/17/297
> > 
> > These posts argue about terminfo being the culprit. But how can terminfo 
> > be at fault, when `echo -en "\ec"` triggers it too?
> > 
> > Since I am in a patch mood, here's my stance/patch, which is compile and 
> > run tested and behaves as expected (both with `echo` and `reset`).
> 
> ...
> 
> > Index: linux-2.6.21-rc5/drivers/char/vt.c
> > ===================================================================
> > --- linux-2.6.21-rc5.orig/drivers/char/vt.c
> > +++ linux-2.6.21-rc5/drivers/char/vt.c
> > @@ -1518,7 +1518,6 @@ static void reset_terminal(struct vc_dat
> >  	vc->vc_charset		= 0;
> >  	vc->vc_need_wrap	= 0;
> >  	vc->vc_report_mouse	= 0;
> > -	vc->vc_utf		= 0;
> >  	vc->vc_utf_count	= 0;
> >  
> >  	vc->vc_disp_ctrl	= 0;
> > #<EOF>
> 
> Is it OK to do that? I recall when I was originally looking at the code
> I didn't want to just remove that line, because it looked like that was
> being used to first initialise the vc* structure when it is created, as
> well as reset it every time. Doesn't this leave vc->vc_utf uninitialised
> when a new VC is allocated?

That's true.  We can move the line vc->vc_utf = 0; in vc_init()
instead. 

Tony


[-- Attachment #2: vc_reset.diff --]
[-- Type: text/x-patch, Size: 576 bytes --]

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 1bbb45b..23e4432 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -1497,7 +1497,6 @@ static void reset_terminal(struct vc_dat
 	vc->vc_charset		= 0;
 	vc->vc_need_wrap	= 0;
 	vc->vc_report_mouse	= 0;
-	vc->vc_utf		= 0;
 	vc->vc_utf_count	= 0;
 
 	vc->vc_disp_ctrl	= 0;
@@ -2590,6 +2589,7 @@ static void vc_init(struct vc_data *vc, 
 	vc->vc_rows = rows;
 	vc->vc_size_row = cols << 1;
 	vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
+	vc->vc_utf = 0;
 
 	set_origin(vc);
 	vc->vc_pos = vc->vc_origin;

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Paul LeoNerd Evans]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On Mon, Apr 02, 2007 at 07:44:13PM +0800, Antonino A. Daplas wrote:
> > Is it OK to do that? I recall when I was originally looking at the code
> > I didn't want to just remove that line, because it looked like that was
> > being used to first initialise the vc* structure when it is created, as
> > well as reset it every time. Doesn't this leave vc->vc_utf uninitialised
> > when a new VC is allocated?
> 
> That's true.  We can move the line vc->vc_utf = 0; in vc_init()
> instead. 

...

> @@ -2590,6 +2589,7 @@ static void vc_init(struct vc_data *vc, 
>  	vc->vc_rows = rows;
>  	vc->vc_size_row = cols << 1;
>  	vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
> +	vc->vc_utf = 0;
>  
>  	set_origin(vc);
>  	vc->vc_pos = vc->vc_origin;

While we're on that subject, did you take a look at my original mail?
The intent with that patch was to allow system policy to state all new
VCs are UTF-8-enabled by default. I feel that in 2007 this should be the
default setting.

Would it therefore be possible to have

   vc->vc_utf = some_default;

where some_default comes maybe from a sysctl or some other configurable
source? Or maybe even have a compiletime option?

This would get around many bugs. For example, on boot, "unicode_start"
can only set utf8 mode on the existing VCs 1 to 6. If X11 fails to
start, debian nicely runs me the XKeepsCrashing program, which offers to
show me logs and the like. It reads the locale, en_GB.UTF-8 and
determines we're in UTF-8 mode, so outputs Unicode linedrawing
characters for dialogs. Unfortunately, we're on VC7 which doesn't have
UTF-8 mode turned on, so much mess results.

It would be nice if the kernel's default UTF-8 mode for new VCs could be
synched to whatever local policy was regarding locale.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Antonino A. Daplas]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Mon, 2007-04-02 at 12:54 +0100, Paul LeoNerd Evans wrote:
> On Mon, Apr 02, 2007 at 07:44:13PM +0800, Antonino A. Daplas wrote:
> > > Is it OK to do that? I recall when I was originally looking at the code
> > > I didn't want to just remove that line, because it looked like that was
> > > being used to first initialise the vc* structure when it is created, as
> > > well as reset it every time. Doesn't this leave vc->vc_utf uninitialised
> > > when a new VC is allocated?
> > 
> > That's true.  We can move the line vc->vc_utf = 0; in vc_init()
> > instead. 
> 
> ...
> 
> > @@ -2590,6 +2589,7 @@ static void vc_init(struct vc_data *vc, 
> >  	vc->vc_rows = rows;
> >  	vc->vc_size_row = cols << 1;
> >  	vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
> > +	vc->vc_utf = 0;
> >  
> >  	set_origin(vc);
> >  	vc->vc_pos = vc->vc_origin;
> 
> While we're on that subject, did you take a look at my original mail?

I did not actually.

> The intent with that patch was to allow system policy to state all new
> VCs are UTF-8-enabled by default. I feel that in 2007 this should be the
> default setting.
> 
> Would it therefore be possible to have
> 
>    vc->vc_utf = some_default;
> 
> where some_default comes maybe from a sysctl or some other configurable
> source? Or maybe even have a compiletime option?
> 
> This would get around many bugs. For example, on boot, "unicode_start"
> can only set utf8 mode on the existing VCs 1 to 6. If X11 fails to
> start, debian nicely runs me the XKeepsCrashing program, which offers to
> show me logs and the like. It reads the locale, en_GB.UTF-8 and
> determines we're in UTF-8 mode, so outputs Unicode linedrawing
> characters for dialogs. Unfortunately, we're on VC7 which doesn't have
> UTF-8 mode turned on, so much mess results.
> 
> It would be nice if the kernel's default UTF-8 mode for new VCs could be
> synched to whatever local policy was regarding locale.

How about this? This should allow us to reset the terminal without
affecting utf, and also allows setting of a global utf default that can
be set via boot option or sysfs:

echo 1 > /sys/module/vt/parameters/default_utf

Tony




> 

[-- Attachment #2: utf.diff --]
[-- Type: text/x-patch, Size: 913 bytes --]

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 1bbb45b..b9b3247 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -157,6 +157,8 @@ static void blank_screen_t(unsigned long
 static void set_palette(struct vc_data *vc);
 
 static int printable;		/* Is console ready for printing? */
+static int default_utf;
+module_param(default_utf, int, S_IRUGO | S_IWUSR);
 
 /*
  * ignore_poke: don't unblank the screen when things are typed.  This is
@@ -1497,7 +1499,6 @@ static void reset_terminal(struct vc_dat
 	vc->vc_charset		= 0;
 	vc->vc_need_wrap	= 0;
 	vc->vc_report_mouse	= 0;
-	vc->vc_utf		= 0;
 	vc->vc_utf_count	= 0;
 
 	vc->vc_disp_ctrl	= 0;
@@ -2590,6 +2591,7 @@ static void vc_init(struct vc_data *vc, 
 	vc->vc_rows = rows;
 	vc->vc_size_row = cols << 1;
 	vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row;
+	vc->vc_utf = default_utf;
 
 	set_origin(vc);
 	vc->vc_pos = vc->vc_origin;

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Paul LeoNerd Evans]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Mon, Apr 02, 2007 at 08:47:59PM +0800, Antonino A. Daplas wrote:
> How about this? This should allow us to reset the terminal without
> affecting utf, and also allows setting of a global utf default that can
> be set via boot option or sysfs:
> 
> echo 1 > /sys/module/vt/parameters/default_utf

That's almost exactly what my suggestion was :)

(except that mine went into /proc/tty/vt/default_utf8_mode, but anywhere
is good really)

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Jan Engelhardt]

On Apr 2 2007 20:47, Antonino A. Daplas wrote:
>> 
>> It would be nice if the kernel's default UTF-8 mode for new VCs could be
>> synched to whatever local policy was regarding locale.
>
>How about this? This should allow us to reset the terminal without
>affecting utf, and also allows setting of a global utf default that can
>be set via boot option or sysfs:
>
>echo 1 > /sys/module/vt/parameters/default_utf

Might want to call it "default_utf8", but it's just minor.

Tony, if you have a patch, send it along so I can test it under "special local
circumstances" :-)

Jan
-- 

Re: [PATCH 09/16] zlib-decompression-status.diff

[Jörn Engel]

On Sun, 1 April 2007 20:15:42 +0200, Jan Engelhardt wrote:
>  
> +static inline void putstr(const char *s) {
> +    printk("%s", s);
> +    return;
> +}
> +
>  static int __init crd_load(int in_fd, int out_fd)
>  {
>  	int result;
> @@ -418,7 +423,7 @@ static int __init crd_load(int in_fd, in
>  		return -1;
>  	}
>  	makecrc();
> -	result = gunzip();
> +	result = gunzip(putstr);

You are sure this wasn't meant as an April fools joke?  Passing the
address of an inline function certainly has a humorous aspect. ;)

Also, you can remove the "return;" in the void function and possibly
change this bit to match Documentation/CodingStyle.

> +    if(putstr != NULL) putstr("*");

The patch alternately uses puts() and putstr(), which looks rather odd.
Not sure whether that makes sense or not.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

Re: [PATCH 17/16] Do not reset UTF8 on terminal reset

[Pavel Machek]

Hi!

> >> Allow for the palette to be exposed and changed via sysfs. A call to
> >> /usr/bin/reset will slurp the new definitions in for the current
> >> console.
> >
> >I like this. The escape sequences to change the palette does not stay
> >permanently.
> 
> As much as you like it, there is a slight problem with it. Linux will
> currently throw virtual consoles out of UTF8 mode when reset is called.
> 
> Also see:
> 	http://lkml.org/lkml/2005/5/17/289
> 	http://lkml.org/lkml/2005/5/17/297
> 
> These posts argue about terminfo being the culprit. But how can terminfo 
> be at fault, when `echo -en "\ec"` triggers it too?
> 
> Since I am in a patch mood, here's my stance/patch, which is compile and 
> run tested and behaves as expected (both with `echo` and `reset`).

Should not reset actually reset terminal? This introduces
bug/unexpected behaviour...
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 09/16] zlib-decompression-status.diff

[Jan Engelhardt]

Hi,


On Apr 2 2007 19:48, Jörn Engel wrote:
>On Sun, 1 April 2007 20:15:42 +0200, Jan Engelhardt wrote:
>>  
>> +static inline void putstr(const char *s) {
>> +    printk("%s", s);
>> +    return;
>> +}
>> +
>>  static int __init crd_load(int in_fd, int out_fd)
>>  {
>>  	int result;
>> @@ -418,7 +423,7 @@ static int __init crd_load(int in_fd, in
>>  		return -1;
>>  	}
>>  	makecrc();
>> -	result = gunzip();
>> +	result = gunzip(putstr);
>
>You are sure this wasn't meant as an April fools joke?

It actually has use (for my 20 MHz 386 *hug*)

>Passing the address of an inline function certainly has a humorous aspect. ;)

You bet. Well, "inline" is, as far as I hear the voices of the C standard, just
a "hint" to the compiler that this function should be inlined. If it cannot do
that, well, then do not inline it. But you have a point, it gets interesting
when "inline" expands to __attribute__((always_inline)). Well, let's hope that
gcc 'carries the inlining over' into gunzip().

>Also, you can remove the "return;" in the void function and possibly
>change this bit to match Documentation/CodingStyle.

Yup.

>> +    if(putstr != NULL) putstr("*");
>
>The patch alternately uses puts() and putstr(), which looks rather odd.

It is because some arches seem to have a arch-specific "output function"
called puts() try the following:

$ grep -r 'puts(' arch/arm26/
(results)
$ grep -r 'puts(' arch/i386/
(no results)

So yes, I would need some advice what people were thinking here. If it
was not for this arch specific stuff, the putstr() function I added in
lib/ would also be gone and the "*" could be directly printed in
gunzip(), making the extra argument to gunzip superfluous.

The extra putstr() in init/initramfs.c [cf. putstr() in lib/inflate.c]
is also something I did not know how to really do better.

Thoughts are appreciated and stylofixed patch below.
(lib/inflate.c does not even use tabs, what could I possibly do more wrong than
already? :p)


---

Shows some stars during decompression. This is particularly useful on old 386s
where one asterisk is probably printed every second - making the long linux and
initramfs uncompress progress more evident.
Not compile tested outside {i386, x86_64} - don't have other machines.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

 arch/alpha/boot/misc.c                    |    2 +-
 arch/arm/boot/compressed/misc.c           |    4 ++--
 arch/arm26/boot/compressed/misc.c         |    4 ++--
 arch/cris/arch-v10/boot/compressed/misc.c |    2 +-
 arch/cris/arch-v32/boot/compressed/misc.c |    2 +-
 arch/i386/boot/compressed/misc.c          |    2 +-
 arch/m32r/boot/compressed/misc.c          |    2 +-
 arch/sh/boot/compressed/misc.c            |    2 +-
 arch/sh64/boot/compressed/misc.c          |    2 +-
 arch/x86_64/boot/compressed/misc.c        |    2 +-
 init/do_mounts_rd.c                       |    7 ++++++-
 init/initramfs.c                          |    7 ++++++-
 lib/inflate.c                             |   10 ++++++----
 13 files changed, 30 insertions(+), 18 deletions(-)

Index: linux-2.6.21-rc5/arch/alpha/boot/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/alpha/boot/misc.c
+++ linux-2.6.21-rc5/arch/alpha/boot/misc.c
@@ -201,7 +201,7 @@ decompress_kernel(void *output_start,
 
 	makecrc();
 /*	puts("Uncompressing Linux..."); */
-	gunzip();
+	gunzip(NULL);
 /*	puts(" done, booting the kernel.\n"); */
 	return output_ptr;
 }
Index: linux-2.6.21-rc5/arch/arm/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/arm/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/arm/boot/compressed/misc.c
@@ -355,7 +355,7 @@ decompress_kernel(ulg output_start, ulg 
 
 	makecrc();
 	putstr("Uncompressing Linux...");
-	gunzip();
+	gunzip(putstr);
 	putstr(" done, booting the kernel.\n");
 	return output_ptr;
 }
@@ -369,7 +369,7 @@ int main()
 
 	makecrc();
 	putstr("Uncompressing Linux...");
-	gunzip();
+	gunzip(putstr);
 	putstr("done.\n");
 	return 0;
 }
Index: linux-2.6.21-rc5/arch/arm26/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/arm26/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/arm26/boot/compressed/misc.c
@@ -294,7 +294,7 @@ decompress_kernel(ulg output_start, ulg 
 
 	makecrc();
 	puts("Uncompressing Linux...");
-	gunzip();
+	gunzip(puts);
 	puts(" done, booting the kernel.\n");
 	return output_ptr;
 }
@@ -308,7 +308,7 @@ int main()
 
 	makecrc();
 	puts("Uncompressing Linux...");
-	gunzip();
+	gunzip(puts);
 	puts("done.\n");
 	return 0;
 }
Index: linux-2.6.21-rc5/arch/cris/arch-v10/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/cris/arch-v10/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/cris/arch-v10/boot/compressed/misc.c
@@ -267,6 +267,6 @@ decompress_kernel()
 	}
 
 	puts("Uncompressing Linux...\n");
-	gunzip();
+	gunzip(puts);
 	puts("Done. Now booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/cris/arch-v32/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/cris/arch-v32/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/cris/arch-v32/boot/compressed/misc.c
@@ -312,6 +312,6 @@ decompress_kernel()
 	}
 
 	puts("Uncompressing Linux...\n");
-	gunzip();
+	gunzip(puts);
 	puts("Done. Now booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/i386/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/i386/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/i386/boot/compressed/misc.c
@@ -373,7 +373,7 @@ asmlinkage void decompress_kernel(void *
 
 	makecrc();
 	putstr("Uncompressing Linux... ");
-	gunzip();
+	gunzip(putstr);
 	putstr("Ok, booting the kernel.\n");
 	return;
 }
Index: linux-2.6.21-rc5/arch/m32r/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/m32r/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/m32r/boot/compressed/misc.c
@@ -204,6 +204,6 @@ decompress_kernel(int mmu_on, unsigned c
 
 	makecrc();
 	puts("Uncompressing Linux... ");
-	gunzip();
+	gunzip(puts);
 	puts("Ok, booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/sh/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/sh/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/sh/boot/compressed/misc.c
@@ -236,6 +236,6 @@ void decompress_kernel(void)
 
 	makecrc();
 	puts("Uncompressing Linux... ");
-	gunzip();
+	gunzip(puts);
 	puts("Ok, booting the kernel.\n");
 }
Index: linux-2.6.21-rc5/arch/sh64/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/sh64/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/sh64/boot/compressed/misc.c
@@ -218,7 +218,7 @@ void decompress_kernel(void)
 	makecrc();
 	puts("Uncompressing Linux... ");
 	cache_control(CACHE_ENABLE);
-	gunzip();
+	gunzip(puts);
 	puts("\n");
 
 #if 0
Index: linux-2.6.21-rc5/arch/x86_64/boot/compressed/misc.c
===================================================================
--- linux-2.6.21-rc5.orig/arch/x86_64/boot/compressed/misc.c
+++ linux-2.6.21-rc5/arch/x86_64/boot/compressed/misc.c
@@ -351,7 +351,7 @@ int decompress_kernel(struct moveparams 
 
 	makecrc();
 	putstr(".\nDecompressing Linux...");
-	gunzip();
+	gunzip(putstr);
 	putstr("done.\nBooting the kernel.\n");
 	if (high_loaded) close_output_buffer_if_we_run_high(mv);
 	return high_loaded;
Index: linux-2.6.21-rc5/init/do_mounts_rd.c
===================================================================
--- linux-2.6.21-rc5.orig/init/do_mounts_rd.c
+++ linux-2.6.21-rc5/init/do_mounts_rd.c
@@ -393,6 +393,11 @@ static void __init error(char *x)
 	unzip_error = 1;
 }
 
+static void putstr(const char *s)
+{
+	printk("%s", s);
+}
+
 static int __init crd_load(int in_fd, int out_fd)
 {
 	int result;
@@ -418,7 +423,7 @@ static int __init crd_load(int in_fd, in
 		return -1;
 	}
 	makecrc();
-	result = gunzip();
+	result = gunzip(putstr);
 	if (unzip_error)
 		result = 1;
 	kfree(inbuf);
Index: linux-2.6.21-rc5/init/initramfs.c
===================================================================
--- linux-2.6.21-rc5.orig/init/initramfs.c
+++ linux-2.6.21-rc5/init/initramfs.c
@@ -441,6 +441,11 @@ static void __init flush_window(void)
 	outcnt = 0;
 }
 
+static void putstr(const char *s)
+{
+	printk("%s", s);
+}
+
 static char * __init unpack_to_rootfs(char *buf, unsigned len, int check_only)
 {
 	int written;
@@ -477,7 +482,7 @@ static char * __init unpack_to_rootfs(ch
 		bytes_out = 0;
 		crc = (ulg)0xffffffffL; /* shift register contents */
 		makecrc();
-		gunzip();
+		gunzip(putstr);
 		if (state != Reset)
 			error("junk in gzipped archive");
 		this_header = saved_offset + inptr;
Index: linux-2.6.21-rc5/lib/inflate.c
===================================================================
--- linux-2.6.21-rc5.orig/lib/inflate.c
+++ linux-2.6.21-rc5/lib/inflate.c
@@ -151,7 +151,7 @@ STATIC int INIT inflate_stored OF((void)
 STATIC int INIT inflate_fixed OF((void));
 STATIC int INIT inflate_dynamic OF((void));
 STATIC int INIT inflate_block OF((int *));
-STATIC int INIT inflate OF((void));
+STATIC int INIT inflate OF((void (*)(const char *)));
 
 
 /* The inflate algorithm uses a sliding 32 K byte window on the uncompressed
@@ -983,7 +983,7 @@ STATIC int INIT inflate_block(
 
 
 
-STATIC int INIT inflate(void)
+STATIC int INIT inflate(void (*putstr)(const char *))
 /* decompress an inflated entry */
 {
   int e;                /* last block flag */
@@ -1000,6 +1000,8 @@ STATIC int INIT inflate(void)
   /* decompress until the last block */
   h = 0;
   do {
+    if(putstr != NULL)
+      putstr("*");
     hufts = 0;
     gzip_mark(&ptr);
     if ((r = inflate_block(&e)) != 0) {
@@ -1093,7 +1095,7 @@ makecrc(void)
 /*
  * Do the uncompression!
  */
-static int INIT gunzip(void)
+static int INIT gunzip(void (*putstr)(const char *))
 {
     uch flags;
     unsigned char magic[2]; /* magic header */
@@ -1157,7 +1159,7 @@ static int INIT gunzip(void)
     }
 
     /* Decompress */
-    if ((res = inflate())) {
+    if ((res = inflate(putstr))) {
 	    switch (res) {
 	    case 0:
 		    break;
#<EOF>


Jan
-- 

Re: [PATCH 10/16] show-partitions-on-mount-error.diff

[Pavel Machek]

Hi!

>  block/genhd.c         |   54 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/genhd.h |    1 
>  init/do_mounts.c      |    7 +++++-
>  3 files changed, 61 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.21-rc5/block/genhd.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/block/genhd.c
> +++ linux-2.6.21-rc5/block/genhd.c
> @@ -215,6 +215,60 @@ struct gendisk *get_gendisk(dev_t dev, i
>  	return  kobj ? to_disk(kobj) : NULL;
>  }
>  
> +/*
> + * printk a full list of all partitions - intended for
> + * places where the root filesystem can't be mounted and thus
> + * to give the victim some idea of what went wrong
> + */
> +void printk_all_partitions(void)
> +{
> +	int n;
> +        struct gendisk* sgp;
> +	mutex_lock(&block_subsys_lock);

tabs-vs-spaces problem.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 10/16] show-partitions-on-mount-error.diff

[Jan Engelhardt]

On Apr 2 2007 18:59, Pavel Machek wrote in http://lkml.org/lkml/2007/4/3/85:
>
>> + * to give the victim some idea of what went wrong
>> + */
>> +void printk_all_partitions(void)
>> +{
>> +	int n;
>> +        struct gendisk* sgp;
>> +	mutex_lock(&block_subsys_lock);
>
>tabs-vs-spaces problem.

Already fixed and sent out in http://lkml.org/lkml/2007/4/2/75


Jan
-- 

Re: [PATCH 13/16] show-pipesize-in-stat.diff

[Jan Engelhardt]

On Apr 2 2007 12:41, Eric Dumazet wrote:
>
>The following patch does the right thing for pipes, I let you doing
>the same for sockets...

Is struct sock->sk_receive_queue->qlen actually the thing I am
looking for? (Previously, I had struct sock->sk_rcvbuf, which was
obviously wrong.)

Thanks,
Jan
-- 

Re: [PATCH 13/16] show-pipesize-in-stat.diff

[Eric Dumazet]

Jan Engelhardt a écrit :
> On Apr 2 2007 12:41, Eric Dumazet wrote:
>> The following patch does the right thing for pipes, I let you doing
>> the same for sockets...
> 
> Is struct sock->sk_receive_queue->qlen actually the thing I am
> looking for? (Previously, I had struct sock->sk_rcvbuf, which was
> obviously wrong.)
> 

find net | xargs grep -n SIOCINQ

I suspect you will find unix_ioctl() in net/unix/af_unix.c ?

BTW, my patch only worked for pipes, not fifos. Ie pipe(), not 
open("/some/fifo.p", ...)

Re: [PATCH 13/16] show-pipesize-in-stat.diff

[Jan Engelhardt]

Hi,

On Wed, 04 Apr 2007 07:03:55 +0200, Eric Dumazet wrote:
>find net | xargs grep -n SIOCINQ
>I suspect you will find unix_ioctl() in net/unix/af_unix.c ?
>BTW, my patch only worked for pipes, not fifos. Ie pipe(), not 
>open("/some/fifo.p", ...)

Thanks for your patch. There is a question however; why don't you do
  stat->size = pipe_size(inode);
in generic_fill_attr (perhaps wrapped into an if(S_ISFIFO))?


Regards,
Jan
-- 

[PATCH]

[Sergey Shtylyov]

Add myself as a reviewer for the libata PATA drivers -- there has been some
activity in this area still... 8-)
Having been hacking on ATA from the early 90s, I think I deserved this
highly responsible position, at last! :-)

Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>

---
This patch is against the 'master' branch of Damien Le Moal's 'libata.git'
repo.

 MAINTAINERS |    6 ++++++
 1 file changed, 6 insertions(+)

Index: libata/MAINTAINERS
===================================================================
--- libata.orig/MAINTAINERS
+++ libata/MAINTAINERS
@@ -10880,6 +10880,12 @@ T:	git git://git.kernel.org/pub/scm/linu
 F:	drivers/ata/pata_arasan_cf.c
 F:	include/linux/pata_arasan_cf_data.h
 
+LIBATA PATA DRIVERS
+R:	Sergey Shtylyov <s.shtylyov@omp.ru>
+L:	linux-ide@vger.kernel.org
+F:	drivers/ata/ata_*.c
+F:	drivers/ata/pata_*.c
+
 LIBATA PATA FARADAY FTIDE010 AND GEMINI SATA BRIDGE DRIVERS
 M:	Linus Walleij <linus.walleij@linaro.org>
 L:	linux-ide@vger.kernel.org

Re: [PATCH]

[Mauro Carvalho Chehab]

Em Mon, 10 Jul 2017 01:35:11 +0200
armetallica <armetallica@gmail.com> escreveu:

> From 043428d63637a6dd8e52449b73dbb8341885d7e4 Mon Sep 17 00:00:00 2001
> From: Armin Schoenlieb <armetallica@gmail.com>
> Date: Mon, 10 Jul 2017 01:12:52 +0200
> Subject: [PATCH] Staging: media: atomisp2: fixed trailing whitespace error in
>  atomisp_v4l2.c This is a patch to the atomisp_v4l2.c file that fixes up a
>  trailing whitespace error found by the checkpatch.pl tool

Something clearly gets wrong here...

Regards,
Mauro

> 
> Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> index a543def739fc..05d02ebb6d25 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> @@ -1277,13 +1277,13 @@ static int atomisp_pci_probe(struct pci_dev *dev,
>  			(ATOMISP_HW_REVISION_ISP2400
>  			 << ATOMISP_HW_REVISION_SHIFT) |
>  			ATOMISP_HW_STEPPING_B0;
> -#ifdef FIXME			
> +#ifdef FIXME
>  		if (INTEL_MID_BOARD(3, TABLET, BYT, BLK, PRO, CRV2) ||
>  			INTEL_MID_BOARD(3, TABLET, BYT, BLK, ENG, CRV2)) {
>  			isp->dfs = &dfs_config_byt_cr;
>  			isp->hpll_freq = HPLL_FREQ_2000MHZ;
>  		} else
> -#endif		
> +#endif
>  		{
>  			isp->dfs = &dfs_config_byt;
>  			isp->hpll_freq = HPLL_FREQ_1600MHZ;



Thanks,
Mauro

[PATCH]

[armetallica]

>From bb1aac6ae6b21b903d8743712e21aeb1a6b22163 Mon Sep 17 00:00:00 2001
From: Armin Schoenlieb <armetallica@gmail.com>
Date: Mon, 10 Jul 2017 01:52:41 +0200
Subject: [PATCH] staging: unisys: visorbus: fix brace coding style issue in
 visorbus_main.c This is a patch to the visorbus_main.c file that fixes up six
 brace errors found by the checkpatch.pl tool

Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c b/drivers/staging/unisys/visorbus/visorbus_main.c
index 1c785dd19ddd..c56496269fc8 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -270,7 +270,8 @@ static const struct attribute_group *visorbus_channel_groups[] = {
 
 static ssize_t partition_handle_show(struct device *dev,
 				     struct device_attribute *attr,
-				     char *buf) {
+				     char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
 
@@ -280,7 +281,8 @@ static DEVICE_ATTR_RO(partition_handle);
 
 static ssize_t partition_guid_show(struct device *dev,
 				   struct device_attribute *attr,
-				   char *buf) {
+				   char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 
 	return sprintf(buf, "{%pUb}\n", &vdev->partition_uuid);
@@ -289,7 +291,8 @@ static DEVICE_ATTR_RO(partition_guid);
 
 static ssize_t partition_name_show(struct device *dev,
 				   struct device_attribute *attr,
-				   char *buf) {
+				   char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 
 	return sprintf(buf, "%s\n", vdev->name);
@@ -298,7 +301,8 @@ static DEVICE_ATTR_RO(partition_name);
 
 static ssize_t channel_addr_show(struct device *dev,
 				 struct device_attribute *attr,
-				 char *buf) {
+				 char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	u64 addr = visorchannel_get_physaddr(vdev->visorchannel);
 
@@ -308,7 +312,8 @@ static DEVICE_ATTR_RO(channel_addr);
 
 static ssize_t channel_bytes_show(struct device *dev,
 				  struct device_attribute *attr,
-				  char *buf) {
+				  char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	u64 nbytes = visorchannel_get_nbytes(vdev->visorchannel);
 
@@ -318,7 +323,8 @@ static DEVICE_ATTR_RO(channel_bytes);
 
 static ssize_t channel_id_show(struct device *dev,
 			       struct device_attribute *attr,
-			       char *buf) {
+			       char *buf)
+{
 	struct visor_device *vdev = to_visor_device(dev);
 	int len = 0;
 
-- 
2.11.0

RE: [PATCH]

[Kershner, David A]

> -----Original Message-----
> From: armetallica [mailto:armetallica@gmail.com]
> Sent: Sunday, July 9, 2017 7:58 PM
> To: gregkh@linuxfoundation.org
> Cc: *S-Par-Maintainer <SParMaintainer@unisys.com>;
> devel@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Subject: [PATCH]
> 
> From bb1aac6ae6b21b903d8743712e21aeb1a6b22163 Mon Sep 17 00:00:00
> 2001
> From: Armin Schoenlieb <armetallica@gmail.com>
> Date: Mon, 10 Jul 2017 01:52:41 +0200
> Subject: [PATCH] staging: unisys: visorbus: fix brace coding style issue in
>  visorbus_main.c This is a patch to the visorbus_main.c file that fixes up six
>  brace errors found by the checkpatch.pl tool
> 

Thanks for the patch! It looks like I sent up a patch to Greg that addresses this
issue on 6/30/2017:
 
	[PATCH 25/25] staging: unisys: visorbus: fix improper bracket blocks

Also, your patch come in with a subject of just the word [PATCH] and the patch
comment was messed up. I'm not sure how you generated the patch, but you
might want to try it with format-patch and then do a git send-email to yourself
as a dry-run to see if the patch looks OK when you get it.

David Kershner


> Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
> ---
>  drivers/staging/unisys/visorbus/visorbus_main.c | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
> b/drivers/staging/unisys/visorbus/visorbus_main.c
> index 1c785dd19ddd..c56496269fc8 100644
> --- a/drivers/staging/unisys/visorbus/visorbus_main.c
> +++ b/drivers/staging/unisys/visorbus/visorbus_main.c
> @@ -270,7 +270,8 @@ static const struct attribute_group
> *visorbus_channel_groups[] = {
> 
>  static ssize_t partition_handle_show(struct device *dev,
>  				     struct device_attribute *attr,
> -				     char *buf) {
> +				     char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	u64 handle = visorchannel_get_clientpartition(vdev->visorchannel);
> 
> @@ -280,7 +281,8 @@ static DEVICE_ATTR_RO(partition_handle);
> 
>  static ssize_t partition_guid_show(struct device *dev,
>  				   struct device_attribute *attr,
> -				   char *buf) {
> +				   char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
> 
>  	return sprintf(buf, "{%pUb}\n", &vdev->partition_uuid);
> @@ -289,7 +291,8 @@ static DEVICE_ATTR_RO(partition_guid);
> 
>  static ssize_t partition_name_show(struct device *dev,
>  				   struct device_attribute *attr,
> -				   char *buf) {
> +				   char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
> 
>  	return sprintf(buf, "%s\n", vdev->name);
> @@ -298,7 +301,8 @@ static DEVICE_ATTR_RO(partition_name);
> 
>  static ssize_t channel_addr_show(struct device *dev,
>  				 struct device_attribute *attr,
> -				 char *buf) {
> +				 char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	u64 addr = visorchannel_get_physaddr(vdev->visorchannel);
> 
> @@ -308,7 +312,8 @@ static DEVICE_ATTR_RO(channel_addr);
> 
>  static ssize_t channel_bytes_show(struct device *dev,
>  				  struct device_attribute *attr,
> -				  char *buf) {
> +				  char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	u64 nbytes = visorchannel_get_nbytes(vdev->visorchannel);
> 
> @@ -318,7 +323,8 @@ static DEVICE_ATTR_RO(channel_bytes);
> 
>  static ssize_t channel_id_show(struct device *dev,
>  			       struct device_attribute *attr,
> -			       char *buf) {
> +			       char *buf)
> +{
>  	struct visor_device *vdev = to_visor_device(dev);
>  	int len = 0;
> 
> --
> 2.11.0

[PATCH]

[armetallica]

>From 043428d63637a6dd8e52449b73dbb8341885d7e4 Mon Sep 17 00:00:00 2001
From: Armin Schoenlieb <armetallica@gmail.com>
Date: Mon, 10 Jul 2017 01:12:52 +0200
Subject: [PATCH] Staging: media: atomisp2: fixed trailing whitespace error in
 atomisp_v4l2.c This is a patch to the atomisp_v4l2.c file that fixes up a
 trailing whitespace error found by the checkpatch.pl tool

Signed-off-by: Armin Schoenlieb <armetallica@gmail.com>
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index a543def739fc..05d02ebb6d25 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1277,13 +1277,13 @@ static int atomisp_pci_probe(struct pci_dev *dev,
 			(ATOMISP_HW_REVISION_ISP2400
 			 << ATOMISP_HW_REVISION_SHIFT) |
 			ATOMISP_HW_STEPPING_B0;
-#ifdef FIXME			
+#ifdef FIXME
 		if (INTEL_MID_BOARD(3, TABLET, BYT, BLK, PRO, CRV2) ||
 			INTEL_MID_BOARD(3, TABLET, BYT, BLK, ENG, CRV2)) {
 			isp->dfs = &dfs_config_byt_cr;
 			isp->hpll_freq = HPLL_FREQ_2000MHZ;
 		} else
-#endif		
+#endif
 		{
 			isp->dfs = &dfs_config_byt;
 			isp->hpll_freq = HPLL_FREQ_1600MHZ;
-- 
2.11.0

Re: [PATCH]

[Greg KH]

On Tue, Dec 24, 2013 at 09:45:03AM -0600, Evan Hosseini wrote:
> ---
> Staging: android: fix parenthesis coding style issue in alarm-dev.c

What happened to your Subject:?

Also, why put the '---' line here?  That means that git will delete
everything else.

> This is a patch to the alarm-dev.c file that fixes up a
>  parenthesis warning found by the checkpatch.pl tool.
> Signed-off-by: Evan Hosseini <hosse005@umn.edu>

Please put a blank line between the changelog info and the
signed-off-by: line.

> 
> ---
>  drivers/staging/android/alarm-dev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/android/alarm-dev.c b/drivers/staging/android/alarm-dev.c
> index 647694f..893362f 100644
> --- a/drivers/staging/android/alarm-dev.c
> +++ b/drivers/staging/android/alarm-dev.c
> @@ -68,7 +68,6 @@ static struct devalarm alarms[ANDROID_ALARM_TYPE_COUNT];
>   */
>  static int is_wakeup(enum android_alarm_type type)
>  {
> -	return (type == ANDROID_ALARM_RTC_WAKEUP ||
> -		type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP);
> +	return type == ANDROID_ALARM_RTC_WAKEUP ||
> +	  type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP;

This patch doesn't apply to the linux-next tree, as someone else has
already made this change, sorry.

greg k-h

[PATCH]

[Evan Hosseini]

---
Staging: android: fix parenthesis coding style issue in alarm-dev.c
This is a patch to the alarm-dev.c file that fixes up a
 parenthesis warning found by the checkpatch.pl tool.
Signed-off-by: Evan Hosseini <hosse005@umn.edu>

---
 drivers/staging/android/alarm-dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/alarm-dev.c b/drivers/staging/android/alarm-dev.c
index 647694f..893362f 100644
--- a/drivers/staging/android/alarm-dev.c
+++ b/drivers/staging/android/alarm-dev.c
@@ -68,7 +68,6 @@ static struct devalarm alarms[ANDROID_ALARM_TYPE_COUNT];
  */
 static int is_wakeup(enum android_alarm_type type)
 {
-	return (type == ANDROID_ALARM_RTC_WAKEUP ||
-		type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP);
+	return type == ANDROID_ALARM_RTC_WAKEUP ||
+	  type == ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP;
 }
--
1.8.3.2

Re: [PATCH]

[Stefan Richter]

On Mar 04 Stefan Richter wrote:
> CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers
> if CONFIG_EXPERT was set.  But in hindsight, this stuff is far too
> useful to omit it.  So get rid of two #else branches that are only
> going to bitrot otherwise.

Sorry, this was meant to be sent with

    Subject: [PATCH] firewire: ohci: move runtime debug facility out of #ifdef
-- 
Stefan Richter
-=====-===-- --== --=--
http://arcgraph.de/sr/

[PATCH]

[Stefan Richter]

CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers
if CONFIG_EXPERT was set.  But in hindsight, this stuff is far too
useful to omit it.  So get rid of two #else branches that are only
going to bitrot otherwise.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 drivers/firewire/Kconfig |    5 -----
 drivers/firewire/ohci.c  |   20 +-------------------
 2 files changed, 1 insertion(+), 24 deletions(-)

--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -28,11 +28,6 @@ config FIREWIRE_OHCI
 	  To compile this driver as a module, say M here:  The module will be
 	  called firewire-ohci.
 
-config FIREWIRE_OHCI_DEBUG
-	bool
-	depends on FIREWIRE_OHCI
-	default y
-
 config FIREWIRE_SBP2
 	tristate "Storage devices (SBP-2 protocol)"
 	depends on FIREWIRE && SCSI
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -338,8 +338,6 @@ MODULE_PARM_DESC(quirks, "Chip quirks (d
 #define OHCI_PARAM_DEBUG_IRQS		4
 #define OHCI_PARAM_DEBUG_BUSRESETS	8 /* only effective before chip init */
 
-#ifdef CONFIG_FIREWIRE_OHCI_DEBUG
-
 static int param_debug;
 module_param_named(debug, param_debug, int, 0644);
 MODULE_PARM_DESC(debug, "Verbose logging (default = 0"
@@ -520,15 +518,6 @@ static void log_ar_at_event(struct fw_oh
 	}
 }
 
-#else
-
-#define param_debug 0
-static inline void log_irqs(struct fw_ohci *ohci, u32 evt) {}
-static inline void log_selfids(struct fw_ohci *ohci, int generation, int self_id_count) {}
-static inline void log_ar_at_event(struct fw_ohci *ohci, char dir, int speed, u32 *header, int evt) {}
-
-#endif /* CONFIG_FIREWIRE_OHCI_DEBUG */
-
 static inline void reg_write(const struct fw_ohci *ohci, int offset, u32 data)
 {
 	writel(data, ohci->registers + offset);
@@ -1640,17 +1629,10 @@ static void detect_dead_context(struct f
 	u32 ctl;
 
 	ctl = reg_read(ohci, CONTROL_SET(regs));
-	if (ctl & CONTEXT_DEAD) {
-#ifdef CONFIG_FIREWIRE_OHCI_DEBUG
+	if (ctl & CONTEXT_DEAD)
 		dev_err(ohci->card.device,
 			"DMA context %s has stopped, error code: %s\n",
 			name, evts[ctl & 0x1f]);
-#else
-		dev_err(ohci->card.device,
-			"DMA context %s has stopped, error code: %#x\n",
-			name, ctl & 0x1f);
-#endif
-	}
 }
 
 static void handle_dead_contexts(struct fw_ohci *ohci)


-- 
Stefan Richter
-=====-===-- --== --=--
http://arcgraph.de/sr/

[PATCH]

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: fs / ext3: Always unlock updates in ext3_freeze()

In analogy with ext4 make ext3_freeze() always call
journal_unlock_updates() to prevent it from leaving a locked mutex
behind.  Accordingly, modify ext3_unfreeze() so that it doesn't
call journal_unlock_updates() any more.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 fs/ext3/super.c |   39 ++++++++++++++++++---------------------
 1 file changed, 18 insertions(+), 21 deletions(-)

Index: linux/fs/ext3/super.c
===================================================================
--- linux.orig/fs/ext3/super.c
+++ linux/fs/ext3/super.c
@@ -2535,30 +2535,28 @@ static int ext3_sync_fs(struct super_blo
  */
 static int ext3_freeze(struct super_block *sb)
 {
-	int error = 0;
+	int error;
 	journal_t *journal;
 
-	if (!(sb->s_flags & MS_RDONLY)) {
-		journal = EXT3_SB(sb)->s_journal;
+	if (sb->s_flags & MS_RDONLY)
+		return 0;
 
-		/* Now we set up the journal barrier. */
-		journal_lock_updates(journal);
+	journal = EXT3_SB(sb)->s_journal;
 
-		/*
-		 * We don't want to clear needs_recovery flag when we failed
-		 * to flush the journal.
-		 */
-		error = journal_flush(journal);
-		if (error < 0)
-			goto out;
-
-		/* Journal blocked and flushed, clear needs_recovery flag. */
-		EXT3_CLEAR_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
-		error = ext3_commit_super(sb, EXT3_SB(sb)->s_es, 1);
-		if (error)
-			goto out;
-	}
-	return 0;
+	/* Now we set up the journal barrier. */
+	journal_lock_updates(journal);
+
+	/*
+	 * We don't want to clear needs_recovery flag when we failed
+	 * to flush the journal.
+	 */
+	error = journal_flush(journal);
+	if (error < 0)
+		goto out;
+
+	/* Journal blocked and flushed, clear needs_recovery flag. */
+	EXT3_CLEAR_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
+	error = ext3_commit_super(sb, EXT3_SB(sb)->s_es, 1);
 
 out:
 	journal_unlock_updates(journal);
@@ -2577,7 +2575,6 @@ static int ext3_unfreeze(struct super_bl
 		EXT3_SET_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
 		ext3_commit_super(sb, EXT3_SB(sb)->s_es, 1);
 		unlock_super(sb);
-		journal_unlock_updates(EXT3_SB(sb)->s_journal);
 	}
 	return 0;
 }

Re: [PATCH]

[Michal Marek]

On 19.9.2010 20:21, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
>> On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
>>> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
>>> support to link menuconfig with ncursesw library was added.  To compute
>>> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
>>> ncursesw to be used as a replacement ncurses.  However, when checking what
>>> header file to include, we do not check /usr/include/ncursesw directory.
>>>
>>> Add /usr/include/ncursesw to the list of directories that are checked.
>>> With this patch, on my Debian Lenny box with libncursesw5-dev package but
>>> not libncurses5-dev package, I can say "make menuconfig".
>>>
>>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>>
[...]
> 
>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> 
> Thanks; is it my responsibility to follow-up the thread with identical
> patch with updated Subject and with your Ack, hoping somebody in kbuild
> team would pick it up?

I fixed the subject line myself and applied it to kbuild-2.6.git#kconfig.

Thanks,
Michal

Re: [PATCH]

[Sam Ravnborg]

On Sun, Sep 19, 2010 at 11:21:21AM -0700, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
> 
> > On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
> >> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
> >> support to link menuconfig with ncursesw library was added.  To compute
> >> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
> >> ncursesw to be used as a replacement ncurses.  However, when checking what
> >> header file to include, we do not check /usr/include/ncursesw directory.
> >> 
> >> Add /usr/include/ncursesw to the list of directories that are checked.
> >> With this patch, on my Debian Lenny box with libncursesw5-dev package but
> >> not libncurses5-dev package, I can say "make menuconfig".
> >> 
> >> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> >
> > Except for the missing patch subject then it looks OK.
> > Suggested subject:
> > kconfig: fix menuconfig on debian lenny
> 
> Sorry, the missing subject really was sloppy of me, and thanks.
> 
> > Add as this is a fix we should Cc: <stable@kerne.org>?
> 
> I don't think the fix deserves to be in stable.  It does not look like
> 60f33b8 made it possible to use ncursesw on a box like mine so the patch
> is not evan an regression-fix.
OK
> 
> > Acked-by: Sam Ravnborg <sam@ravnborg.org>
> 
> Thanks; is it my responsibility to follow-up the thread with identical
> patch with updated Subject and with your Ack, hoping somebody in kbuild
> team would pick it up?

I assume Michal will pick it up anyway - but if you do it would make
it simpler for him to do so.
So no need..

	Sam

Re: [PATCH]

[Junio C Hamano]

Sam Ravnborg <sam@ravnborg.org> writes:

> On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
>> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
>> support to link menuconfig with ncursesw library was added.  To compute
>> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
>> ncursesw to be used as a replacement ncurses.  However, when checking what
>> header file to include, we do not check /usr/include/ncursesw directory.
>> 
>> Add /usr/include/ncursesw to the list of directories that are checked.
>> With this patch, on my Debian Lenny box with libncursesw5-dev package but
>> not libncurses5-dev package, I can say "make menuconfig".
>> 
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Except for the missing patch subject then it looks OK.
> Suggested subject:
> kconfig: fix menuconfig on debian lenny

Sorry, the missing subject really was sloppy of me, and thanks.

> Add as this is a fix we should Cc: <stable@kerne.org>?

I don't think the fix deserves to be in stable.  It does not look like
60f33b8 made it possible to use ncursesw on a box like mine so the patch
is not evan an regression-fix.

> Acked-by: Sam Ravnborg <sam@ravnborg.org>

Thanks; is it my responsibility to follow-up the thread with identical
patch with updated Subject and with your Ack, hoping somebody in kbuild
team would pick it up?

Re: [PATCH]

[Sam Ravnborg]

On Sat, Sep 18, 2010 at 07:25:32PM -0700, Junio C Hamano wrote:
> In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
> support to link menuconfig with ncursesw library was added.  To compute
> the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
> ncursesw to be used as a replacement ncurses.  However, when checking what
> header file to include, we do not check /usr/include/ncursesw directory.
> 
> Add /usr/include/ncursesw to the list of directories that are checked.
> With this patch, on my Debian Lenny box with libncursesw5-dev package but
> not libncurses5-dev package, I can say "make menuconfig".
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Except for the missing patch subject then it looks OK.

Suggested subject:
kconfig: fix menuconfig on debian lenny

Add as this is a fix we should Cc: <stable@kerne.org>?

Acked-by: Sam Ravnborg <sam@ravnborg.org>

	Sam

[PATCH]

[Junio C Hamano]

In 60f33b8 (kconfig: get rid of stray a.o, support ncursesw, 2006-01-15),
support to link menuconfig with ncursesw library was added.  To compute
the linker command option -l, we check "libncursesw.{so,a,dylib}" to allow
ncursesw to be used as a replacement ncurses.  However, when checking what
header file to include, we do not check /usr/include/ncursesw directory.

Add /usr/include/ncursesw to the list of directories that are checked.
With this patch, on my Debian Lenny box with libncursesw5-dev package but
not libncurses5-dev package, I can say "make menuconfig".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * There is no /usr/include/ncurses/ directory but /usr/include/ncursesw
   exists, and has curses.h in it.

 scripts/kconfig/lxdialog/check-lxdialog.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh b/scripts/kconfig/lxdialog/check-lxdialog.sh
index fcef0f5..82cc3a8 100644
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -23,6 +23,8 @@ ccflags()
 		echo '-I/usr/include/ncurses -DCURSES_LOC="<ncurses.h>"'
 	elif [ -f /usr/include/ncurses/curses.h ]; then
 		echo '-I/usr/include/ncurses -DCURSES_LOC="<ncurses/curses.h>"'
+	elif [ -f /usr/include/ncursesw/curses.h ]; then
+		echo '-I/usr/include/ncursesw -DCURSES_LOC="<ncursesw/curses.h>"'
 	elif [ -f /usr/include/ncurses.h ]; then
 		echo '-DCURSES_LOC="<ncurses.h>"'
 	else

[PATCH]

[Sam Ravnborg]

>From 705dbd8a31520722bda78e1bc731e2880f8df0ff Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 14 Aug 2010 14:40:00 +0200
Subject: [PATCH] kconfig: fix segfault when detecting recursive dependency

Following sample Kconfig generated a segfault:

config FOO
        bool
        select PERF_EVENTS if HAVE_HW_BREAKPOINT

config PERF_EVENTS
        bool

config HAVE_HW_BREAKPOINT
        bool
        depends on PERF_EVENTS

Fix by reverting back to a valid property if there was no
property on the stack of symbols.

The above pattern were seen in sh Kconfig.
A fix for the Kconfig file has been sent to the sh folks.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
 scripts/kconfig/symbol.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index e95718f..943712c 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -937,6 +937,8 @@ static void sym_check_print_recursive(struct symbol *last_sym)
 		sym = stack->sym;
 		next_sym = stack->next ? stack->next->sym : last_sym;
 		prop = stack->prop;
+		if (prop == NULL)
+			prop = stack->sym->prop;
 
 		/* for choice values find the menu entry (used below) */
 		if (sym_is_choice(sym) || sym_is_choice_value(sym)) {
-- 
1.6.0.6

[PATCH]

[Christoph Hellwig]

It's used by DM and MD and generally useful, so move the bio list
helpers into bio.h.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/drivers/md/dm-bio-list.h
===================================================================
--- linux-2.6.orig/drivers/md/dm-bio-list.h	2009-04-05 13:10:25.427445349 +0200
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,117 +0,0 @@
-/*
- * Copyright (C) 2004 Red Hat UK Ltd.
- *
- * This file is released under the GPL.
- */
-
-#ifndef DM_BIO_LIST_H
-#define DM_BIO_LIST_H
-
-#include <linux/bio.h>
-
-#ifdef CONFIG_BLOCK
-
-struct bio_list {
-	struct bio *head;
-	struct bio *tail;
-};
-
-static inline int bio_list_empty(const struct bio_list *bl)
-{
-	return bl->head == NULL;
-}
-
-static inline void bio_list_init(struct bio_list *bl)
-{
-	bl->head = bl->tail = NULL;
-}
-
-#define bio_list_for_each(bio, bl) \
-	for (bio = (bl)->head; bio; bio = bio->bi_next)
-
-static inline unsigned bio_list_size(const struct bio_list *bl)
-{
-	unsigned sz = 0;
-	struct bio *bio;
-
-	bio_list_for_each(bio, bl)
-		sz++;
-
-	return sz;
-}
-
-static inline void bio_list_add(struct bio_list *bl, struct bio *bio)
-{
-	bio->bi_next = NULL;
-
-	if (bl->tail)
-		bl->tail->bi_next = bio;
-	else
-		bl->head = bio;
-
-	bl->tail = bio;
-}
-
-static inline void bio_list_add_head(struct bio_list *bl, struct bio *bio)
-{
-	bio->bi_next = bl->head;
-
-	bl->head = bio;
-
-	if (!bl->tail)
-		bl->tail = bio;
-}
-
-static inline void bio_list_merge(struct bio_list *bl, struct bio_list *bl2)
-{
-	if (!bl2->head)
-		return;
-
-	if (bl->tail)
-		bl->tail->bi_next = bl2->head;
-	else
-		bl->head = bl2->head;
-
-	bl->tail = bl2->tail;
-}
-
-static inline void bio_list_merge_head(struct bio_list *bl,
-				       struct bio_list *bl2)
-{
-	if (!bl2->head)
-		return;
-
-	if (bl->head)
-		bl2->tail->bi_next = bl->head;
-	else
-		bl->tail = bl2->tail;
-
-	bl->head = bl2->head;
-}
-
-static inline struct bio *bio_list_pop(struct bio_list *bl)
-{
-	struct bio *bio = bl->head;
-
-	if (bio) {
-		bl->head = bl->head->bi_next;
-		if (!bl->head)
-			bl->tail = NULL;
-
-		bio->bi_next = NULL;
-	}
-
-	return bio;
-}
-
-static inline struct bio *bio_list_get(struct bio_list *bl)
-{
-	struct bio *bio = bl->head;
-
-	bl->head = bl->tail = NULL;
-
-	return bio;
-}
-
-#endif /* CONFIG_BLOCK */
-#endif
Index: linux-2.6/drivers/md/dm-delay.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-delay.c	2009-04-05 13:13:29.222444720 +0200
+++ linux-2.6/drivers/md/dm-delay.c	2009-04-05 13:13:32.398573159 +0200
@@ -15,8 +15,6 @@
 
 #include <linux/device-mapper.h>
 
-#include "dm-bio-list.h"
-
 #define DM_MSG_PREFIX "delay"
 
 struct delay_c {
Index: linux-2.6/drivers/md/dm-mpath.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-mpath.c	2009-04-05 13:13:29.242444961 +0200
+++ linux-2.6/drivers/md/dm-mpath.c	2009-04-05 13:13:57.017458602 +0200
@@ -8,7 +8,6 @@
 #include <linux/device-mapper.h>
 
 #include "dm-path-selector.h"
-#include "dm-bio-list.h"
 #include "dm-bio-record.h"
 #include "dm-uevent.h"
 
Index: linux-2.6/drivers/md/dm-raid1.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-raid1.c	2009-04-05 13:13:29.255452134 +0200
+++ linux-2.6/drivers/md/dm-raid1.c	2009-04-05 13:13:38.802447942 +0200
@@ -5,7 +5,6 @@
  * This file is released under the GPL.
  */
 
-#include "dm-bio-list.h"
 #include "dm-bio-record.h"
 
 #include <linux/init.h>
Index: linux-2.6/drivers/md/dm-region-hash.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-region-hash.c	2009-04-05 13:13:29.270445034 +0200
+++ linux-2.6/drivers/md/dm-region-hash.c	2009-04-05 13:13:41.473449954 +0200
@@ -14,7 +14,6 @@
 #include <linux/vmalloc.h>
 
 #include "dm.h"
-#include "dm-bio-list.h"
 
 #define	DM_MSG_PREFIX	"region hash"
 
Index: linux-2.6/drivers/md/dm-snap.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-snap.c	2009-04-05 13:13:29.287445452 +0200
+++ linux-2.6/drivers/md/dm-snap.c	2009-04-05 13:13:43.704446877 +0200
@@ -22,7 +22,6 @@
 #include <linux/workqueue.h>
 
 #include "dm-exception-store.h"
-#include "dm-bio-list.h"
 
 #define DM_MSG_PREFIX "snapshots"
 
Index: linux-2.6/drivers/md/dm.c
===================================================================
--- linux-2.6.orig/drivers/md/dm.c	2009-04-05 13:13:29.300444453 +0200
+++ linux-2.6/drivers/md/dm.c	2009-04-05 13:13:45.999446772 +0200
@@ -6,7 +6,6 @@
  */
 
 #include "dm.h"
-#include "dm-bio-list.h"
 #include "dm-uevent.h"
 
 #include <linux/init.h>
Index: linux-2.6/drivers/md/raid1.c
===================================================================
--- linux-2.6.orig/drivers/md/raid1.c	2009-04-05 13:13:29.316444814 +0200
+++ linux-2.6/drivers/md/raid1.c	2009-04-05 13:13:49.188479487 +0200
@@ -35,7 +35,6 @@
 #include <linux/blkdev.h>
 #include <linux/seq_file.h>
 #include "md.h"
-#include "dm-bio-list.h"
 #include "raid1.h"
 #include "bitmap.h"
 
Index: linux-2.6/drivers/md/raid10.c
===================================================================
--- linux-2.6.orig/drivers/md/raid10.c	2009-04-05 13:13:29.332445594 +0200
+++ linux-2.6/drivers/md/raid10.c	2009-04-05 13:13:52.435605187 +0200
@@ -22,7 +22,6 @@
 #include <linux/blkdev.h>
 #include <linux/seq_file.h>
 #include "md.h"
-#include "dm-bio-list.h"
 #include "raid10.h"
 #include "bitmap.h"
 
Index: linux-2.6/include/linux/bio.h
===================================================================
--- linux-2.6.orig/include/linux/bio.h	2009-04-05 13:10:25.442444604 +0200
+++ linux-2.6/include/linux/bio.h	2009-04-05 13:12:47.685574569 +0200
@@ -501,6 +501,115 @@ static inline int bio_has_data(struct bi
 	return bio && bio->bi_io_vec != NULL;
 }
 
+/*
+ * BIO list managment for use by remapping drivers (e.g. DM or MD).
+ *
+ * A bio_list anchors a singly-linked list of bios chained through the bi_next
+ * member of the bio.  The bio_list also caches the last list member to allow
+ * fast access to the tail.
+ */
+struct bio_list {
+	struct bio *head;
+	struct bio *tail;
+};
+
+static inline int bio_list_empty(const struct bio_list *bl)
+{
+	return bl->head == NULL;
+}
+
+static inline void bio_list_init(struct bio_list *bl)
+{
+	bl->head = bl->tail = NULL;
+}
+
+#define bio_list_for_each(bio, bl) \
+	for (bio = (bl)->head; bio; bio = bio->bi_next)
+
+static inline unsigned bio_list_size(const struct bio_list *bl)
+{
+	unsigned sz = 0;
+	struct bio *bio;
+
+	bio_list_for_each(bio, bl)
+		sz++;
+
+	return sz;
+}
+
+static inline void bio_list_add(struct bio_list *bl, struct bio *bio)
+{
+	bio->bi_next = NULL;
+
+	if (bl->tail)
+		bl->tail->bi_next = bio;
+	else
+		bl->head = bio;
+
+	bl->tail = bio;
+}
+
+static inline void bio_list_add_head(struct bio_list *bl, struct bio *bio)
+{
+	bio->bi_next = bl->head;
+
+	bl->head = bio;
+
+	if (!bl->tail)
+		bl->tail = bio;
+}
+
+static inline void bio_list_merge(struct bio_list *bl, struct bio_list *bl2)
+{
+	if (!bl2->head)
+		return;
+
+	if (bl->tail)
+		bl->tail->bi_next = bl2->head;
+	else
+		bl->head = bl2->head;
+
+	bl->tail = bl2->tail;
+}
+
+static inline void bio_list_merge_head(struct bio_list *bl,
+				       struct bio_list *bl2)
+{
+	if (!bl2->head)
+		return;
+
+	if (bl->head)
+		bl2->tail->bi_next = bl->head;
+	else
+		bl->tail = bl2->tail;
+
+	bl->head = bl2->head;
+}
+
+static inline struct bio *bio_list_pop(struct bio_list *bl)
+{
+	struct bio *bio = bl->head;
+
+	if (bio) {
+		bl->head = bl->head->bi_next;
+		if (!bl->head)
+			bl->tail = NULL;
+
+		bio->bi_next = NULL;
+	}
+
+	return bio;
+}
+
+static inline struct bio *bio_list_get(struct bio_list *bl)
+{
+	struct bio *bio = bl->head;
+
+	bl->head = bl->tail = NULL;
+
+	return bio;
+}
+
 #if defined(CONFIG_BLK_DEV_INTEGRITY)
 
 #define bip_vec_idx(bip, idx)	(&(bip->bip_vec[(idx)]))

[PATCH]

[Tim Shimmin]

Hi Linus,

Please include the following patch for 2.6.27.1 stable release as
suggested by Christoph Hellwig and Eric Sandeen.
It fixes a regression in the recent remount recoding
where remounting say from ro to rw allows the xfs flags to
be out of sync with the vfs flags, resulting
in failures for some programs such as touch (which end up calling xfs_setattr).
The fix is a very minor and clear.

Thanks,
Tim.

Date: Sun, 12 Oct 2008 14:30:44 +0200
From: Christoph Hellwig <hch@lst.de>
To: xfs@oss.sgi.com
Subject: [PATCH] fix remount rw with unrecognized options

When we skip unrecognized options in xfs_fs_remount we should just break
out of the switch and not return because otherwise we may skip clearing
the xfs-internal read-only flag.  This will only show up on some
operations like touch because most read-only checks are done by the VFS
which thinks this filesystem is r/w.  Eventually we should replace the
XFS read-only flag with a helper that always checks the VFS flag to make
sure they can never get out of sync.

Bug reported and fix verified by Marcel Beister on #xfs.
Bug fix verified by updated xfstests/189.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Eric Sandeen <sandeen@sandeen.net>
Signed-off-by: Timothy Shimmin <tes@sgi.com>

Index: mainline/fs/xfs/linux-2.6/xfs_super.c
===================================================================
--- mainline.orig/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:26.542652847 +1100
+++ mainline/fs/xfs/linux-2.6/xfs_super.c	2008-10-15 17:59:45.376217172 +1100
@@ -1323,7 +1323,7 @@ xfs_fs_remount(
 	"XFS: mount option \"%s\" not supported for remount\n", p);
 			return -EINVAL;
 #else
-			return 0;
+			break;
 #endif
 		}
 	}

Re: [PATCH]

[Alan Cox]

On Mon, 3 Dec 2007 16:54:55 +0100
"Andries E. Brouwer" <Andries.Brouwer@cwi.nl> wrote:

> As it turns out, the kernel divides by EXT3_INODES_PER_GROUP(s)
> when mounting an ext3 filesystem. If that number is zero,
> a crash follows. Below a patch.
> 
> This crash was reported by Joeri de Ruiter, Carst Tankink and Pim Vullers.

Acked-by: Alan Cox <alan@redhat.com>

[PATCH]

[Andries E. Brouwer]

As it turns out, the kernel divides by EXT3_INODES_PER_GROUP(s)
when mounting an ext3 filesystem. If that number is zero,
a crash follows. Below a patch.

This crash was reported by Joeri de Ruiter, Carst Tankink and Pim Vullers.

Andries

diff -uprN -X /linux/dontdiff a/fs/ext3/super.c b/fs/ext3/super.c
--- a/fs/ext3/super.c	2007-10-13 19:51:45.000000000 +0200
+++ b/fs/ext3/super.c	2007-12-03 16:00:36.802510904 +0100
@@ -1596,7 +1596,7 @@ static int ext3_fill_super (struct super
 	sbi->s_blocks_per_group = le32_to_cpu(es->s_blocks_per_group);
 	sbi->s_frags_per_group = le32_to_cpu(es->s_frags_per_group);
 	sbi->s_inodes_per_group = le32_to_cpu(es->s_inodes_per_group);
-	if (EXT3_INODE_SIZE(sb) == 0)
+	if (EXT3_INODE_SIZE(sb) == 0 || EXT3_INODES_PER_GROUP(sb) == 0)
 		goto cantfind_ext3;
 	sbi->s_inodes_per_block = blocksize / EXT3_INODE_SIZE(sb);
 	if (sbi->s_inodes_per_block == 0)
diff -uprN -X /linux/dontdiff a/fs/ext4/super.c b/fs/ext4/super.c
--- a/fs/ext4/super.c	2007-10-13 19:51:45.000000000 +0200
+++ b/fs/ext4/super.c	2007-12-03 16:05:14.722260680 +0100
@@ -1678,7 +1678,7 @@ static int ext4_fill_super (struct super
 	sbi->s_blocks_per_group = le32_to_cpu(es->s_blocks_per_group);
 	sbi->s_frags_per_group = le32_to_cpu(es->s_frags_per_group);
 	sbi->s_inodes_per_group = le32_to_cpu(es->s_inodes_per_group);
-	if (EXT4_INODE_SIZE(sb) == 0)
+	if (EXT4_INODE_SIZE(sb) == 0 || EXT4_INODES_PER_GROUP(sb) == 0)
 		goto cantfind_ext4;
 	sbi->s_inodes_per_block = blocksize / EXT4_INODE_SIZE(sb);
 	if (sbi->s_inodes_per_block == 0)

[PATCH]

[James Simmons]

This is the new display intreface. Its goal is to provide a standard 
interface to various types of displays. Currently we have auxdisplay, 
output acpi device and the now defunct lcd class in the backlight directory.
Please apply.

Signed-Off: James Simmons <jsimmons@infradead.org>

diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/display-sysfs.c fbdev-2.6/drivers/video/display/display-sysfs.c
--- linus-2.6/drivers/video/display/display-sysfs.c	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/display-sysfs.c	2007-02-21 15:55:18.000000000 -0500
@@ -0,0 +1,200 @@
+/*
+ *  display-sysfs.c - Display output driver sysfs interface
+ *
+ *  Copyright (C) 2007 James Simmons <jsimmons@infradead.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+#include <linux/module.h>
+#include <linux/display.h>
+#include <linux/err.h>
+#include <linux/ctype.h>
+
+static ssize_t display_show_name(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	return snprintf(buf, PAGE_SIZE, "%s\n", dsp->name);
+}
+
+static ssize_t display_show_type(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	return snprintf(buf, PAGE_SIZE, "%s\n", dsp->type);
+}
+
+static ssize_t display_show_contrast(struct device *dev, struct device_attribute *attr,
+				char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t rc = -ENXIO;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver) && dsp->driver->get_contrast)
+		rc = sprintf(buf, "%d\n", dsp->driver->get_contrast(dsp));
+	mutex_unlock(&dsp->lock);
+	return rc;
+}
+
+static ssize_t display_store_contrast(struct device *dev, struct device_attribute *attr,
+				const char *buf, size_t count)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t ret = -EINVAL, size;
+	int contrast;
+	char *endp;
+
+	contrast = simple_strtoul(buf, &endp, 0);
+	size = endp - buf;
+
+	if (*endp && isspace(*endp))
+		size++;
+
+	if (size != count)
+		return ret;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver && dsp->driver->set_contrast)) {
+		pr_debug("display: set contrast to %d\n", contrast);
+		dsp->driver->set_contrast(dsp, contrast);
+		ret = count;
+	}
+	mutex_unlock(&dsp->lock);
+	return ret;
+}
+
+static ssize_t display_show_max_contrast(struct device *dev, struct device_attribute *attr,
+					char *buf)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+	ssize_t rc = -ENXIO;
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver))
+		rc = sprintf(buf, "%d\n", dsp->driver->max_contrast);
+	mutex_unlock(&dsp->lock);
+	return rc;
+}
+
+static struct device_attribute display_attrs[] = {
+	__ATTR(name, S_IRUGO, display_show_name, NULL),
+	__ATTR(type, S_IRUGO, display_show_type, NULL),
+	__ATTR(contrast, S_IRUGO | S_IWUSR, display_show_contrast, display_store_contrast),
+	__ATTR(max_contrast, S_IRUGO, display_show_max_contrast, NULL),
+};
+
+static int display_suspend(struct device *dev, pm_message_t state)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver->suspend))
+		dsp->driver->suspend(dsp, state);
+	mutex_unlock(&dsp->lock);
+	return 0;
+};
+
+static int display_resume(struct device *dev)
+{
+	struct display_device *dsp = dev_get_drvdata(dev);
+
+	mutex_lock(&dsp->lock);
+	if (likely(dsp->driver->resume))
+		dsp->driver->resume(dsp);
+	mutex_unlock(&dsp->lock);
+	return 0;
+};
+
+struct class *display_class;
+EXPORT_SYMBOL(display_class);
+static int index;
+
+struct display_device *display_device_register(struct display_driver *driver,
+						struct device *dev, void *devdata)
+{
+	struct display_device *new_dev = NULL;
+	int ret = -EINVAL;
+
+	if (unlikely(!driver))
+		return ERR_PTR(ret);
+
+	new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
+	if (likely(new_dev) && unlikely(driver->probe(new_dev, devdata))) {
+		new_dev->dev = device_create(display_class, dev, 0,
+						"display%d", index);
+
+		if (!IS_ERR(new_dev->dev)) {
+			dev_set_drvdata(new_dev->dev, new_dev);
+			new_dev->driver = driver;
+			new_dev->parent = dev;
+			mutex_init(&new_dev->lock);
+			index++;
+		} else {
+			new_dev->dev = NULL;
+			kfree(new_dev);
+		}
+	}
+	return new_dev;
+}
+EXPORT_SYMBOL(display_device_register);
+
+void display_device_unregister(struct display_device *ddev)
+{
+	if (!ddev)
+		return;
+	mutex_lock(&ddev->lock);
+	device_del(ddev->dev);
+	ddev->driver = NULL;
+	index--;
+	mutex_unlock(&ddev->lock);
+	kfree(ddev);
+}
+EXPORT_SYMBOL(display_device_unregister);
+
+static int __init display_class_init(void)
+{
+	display_class = class_create(THIS_MODULE, "display");
+	if (IS_ERR(display_class)) {
+		printk(KERN_ERR "Failed to create display class\n");
+		display_class = NULL;
+		return -EINVAL;
+	}
+	display_class->dev_attrs = display_attrs;
+	display_class->suspend = display_suspend;
+	display_class->resume = display_resume;
+	return 0;
+}
+
+#ifdef MODULE
+module_init(display_class_init);
+
+static void __exit display_class_exit(void)
+{
+	class_destroy(display_class);
+}
+module_exit(display_class_exit);
+#else
+subsys_initcall(display_class_init);
+#endif
+
+MODULE_DESCRIPTION("Display Hardware handling");
+MODULE_AUTHOR("James Simmons <jsimmons@infradead.org>");
+MODULE_LICENSE("GPL");
+
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/Kconfig fbdev-2.6/drivers/video/display/Kconfig
--- linus-2.6/drivers/video/display/Kconfig	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/Kconfig	2007-02-21 15:56:32.000000000 -0500
@@ -0,0 +1,24 @@
+#
+# Display drivers configuration
+#
+
+menu "Display device support"
+
+config DISPLAY_SUPPORT
+	tristate "Display panel/monitor support"
+	---help---
+	  This framework adds support for low-level control of a display.
+	  This includes support for power.
+
+	  Enable this to be able to choose the drivers for controlling the
+	  physical display panel/monitor on some platforms. This not only
+	  covers LCD displays for PDAs but also other types of displays
+	  such as CRT, TVout etc.
+
+	  To have support for your specific display panel you will have to
+	  select the proper drivers which depend on this option.
+
+comment "Display hardware drivers"
+	depends on DISPLAY_SUPPORT
+
+endmenu
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/display/Makefile fbdev-2.6/drivers/video/display/Makefile
--- linus-2.6/drivers/video/display/Makefile	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/drivers/video/display/Makefile	2007-02-21 15:56:22.000000000 -0500
@@ -0,0 +1,6 @@
+# Display drivers
+
+display-objs				:= display-sysfs.o
+
+obj-$(CONFIG_DISPLAY_SUPPORT)		+= display.o
+
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/Kconfig fbdev-2.6/drivers/video/Kconfig
--- linus-2.6/drivers/video/Kconfig	2007-02-21 10:59:24.000000000 -0500
+++ fbdev-2.6/drivers/video/Kconfig	2007-02-21 15:55:56.000000000 -0500
@@ -5,6 +5,7 @@
 menu "Graphics support"
 
 source "drivers/video/backlight/Kconfig"
+source "drivers/video/display/Kconfig"
 
 config FB
 	tristate "Support for frame buffer devices"
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/drivers/video/Makefile fbdev-2.6/drivers/video/Makefile
--- linus-2.6/drivers/video/Makefile	2007-02-21 10:59:24.000000000 -0500
+++ fbdev-2.6/drivers/video/Makefile	2007-02-21 15:16:48.000000000 -0500
@@ -12,7 +12,7 @@
 
 obj-$(CONFIG_VT)		  += console/
 obj-$(CONFIG_LOGO)		  += logo/
-obj-y				  += backlight/
+obj-y				  += backlight/ display/
 
 obj-$(CONFIG_FB_CFB_FILLRECT)  += cfbfillrect.o
 obj-$(CONFIG_FB_CFB_COPYAREA)  += cfbcopyarea.o
diff -urN -X linus-2.6/Documentation/dontdiff linus-2.6/include/linux/display.h fbdev-2.6/include/linux/display.h
--- linus-2.6/include/linux/display.h	1969-12-31 19:00:00.000000000 -0500
+++ fbdev-2.6/include/linux/display.h	2007-02-21 15:34:31.000000000 -0500
@@ -0,0 +1,60 @@
+/*
+ *  Copyright (C) 2006 James Simmons <jsimmons@infradead.org>
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful, but
+ *  WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ */
+
+#ifndef _LINUX_DISPLAY_H
+#define _LINUX_DISPLAY_H
+
+#include <linux/device.h>
+
+struct display_device;
+
+/* This structure defines all the properties of a Display. */
+struct display_driver {
+	int  (*set_contrast)(struct display_device *, unsigned int);
+	int  (*get_contrast)(struct display_device *);
+	void (*suspend)(struct display_device *, pm_message_t state);
+	void (*resume)(struct display_device *);
+	int  (*probe)(struct display_device *, void *);
+	int  (*remove)(struct display_device *);
+	int  max_contrast;
+};
+
+struct display_device {
+	struct module *owner;	/* Owner module */
+	char type[16];
+	char *name;
+	struct mutex lock;
+	struct display_driver *driver;
+	struct device *parent;			/* This is the parent */
+	struct device *dev;			/* This is this display device */
+	void *priv_data;
+};
+
+extern struct display_device *display_device_register(struct display_driver *driver,
+					struct device *dev, void *devdata);
+extern void display_device_unregister(struct display_device *dev);
+
+extern int probe_edid(struct display_device *dev, void *devdata);
+
+#define to_display_device(obj) container_of(obj, struct display_device, class_dev)
+
+#endif

[PATCH]

[Chris Boot]

Make the next48xx LED code use scx200_gpio_ops instead of raw SCx200 GPIO accesses.

Signed-off-by: Chris Boot <bootc@bootc.net>

diff --git a/drivers/leds/leds-net48xx.c b/drivers/leds/leds-net48xx.c
index 713c4a8..45ba3d4 100644
--- a/drivers/leds/leds-net48xx.c
+++ b/drivers/leds/leds-net48xx.c
@@ -16,6 +16,7 @@
  #include <linux/leds.h>
  #include <linux/err.h>
  #include <asm/io.h>
+#include <linux/nsc_gpio.h>
  #include <linux/scx200_gpio.h>

  #define DRVNAME "net48xx-led"
@@ -26,10 +27,7 @@ static struct platform_device *pdev;
  static void net48xx_error_led_set(struct led_classdev *led_cdev,
  		enum led_brightness value)
  {
-	if (value)
-		scx200_gpio_set_high(NET48XX_ERROR_LED_GPIO);
-	else
-		scx200_gpio_set_low(NET48XX_ERROR_LED_GPIO);
+	scx200_gpio_ops.gpio_set(NET48XX_ERROR_LED_GPIO, value ? 1 : 0);
  }

  static struct led_classdev net48xx_error_led = {
@@ -81,7 +79,8 @@ static int __init net48xx_led_init(void)
  {
  	int ret;

-	if (!scx200_gpio_present()) {
+	/* small hack, but scx200_gpio doesn't set .dev if the probe fails */
+	if (!scx200_gpio_ops.dev) {
  		ret = -ENODEV;
  		goto out;
  	}


-- 
Chris Boot
bootc@bootc.net
http://www.bootc.net/

Re: [PATCH]

[Daniel Walker]

On Fri, 2006-03-24 at 15:19 -0800, john stultz wrote:
> On Fri, 2006-03-24 at 15:07 -0800, Daniel Walker wrote:
> > Signed-Off-By: Daniel Walker <dwalker@mvista.com>
> > 
> > Index: linux-2.6.16/kernel/time/timeofday.c
> > ===================================================================
> > --- linux-2.6.16.orig/kernel/time/timeofday.c
> > +++ linux-2.6.16/kernel/time/timeofday.c
> > @@ -644,7 +644,7 @@ static void timeofday_periodic_hook(unsi
> >  
> >  	int something_changed = 0;
> >   	int clocksource_changed = 0;
> > -	struct clocksource old_clock;
> > +	struct clocksource old_clock = { .mult = 1, .shift = 0 };
> >  	static s64 second_check;
> >  
> >  	write_seqlock_irqsave(&system_time_lock, flags);
> 
> I assume this is a fix for the GCC "may be used uninitialized" warning?

Yeah, Sorry ,I accidentally pressed enter before I described it ..

Daniel

Re: [PATCH]

[john stultz]

On Fri, 2006-03-24 at 15:07 -0800, Daniel Walker wrote:
> Signed-Off-By: Daniel Walker <dwalker@mvista.com>
> 
> Index: linux-2.6.16/kernel/time/timeofday.c
> ===================================================================
> --- linux-2.6.16.orig/kernel/time/timeofday.c
> +++ linux-2.6.16/kernel/time/timeofday.c
> @@ -644,7 +644,7 @@ static void timeofday_periodic_hook(unsi
>  
>  	int something_changed = 0;
>   	int clocksource_changed = 0;
> -	struct clocksource old_clock;
> +	struct clocksource old_clock = { .mult = 1, .shift = 0 };
>  	static s64 second_check;
>  
>  	write_seqlock_irqsave(&system_time_lock, flags);

I assume this is a fix for the GCC "may be used uninitialized" warning?

thanks
-john

[PATCH]

[Daniel Walker]

Signed-Off-By: Daniel Walker <dwalker@mvista.com>

Index: linux-2.6.16/kernel/time/timeofday.c
===================================================================
--- linux-2.6.16.orig/kernel/time/timeofday.c
+++ linux-2.6.16/kernel/time/timeofday.c
@@ -644,7 +644,7 @@ static void timeofday_periodic_hook(unsi
 
 	int something_changed = 0;
  	int clocksource_changed = 0;
-	struct clocksource old_clock;
+	struct clocksource old_clock = { .mult = 1, .shift = 0 };
 	static s64 second_check;
 
 	write_seqlock_irqsave(&system_time_lock, flags);

Re: [PATCH]

[Kumar Gala]

Ack, this is what I get for sending patches before I've actually gotten 
up.  The first line was suppose to be the subject line, oh well will 
resend this.

- k

On Fri, 10 Mar 2006, Kumar Gala wrote:

> PCI: Add pci_assign_resource_fixed -- allow fixed address assignments
> 
> On some embedded systems the PCI address for hotplug devices are not only
> known a priori but are required to be at a given PCI address for other
> master in the system to be able to access.
> 
> An example of such a system would be an FPGA which is setup from user space
> after the system has booted.  The FPGA may be access by DSPs in the system
> and those DSPs expect the FPGA at a fixed PCI address.
> 
> Added pci_assign_resource_fixed() as a way to allow assignment of the PCI
> devices's BARs at fixed PCI addresses.
> 
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> 
> ---
> commit 45d4a23317c459865ec740c80b6e2a2ad9f53fd3
> tree 432b5e41ef5f231dd57eb1a98f103239c62d63a0
> parent 8176dee014ec6ad1039b8c0075c9c1d02147c2c8
> author Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600
> committer Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600
> 
>  drivers/pci/pci.c       |    1 +
>  drivers/pci/setup-res.c |   35 +++++++++++++++++++++++++++++++++++
>  include/linux/pci.h     |    1 +
>  3 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index d2d1879..2557e86 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -935,6 +935,7 @@ EXPORT_SYMBOL_GPL(pci_intx);
>  EXPORT_SYMBOL(pci_set_dma_mask);
>  EXPORT_SYMBOL(pci_set_consistent_dma_mask);
>  EXPORT_SYMBOL(pci_assign_resource);
> +EXPORT_SYMBOL(pci_assign_resource_fixed);
>  EXPORT_SYMBOL(pci_find_parent_resource);
>  
>  EXPORT_SYMBOL(pci_set_power_state);
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index ea9277b..f485958 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -155,6 +155,41 @@ int pci_assign_resource(struct pci_dev *
>  	return ret;
>  }
>  
> +int pci_assign_resource_fixed(struct pci_dev *dev, int resno)
> +{
> +	struct pci_bus *bus = dev->bus;
> +	struct resource *res = dev->resource + resno;
> +	unsigned int type_mask;
> +	int i, ret = -EBUSY;
> +
> +	type_mask = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
> +
> +	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
> +		struct resource *r = bus->resource[i];
> +		if (!r)
> +			continue;
> +
> +		/* type_mask must match */
> +		if ((res->flags ^ r->flags) & type_mask)
> +			continue;
> +
> +		ret = request_resource(r, res);
> +
> +		if (ret == 0)
> +			break;
> +	}
> +
> +	if (ret) {
> +		printk(KERN_ERR "PCI: Failed to allocate %s resource #%d:%lx@%lx for %s\n",
> +		       res->flags & IORESOURCE_IO ? "I/O" : "mem",
> +		       resno, res->end - res->start + 1, res->start, pci_name(dev));
> +	} else if (resno < PCI_BRIDGE_RESOURCES) {
> +		pci_update_resource(dev, res, resno);
> +	}
> +
> +	return ret;
> +}
> +
>  /* Sort resources by alignment */
>  void __devinit
>  pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index fe1a2b0..0db1e2d 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -460,6 +460,7 @@ int pci_set_dma_mask(struct pci_dev *dev
>  int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask);
>  void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno);
>  int pci_assign_resource(struct pci_dev *dev, int i);
> +int pci_assign_resource_fixed(struct pci_dev *dev, int i);
>  void pci_restore_bars(struct pci_dev *dev);
>  
>  /* ROM control related routines */
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[PATCH]

[Kumar Gala]

PCI: Add pci_assign_resource_fixed -- allow fixed address assignments

On some embedded systems the PCI address for hotplug devices are not only
known a priori but are required to be at a given PCI address for other
master in the system to be able to access.

An example of such a system would be an FPGA which is setup from user space
after the system has booted.  The FPGA may be access by DSPs in the system
and those DSPs expect the FPGA at a fixed PCI address.

Added pci_assign_resource_fixed() as a way to allow assignment of the PCI
devices's BARs at fixed PCI addresses.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

---
commit 45d4a23317c459865ec740c80b6e2a2ad9f53fd3
tree 432b5e41ef5f231dd57eb1a98f103239c62d63a0
parent 8176dee014ec6ad1039b8c0075c9c1d02147c2c8
author Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 09 Mar 2006 12:34:25 -0600

 drivers/pci/pci.c       |    1 +
 drivers/pci/setup-res.c |   35 +++++++++++++++++++++++++++++++++++
 include/linux/pci.h     |    1 +
 3 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d2d1879..2557e86 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -935,6 +935,7 @@ EXPORT_SYMBOL_GPL(pci_intx);
 EXPORT_SYMBOL(pci_set_dma_mask);
 EXPORT_SYMBOL(pci_set_consistent_dma_mask);
 EXPORT_SYMBOL(pci_assign_resource);
+EXPORT_SYMBOL(pci_assign_resource_fixed);
 EXPORT_SYMBOL(pci_find_parent_resource);
 
 EXPORT_SYMBOL(pci_set_power_state);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index ea9277b..f485958 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -155,6 +155,41 @@ int pci_assign_resource(struct pci_dev *
 	return ret;
 }
 
+int pci_assign_resource_fixed(struct pci_dev *dev, int resno)
+{
+	struct pci_bus *bus = dev->bus;
+	struct resource *res = dev->resource + resno;
+	unsigned int type_mask;
+	int i, ret = -EBUSY;
+
+	type_mask = IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH;
+
+	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
+		struct resource *r = bus->resource[i];
+		if (!r)
+			continue;
+
+		/* type_mask must match */
+		if ((res->flags ^ r->flags) & type_mask)
+			continue;
+
+		ret = request_resource(r, res);
+
+		if (ret == 0)
+			break;
+	}
+
+	if (ret) {
+		printk(KERN_ERR "PCI: Failed to allocate %s resource #%d:%lx@%lx for %s\n",
+		       res->flags & IORESOURCE_IO ? "I/O" : "mem",
+		       resno, res->end - res->start + 1, res->start, pci_name(dev));
+	} else if (resno < PCI_BRIDGE_RESOURCES) {
+		pci_update_resource(dev, res, resno);
+	}
+
+	return ret;
+}
+
 /* Sort resources by alignment */
 void __devinit
 pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fe1a2b0..0db1e2d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -460,6 +460,7 @@ int pci_set_dma_mask(struct pci_dev *dev
 int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask);
 void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno);
 int pci_assign_resource(struct pci_dev *dev, int i);
+int pci_assign_resource_fixed(struct pci_dev *dev, int i);
 void pci_restore_bars(struct pci_dev *dev);
 
 /* ROM control related routines */

[PATCH]

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

(Note: Patch also attached because the inline version is certain to get
line wrapped.)

When significant delays happen during boot (e.g. with a kernel debugger, but
the problem has also seen in other cases) the timeout for blanking the
console may trigger, but the work scheduler may not have been initialized,
yet. This previously led to a page fault due to a NULL pointer access.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -Npru linux-2.6.12-rc6.base/drivers/char/vt.c linux-2.6.12-rc6/drivers/char/vt.c
--- linux-2.6.12-rc6.base/drivers/char/vt.c	2005-06-15 13:24:51.000000000 +0200
+++ linux-2.6.12-rc6/drivers/char/vt.c	2005-06-15 13:30:39.933774576 +0200
@@ -2867,6 +2867,10 @@ void unblank_screen(void)
  */
 static void blank_screen_t(unsigned long dummy)
 {
+	if (unlikely(!keventd_up())) {
+		mod_timer(&console_timer, jiffies + blankinterval);
+		return;
+	}
 	blank_timer_expired = 1;
 	schedule_work(&console_work);
 }



[-- Attachment #2: linux-2.6.12-rc6-blank-timeout.patch --]
[-- Type: text/plain, Size: 945 bytes --]

(Note: Patch also attached because the inline version is certain to get
line wrapped.)

When significant delays happen during boot (e.g. with a kernel debugger, but
the problem has also seen in other cases) the timeout for blanking the
console may trigger, but the work scheduler may not have been initialized,
yet. This previously led to a page fault due to a NULL pointer access.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -Npru linux-2.6.12-rc6.base/drivers/char/vt.c linux-2.6.12-rc6/drivers/char/vt.c
--- linux-2.6.12-rc6.base/drivers/char/vt.c	2005-06-15 13:24:51.000000000 +0200
+++ linux-2.6.12-rc6/drivers/char/vt.c	2005-06-15 13:30:39.933774576 +0200
@@ -2867,6 +2867,10 @@ void unblank_screen(void)
  */
 static void blank_screen_t(unsigned long dummy)
 {
+	if (unlikely(!keventd_up())) {
+		mod_timer(&console_timer, jiffies + blankinterval);
+		return;
+	}
 	blank_timer_expired = 1;
 	schedule_work(&console_work);
 }

[PATCH]

[Colin Leroy]

[resend - previous mail seem to have lost itself
Hi,

this patch is an RFC patch not to be applied.
It adds MS_SYNCHRONOUS support to FAT filesystem, so that less
filesystem breakage happen when disconnecting an USB key, for 
example. I'd like to have comments about it, because as it 
seems to work fine here, I'm not used to fs drivers and could
have made mistakes.
Thanks,

Signed-off-by: Colin Leroy <colin@colino.net>
--- a/fs/fat/dir.c	2004-11-18 19:42:41.704777744 +0100
+++ b/fs/fat/dir.c	2004-11-18 14:36:44.000000000 +0100
@@ -736,6 +736,7 @@
 {
 	struct buffer_head *bh;
 	struct msdos_dir_entry *de;
+	struct super_block *sb;
 	__le16 date, time;
 
 	bh = fat_extend_dir(dir);
@@ -764,6 +765,11 @@
 	dir->i_atime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
 	mark_inode_dirty(dir);
 
+	sb = dir->i_sb;
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+
 	return 0;
 }
 
--- a/fs/fat/file.c	2004-10-18 23:53:44.000000000 +0200
+++ b/fs/fat/file.c	2004-11-18 14:57:03.000000000 +0100
@@ -74,21 +74,34 @@
 {
 	struct inode *inode = filp->f_dentry->d_inode;
 	int retval;
+	struct super_block *sb = inode->i_sb;
+	struct buffer_head *bh = NULL;
 
 	retval = generic_file_write(filp, buf, count, ppos);
 	if (retval > 0) {
 		inode->i_mtime = inode->i_ctime = CURRENT_TIME;
 		MSDOS_I(inode)->i_attrs |= ATTR_ARCH;
 		mark_inode_dirty(inode);
+		if (sb->s_flags & MS_SYNCHRONOUS) {
+			bh = sb_bread(sb, MSDOS_SB(sb)->fsinfo_sector);
+			if (bh != NULL) {
+				sync_dirty_buffer(bh);
+				brelse(bh);
+			} else {
+				BUG_ON(1);
+			}
+		}
 	}
 	return retval;
 }
 
 void fat_truncate(struct inode *inode)
 {
+	struct super_block *sb = inode->i_sb;
 	struct msdos_sb_info *sbi = MSDOS_SB(inode->i_sb);
 	const unsigned int cluster_size = sbi->cluster_size;
 	int nr_clusters;
+	struct buffer_head *bh = NULL;
 
 	/* 
 	 * This protects against truncating a file bigger than it was then
@@ -105,4 +118,8 @@
 	unlock_kernel();
 	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
 	mark_inode_dirty(inode);
+	if (sb->s_flags & MS_SYNCHRONOUS) {
+		bh = sb_bread(sb, sbi->fsinfo_sector);
+		sync_dirty_buffer(bh);
+	}
 }
--- a/fs/fat/inode.c	2004-11-18 19:42:41.710776832 +0100
+++ b/fs/fat/inode.c	2004-11-18 15:00:55.000000000 +0100
@@ -1273,8 +1273,12 @@
 	}
 	spin_unlock(&sbi->inode_hash_lock);
 	mark_buffer_dirty(bh);
-	brelse(bh);
 	unlock_kernel();
+
+	if (sb->s_flags & MS_SYNCHRONOUS)
+		sync_dirty_buffer(bh);
+	brelse(bh);
+
 	return 0;
 }

[PATCH]

[Roland McGrath]

This replaces x86-64-singlestep-through-sigreturn-system-call-2.patch
from 2.6.8-rc2-mm2.  The second addition in entry.S is the difference.
This fixes a problem where additional singlesteps immediately after the
singlestep stop after sigreturn would not work right.

Note you might want to rename the patch, since this also has the effect of
making single-stepping of IA32 syscalls work right.


Thanks,
Roland


Signed-off-by: Roland McGrath <roland@redhat.com>

Index: linux-2.6/arch/x86_64/kernel/entry.S
===================================================================
RCS file: /home/roland/redhat/bkcvs/linux-2.5/arch/x86_64/kernel/entry.S,v
retrieving revision 1.22
diff -b -p -u -r1.22 entry.S
--- linux-2.6/arch/x86_64/kernel/entry.S 12 Apr 2004 20:29:12 -0000 1.22
+++ linux-2.6/arch/x86_64/kernel/entry.S 10 Aug 2004 02:34:01 -0000
@@ -297,7 +297,7 @@ int_very_careful:
 	sti
 	SAVE_REST
 	/* Check for syscall exit trace */	
-	testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),%edx
+	testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP),%edx
 	jz int_signal
 	pushq %rdi
 	leaq 8(%rsp),%rdi	# &ptregs -> arg1	
@@ -305,6 +305,7 @@ int_very_careful:
 	popq %rdi
 	btr  $TIF_SYSCALL_TRACE,%edi
 	btr  $TIF_SYSCALL_AUDIT,%edi
+	btr  $TIF_SINGLESTEP,%edi
 	jmp int_restore_rest
 	
 int_signal:
Index: linux-2.6/arch/x86_64/kernel/ptrace.c
===================================================================
RCS file: /home/roland/redhat/bkcvs/linux-2.5/arch/x86_64/kernel/ptrace.c,v
retrieving revision 1.16
diff -b -p -u -r1.16 ptrace.c
--- linux-2.6/arch/x86_64/kernel/ptrace.c 31 May 2004 03:07:42 -0000 1.16
+++ linux-2.6/arch/x86_64/kernel/ptrace.c 15 Jul 2004 23:56:44 -0000
@@ -88,6 +88,7 @@ void ptrace_disable(struct task_struct *
 { 
 	long tmp;
 
+	clear_tsk_thread_flag(child, TIF_SINGLESTEP);
 	tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG;
 	put_stack_long(child, EFL_OFFSET, tmp);
 }
@@ -344,6 +345,7 @@ asmlinkage long sys_ptrace(long request,
 			set_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
 		else
 			clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE);
+		clear_tsk_thread_flag(child, TIF_SINGLESTEP);
 		child->exit_code = data;
 	/* make sure the single step bit is not set. */
 		tmp = get_stack_long(child, EFL_OFFSET);
@@ -395,6 +397,7 @@ asmlinkage long sys_ptrace(long request,
 		ret = 0;
 		if (child->state == TASK_ZOMBIE)	/* already dead */
 			break;
+		clear_tsk_thread_flag(child, TIF_SINGLESTEP);
 		child->exit_code = SIGKILL;
 		/* make sure the single step bit is not set. */
 		tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG;
@@ -416,6 +419,7 @@ asmlinkage long sys_ptrace(long request,
 		}
 		tmp = get_stack_long(child, EFL_OFFSET) | TRAP_FLAG;
 		put_stack_long(child, EFL_OFFSET, tmp);
+		set_tsk_thread_flag(child, TIF_SINGLESTEP);
 		child->exit_code = data;
 		/* give it a chance to run. */
 		wake_up_process(child);
@@ -528,7 +532,8 @@ asmlinkage void syscall_trace_leave(stru
 	if (unlikely(current->audit_context))
 		audit_syscall_exit(current, regs->rax);
 
-	if (test_thread_flag(TIF_SYSCALL_TRACE)
+	if ((test_thread_flag(TIF_SYSCALL_TRACE)
+	     || test_thread_flag(TIF_SINGLESTEP))
 	    && (current->ptrace & PT_PTRACED))
 		syscall_trace(regs);
 }

Re: [PATCH]

[Theodore Ts'o]

On Mon, Aug 09, 2004 at 02:49:51PM -0400, Jean-Luc Cooke wrote:
> The only parts we're proposing to replace are:
>  - TCP sequence number generation (AES in CTR mode truncated to 32 bits, has
>    period of 2^32 and cannot be easily determined from pervious sequences)
>    I will read your reference and learn from the implementation in random.c

Nope, that's not sufficient.  There's a reason why we're doing what
we're doing in random.c.  To quote from RFC 1948:

   The choice of initial sequence numbers for a connection is not
   random.  Rather, it must be chosen so as to minimize the probability
   of old stale packets being accepted by new incarnations of the same
   connection [6, Appendix A].  Furthermore, implementations of TCP
   derived from 4.2BSD contain special code to deal with such
   reincarnations when the server end of the original connection is
   still in TIMEWAIT state [7, pp. 945].  Accordingly, SIMPLE
   RANDOMIZATION, AS SUGGESTED IN [8], WILL NOT WORK WELL.

The F() as defined in RFC 1948, needs to be a crypto hash.  But it
doesn't need to be a particularly strong hash.  If it takes longer for
the attacker to break the hash than our rekey interval, that's
sufficient, since what we're protecting any kind of secrecy of the
data; we just need to prevent the attacker from guessing the initial
sequence number just long enough so that he can't hijack a TCP
connection.  Hence the use of a cut-down MD4.  It's kludgy, yeah, and
it smells of roll-your-own-crypto, granted, but I emphasize again that
(a) this was never considered very high protection; if you really care
about protecting against these sorts of attacks, you will be using
application-level crypto (i.e., ssh'ing to a Cisco box instead of
using an unencrypted telnet connection), and (b) using real crypto is
too slow, and was affecting Linux in various network benchmarks.
That's why it was changed from the original MD5 as suggested by
Bellovin in RFC 1948, to a cut-down MD4.  

And we ***never*** were insane enough to use SHA, or suggest that the
use of SHA was a good idea in this particular application.  I don't
know why some people had the assumption that SHA was ever used in TCP
sequence number generation, but they were wrong; that was never the
case.

						- Ted

Re: [PATCH]

[Jean-Luc Cooke]

On Mon, Aug 09, 2004 at 02:43:24PM -0400, Theodore Ts'o wrote:
> On Sun, Aug 08, 2004 at 11:38:46AM -0400, Jean-Luc Cooke wrote:
> > In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
> > PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
> > message digest & block cipher combo).  The primary advantages of this design
> > would be:
> >  - It's simpler
> >  - It's faster
> >  - It doesn't "rool your own" crypto
> 
> SHA is not going to be faster than the cut-down MD4 --- and you can't
> use a pure random sequence number for the initial TCP sequence number,
> lest a packet from a previous TCP connection get mistaken as belong to
> the newly created TCP stream.  See Bellovin's recommendations for
> secure TCP sequnce number genreation for a discussion of the
> constraints.  
> 
> > If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
> > we're going to propose - you will never care about this since the current
> > state of the pools are always based on all the previous input.
> 
> The Yarrow-type PRNG suffers from the problem that the entropy pool is
> pathetically small.  It fundamentally assumes that the crypto checksum
> is secure, and it is really much more of a *P*RNG than anything else.
> The scheme used in the current /dev/random design is much closer to
> that used by GPG, and relies on a large pool so that we can collect as
> much entropy as possible from the hardware sources available to the
> kernel.  I'm not familiar with the Fortuna PRNG that you're going to
> propose, but my guess is that it will have a similar, much heavier
> dependence on the crypto algorithms in terms of its assumptions.

Fortuna overcomes the small pool size problem.  For the most part, I really
like how the current random.c collects data.  

The only parts we're proposing to replace are:
 - The pooling (thus, mixing) mechanizums as per in Fortuna by Schnier and
   Furguson
 - The random data output mechanizum (Fortuna)
 - TCP sequence number generation (AES in CTR mode truncated to 32 bits, has
   period of 2^32 and cannot be easily determined from pervious sequences)
   I will read your reference and learn from the implementation in random.c
 - TCP SYNcookies to encrypt 8bit "count" value and the 24bit "data" (MSS)
   value with AES in CTR mode.  I can prove that this is exactly what is
   being done now with the "two SHA1 hashes and a bunch of addition" method.

Crutial to my proposal will be not "not rock the boat".  That is, keeping all
important interfaces intact to not break anything else in the kernel.

JLC

Re: [PATCH]

[Theodore Ts'o]

On Sun, Aug 08, 2004 at 11:38:46AM -0400, Jean-Luc Cooke wrote:
> In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
> PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
> message digest & block cipher combo).  The primary advantages of this design
> would be:
>  - It's simpler
>  - It's faster
>  - It doesn't "rool your own" crypto

SHA is not going to be faster than the cut-down MD4 --- and you can't
use a pure random sequence number for the initial TCP sequence number,
lest a packet from a previous TCP connection get mistaken as belong to
the newly created TCP stream.  See Bellovin's recommendations for
secure TCP sequnce number genreation for a discussion of the
constraints.  

> If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
> we're going to propose - you will never care about this since the current
> state of the pools are always based on all the previous input.

The Yarrow-type PRNG suffers from the problem that the entropy pool is
pathetically small.  It fundamentally assumes that the crypto checksum
is secure, and it is really much more of a *P*RNG than anything else.
The scheme used in the current /dev/random design is much closer to
that used by GPG, and relies on a large pool so that we can collect as
much entropy as possible from the hardware sources available to the
kernel.  I'm not familiar with the Fortuna PRNG that you're going to
propose, but my guess is that it will have a similar, much heavier
dependence on the crypto algorithms in terms of its assumptions.

						- Ted

Re: [PATCH]

[Jean-Luc Cooke]

Glad to have you join the discussion Ted!

On Sat, Aug 07, 2004 at 06:26:34PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> > That and it's not endian-correct.  There are other issues with random.c (lack
> > for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> > creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> > madness
> > (what is 2/3's of 16!?!), 
> 
> This was deliberate becasue sequence number generation could not be
> slow for some workloads.  The sequence number attacks that MD4
> protects against are tcp hijacking attacks where the attacker is on
> the network path ---- if you really want security you'd be using real
> crypto for encryption and for integrity protection at the application
> layer.

In our paper (I'm testing the patch now) we'll be proposing using the Fortuna
PRNG inplace of the current design.  It only uses SHA256 and AES256 (or any
message digest & block cipher combo).  The primary advantages of this design
would be:
 - It's simpler
 - It's faster
 - It doesn't "rool your own" crypto

> > the use of LFSRs for "mixing" when they're linear,
> > the polymonials used are not even primitive, 
> 
> The basic idea here is that you can mix in arbitrary amounts of zero
> data without destroying the randomness of the pool.  This is
> important, and was an explicit design goal.

If you pass all input data into a Yarrow-type PRNG - like the Fortuna PRNG
we're going to propose - you will never care about this since the current
state of the pools are always based on all the previous input.

> > the ability for root to wipe-out
> > the random pool, the ability for root to access the random seed directly, the
> > paper I'm co-authoring will explain all of this).
> 
> Yawn.  Root has access to /dev/mem.  Your point?

I guess the point I was trying to make was:
 - You never want to wipe out the pool
 - You never want to let people (not even yourself) get access to the pool
   The closest thing you can do (and the paper will explain this) is hash
   a counter and the data from each of your pools though a message digest
   and concatenate it together.

I'm really putting the horse infront of the cart here.  We'll put a paper up
for lkml to read by the end of the month which will fully explain:
 - Our reasoning
 - Our goals
 - Our results

Cheers,

JLC

Re: [PATCH]

[Theodore Ts'o]

On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> That and it's not endian-correct.  There are other issues with random.c (lack
> for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> madness
> (what is 2/3's of 16!?!), 

This was deliberate becasue sequence number generation could not be
slow for some workloads.  The sequence number attacks that MD4
protects against are tcp hijacking attacks where the attacker is on
the network path ---- if you really want security you'd be using real
crypto for encryption and for integrity protection at the application
layer.

> the use of LFSRs for "mixing" when they're linear,
> the polymonials used are not even primitive, 

The basic idea here is that you can mix in arbitrary amounts of zero
data without destroying the randomness of the pool.  This is
important, and was an explicit design goal.

> the ability for root to wipe-out
> the random pool, the ability for root to access the random seed directly, the
> paper I'm co-authoring will explain all of this).

Yawn.  Root has access to /dev/mem.  Your point?

							- Ted

Re: [PATCH]

[Jean-Luc Cooke]

On Fri, Aug 06, 2004 at 06:24:52PM -0500, Matt Mackall wrote:
> On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> > On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> > > On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> > > 
> > > > James,
> > > >   Back to your question:
> > > >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> > > >     implementations from driver/char/random.c
> > > 
> > > Incorrectly implemented?  Do you mean not appending the bit count?
> > 
> > That and it's not endian-correct.
> 
> Are you saying that it's hashing incorrectly or that the final form is
> not in the standard bit-order? For the purposes of a random number
> generator, the latter isn't terribly important. Nor is it particularly
> important for GUIDs.

The problems with the SHA1 implementation is the least of random.c's
concerns.  But it's just bad taste to tell on-lookers "we use SHA-1" and you
actually don't.  It causes people to re-evailuate your implementation.

Ease of reading, ease of analysis are related to using proper implementations
of cryptographic primitives.

> Last time I proposed a cryptoapi-based version, I couldn't get any
> buy-off on making cryptoapi a non-optional part of the kernel. Looking
> forward to your patch/paper.

I'll credit you for breaking the ice if capi becomes a standard feature.  ;)

JLC

Re: [PATCH]

[Matt Mackall]

On Fri, Aug 06, 2004 at 08:54:27AM -0400, Jean-Luc Cooke wrote:
> On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> > On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> > 
> > > James,
> > >   Back to your question:
> > >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> > >     implementations from driver/char/random.c
> > 
> > Incorrectly implemented?  Do you mean not appending the bit count?
> 
> That and it's not endian-correct.

Are you saying that it's hashing incorrectly or that the final form is
not in the standard bit-order? For the purposes of a random number
generator, the latter isn't terribly important. Nor is it particularly
important for GUIDs.

> There are other issues with random.c (lack
> for forward secrecy in the case of seed discovery, use of the insecure MD4 in
> creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
> madness
> (what is 2/3's of 16!?!), the use of LFSRs for "mixing" when they're linear,
> the polymonials used are not even primitive, the ability for root to wipe-out
> the random pool, the ability for root to access the random seed directly, the
> paper I'm co-authoring will explain all of this).
> 
> Basically, the paper will be describing about 12 security problems with the
> current random.c and propose (with patch included) a new design that solves
> all of these, uses crypto-api, uses known crypto primitives, is simpler to
> read
> and analyse and for a bonus is 2x to 4x faster in adding and retrieving data
> from the pool.

Last time I proposed a cryptoapi-based version, I couldn't get any
buy-off on making cryptoapi a non-optional part of the kernel. Looking
forward to your patch/paper.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [PATCH]

[Jean-Luc Cooke]

OK then,

I tried.  scretterlists it is... I'm a push over.  ;)

JLC

On Fri, Aug 06, 2004 at 11:26:46AM -0700, David S. Miller wrote:
> On Fri, 6 Aug 2004 08:54:27 -0400
> Jean-Luc Cooke <jlcooke@certainkey.com> wrote:
> 
> > If I can avoid scatter-gather for what is effectively just mixing bytes with
> > SHA256
> > & AES256 then this would make things very neat and tidy (read: easier for
> > peer review)
> 
> Why do you care about scatter gather at all?  You need to allocate
> a kernel buffer to copy the user bits into _anyways_.  Once you
> have a kernel buffer, doing a quick onstack one-entry scatter list
> is simple.
> 
> If you're trying to use the user buffer directly, sorry we're not
> going to add support for that, as Linus explained it's silly.

Re: [PATCH]

[David S. Miller]

On Fri, 6 Aug 2004 08:54:27 -0400
Jean-Luc Cooke <jlcooke@certainkey.com> wrote:

> If I can avoid scatter-gather for what is effectively just mixing bytes with
> SHA256
> & AES256 then this would make things very neat and tidy (read: easier for
> peer review)

Why do you care about scatter gather at all?  You need to allocate
a kernel buffer to copy the user bits into _anyways_.  Once you
have a kernel buffer, doing a quick onstack one-entry scatter list
is simple.

If you're trying to use the user buffer directly, sorry we're not
going to add support for that, as Linus explained it's silly.

Re: [PATCH]

[Jean-Luc Cooke]

On Thu, Aug 05, 2004 at 09:58:58PM -0700, Linus Torvalds wrote:
> So I'd strongly suggest against doing any "raw crypto access". Zero-copy
> is often just a complicated way of doing things slowly, all in the name of
> some benchmark performance.

I hear you, these are all desirable things and I hate trying to be the black
sheep - but would random.c make sense in being the exception since the
outward looking interfaces (random_write for example) all use const char*
type as arguments?

Keeping the existing random.c interface and using crypto-api's scatter-gather
interface are kind of contradictory ... or and I really missing something
important (likely)?

JLC

Re: [PATCH]

[Jean-Luc Cooke]

On Fri, Aug 06, 2004 at 12:42:38AM -0400, James Morris wrote:
> On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:
> 
> > James,
> >   Back to your question:
> >     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
> >     implementations from driver/char/random.c
> 
> Incorrectly implemented?  Do you mean not appending the bit count?

That and it's not endian-correct.  There are other issues with random.c (lack
for forward secrecy in the case of seed discovery, use of the insecure MD4 in
creating syn and seq# for tcp, the use of halfMD4 and twothridsMD4 is
madness
(what is 2/3's of 16!?!), the use of LFSRs for "mixing" when they're linear,
the polymonials used are not even primitive, the ability for root to wipe-out
the random pool, the ability for root to access the random seed directly, the
paper I'm co-authoring will explain all of this).

Basically, the paper will be describing about 12 security problems with the
current random.c and propose (with patch included) a new design that solves
all of these, uses crypto-api, uses known crypto primitives, is simpler to
read
and analyse and for a bonus is 2x to 4x faster in adding and retrieving data
from the pool.

If I can avoid scatter-gather for what is effectively just mixing bytes with
SHA256
& AES256 then this would make things very neat and tidy (read: easier for
peer review)

Cheers,

JLC

Re: [PATCH]

[Linus Torvalds]

On Thu, 5 Aug 2004, Michael Halcrow wrote:
> 
> I often have a virtual address to work with in the first place, and
> the data that I hash usually occupies less than one page (passphrases,
> keys, etc.).

Ehh. A lot of encryption algorithms are not re-entrant, which means that 
you can't take page faults in the middle without serious trouble.

And if the data is smaller than a page, then it's cheaper to just copy it
into kernel memory than it is to try to follow the page tables by hand.  
One is usually nice cached accesses, the other one is nasty code with
locking and often totally uncached.

So I'd strongly suggest against doing any "raw crypto access". Zero-copy
is often just a complicated way of doing things slowly, all in the name of
some benchmark performance.

		Linus

Re: [PATCH]

[James Morris]

On Fri, 6 Aug 2004, Jean-Luc Cooke wrote:

> James,
>   Back to your question:
>     I want to replace the legacy MD5 and the incorrectly implemented SHA-1
>     implementations from driver/char/random.c

Incorrectly implemented?  Do you mean not appending the bit count?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH]

[Jean-Luc Cooke]

On Thu, Aug 05, 2004 at 08:36:23PM -0700, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <Xine.LNX.4.44.0408052245380.20516-100000@dhcp83-76.boston.redhat.com> (at Thu, 5 Aug 2004 22:47:12 -0400 (EDT)), James Morris <jmorris@redhat.com> says:
> 
> > > Would you be against a patch to cryptoapi to have access to a
> > > non-scatter-list set of calls?
> :
> > level.  Can you demonstrate a compelling need for raw access to the
> > algorithms via the API?
> 
> I would use them for
>  - Privacy Extensions (RFC3041) support
>  - upcoming TCP MD5 signature (RFC2385) support
> since I don't see the advantage(s) of sg for allocated memories there.

Thank you for your input.  But please read this note in the RFC2385:
http://www.faqs.org/rfcs/rfc2385.html
 "Section 4.4: MD5 as a Hashing Algorithm"
 It talks about MD5 as an insecure algorithm and how changing it would
 require a new RFC, which make me sad.
 If you could add support for SHA-1 as well that would be nifty.
 
James,
  Back to your question:
    I want to replace the legacy MD5 and the incorrectly implemented SHA-1
    implementations from driver/char/random.c

Thanks, cheers!

JLC

Re: [PATCH]

[David S. Miller]

On Thu, 05 Aug 2004 20:36:23 -0700 (PDT)
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B <yoshfuji@linux-ipv6.org> wrote:

> In article <Xine.LNX.4.44.0408052245380.20516-100000@dhcp83-76.boston.redhat.com> (at Thu, 5 Aug 2004 22:47:12 -0400 (EDT)), James Morris <jmorris@redhat.com> says:
> 
> > > Would you be against a patch to cryptoapi to have access to a
> > > non-scatter-list set of calls?
> :
> > level.  Can you demonstrate a compelling need for raw access to the
> > algorithms via the API?
> 
> I would use them for
>  - Privacy Extensions (RFC3041) support
>  - upcoming TCP MD5 signature (RFC2385) support
> since I don't see the advantage(s) of sg for allocated memories there.

But here is the problem, it's going to be implemented as a scatter-
gather list on the stack to pass on to the actual crypto layer.

If you just blindly use this new interface, you may not be aware
of this overhead and thus not consider moving to sg-based methods.
This is what I want to avoid.

Yes, it is social engineering. :-)

I see nothing wrong with explicitly coding things out, as we do
now.

Re: [PATCH]

[YOSHIFUJI Hideaki / 吉藤英明]

In article <Xine.LNX.4.44.0408052245380.20516-100000@dhcp83-76.boston.redhat.com> (at Thu, 5 Aug 2004 22:47:12 -0400 (EDT)), James Morris <jmorris@redhat.com> says:

> > Would you be against a patch to cryptoapi to have access to a
> > non-scatter-list set of calls?
:
> level.  Can you demonstrate a compelling need for raw access to the
> algorithms via the API?

I would use them for
 - Privacy Extensions (RFC3041) support
 - upcoming TCP MD5 signature (RFC2385) support
since I don't see the advantage(s) of sg for allocated memories there.

--yoshfuji

Re: [PATCH]

[James Morris]

On Thu, 5 Aug 2004, Jean-Luc Cooke wrote:

> Would you be against a patch to cryptoapi to have access to a
> non-scatter-list set of calls?
> 
> I know a few people would like to see that , and I would also like to use
> some low-level:
> 
> crypto_digest_update_byte(struct digest_alg *digest,
>                           unsigned char *buf,
>                           unsigned int  nbytes);
> crypto_cipher_encrypt_byte(struct cipher_alg *cipher,
>                            unsigned char *dst,
>                            unsigned char *src,
>                            unsigned int  nbytes);
> 
> I'm in the middle of preparing for a paper and would like to get code running
> without scatterlists.

The idea of the scatterlist API is to encourage encryption at the page
level.  Can you demonstrate a compelling need for raw access to the
algorithms via the API?


- James
-- 
James Morris
<jmorris@redhat.com>

Re: [PATCH]

[Michael Halcrow]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Thu, Aug 05, 2004 at 10:47:12PM -0400, James Morris wrote:
> On Thu, 5 Aug 2004, Jean-Luc Cooke wrote:
> 
> > Would you be against a patch to cryptoapi to have access to a
> > non-scatter-list set of calls?
> > 
> > I know a few people would like to see that , and I would also like to use
> > some low-level:
> > 
> > crypto_digest_update_byte(struct digest_alg *digest,
> >                           unsigned char *buf,
> >                           unsigned int  nbytes);
> > crypto_cipher_encrypt_byte(struct cipher_alg *cipher,
> >                            unsigned char *dst,
> >                            unsigned char *src,
> >                            unsigned int  nbytes);
> > 
> > I'm in the middle of preparing for a paper and would like to get code running
> > without scatterlists.
> 
> The idea of the scatterlist API is to encourage encryption at the
> page level.  Can you demonstrate a compelling need for raw access to
> the algorithms via the API?

I often have a virtual address to work with in the first place, and
the data that I hash usually occupies less than one page (passphrases,
keys, etc.).

Mike
.___________________________________________________________________.
                         Michael A. Halcrow                          
       Security Software Engineer, IBM Linux Technology Center       
GnuPG Fingerprint: 05B5 08A8 713A 64C1 D35D  2371 2D3C FDDA 3EB6 601D

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH]

[Jean-Luc Cooke]

James,

Would you be against a patch to cryptoapi to have access to a
non-scatter-list set of calls?

I know a few people would like to see that , and I would also like to use
some low-level:

crypto_digest_update_byte(struct digest_alg *digest,
                          unsigned char *buf,
                          unsigned int  nbytes);
crypto_cipher_encrypt_byte(struct cipher_alg *cipher,
                           unsigned char *dst,
                           unsigned char *src,
                           unsigned int  nbytes);

I'm in the middle of preparing for a paper and would like to get code running
without scatterlists.

Cheers,

JLC

On Thu, Aug 05, 2004 at 10:11:14AM -0400, James Morris wrote:
> On Thu, 5 Aug 2004, Michal Ludvig wrote:
> 
> > Hi James,
> > 
> > the aes-i586 patch recently added to BK breaks compilation of AES on
> > non-i586 platforms. Attached patch fixes it.
> 
> Thanks, the code is about to be dropped and replaced, so we need to
> remember to fix it then.
> 
> 
> - James
> -- 
> James Morris
> <jmorris@redhat.com>
> 
> 
> _______________________________________________
> 
> Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
> List archive: http://lists.logix.cz/pipermail/cryptoapi

Re: [PATCH]

[James Morris]

On Thu, 5 Aug 2004, Michal Ludvig wrote:

> Hi James,
> 
> the aes-i586 patch recently added to BK breaks compilation of AES on
> non-i586 platforms. Attached patch fixes it.

Thanks, the code is about to be dropped and replaced, so we need to
remember to fix it then.


- James
-- 
James Morris
<jmorris@redhat.com>

[PATCH]

[Michal Ludvig]

[-- Attachment #1.1: Type: text/plain, Size: 481 bytes --]

Hi James,

the aes-i586 patch recently added to BK breaks compilation of AES on
non-i586 platforms. Attached patch fixes it.

BTW Why was the config option renamed to CRYPTO_AES_GENERIC? The
optimized implementations had their own names anyway (e.g.
CRYPTO_AES_586) and wouldn't collide. Couldn't we revert this little change?

Michal Ludvig
-- 
SUSE Labs                    mludvig@suse.cz
(+420) 296.542.396        http://www.suse.cz
Personal homepage http://www.logix.cz/michal

[-- Attachment #1.2: build-crypto-aes --]
[-- Type: text/plain, Size: 586 bytes --]

Index: linux-2.6.7/crypto/Makefile
===================================================================
--- linux-2.6.7.orig/crypto/Makefile	2004-08-05 17:44:32.428599792 +0200
+++ linux-2.6.7/crypto/Makefile	2004-08-05 17:46:07.589133192 +0200
@@ -18,7 +18,7 @@
 obj-$(CONFIG_CRYPTO_BLOWFISH) += blowfish.o
 obj-$(CONFIG_CRYPTO_TWOFISH) += twofish.o
 obj-$(CONFIG_CRYPTO_SERPENT) += serpent.o
-obj-$(CONFIG_CRYPTO_AES) += aes.o
+obj-$(CONFIG_CRYPTO_AES_GENERIC) += aes.o
 obj-$(CONFIG_CRYPTO_CAST5) += cast5.o
 obj-$(CONFIG_CRYPTO_CAST6) += cast6.o
 obj-$(CONFIG_CRYPTO_ARC4) += arc4.o

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[PATCH]

[davej]

>From Dave Richards (drichards@mahinetworks.com)

While diagnosing an MMX/FPU problem I found a minor problem in the code
which diagnoses and generates signals for FPU exceptions. On x86 Stack
Fault Exception are a subclass of Invalid Operation. Thus, the FPU status
register will have both the SF and IF bits set when a stack fault occurs.
The code which turns FPU exceptions into signals was assuming IF would be
clear:

diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/traps.c linux-2.5/arch/i386/kernel/traps.c
--- bk-linus/arch/i386/kernel/traps.c	2003-06-26 19:49:20.000000000 +0100
+++ linux-2.5/arch/i386/kernel/traps.c	2003-06-26 20:11:29.000000000 +0100
@@ -629,9 +629,10 @@ void math_error(void *eip)
 		default:
 			break;
 		case 0x001: /* Invalid Op */
-		case 0x040: /* Stack Fault */
-		case 0x240: /* Stack Fault | Direction */
+		case 0x041: /* Stack Fault */
+		case 0x241: /* Stack Fault | Direction */
 			info.si_code = FPE_FLTINV;
+			/* Should we clear the SF or let user space do it ???? */
 			break;
 		case 0x002: /* Denormalize */
 		case 0x010: /* Underflow */

[patch]

[Adrian Bunk]

gcc 3.3 correctly gives the following warning:

<--  snip  -->

...
  CC      drivers/mtd/ftl.o
drivers/mtd/ftl.c: In function `scan_header':
drivers/mtd/ftl.c:191: warning: comparison is always false due to 
limited range 
...

<--  snip  -->

Looking at the code it seems gcc is correct, a 16bit number can _never_
be > 65536.

The following patch removes this comparison:


--- linux-2.6.0-test2-full/drivers/mtd/ftl.c.old	2003-07-30 13:04:05.000000000 +0200
+++ linux-2.6.0-test2-full/drivers/mtd/ftl.c	2003-07-30 13:04:13.000000000 +0200
@@ -188,7 +188,7 @@
 	printk(KERN_NOTICE "ftl_cs: FTL header not found.\n");
 	return -ENOENT;
     }
-    if ((le16_to_cpu(header.NumEraseUnits) > 65536) || header.BlockSize != 9 ||
+    if (header.BlockSize != 9 ||
 	(header.EraseUnitSize < 10) || (header.EraseUnitSize > 31) ||
 	(header.NumTransferUnits >= le16_to_cpu(header.NumEraseUnits))) {
 	printk(KERN_NOTICE "ftl_cs: FTL header corrupt!\n");



I've tested the compilation with 2.6.0-test2 and 2.4.22-pre9.


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

[PATCH]

[Paul Mackerras]

Linus,

This patch is a forward-port from 2.4.  It changes the pcmcia resource
allocation code so that it allocates IO and memory resources from the
correct resource parent.  The details were discussed on lkml last year
in the 2.4 context.  I need this on powerbooks because they have
multiple PCI host bridges.  Please apply this to your tree.

Paul.

diff -urN linux-2.5/drivers/pcmcia/cistpl.c pmac-2.5/drivers/pcmcia/cistpl.c
--- linux-2.5/drivers/pcmcia/cistpl.c	Tue Feb  5 18:55:14 2002
+++ pmac-2.5/drivers/pcmcia/cistpl.c	Sun Jul 21 14:01:56 2002
@@ -264,11 +264,11 @@
 	(s->cis_mem.sys_start == 0)) {
 	int low = !(s->cap.features & SS_CAP_PAGE_REGS);
 	vs = s;
-	validate_mem(cis_readable, checksum_match, low);
+	validate_mem(cis_readable, checksum_match, low, s);
 	s->cis_mem.sys_start = 0;
 	vs = NULL;
 	if (find_mem_region(&s->cis_mem.sys_start, s->cap.map_size,
-			    s->cap.map_size, low, "card services")) {
+			    s->cap.map_size, low, "card services", s)) {
 	    printk(KERN_NOTICE "cs: unable to map card memory!\n");
 	    return CS_OUT_OF_RESOURCE;
 	}
diff -urN linux-2.5/drivers/pcmcia/cs.c pmac-2.5/drivers/pcmcia/cs.c
--- linux-2.5/drivers/pcmcia/cs.c	Tue Feb  5 18:55:14 2002
+++ pmac-2.5/drivers/pcmcia/cs.c	Sat Jul 20 20:41:46 2002
@@ -809,7 +809,7 @@
 	    return 1;
     for (i = 0; i < MAX_IO_WIN; i++) {
 	if (s->io[i].NumPorts == 0) {
-	    if (find_io_region(base, num, align, name) == 0) {
+	    if (find_io_region(base, num, align, name, s) == 0) {
 		s->io[i].Attributes = attr;
 		s->io[i].BasePort = *base;
 		s->io[i].NumPorts = s->io[i].InUse = num;
@@ -821,7 +821,7 @@
 	/* Try to extend top of window */
 	try = s->io[i].BasePort + s->io[i].NumPorts;
 	if ((*base == 0) || (*base == try))
-	    if (find_io_region(&try, num, 0, name) == 0) {
+	    if (find_io_region(&try, num, 0, name, s) == 0) {
 		*base = try;
 		s->io[i].NumPorts += num;
 		s->io[i].InUse += num;
@@ -830,7 +830,7 @@
 	/* Try to extend bottom of window */
 	try = s->io[i].BasePort - num;
 	if ((*base == 0) || (*base == try))
-	    if (find_io_region(&try, num, 0, name) == 0) {
+	    if (find_io_region(&try, num, 0, name, s) == 0) {
 		s->io[i].BasePort = *base = try;
 		s->io[i].NumPorts += num;
 		s->io[i].InUse += num;
@@ -1974,7 +1974,7 @@
 	find_mem_region(&win->base, win->size, align,
 			(req->Attributes & WIN_MAP_BELOW_1MB) ||
 			!(s->cap.features & SS_CAP_PAGE_REGS),
-			(*handle)->dev_info))
+			(*handle)->dev_info, s))
 	return CS_IN_USE;
     (*handle)->state |= CLIENT_WIN_REQ(w);
 
diff -urN linux-2.5/drivers/pcmcia/cs_internal.h pmac-2.5/drivers/pcmcia/cs_internal.h
--- linux-2.5/drivers/pcmcia/cs_internal.h	Wed Feb  6 04:40:18 2002
+++ pmac-2.5/drivers/pcmcia/cs_internal.h	Sat Jul 20 20:38:06 2002
@@ -238,11 +238,11 @@
 
 /* In rsrc_mgr */
 void validate_mem(int (*is_valid)(u_long), int (*do_cksum)(u_long),
-		  int force_low);
+		  int force_low, socket_info_t *s);
 int find_io_region(ioaddr_t *base, ioaddr_t num, ioaddr_t align,
-		   char *name);
+		   char *name, socket_info_t *s);
 int find_mem_region(u_long *base, u_long num, u_long align,
-		    int force_low, char *name);
+		    int force_low, char *name, socket_info_t *s);
 int try_irq(u_int Attributes, int irq, int specific);
 void undo_irq(u_int Attributes, int irq);
 int adjust_resource_info(client_handle_t handle, adjust_t *adj);
diff -urN linux-2.5/drivers/pcmcia/rsrc_mgr.c pmac-2.5/drivers/pcmcia/rsrc_mgr.c
--- linux-2.5/drivers/pcmcia/rsrc_mgr.c	Tue Feb  5 18:55:14 2002
+++ pmac-2.5/drivers/pcmcia/rsrc_mgr.c	Sun Jul 21 14:02:02 2002
@@ -44,6 +44,7 @@
 #include <linux/ioport.h>
 #include <linux/timer.h>
 #include <linux/proc_fs.h>
+#include <linux/pci.h>
 #include <asm/irq.h>
 #include <asm/io.h>
 
@@ -103,8 +104,82 @@
 
 ======================================================================*/
 
-#define check_io_resource(b,n)	check_resource(&ioport_resource, (b), (n))
-#define check_mem_resource(b,n)	check_resource(&iomem_resource, (b), (n))
+static struct resource *resource_parent(unsigned long b, unsigned long n,
+					int flags, struct pci_dev *dev)
+{
+#ifdef CONFIG_PCI
+	struct resource res, *pr;
+
+	if (dev != NULL) {
+		res.start = b;
+		res.end = b + n - 1;
+		res.flags = flags;
+		pr = pci_find_parent_resource(dev, &res);
+		if (pr)
+			return pr;
+	}
+#endif /* CONFIG_PCI */
+	if (flags & IORESOURCE_MEM)
+		return &iomem_resource;
+	return &ioport_resource;
+}
+
+static inline int check_io_resource(unsigned long b, unsigned long n,
+				    struct pci_dev *dev)
+{
+	return check_resource(resource_parent(b, n, IORESOURCE_IO, dev), b, n);
+}
+
+static inline int check_mem_resource(unsigned long b, unsigned long n,
+				     struct pci_dev *dev)
+{
+	return check_resource(resource_parent(b, n, IORESOURCE_MEM, dev), b, n);
+}
+
+static struct resource *make_resource(unsigned long b, unsigned long n,
+				      int flags, char *name)
+{
+	struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
+
+	if (res) {
+		memset(res, 0, sizeof(*res));
+		res->name = name;
+		res->start = b;
+		res->end = b + n - 1;
+		res->flags = flags | IORESOURCE_BUSY;
+	}
+	return res;
+}
+
+static int request_io_resource(unsigned long b, unsigned long n,
+			       char *name, struct pci_dev *dev)
+{
+	struct resource *res = make_resource(b, n, IORESOURCE_IO, name);
+	struct resource *pr = resource_parent(b, n, IORESOURCE_IO, dev);
+	int err = -ENOMEM;
+
+	if (res) {
+		err = request_resource(pr, res);
+		if (err)
+			kfree(res);
+	}
+	return err;
+}
+
+static int request_mem_resource(unsigned long b, unsigned long n,
+				char *name, struct pci_dev *dev)
+{
+	struct resource *res = make_resource(b, n, IORESOURCE_MEM, name);
+	struct resource *pr = resource_parent(b, n, IORESOURCE_MEM, dev);
+	int err = -ENOMEM;
+
+	if (res) {
+		err = request_resource(pr, res);
+		if (err)
+			kfree(res);
+	}
+	return err;
+}
 
 /*======================================================================
 
@@ -194,7 +269,7 @@
     }   
     memset(b, 0, 256);
     for (i = base, most = 0; i < base+num; i += 8) {
-	if (check_io_resource(i, 8))
+	if (check_io_resource(i, 8, NULL))
 	    continue;
 	hole = inb(i);
 	for (j = 1; j < 8; j++)
@@ -207,7 +282,7 @@
 
     bad = any = 0;
     for (i = base; i < base+num; i += 8) {
-	if (check_io_resource(i, 8))
+	if (check_io_resource(i, 8, NULL))
 	    continue;
 	for (j = 0; j < 8; j++)
 	    if (inb(i+j) != most) break;
@@ -247,7 +322,8 @@
 ======================================================================*/
 
 static int do_mem_probe(u_long base, u_long num,
-			int (*is_valid)(u_long), int (*do_cksum)(u_long))
+			int (*is_valid)(u_long), int (*do_cksum)(u_long),
+			socket_info_t *s)
 {
     u_long i, j, bad, fail, step;
 
@@ -258,13 +334,14 @@
     for (i = j = base; i < base+num; i = j + step) {
 	if (!fail) {	
 	    for (j = i; j < base+num; j += step)
-		if ((check_mem_resource(j, step) == 0) && is_valid(j))
+		if ((check_mem_resource(j, step, s->cap.cb_dev) == 0) &&
+		    is_valid(j))
 		    break;
 	    fail = ((i == base) && (j == base+num));
 	}
 	if (fail) {
 	    for (j = i; j < base+num; j += 2*step)
-		if ((check_mem_resource(j, 2*step) == 0) &&
+		if ((check_mem_resource(j, 2*step, s->cap.cb_dev) == 0) &&
 		    do_cksum(j) && do_cksum(j+step))
 		    break;
 	}
@@ -283,12 +360,12 @@
 
 static u_long inv_probe(int (*is_valid)(u_long),
 			int (*do_cksum)(u_long),
-			resource_map_t *m)
+			resource_map_t *m, socket_info_t *s)
 {
     u_long ok;
     if (m == &mem_db)
 	return 0;
-    ok = inv_probe(is_valid, do_cksum, m->next);
+    ok = inv_probe(is_valid, do_cksum, m->next, s);
     if (ok) {
 	if (m->base >= 0x100000)
 	    sub_interval(&mem_db, m->base, m->num);
@@ -296,11 +373,11 @@
     }
     if (m->base < 0x100000)
 	return 0;
-    return do_mem_probe(m->base, m->num, is_valid, do_cksum);
+    return do_mem_probe(m->base, m->num, is_valid, do_cksum, s);
 }
 
 void validate_mem(int (*is_valid)(u_long), int (*do_cksum)(u_long),
-		  int force_low)
+		  int force_low, socket_info_t *s)
 {
     resource_map_t *m, *n;
     static u_char order[] = { 0xd0, 0xe0, 0xc0, 0xf0 };
@@ -310,7 +387,7 @@
     if (!probe_mem) return;
     /* We do up to four passes through the list */
     if (!force_low) {
-	if (hi++ || (inv_probe(is_valid, do_cksum, mem_db.next) > 0))
+	if (hi++ || (inv_probe(is_valid, do_cksum, mem_db.next, s) > 0))
 	    return;
 	printk(KERN_NOTICE "cs: warning: no high memory space "
 	       "available!\n");
@@ -321,7 +398,7 @@
 	/* Only probe < 1 MB */
 	if (m->base >= 0x100000) continue;
 	if ((m->base | m->num) & 0xffff) {
-	    ok += do_mem_probe(m->base, m->num, is_valid, do_cksum);
+	    ok += do_mem_probe(m->base, m->num, is_valid, do_cksum, s);
 	    continue;
 	}
 	/* Special probe for 64K-aligned block */
@@ -331,7 +408,7 @@
 		if (ok >= mem_limit)
 		    sub_interval(&mem_db, b, 0x10000);
 		else
-		    ok += do_mem_probe(b, 0x10000, is_valid, do_cksum);
+		    ok += do_mem_probe(b, 0x10000, is_valid, do_cksum, s);
 	    }
 	}
     }
@@ -340,7 +417,7 @@
 #else /* CONFIG_ISA */
 
 void validate_mem(int (*is_valid)(u_long), int (*do_cksum)(u_long),
-		  int force_low)
+		  int force_low, socket_info_t *s)
 {
     resource_map_t *m;
     static int done = 0;
@@ -348,7 +425,7 @@
     if (!probe_mem || done++)
 	return;
     for (m = mem_db.next; m != &mem_db; m = m->next)
-	if (do_mem_probe(m->base, m->num, is_valid, do_cksum))
+	if (do_mem_probe(m->base, m->num, is_valid, do_cksum, s))
 	    return;
 }
 
@@ -368,7 +445,7 @@
 ======================================================================*/
 
 int find_io_region(ioaddr_t *base, ioaddr_t num, ioaddr_t align,
-		   char *name)
+		   char *name, socket_info_t *s)
 {
     ioaddr_t try;
     resource_map_t *m;
@@ -378,9 +455,8 @@
 	for (try = (try >= m->base) ? try : try+align;
 	     (try >= m->base) && (try+num <= m->base+m->num);
 	     try += align) {
-	    if (check_io_resource(try, num) == 0) {
+	    if (request_io_resource(try, num, name, s->cap.cb_dev) == 0) {
 		*base = try;
-		request_region(try, num, name);
 		return 0;
 	    }
 	    if (!align) break;
@@ -390,7 +466,7 @@
 }
 
 int find_mem_region(u_long *base, u_long num, u_long align,
-		    int force_low, char *name)
+		    int force_low, char *name, socket_info_t *s)
 {
     u_long try;
     resource_map_t *m;
@@ -403,8 +479,7 @@
 	    for (try = (try >= m->base) ? try : try+align;
 		 (try >= m->base) && (try+num <= m->base+m->num);
 		 try += align) {
-		if (check_mem_resource(try, num) == 0) {
-		    request_mem_region(try, num, name);
+		if (request_mem_resource(try, num, name, s->cap.cb_dev) == 0) {
 		    *base = try;
 		    return 0;
 		}

Re: [PATCH]

[Andre Hedrick]

This patch is not going anywhere for a while, until all the archs have
consistant local_*_*() spinlock but I noted what needs to be fixed and who
broke what.

I have another method but it was not reasonable or predictable until I
finish the driver conversion to fully modular and delete 95% of the
duplicated code mess I made over the years.

Your are free to copy it into 2.5 as always.

regards,

--andre

On Tue, 16 Apr 2002, Jens Axboe wrote:

> On Mon, Apr 15 2002, Andre Hedrick wrote:
> > 
> > It is 99% usage for distro to ship stable booting kernels given atapi is
> > flakey.  However if you have a suggestion I am accepting options
> 
> I agree with the option, just not the way it is implemented. If I want
> to enable dma after boot, I must be able to do so.
> 
> I have a solution, the current SuSE kernel gets it right. I'll backport
> that to 2.4.19-pre once this patch is in.
> 
> -- 
> Jens Axboe
> 

Re: [PATCH]

[Jens Axboe]

On Mon, Apr 15 2002, Andre Hedrick wrote:
> 
> It is 99% usage for distro to ship stable booting kernels given atapi is
> flakey.  However if you have a suggestion I am accepting options

I agree with the option, just not the way it is implemented. If I want
to enable dma after boot, I must be able to do so.

I have a solution, the current SuSE kernel gets it right. I'll backport
that to 2.4.19-pre once this patch is in.

-- 
Jens Axboe

Re: [PATCH]

[Andre Hedrick]

It is 99% usage for distro to ship stable booting kernels given atapi is
flakey.  However if you have a suggestion I am accepting options

--andre

On Tue, 16 Apr 2002, Jens Axboe wrote:

> On Mon, Apr 15 2002, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2
> 
> seems that you haven't fixed the case where you cannot enable dma on an
> atapi drive if CONFIG_IDEDMA_ONLYDISK has been selected? to me this is a
> bug -- I don't want auto-enable of dma on my atapi drives, but I surely
> want to be able to hdparm -d1 them at will later on.
> 
> -- 
> Jens Axboe
> 

Re: [PATCH]

[Jens Axboe]

On Mon, Apr 15 2002, Andre Hedrick wrote:
> 
> http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2

seems that you haven't fixed the case where you cannot enable dma on an
atapi drive if CONFIG_IDEDMA_ONLYDISK has been selected? to me this is a
bug -- I don't want auto-enable of dma on my atapi drives, but I surely
want to be able to hdparm -d1 them at will later on.

-- 
Jens Axboe

Re: [PATCH]

[Andre Hedrick]

Yep,

Edit ide-taskfile.c find ide_driveid_update

Changes the #if 1 to #if 0

Attempting to make the code compress but it appears that entry for
updating is more than a simple direct call.  Still banging it out.

Cheers,

On Mon, 15 Apr 2002, Josh McKinney wrote:

> On approximately Mon, Apr 15, 2002 at 12:59:20PM -0700, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2
> > 
> > Lets try it again, I diffed the wrong tree :-/
> > 
> 
> Well it compiled fine this time, but it seems to have problems with gcc-3.0.4 I am using to
> compile kernels.  This gcc has been fine for all other uses, but it must be something with this
> particular build because gcc-2.95.4 works without a problem.  Anyways, here is the oops report
> if it may interest you.
> 
> <1>Unable to handle kernel paging request at virtual address 3fff432a
> c01c2c90
> *pde = 00000000
> Oops: 0000
> CPU:    0
> EIP:    0010:[<c01c2c90>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010202
> eax: 3fff427a   ebx: c02fc928   ecx: 00000001   edx: dda11e04
> esi: c02fc928   edi: dda11e98   ebp: bffff7f0   esp: dda11e04
> ds: 0018   es: 0018   ss: 0018
> Process hdparm (pid: 492, stackpage=dda11000)
> Stack: 3fff427a 00100000 0258e100 0010003f 000e0000 2d575744 39504d41 30353136
>        31003238 00000000 10000003 30320028 35422e30 57443032 57444320 30423630
>        3332422d 41304358 20202020 20202020 20202020 20202020 20202020 80102020
> Code: 0f b7 80 b0 00 00 00 8b 93 f0 00 00 00 66 89 82 b0 00 00 00
> 
> 
> >>EIP; c01c2c90 <ide_driveid_update+30/90>   <=====
> 
> >>eax; 3fff427a Before first symbol
> >>ebx; c02fc928 <ide_hwifs+388/20a8>
> >>edx; dda11e04 <_end+1d70bb50/2253ad4c>
> >>esi; c02fc928 <ide_hwifs+388/20a8>
> >>edi; dda11e98 <_end+1d70bbe4/2253ad4c>
> >>ebp; bffff7f0 Before first symbol
> >>esp; dda11e04 <_end+1d70bb50/2253ad4c>
> 
> Code;  c01c2c90 <ide_driveid_update+30/90>
> 00000000 <_EIP>:
> Code;  c01c2c90 <ide_driveid_update+30/90>   <=====
>    0:   0f b7 80 b0 00 00 00      movzwl 0xb0(%eax),%eax   <=====
> Code;  c01c2c97 <ide_driveid_update+37/90>
>    7:   8b 93 f0 00 00 00         mov    0xf0(%ebx),%edx
> Code;  c01c2c9d <ide_driveid_update+3d/90>
>    d:   66 89 82 b0 00 00 00      mov    %ax,0xb0(%edx)
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Josh McKinney]

On approximately Mon, Apr 15, 2002 at 12:59:20PM -0700, Andre Hedrick wrote:
> 
> http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2
> 
> Lets try it again, I diffed the wrong tree :-/
> 

Well it compiled fine this time, but it seems to have problems with gcc-3.0.4 I am using to
compile kernels.  This gcc has been fine for all other uses, but it must be something with this
particular build because gcc-2.95.4 works without a problem.  Anyways, here is the oops report
if it may interest you.

<1>Unable to handle kernel paging request at virtual address 3fff432a
c01c2c90
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c01c2c90>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 3fff427a   ebx: c02fc928   ecx: 00000001   edx: dda11e04
esi: c02fc928   edi: dda11e98   ebp: bffff7f0   esp: dda11e04
ds: 0018   es: 0018   ss: 0018
Process hdparm (pid: 492, stackpage=dda11000)
Stack: 3fff427a 00100000 0258e100 0010003f 000e0000 2d575744 39504d41 30353136
       31003238 00000000 10000003 30320028 35422e30 57443032 57444320 30423630
       3332422d 41304358 20202020 20202020 20202020 20202020 20202020 80102020
Code: 0f b7 80 b0 00 00 00 8b 93 f0 00 00 00 66 89 82 b0 00 00 00


>>EIP; c01c2c90 <ide_driveid_update+30/90>   <=====

>>eax; 3fff427a Before first symbol
>>ebx; c02fc928 <ide_hwifs+388/20a8>
>>edx; dda11e04 <_end+1d70bb50/2253ad4c>
>>esi; c02fc928 <ide_hwifs+388/20a8>
>>edi; dda11e98 <_end+1d70bbe4/2253ad4c>
>>ebp; bffff7f0 Before first symbol
>>esp; dda11e04 <_end+1d70bb50/2253ad4c>

Code;  c01c2c90 <ide_driveid_update+30/90>
00000000 <_EIP>:
Code;  c01c2c90 <ide_driveid_update+30/90>   <=====
   0:   0f b7 80 b0 00 00 00      movzwl 0xb0(%eax),%eax   <=====
Code;  c01c2c97 <ide_driveid_update+37/90>
   7:   8b 93 f0 00 00 00         mov    0xf0(%ebx),%edx
Code;  c01c2c9d <ide_driveid_update+3d/90>
   d:   66 89 82 b0 00 00 00      mov    %ax,0xb0(%edx)

Re: [PATCH]

[Andre Hedrick]

http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2

Lets try it again, I diffed the wrong tree :-/

On Mon, 15 Apr 2002, Josh McKinney wrote:

> On approximately Mon, Apr 15, 2002 at 11:39:14AM -0700, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3a.patch.bz2
> > 
> Just got this when compiling...
> 
> drivers/ide/idedriver.o: In function `task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x9f1): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `flagged_task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x14c7): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_cmd_ioctl':
> drivers/ide/idedriver.o(.text+0x23e0): undefined reference to `set_transfer'
> drivers/ide/idedriver.o(.text+0x23fc): undefined reference to `ide_ata66_check'
> drivers/ide/idedriver.o(.text+0x24a7): undefined reference to `ide_driveid_update'
> drivers/ide/idedriver.o: In function `check_dma_crc':
> drivers/ide/idedriver.o(.text+0x2fc3): undefined reference to `ide_auto_reduce_xfer'
> drivers/ide/idedriver.o: In function `ide_dump_status':
> drivers/ide/idedriver.o(.text+0x34c8): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `drive_cmd_intr':
> drivers/ide/idedriver.o(.text+0x3b21): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_wait_stat':
> drivers/ide/idedriver.o(.text+0x3cd5): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_do_request':
> drivers/ide/idedriver.o(.text+0x42c9): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_intr':
> drivers/ide/idedriver.o(.text+0x48f3): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `report_drive_dmaing':
> drivers/ide/idedriver.o(.text+0x784a): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x789e): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `config_drive_for_dma':
> drivers/ide/idedriver.o(.text+0x79ce): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x79fe): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `via_set_drive':
> drivers/ide/idedriver.o(.text+0x91a8): undefined reference to `ide_config_drive_speed'
> drivers/ide/idedriver.o: In function `actual_try_to_identify':
> drivers/ide/idedriver.o(.text+0xaaec): undefined reference to `ide__sti'
> make: *** [vmlinux] Error 1
> 
> This comes at the final linking stage.
> 
> Thanks for the great stuff Andre.
> 
> Josh McKinney
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Andre Hedrick]

Please send me your .config cause this built clean ...

On Mon, 15 Apr 2002, Josh McKinney wrote:

> On approximately Mon, Apr 15, 2002 at 11:39:14AM -0700, Andre Hedrick wrote:
> > 
> > http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2
> > 
> Just got this when compiling...
> 
> drivers/ide/idedriver.o: In function `task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x9f1): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `flagged_task_no_data_intr':
> drivers/ide/idedriver.o(.text+0x14c7): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_cmd_ioctl':
> drivers/ide/idedriver.o(.text+0x23e0): undefined reference to `set_transfer'
> drivers/ide/idedriver.o(.text+0x23fc): undefined reference to `ide_ata66_check'
> drivers/ide/idedriver.o(.text+0x24a7): undefined reference to `ide_driveid_update'
> drivers/ide/idedriver.o: In function `check_dma_crc':
> drivers/ide/idedriver.o(.text+0x2fc3): undefined reference to `ide_auto_reduce_xfer'
> drivers/ide/idedriver.o: In function `ide_dump_status':
> drivers/ide/idedriver.o(.text+0x34c8): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `drive_cmd_intr':
> drivers/ide/idedriver.o(.text+0x3b21): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_wait_stat':
> drivers/ide/idedriver.o(.text+0x3cd5): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_do_request':
> drivers/ide/idedriver.o(.text+0x42c9): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `ide_intr':
> drivers/ide/idedriver.o(.text+0x48f3): undefined reference to `ide__sti'
> drivers/ide/idedriver.o: In function `report_drive_dmaing':
> drivers/ide/idedriver.o(.text+0x784a): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x789e): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `config_drive_for_dma':
> drivers/ide/idedriver.o(.text+0x79ce): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o(.text+0x79fe): undefined reference to `eighty_ninty_three'
> drivers/ide/idedriver.o: In function `via_set_drive':
> drivers/ide/idedriver.o(.text+0x91a8): undefined reference to `ide_config_drive_speed'
> drivers/ide/idedriver.o: In function `actual_try_to_identify':
> drivers/ide/idedriver.o(.text+0xaaec): undefined reference to `ide__sti'
> make: *** [vmlinux] Error 1
> 
> This comes at the final linking stage.
> 
> Thanks for the great stuff Andre.
> 
> Josh McKinney
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Andre Hedrick
LAD Storage Consulting Group

Re: [PATCH]

[Josh McKinney]

On approximately Mon, Apr 15, 2002 at 11:39:14AM -0700, Andre Hedrick wrote:
> 
> http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2
> 
Just got this when compiling...

drivers/ide/idedriver.o: In function `task_no_data_intr':
drivers/ide/idedriver.o(.text+0x9f1): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `flagged_task_no_data_intr':
drivers/ide/idedriver.o(.text+0x14c7): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_cmd_ioctl':
drivers/ide/idedriver.o(.text+0x23e0): undefined reference to `set_transfer'
drivers/ide/idedriver.o(.text+0x23fc): undefined reference to `ide_ata66_check'
drivers/ide/idedriver.o(.text+0x24a7): undefined reference to `ide_driveid_update'
drivers/ide/idedriver.o: In function `check_dma_crc':
drivers/ide/idedriver.o(.text+0x2fc3): undefined reference to `ide_auto_reduce_xfer'
drivers/ide/idedriver.o: In function `ide_dump_status':
drivers/ide/idedriver.o(.text+0x34c8): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `drive_cmd_intr':
drivers/ide/idedriver.o(.text+0x3b21): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_wait_stat':
drivers/ide/idedriver.o(.text+0x3cd5): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_do_request':
drivers/ide/idedriver.o(.text+0x42c9): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `ide_intr':
drivers/ide/idedriver.o(.text+0x48f3): undefined reference to `ide__sti'
drivers/ide/idedriver.o: In function `report_drive_dmaing':
drivers/ide/idedriver.o(.text+0x784a): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o(.text+0x789e): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o: In function `config_drive_for_dma':
drivers/ide/idedriver.o(.text+0x79ce): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o(.text+0x79fe): undefined reference to `eighty_ninty_three'
drivers/ide/idedriver.o: In function `via_set_drive':
drivers/ide/idedriver.o(.text+0x91a8): undefined reference to `ide_config_drive_speed'
drivers/ide/idedriver.o: In function `actual_try_to_identify':
drivers/ide/idedriver.o(.text+0xaaec): undefined reference to `ide__sti'
make: *** [vmlinux] Error 1

This comes at the final linking stage.

Thanks for the great stuff Andre.

Josh McKinney

[PATCH]

[Andre Hedrick]

http://www.linuxdiskcert.org/ide-2.4.19-p6.all.convert.3.patch.bz2

Spinlock issues address and 99% fixed.
6 new chipsets.
Taskfile IO should be stable.
Borrowed cleanups from 2.5.5 credit given to <martin d>
Bunches of patchs that have been submitted but not added until now.

Thanks for all the support gang ... this should make life a little better.

AEC6280 U100
AEC6880 U133
SI680 U133
CSB6 U100
HPT374 U100(U133??)
HPT372
Intel ICH3
VIA latest (via vojtech)

Super Taskfile special vender modes, and transparent to API.

Things which can not be fixed yet.

Spinlock sleep during probe to get.
Spinlock on pci-proc operations.

Process to convert codebase to as single filter/mask ruleset for timings.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

[PATCH]

[Christoph Hellwig]

Hi Linus,

the appended patch adds four exports needed for Linux-ABI:

 o do_fork & do_pipe because the emulated SysV syscalls call
   these directly.
 o the other two are needed by emulated syscongig() support.

Please apply,

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

diff -uNr -Xdontdiff ../master/linux-2.4.14-pre1/kernel/ksyms.c linux-2.4.14-pre1/kernel/ksyms.c
--- ../master/linux-2.4.14-pre1/kernel/ksyms.c	Thu Oct 25 19:05:49 2001
+++ linux-2.4.14-pre1/kernel/ksyms.c	Thu Oct 25 19:16:47 2001
@@ -60,6 +60,7 @@
 extern void *sys_call_table;
 
 extern struct timezone sys_tz;
+extern int max_threads;
 extern int request_dma(unsigned int dmanr, char * deviceID);
 extern void free_dma(unsigned int dmanr);
 extern spinlock_t dma_spin_lock;
@@ -550,3 +551,11 @@
 
 EXPORT_SYMBOL(tasklist_lock);
 EXPORT_SYMBOL(pidhash);
+
+/* for Linux-ABI */
+EXPORT_SYMBOL(do_fork);
+EXPORT_SYMBOL(do_pipe);
+
+/* sysconfig support */
+EXPORT_SYMBOL(nr_free_pages);
+EXPORT_SYMBOL(max_threads);

Re: [PATCH]

[Bartlomiej Zolnierkiewicz]

Yeach... I'm a bit sleepy...

first  [PATCH]: kmalloc/kfree bugs hit 1
second [PATCH]: ide modules and /proc fs

--
bkz

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH]

[Bartlomiej Zolnierkiewicz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 203 bytes --]


Patch fixes ide-disk/ide-floppy/ide-probe modules interaction
with /proc fs. Last chunk is needed to compile ide-probe as
module without /proc support.

--
Bartlomiej Zolnierkiewicz
<bkz@linux-ide.org>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1210 bytes --]

--- linux-240t10p6/drivers/ide/ide-disk.c	Thu Oct 19 22:05:01 2000
+++ linux/drivers/ide/ide-disk.c	Sat Oct 28 22:59:22 2000
@@ -891,8 +891,10 @@
 		}
 		/* We must remove proc entries defined in this module.
 		   Otherwise we oops while accessing these entries */
+#ifdef CONFIG_PROC_FS
 		if (drive->proc)
 			ide_remove_proc_entries(drive->proc, idedisk_proc);
+#endif
 	}
 	ide_unregister_module(&idedisk_module);
 }
--- linux-240t10p6/drivers/ide/ide-floppy.c	Tue Jun 13 20:32:00 2000
+++ linux/drivers/ide/ide-floppy.c	Sat Oct 28 22:59:51 2000
@@ -1683,8 +1683,10 @@
 		}
 		/* We must remove proc entries defined in this module.
 		   Otherwise we oops while accessing these entries */
+#ifdef CONFIG_PROC_FS
 		if (drive->proc)
 			ide_remove_proc_entries(drive->proc, idefloppy_proc);
+#endif
 	}
 	ide_unregister_module(&idefloppy_module);
 }
--- linux-240t10p6/drivers/ide/ide-probe.c	Tue Oct  3 00:16:51 2000
+++ linux/drivers/ide/ide-probe.c	Sat Oct 28 22:58:09 2000
@@ -906,7 +906,9 @@
 	for (index = 0; index < MAX_HWIFS; ++index)
 		ide_unregister(index);
 	ideprobe_init();
+#ifdef CONFIG_PROC_FS
 	create_proc_ide_interfaces();
+#endif
 	return 0;
 }
 

[PATCH]

[Bartlomiej Zolnierkiewicz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 131 bytes --]


I hitted few items from Dawson Engler's list of potential kmalloc/kfree
bugs...

--
Bartlomiej Zolnierkiewicz
<bkz@linux-ide.org>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 5501 bytes --]

--- linux-240t10/drivers/ide/ide-probe.c	Tue Oct  3 00:16:51 2000
+++ linux/drivers/ide/ide-probe.c	Tue Nov  7 00:25:35 2000
@@ -652,6 +653,10 @@
 		hwgroup = match->hwgroup;
 	} else {
 		hwgroup = kmalloc(sizeof(ide_hwgroup_t), GFP_KERNEL);
+		if(!hwgroup) {
+			restore_flags(flags);
+			return 1;
+		}
 		memset(hwgroup, 0, sizeof(ide_hwgroup_t));
 		hwgroup->hwif     = hwif->next = hwif;
 		hwgroup->rq       = NULL;
@@ -746,11 +751,23 @@
 	}
 	minors    = units * (1<<PARTN_BITS);
 	gd        = kmalloc (sizeof(struct gendisk), GFP_KERNEL);
+	if(!gd)
+		goto cleanup_gd;
 	gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
+	if(!gd->sizes)
+		goto cleanup_gd_sizes;
 	gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
+	if(!gd->part)
+		goto cleanup_gd_part;
 	bs        = kmalloc (minors*sizeof(int), GFP_KERNEL);
+	if(!bs)
+		goto cleanup_bs;
 	max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
+	if(!max_sect)
+		goto cleanup_max_sect;
 	max_ra    = kmalloc (minors*sizeof(int), GFP_KERNEL);
+	if(!max_ra)
+		goto cleanup_max_ra;
 
 	memset(gd->part, 0, minors * sizeof(struct hd_struct));
 
@@ -779,12 +796,16 @@
 	gd->real_devices= hwif;			/* ptr to internal data */
 	gd->next	= NULL;			/* linked list of major devs */
 	gd->fops        = ide_fops;             /* file operations */
-	gd->de_arr	= kmalloc (sizeof *gd->de_arr * units, GFP_KERNEL);
-	gd->flags	= kmalloc (sizeof *gd->flags * units, GFP_KERNEL);
-	if (gd->de_arr)
-		memset (gd->de_arr, 0, sizeof *gd->de_arr * units);
-	if (gd->flags)
-		memset (gd->flags, 0, sizeof *gd->flags * units);
+	if(units) {
+		gd->de_arr = kmalloc (sizeof *gd->de_arr * units, GFP_KERNEL);
+		if(!gd->de_arr)
+			goto cleanup_gd_de_arr;
+		gd->flags  = kmalloc (sizeof *gd->flags * units, GFP_KERNEL);
+		if(!gd->flags)
+			goto cleanup_gd_flags;
+		memset(gd->de_arr, 0, sizeof *gd->de_arr * units);
+		memset(gd->flags, 0, sizeof *gd->flags * units);
+	}
 
 	for (gdp = &gendisk_head; *gdp; gdp = &((*gdp)->next)) ;
 	hwif->gd = *gdp = gd;			/* link onto tail of list */
@@ -802,6 +823,26 @@
 				devfs_mk_dir (ide_devfs_handle, name, NULL);
 		}
 	}
+	return;
+
+cleanup_gd_flags:
+	kfree(gd->flags);
+cleanup_gd_de_arr:
+	kfree(gd->de_arr);
+cleanup_max_ra:
+	kfree(max_ra);
+cleanup_max_sect:
+	kfree(max_sect);
+cleanup_bs:
+	kfree(bs);
+cleanup_gd_part:
+	kfree(gd->part);
+cleanup_gd_sizes:
+	kfree(gd->sizes);
+cleanup_gd:
+	kfree(gd);
+
+	printk(KERN_ERR "ide-probe: not enough memory for init_gendisk()\n");
 }
 
 static int hwif_init (ide_hwif_t *hwif)
--- linux-240t10/drivers/i2o/i2o_config.c	Tue Oct  3 00:15:34 2000
+++ linux/drivers/i2o/i2o_config.c	Mon Nov  6 22:41:41 2000
@@ -499,6 +499,8 @@
 	if(!res)
 	{
 		i2o_unlock_controller(c);
+		printk(KERN_INFO "i2o_config: could not get res\n");
+		if(kcmd.qlen) kfree(query);
 		return -ENOMEM;
 	}
 
--- linux-240t10/drivers/i2o/i2o_core.c	Thu Oct 19 22:05:01 2000
+++ linux/drivers/i2o/i2o_core.c	Mon Nov  6 22:49:55 2000
@@ -1664,6 +1664,7 @@
 			{
 				printk(KERN_ERR "%s: Timeout waiting for IOP reset.\n", 
 						c->name); 
+				kfree(status);
 				return -ETIMEDOUT; 
 			} 
 			schedule(); 
--- linux-240t10/drivers/scsi/eata_dma.c	Tue Oct  3 14:27:44 2000
+++ linux/drivers/scsi/eata_dma.c	Mon Nov  6 23:21:04 2000
@@ -909,8 +909,17 @@
 
     cp = (struct eata_ccb *) kmalloc(sizeof(struct eata_ccb),
 				     GFP_ATOMIC | GFP_DMA);
+    if(!cp) {
+	printk(KERN_ERR "eata_dma: out of DMA memory\n");
+	return NULL;
+    }
     sp = (struct eata_sp *) kmalloc(sizeof(struct eata_sp), 
 					     GFP_ATOMIC | GFP_DMA);
+    if(!sp) {
+	printk(KERN_ERR "eata_dma: out of DMA memory\n");
+	kfree(cp);
+	return NULL;
+    }
 
     buff = dma_scratch;
  
@@ -1459,11 +1468,15 @@
     tpnt->proc_name = "eata_dma";
 
     status = kmalloc(512, GFP_ATOMIC | GFP_DMA);
+    if(!status) {
+	printk(KERN_ERR "eata_dma: not enough DMA memory to probe for hosts!\n");
+	return 0;
+    }
     dma_scratch = kmalloc(1024, GFP_ATOMIC | GFP_DMA);
-
-    if(status == NULL || dma_scratch == NULL) {
-	printk("eata_dma: can't allocate enough memory to probe for hosts !\n");
-	return(0);
+    if(!dma_scratch) {
+	printk(KERN_ERR "eata_dma: not enough DMA memory to probe for hosts!\n");
+	kfree(status);
+	return 0;
     }
 
     dma_scratch += 4;
--- linux-240t10/drivers/scsi/hosts.c	Tue Oct 31 11:20:15 2000
+++ linux/driver/scsi/hosts.c	Mon Nov  6 23:40:45 2000
@@ -168,7 +168,18 @@
     retval->loaded_as_module = 1;
     if (flag_new) {
 	shn = (Scsi_Host_Name *) kmalloc(sizeof(Scsi_Host_Name), GFP_ATOMIC);
+	if(!shn) {
+		printk(KERN_ERR "scsi: out of memory in scsi_register\n");
+		kfree(retval);
+		return NULL;
+	}
 	shn->name = kmalloc(hname_len + 1, GFP_ATOMIC);
+	if(!shn->name) {
+		printk(KERN_ERR "scsi: out of memory in scsi_register\n");
+		kfree(shn);
+		kfree(retval);
+		return NULL;
+	}
 	if (hname_len > 0)
 	    strncpy(shn->name, hname, hname_len);
 	shn->name[hname_len] = 0;
--- linux-240t10/drivers/scsi/ips.c	Tue Oct  3 14:27:45 2000
+++ linux/drivers/scsi/ips.c	Mon Nov  6 23:48:22 2000
@@ -4552,6 +4552,8 @@
 
    /* Allocate memory for the CCBs */
    ha->scbs = (ips_scb_t *) kmalloc(ha->max_cmds * sizeof(ips_scb_t), GFP_ATOMIC|GFP_DMA);
+   if(!ha->scbs)
+      return 0;
 
    memset(ha->scbs, 0, ha->max_cmds * sizeof(ips_scb_t));