Re: [uml-devel] [PATCH 3/6] UML - Userspace files should call libc directly
On venerdì 17 agosto 2007, Jeff Dike wrote: > A number of files that were changed in the recent removal of tt mode > are userspace files which call the os_* wrappers instead of calling > libc directly. A few other files were affected by this, through > os_print_error has no remaining callers, so it is deleted. Actually, os_print_error() (or some other interface to perror()) should be reintroduced and used more for error messages (and also strsignal() should be, for "Kernel mode signal N"). Problem debugging is hard, but there is no reason make it harder (or rather, not to simplify it for users). Btw, the inlined abs() call is not very nice; on the other hand, it's a simple solution to make it robust, and we do not to be extra-optimal on these debug code paths. Bye -- "Doh!" (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 3/6] UML - Userspace files should call libc directly
On venerdì 17 agosto 2007, Jeff Dike wrote: A number of files that were changed in the recent removal of tt mode are userspace files which call the os_* wrappers instead of calling libc directly. A few other files were affected by this, through os_print_error has no remaining callers, so it is deleted. Actually, os_print_error() (or some other interface to perror()) should be reintroduced and used more for error messages (and also strsignal() should be, for Kernel mode signal N). Problem debugging is hard, but there is no reason make it harder (or rather, not to simplify it for users). Btw, the inlined abs() call is not very nice; on the other hand, it's a simple solution to make it robust, and we do not to be extra-optimal on these debug code paths. Bye -- Doh! (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 6/6] UML - Fix hostfs style
On venerdì 24 agosto 2007, Jeff Dike wrote: > On Thu, Aug 23, 2007 at 04:54:59PM +0200, Blaisorblade wrote: > > > actually. Personally I'd prefer: > > > > > > else > > > type = OS_TYPE_DIR; > > > > I strongly agree with this style; beyond style itself, one strong reason > > is that joining statements hinder singlestepping through function code > > (it's easy to run gdb on UML, and anyway kgdb exists). > > How does that help? gdb should stop as easily on a "else foo;" line as on > else > foo; > right? Sorry, a better example is on: if (bar) foo; where the test and foo are two distinct parts. One step is "I execute the if", another (possible) step is "I perform foo" - which is not easy to tell if it is not on a different line. -- "Doh!" (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
[PATCH] Script to check for undefined Kconfig symbols - v2
In this version, I've updated the scripts to search for "\<$symb_bare\>" instead
of $symb_bare in Kconfig files. Please ignore my previous message.
To avoid to look manually for used but undefined Kconfig variables, I've
written a script which tries do this efficiently, in case all other attention
fail. It accounts for _MODULE suffix and for UML_ prefixes to Kconfig variable,
but otherwise looks for exact matches (i.e. \
---
scripts/checkunknowndefines.sh | 59
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/scripts/checkunknowndefines.sh b/scripts/checkunknowndefines.sh
new file mode 100755
index 000..dbb5cef
--- /dev/null
+++ b/scripts/checkunknowndefines.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+# Find Kconfig variables used in source code but never defined in Kconfig
+# Copyright (C) 2007, Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
+
+# Tested with dash.
+paths="$@"
+[ -z "$paths" ] && paths=.
+
+# Doing this once at the beginning saves a lot of time, on a cache-hot tree.
+Kconfigs="`find . -name 'Kconfig' -o -name 'Kconfig*[^~]'`"
+
+echo "File list \tundefined symbol used"
+find $paths -name '*.[chS]' -o -name 'Makefile' -o -name 'Makefile*[^~]'|
while read i
+do
+ # Output the bare Kconfig variable and the filename; the _MODULE part at
+ # the end is not removed here (would need perl an not-hungry regexp for
that).
+ sed -ne 's!^.*\<\(UML_\)\?CONFIG_\([0-9A-Z_]\+\).*!\2 '$i'!p' < $i
+done | \
+# Smart "sort|uniq" implemented in awk and tuned to collect the names of all
+# files which use a given symbol
+awk '{map[$1, count[$1]++] = $2; }
+END {
+ for (combIdx in map) {
+ split(combIdx, separate, SUBSEP);
+ # The value may have been removed.
+ if (! ( (separate[1], separate[2]) in map ) )
+ continue;
+ symb=separate[1];
+ printf "%s ", symb;
+ #Use gawk extension to delete the names vector
+ delete names;
+ #Portably delete the names vector
+ #split("", names);
+ for (i=0; i < count[symb]; i++) {
+ names[map[symb, i]] = 1;
+ # Unfortunately, we may still encounter symb, i in the
+ # outside iteration.
+ delete map[symb, i];
+ }
+ i=0;
+ for (name in names) {
+ if (i > 0)
+ printf ", %s", name;
+ else
+ printf "%s", name;
+ i++;
+ }
+ printf "\n";
+ }
+}' |
+while read symb files; do
+ # Remove the _MODULE suffix when checking the variable name. This should
+ # be done only on tristate symbols, actually, but Kconfig parsing is
+ # beyond the purpose of this script.
+ symb_bare=`echo $symb | sed -e 's/_MODULE//'`
+ if ! grep -q "\<$symb_bare\>" $Kconfigs; then
+ echo "$files: \t$symb"
+ fi
+done|sort
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Script to check for undefined Kconfig symbols
To avoid to look manually for used but undefined Kconfig variables, I've
written a script which tries do this efficiently, in case all other attention
fail. It accounts for _MODULE suffix and for UML_ prefixes to Kconfig variable,
but otherwise looks for exact matches (i.e. \
---
scripts/checkunknowndefines.sh | 59
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/scripts/checkunknowndefines.sh b/scripts/checkunknowndefines.sh
new file mode 100755
index 000..d15950e
--- /dev/null
+++ b/scripts/checkunknowndefines.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+# Find Kconfig variables used in source code but never defined in Kconfig
+# Copyright (C) 2007, Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
+
+# Tested with dash.
+paths="$@"
+[ -z "$paths" ] && paths=.
+
+# Doing this once at the beginning saves a lot of time, on a cache-hot tree.
+Kconfigs="`find . -name 'Kconfig' -o -name 'Kconfig*[^~]'`"
+
+echo "File list \tundefined symbol used"
+find $paths -name '*.[chS]' -o -name 'Makefile' -o -name 'Makefile*[^~]'|
while read i
+do
+ # Output the bare Kconfig variable and the filename; the _MODULE part at
+ # the end is not removed here (would need perl an not-hungry regexp for
that).
+ sed -ne 's!^.*\<\(UML_\)\?CONFIG_\([0-9A-Z_]\+\).*!\2 '$i'!p' < $i
+done | \
+# Smart "sort|uniq" implemented in awk and tuned to collect the names of all
+# files which use a given symbol
+awk '{map[$1, count[$1]++] = $2; }
+END {
+ for (combIdx in map) {
+ split(combIdx, separate, SUBSEP);
+ # The value may have been removed.
+ if (! ( (separate[1], separate[2]) in map ) )
+ continue;
+ symb=separate[1];
+ printf "%s ", symb;
+ #Use gawk extension to delete the names vector
+ delete names;
+ #Portably delete the names vector
+ #split("", names);
+ for (i=0; i < count[symb]; i++) {
+ names[map[symb, i]] = 1;
+ # Unfortunately, we may still encounter symb, i in the
+ # outside iteration.
+ delete map[symb, i];
+ }
+ i=0;
+ for (name in names) {
+ if (i > 0)
+ printf ", %s", name;
+ else
+ printf "%s", name;
+ i++;
+ }
+ printf "\n";
+ }
+}' |
+while read symb files; do
+ # Remove the _MODULE suffix when checking the variable name. This should
+ # be done only on tristate symbols, actually, but Kconfig parsing is
+ # beyond the purpose of this script.
+ symb_bare=`echo $symb | sed -e 's/_MODULE//'`
+ if ! grep -q $symb_bare $Kconfigs; then
+ echo "$files: \t$symb"
+ fi
+done|sort
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Replace CONFIG_USB_OHCI with CONFIG_USB_OHCI_HCD in a few overlooked files
Finish the rename of CONFIG_USB_OHCI to CONFIG_USB_OHCI_HCD, which started
in 2005 (before 2.6.12-rc2). The patch in this message has not been applied yet;
moreover, it is not something to fix afterwards. I've verified that no more
instances of 'CONFIG_USB_[UOE]HCI\>' exist in the source tree.
http://www.linux-mips.org/archives/linux-mips/2005-06/msg00060.html
I'm also sending a script to detect undefined Kconfig variables in next patch.
Thanks to my colleague Giuseppe Patanè for the original report: he discovered
the original mail (above) and for verified that the fix had not yet been
applied.
Cc: Giuseppe Patanè <[EMAIL PROTECTED]>
Cc: Ralf Baechle <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/mips/au1000/mtx-1/board_setup.c |4 ++--
arch/mips/au1000/pb1000/board_setup.c |6 +++---
arch/mips/au1000/pb1100/board_setup.c |4 ++--
arch/mips/au1000/pb1500/board_setup.c |6 +++---
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/mips/au1000/mtx-1/board_setup.c
b/arch/mips/au1000/mtx-1/board_setup.c
index 7bc5af8..1688ca9 100644
--- a/arch/mips/au1000/mtx-1/board_setup.c
+++ b/arch/mips/au1000/mtx-1/board_setup.c
@@ -54,11 +54,11 @@ void board_reset (void)
void __init board_setup(void)
{
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
// enable USB power switch
au_writel( au_readl(GPIO2_DIR) | 0x10, GPIO2_DIR );
au_writel( 0x10, GPIO2_OUTPUT );
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
#ifdef CONFIG_PCI
#if defined(__MIPSEB__)
diff --git a/arch/mips/au1000/pb1000/board_setup.c
b/arch/mips/au1000/pb1000/board_setup.c
index 824cfaf..f25b38f 100644
--- a/arch/mips/au1000/pb1000/board_setup.c
+++ b/arch/mips/au1000/pb1000/board_setup.c
@@ -54,7 +54,7 @@ void __init board_setup(void)
au_writel(0, SYS_PINSTATERD);
udelay(100);
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
/* zero and disable FREQ2 */
sys_freqctrl = au_readl(SYS_FREQCTRL0);
sys_freqctrl &= ~0xFFF0;
@@ -102,7 +102,7 @@ void __init board_setup(void)
/*
* Route 48MHz FREQ2 into USB Host and/or Device
*/
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
sys_clksrc |= ((4<<12) | (0<<11) | (0<<10));
#endif
au_writel(sys_clksrc, SYS_CLKSRC);
@@ -116,7 +116,7 @@ void __init board_setup(void)
au_writel(pin_func, SYS_PINFUNC);
au_writel(0x2800, SYS_TRIOUTCLR);
au_writel(0x0030, SYS_OUTPUTCLR);
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
// make gpio 15 an input (for interrupt line)
pin_func = au_readl(SYS_PINFUNC) & (u32)(~0x100);
diff --git a/arch/mips/au1000/pb1100/board_setup.c
b/arch/mips/au1000/pb1100/board_setup.c
index 6bc1f8e..3205f88 100644
--- a/arch/mips/au1000/pb1100/board_setup.c
+++ b/arch/mips/au1000/pb1100/board_setup.c
@@ -54,7 +54,7 @@ void __init board_setup(void)
au_writel(0, SYS_PININPUTEN);
udelay(100);
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
{
u32 pin_func, sys_freqctrl, sys_clksrc;
@@ -98,7 +98,7 @@ void __init board_setup(void)
pin_func |= 0x8000;
au_writel(pin_func, SYS_PINFUNC);
}
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
/* Enable sys bus clock divider when IDLE state or no bus activity. */
au_writel(au_readl(SYS_POWERCTRL) | (0x3 << 5), SYS_POWERCTRL);
diff --git a/arch/mips/au1000/pb1500/board_setup.c
b/arch/mips/au1000/pb1500/board_setup.c
index c9b6556..118e32a 100644
--- a/arch/mips/au1000/pb1500/board_setup.c
+++ b/arch/mips/au1000/pb1500/board_setup.c
@@ -56,7 +56,7 @@ void __init board_setup(void)
au_writel(0, SYS_PINSTATERD);
udelay(100);
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
/* GPIO201 is input for PCMCIA card detect */
/* GPIO203 is input for PCMCIA interrupt request */
@@ -85,7 +85,7 @@ void __init board_setup(void)
/*
* Route 48MHz FREQ2 into USB Host and/or Device
*/
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
sys_clksrc |= ((4<<12) | (0<<11) | (0<<10));
#endif
au_writel(sys_clksrc, SYS_CLKSRC);
@@ -95,7 +95,7 @@ void __init board_setup(void)
// 2nd USB port is USB host
pin_func |= 0x8000;
au_writel(pin_func, SYS_PINFUNC);
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usbmon doc update - mention new wildcard ('0') bus
Update usbmon documentation, mentioning the "zero" (wildcard) bus. Possibly, in my first hunk, the 'either ... or ...' should be rephrased a bit to be expressed better. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> Cc: USB development list <[EMAIL PROTECTED]> Cc: Pete Zaitcev <[EMAIL PROTECTED]> Cc: Alan Stern <[EMAIL PROTECTED]> --- Documentation/usb/usbmon.txt |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 53ae866..2917ce4 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt @@ -34,9 +34,12 @@ if usbmon is built into the kernel. Verify that bus sockets are present. # ls /sys/kernel/debug/usbmon -1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u +0s 0t 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u # +Now you can choose to either use the sockets numbered '0' (to capture packets on +all buses), and skip to step #3, or find the bus used by your device with step #2. + 2. Find which bus connects to the desired device Run "cat /proc/bus/usb/devices", and find the T-line which corresponds to @@ -56,6 +59,10 @@ Bus=03 means it's bus 3. # cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out +to listen on a single bus, otherwise, to listen on all buses, type: + +# cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out + This process will be reading until killed. Naturally, the output can be redirected to a desirable location. This is preferred, because it is going to be quite long. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usbmon doc update - mention new wildcard ('0') bus
Update usbmon documentation, mentioning the zero (wildcard) bus. Possibly, in my first hunk, the 'either ... or ...' should be rephrased a bit to be expressed better. Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] Cc: USB development list [EMAIL PROTECTED] Cc: Pete Zaitcev [EMAIL PROTECTED] Cc: Alan Stern [EMAIL PROTECTED] --- Documentation/usb/usbmon.txt |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 53ae866..2917ce4 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt @@ -34,9 +34,12 @@ if usbmon is built into the kernel. Verify that bus sockets are present. # ls /sys/kernel/debug/usbmon -1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u +0s 0t 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u # +Now you can choose to either use the sockets numbered '0' (to capture packets on +all buses), and skip to step #3, or find the bus used by your device with step #2. + 2. Find which bus connects to the desired device Run cat /proc/bus/usb/devices, and find the T-line which corresponds to @@ -56,6 +59,10 @@ Bus=03 means it's bus 3. # cat /sys/kernel/debug/usbmon/3u /tmp/1.mon.out +to listen on a single bus, otherwise, to listen on all buses, type: + +# cat /sys/kernel/debug/usbmon/0u /tmp/1.mon.out + This process will be reading until killed. Naturally, the output can be redirected to a desirable location. This is preferred, because it is going to be quite long. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Replace CONFIG_USB_OHCI with CONFIG_USB_OHCI_HCD in a few overlooked files
Finish the rename of CONFIG_USB_OHCI to CONFIG_USB_OHCI_HCD, which started
in 2005 (before 2.6.12-rc2). The patch in this message has not been applied yet;
moreover, it is not something to fix afterwards. I've verified that no more
instances of 'CONFIG_USB_[UOE]HCI\' exist in the source tree.
http://www.linux-mips.org/archives/linux-mips/2005-06/msg00060.html
I'm also sending a script to detect undefined Kconfig variables in next patch.
Thanks to my colleague Giuseppe Patanè for the original report: he discovered
the original mail (above) and for verified that the fix had not yet been
applied.
Cc: Giuseppe Patanè [EMAIL PROTECTED]
Cc: Ralf Baechle [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
arch/mips/au1000/mtx-1/board_setup.c |4 ++--
arch/mips/au1000/pb1000/board_setup.c |6 +++---
arch/mips/au1000/pb1100/board_setup.c |4 ++--
arch/mips/au1000/pb1500/board_setup.c |6 +++---
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/mips/au1000/mtx-1/board_setup.c
b/arch/mips/au1000/mtx-1/board_setup.c
index 7bc5af8..1688ca9 100644
--- a/arch/mips/au1000/mtx-1/board_setup.c
+++ b/arch/mips/au1000/mtx-1/board_setup.c
@@ -54,11 +54,11 @@ void board_reset (void)
void __init board_setup(void)
{
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
// enable USB power switch
au_writel( au_readl(GPIO2_DIR) | 0x10, GPIO2_DIR );
au_writel( 0x10, GPIO2_OUTPUT );
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
#ifdef CONFIG_PCI
#if defined(__MIPSEB__)
diff --git a/arch/mips/au1000/pb1000/board_setup.c
b/arch/mips/au1000/pb1000/board_setup.c
index 824cfaf..f25b38f 100644
--- a/arch/mips/au1000/pb1000/board_setup.c
+++ b/arch/mips/au1000/pb1000/board_setup.c
@@ -54,7 +54,7 @@ void __init board_setup(void)
au_writel(0, SYS_PINSTATERD);
udelay(100);
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
/* zero and disable FREQ2 */
sys_freqctrl = au_readl(SYS_FREQCTRL0);
sys_freqctrl = ~0xFFF0;
@@ -102,7 +102,7 @@ void __init board_setup(void)
/*
* Route 48MHz FREQ2 into USB Host and/or Device
*/
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
sys_clksrc |= ((412) | (011) | (010));
#endif
au_writel(sys_clksrc, SYS_CLKSRC);
@@ -116,7 +116,7 @@ void __init board_setup(void)
au_writel(pin_func, SYS_PINFUNC);
au_writel(0x2800, SYS_TRIOUTCLR);
au_writel(0x0030, SYS_OUTPUTCLR);
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
// make gpio 15 an input (for interrupt line)
pin_func = au_readl(SYS_PINFUNC) (u32)(~0x100);
diff --git a/arch/mips/au1000/pb1100/board_setup.c
b/arch/mips/au1000/pb1100/board_setup.c
index 6bc1f8e..3205f88 100644
--- a/arch/mips/au1000/pb1100/board_setup.c
+++ b/arch/mips/au1000/pb1100/board_setup.c
@@ -54,7 +54,7 @@ void __init board_setup(void)
au_writel(0, SYS_PININPUTEN);
udelay(100);
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
{
u32 pin_func, sys_freqctrl, sys_clksrc;
@@ -98,7 +98,7 @@ void __init board_setup(void)
pin_func |= 0x8000;
au_writel(pin_func, SYS_PINFUNC);
}
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
/* Enable sys bus clock divider when IDLE state or no bus activity. */
au_writel(au_readl(SYS_POWERCTRL) | (0x3 5), SYS_POWERCTRL);
diff --git a/arch/mips/au1000/pb1500/board_setup.c
b/arch/mips/au1000/pb1500/board_setup.c
index c9b6556..118e32a 100644
--- a/arch/mips/au1000/pb1500/board_setup.c
+++ b/arch/mips/au1000/pb1500/board_setup.c
@@ -56,7 +56,7 @@ void __init board_setup(void)
au_writel(0, SYS_PINSTATERD);
udelay(100);
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
/* GPIO201 is input for PCMCIA card detect */
/* GPIO203 is input for PCMCIA interrupt request */
@@ -85,7 +85,7 @@ void __init board_setup(void)
/*
* Route 48MHz FREQ2 into USB Host and/or Device
*/
-#ifdef CONFIG_USB_OHCI
+#ifdef CONFIG_USB_OHCI_HCD
sys_clksrc |= ((412) | (011) | (010));
#endif
au_writel(sys_clksrc, SYS_CLKSRC);
@@ -95,7 +95,7 @@ void __init board_setup(void)
// 2nd USB port is USB host
pin_func |= 0x8000;
au_writel(pin_func, SYS_PINFUNC);
-#endif // defined (CONFIG_USB_OHCI)
+#endif // defined (CONFIG_USB_OHCI_HCD)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Script to check for undefined Kconfig symbols
To avoid to look manually for used but undefined Kconfig variables, I've
written a script which tries do this efficiently, in case all other attention
fail. It accounts for _MODULE suffix and for UML_ prefixes to Kconfig variable,
but otherwise looks for exact matches (i.e. \CONFIG_; this is done to exclude
macros like MMCONFIG_).
Undefined Kconfig variables should be not be removed without care, but for
instance arch/i386/boot/ uses a bunch of undefined Kconfig vars:
$ scripts/checkunknowndefines.sh arch/i386/boot/
arch/i386/boot/video.h uses undefined symbol VIDEO_400_HACK
arch/i386/boot/video-vga.c uses undefined symbol VIDEO_400_HACK
arch/i386/boot/video.c uses undefined symbol VIDEO_RETAIN
arch/i386/boot/video.h uses undefined symbol VIDEO_RETAIN
arch/i386/boot/video.h uses undefined symbol VIDEO_SVGA
arch/i386/boot/video.h uses undefined symbol VIDEO_VESA
arch/i386/boot/video-vesa.c uses undefined symbol VIDEO_VESA
Hope you can merge this in -mm and use it frequently (probably, a script to
look for
regressions in its output is useful). It should also be mentioned in
SubmittingPatches if you agree.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
scripts/checkunknowndefines.sh | 59
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/scripts/checkunknowndefines.sh b/scripts/checkunknowndefines.sh
new file mode 100755
index 000..d15950e
--- /dev/null
+++ b/scripts/checkunknowndefines.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+# Find Kconfig variables used in source code but never defined in Kconfig
+# Copyright (C) 2007, Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
+
+# Tested with dash.
+paths=$@
+[ -z $paths ] paths=.
+
+# Doing this once at the beginning saves a lot of time, on a cache-hot tree.
+Kconfigs=`find . -name 'Kconfig' -o -name 'Kconfig*[^~]'`
+
+echo File list \tundefined symbol used
+find $paths -name '*.[chS]' -o -name 'Makefile' -o -name 'Makefile*[^~]'|
while read i
+do
+ # Output the bare Kconfig variable and the filename; the _MODULE part at
+ # the end is not removed here (would need perl an not-hungry regexp for
that).
+ sed -ne 's!^.*\\(UML_\)\?CONFIG_\([0-9A-Z_]\+\).*!\2 '$i'!p' $i
+done | \
+# Smart sort|uniq implemented in awk and tuned to collect the names of all
+# files which use a given symbol
+awk '{map[$1, count[$1]++] = $2; }
+END {
+ for (combIdx in map) {
+ split(combIdx, separate, SUBSEP);
+ # The value may have been removed.
+ if (! ( (separate[1], separate[2]) in map ) )
+ continue;
+ symb=separate[1];
+ printf %s , symb;
+ #Use gawk extension to delete the names vector
+ delete names;
+ #Portably delete the names vector
+ #split(, names);
+ for (i=0; i count[symb]; i++) {
+ names[map[symb, i]] = 1;
+ # Unfortunately, we may still encounter symb, i in the
+ # outside iteration.
+ delete map[symb, i];
+ }
+ i=0;
+ for (name in names) {
+ if (i 0)
+ printf , %s, name;
+ else
+ printf %s, name;
+ i++;
+ }
+ printf \n;
+ }
+}' |
+while read symb files; do
+ # Remove the _MODULE suffix when checking the variable name. This should
+ # be done only on tristate symbols, actually, but Kconfig parsing is
+ # beyond the purpose of this script.
+ symb_bare=`echo $symb | sed -e 's/_MODULE//'`
+ if ! grep -q $symb_bare $Kconfigs; then
+ echo $files: \t$symb
+ fi
+done|sort
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Script to check for undefined Kconfig symbols - v2
In this version, I've updated the scripts to search for \$symb_bare\ instead
of $symb_bare in Kconfig files. Please ignore my previous message.
To avoid to look manually for used but undefined Kconfig variables, I've
written a script which tries do this efficiently, in case all other attention
fail. It accounts for _MODULE suffix and for UML_ prefixes to Kconfig variable,
but otherwise looks for exact matches (i.e. \CONFIG_; this is done to exclude
macros like MMCONFIG_).
Undefined Kconfig variables should be not be removed without care, but for
instance arch/i386/boot/ uses a bunch of undefined Kconfig vars:
$ scripts/checkunknowndefines.sh arch/i386/boot/
arch/i386/boot/video.h uses undefined symbol VIDEO_400_HACK
arch/i386/boot/video-vga.c uses undefined symbol VIDEO_400_HACK
arch/i386/boot/video.c uses undefined symbol VIDEO_RETAIN
arch/i386/boot/video.h uses undefined symbol VIDEO_RETAIN
arch/i386/boot/video.h uses undefined symbol VIDEO_SVGA
arch/i386/boot/video.h uses undefined symbol VIDEO_VESA
arch/i386/boot/video-vesa.c uses undefined symbol VIDEO_VESA
Hope you can merge this in -mm and use it frequently (probably, a script to
look for
regressions in its output is useful). It should also be mentioned in
SubmittingPatches if you agree.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
scripts/checkunknowndefines.sh | 59
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/scripts/checkunknowndefines.sh b/scripts/checkunknowndefines.sh
new file mode 100755
index 000..dbb5cef
--- /dev/null
+++ b/scripts/checkunknowndefines.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+# Find Kconfig variables used in source code but never defined in Kconfig
+# Copyright (C) 2007, Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
+
+# Tested with dash.
+paths=$@
+[ -z $paths ] paths=.
+
+# Doing this once at the beginning saves a lot of time, on a cache-hot tree.
+Kconfigs=`find . -name 'Kconfig' -o -name 'Kconfig*[^~]'`
+
+echo File list \tundefined symbol used
+find $paths -name '*.[chS]' -o -name 'Makefile' -o -name 'Makefile*[^~]'|
while read i
+do
+ # Output the bare Kconfig variable and the filename; the _MODULE part at
+ # the end is not removed here (would need perl an not-hungry regexp for
that).
+ sed -ne 's!^.*\\(UML_\)\?CONFIG_\([0-9A-Z_]\+\).*!\2 '$i'!p' $i
+done | \
+# Smart sort|uniq implemented in awk and tuned to collect the names of all
+# files which use a given symbol
+awk '{map[$1, count[$1]++] = $2; }
+END {
+ for (combIdx in map) {
+ split(combIdx, separate, SUBSEP);
+ # The value may have been removed.
+ if (! ( (separate[1], separate[2]) in map ) )
+ continue;
+ symb=separate[1];
+ printf %s , symb;
+ #Use gawk extension to delete the names vector
+ delete names;
+ #Portably delete the names vector
+ #split(, names);
+ for (i=0; i count[symb]; i++) {
+ names[map[symb, i]] = 1;
+ # Unfortunately, we may still encounter symb, i in the
+ # outside iteration.
+ delete map[symb, i];
+ }
+ i=0;
+ for (name in names) {
+ if (i 0)
+ printf , %s, name;
+ else
+ printf %s, name;
+ i++;
+ }
+ printf \n;
+ }
+}' |
+while read symb files; do
+ # Remove the _MODULE suffix when checking the variable name. This should
+ # be done only on tristate symbols, actually, but Kconfig parsing is
+ # beyond the purpose of this script.
+ symb_bare=`echo $symb | sed -e 's/_MODULE//'`
+ if ! grep -q \$symb_bare\ $Kconfigs; then
+ echo $files: \t$symb
+ fi
+done|sort
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 6/6] UML - Fix hostfs style
On venerdì 24 agosto 2007, Jeff Dike wrote: On Thu, Aug 23, 2007 at 04:54:59PM +0200, Blaisorblade wrote: actually. Personally I'd prefer: else type = OS_TYPE_DIR; I strongly agree with this style; beyond style itself, one strong reason is that joining statements hinder singlestepping through function code (it's easy to run gdb on UML, and anyway kgdb exists). How does that help? gdb should stop as easily on a else foo; line as on else foo; right? Sorry, a better example is on: if (bar) foo; where the test and foo are two distinct parts. One step is I execute the if, another (possible) step is I perform foo - which is not easy to tell if it is not on a different line. -- Doh! (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 6/6] UML - Fix hostfs style
On sabato 18 agosto 2007, Satyam Sharma wrote: > On Fri, 17 Aug 2007, Jeff Dike wrote: > > Style fixes in hostfs. > > @@ -328,17 +326,17 @@ int hostfs_readdir(struct file *file, vo > > [...] > > - if(error) break; > > + if (error) break; > > if (error) > break; > > > @@ -522,28 +523,28 @@ static int init_inode(struct inode *inod > > [...] > > else type = OS_TYPE_DIR; > > I wonder what's the generally accepted / followed coding style for this, > actually. Personally I'd prefer: > > else > type = OS_TYPE_DIR; I strongly agree with this style; beyond style itself, one strong reason is that joining statements hinder singlestepping through function code (it's easy to run gdb on UML, and anyway kgdb exists). Bye -- "Doh!" (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH] UML - Add a .note.SuSE section
On mercoledì 22 agosto 2007, Jeff Dike wrote: > On Tue, Aug 21, 2007 at 07:05:53PM +0200, Blaisorblade wrote: > > It's not the first time we hit effects of such bugs, is it? > > I don't remember seeing this before. > > > The .note.ABI-tag fix, time ago, may be about the same problem. > > Are you referring to > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi >ff;h=c35e584c087381aaa5f1ed40a28b978535c18fb2;hp=a5bd1786fb30abe663b904f6d79 >bba413e9ba883? Yes. >If so, I never understood that - it just came in saying "this > fixes static building", so I sent it along. In this case, I'm referring to the patch which had a typo, which is yours: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7632fc8f809a97f9d82ce125e8e3e579390ce2e5 Description follows: "During a static link, ld has started putting a .note section in the .uml.setup.init section. This has the result that the UML setups begin with 32 bytes of garbage and UML crashes immediately on boot. This patch creates a specific .note section for ld to drop this stuff into." My patch only made your change work for real - IIRC you had fixed that exact typo too, but you forgot to run quilt refresh before sending the patch (btw, quilt pop -a will force you to refresh all patches to succeed - I do it frequently). > BTW, that commit was singled > out by git-bisect as "causing" this particular problem. > > > Can you > > double-check all UML linker scripts for more instances of this bug? > > I did, I have a patch, and it's been verified to fix the problem. In this case, we _may_ want to remove the .note section altogether - even if it is likely to shake out more problems. Good bye! -- "Doh!" (cit.), I've made another another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH] UML - Add a .note.SuSE section
On mercoledì 22 agosto 2007, Jeff Dike wrote: On Tue, Aug 21, 2007 at 07:05:53PM +0200, Blaisorblade wrote: It's not the first time we hit effects of such bugs, is it? I don't remember seeing this before. The .note.ABI-tag fix, time ago, may be about the same problem. Are you referring to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi ff;h=c35e584c087381aaa5f1ed40a28b978535c18fb2;hp=a5bd1786fb30abe663b904f6d79 bba413e9ba883? Yes. If so, I never understood that - it just came in saying this fixes static building, so I sent it along. In this case, I'm referring to the patch which had a typo, which is yours: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7632fc8f809a97f9d82ce125e8e3e579390ce2e5 Description follows: During a static link, ld has started putting a .note section in the .uml.setup.init section. This has the result that the UML setups begin with 32 bytes of garbage and UML crashes immediately on boot. This patch creates a specific .note section for ld to drop this stuff into. My patch only made your change work for real - IIRC you had fixed that exact typo too, but you forgot to run quilt refresh before sending the patch (btw, quilt pop -a will force you to refresh all patches to succeed - I do it frequently). BTW, that commit was singled out by git-bisect as causing this particular problem. Can you double-check all UML linker scripts for more instances of this bug? I did, I have a patch, and it's been verified to fix the problem. In this case, we _may_ want to remove the .note section altogether - even if it is likely to shake out more problems. Good bye! -- Doh! (cit.), I've made another another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 6/6] UML - Fix hostfs style
On sabato 18 agosto 2007, Satyam Sharma wrote: On Fri, 17 Aug 2007, Jeff Dike wrote: Style fixes in hostfs. @@ -328,17 +326,17 @@ int hostfs_readdir(struct file *file, vo [...] - if(error) break; + if (error) break; if (error) break; @@ -522,28 +523,28 @@ static int init_inode(struct inode *inod [...] else type = OS_TYPE_DIR; I wonder what's the generally accepted / followed coding style for this, actually. Personally I'd prefer: else type = OS_TYPE_DIR; I strongly agree with this style; beyond style itself, one strong reason is that joining statements hinder singlestepping through function code (it's easy to run gdb on UML, and anyway kgdb exists). Bye -- Doh! (cit.), I've made another mistake! Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH] UML - Add a .note.SuSE section
On giovedì 16 agosto 2007, Jeff Dike wrote:
> On Thu, Aug 16, 2007 at 10:04:55PM +0200, Sam Ravnborg wrote:
> > On Thu, Aug 16, 2007 at 03:26:39PM -0400, Jeff Dike wrote:
> > > The crash is in this section:
> > >
> > > __uml_setup_start = .;
> > > .uml.setup.init : { *(.uml.setup.init) }
> > > __uml_setup_end = .;
> >
> > This looks like a classic bug.
> > You wanted this:
> > .uml.setup.init : {
> > __uml_setup_start = .;
> > *(.uml.setup.init)
> > __uml_setup_end = .;
> > }
>
> Ooh, this sounds promising, thanks.
It's not the first time we hit effects of such bugs, is it? The .note.ABI-tag
fix, time ago, may be about the same problem. Can you double-check all UML
linker scripts for more instances of this bug?
Bye
--
"Doh!" (cit.), I've made another another mistake!
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
signature.asc
Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH] UML - Add a .note.SuSE section
On giovedì 16 agosto 2007, Jeff Dike wrote:
On Thu, Aug 16, 2007 at 10:04:55PM +0200, Sam Ravnborg wrote:
On Thu, Aug 16, 2007 at 03:26:39PM -0400, Jeff Dike wrote:
The crash is in this section:
__uml_setup_start = .;
.uml.setup.init : { *(.uml.setup.init) }
__uml_setup_end = .;
This looks like a classic bug.
You wanted this:
.uml.setup.init : {
__uml_setup_start = .;
*(.uml.setup.init)
__uml_setup_end = .;
}
Ooh, this sounds promising, thanks.
It's not the first time we hit effects of such bugs, is it? The .note.ABI-tag
fix, time ago, may be about the same problem. Can you double-check all UML
linker scripts for more instances of this bug?
Bye
--
Doh! (cit.), I've made another another mistake!
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade
signature.asc
Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 4/5] UML - Simplify helper stack handling
On giovedì 28 giugno 2007, Andrew Morton wrote: > So I'm running the generic version of this on i386 with 8k stacks (below), > with a quick LTP run. > > Holy cow, either we use a _lot_ of stack or these numbers are off: > > vmm:/home/akpm> dmesg -s 100|grep 'bytes left' > khelper used greatest stack depth: 7176 bytes left > khelper used greatest stack depth: 7064 bytes left > khelper used greatest stack depth: 6840 bytes left > khelper used greatest stack depth: 6812 bytes left > hostname used greatest stack depth: 6636 bytes left > uname used greatest stack depth: 6592 bytes left > uname used greatest stack depth: 6284 bytes left > hotplug used greatest stack depth: 5568 bytes left > rpc.nfsd used greatest stack depth: 5136 bytes left > chown02 used greatest stack depth: 4956 bytes left > fchown01 used greatest stack depth: 4892 bytes left > That's the sum of process stack and interrupt stack, but I doubt if this > little box is using much interrupt stack space. > > No wonder people are still getting stack overflows with 4k stacks... First, those numbers pretend to be _unused_ stack space. Well, UML tends to use more stack space than the rest of kernel. Apart it has a bit more layering (even if less than in the past), we must use libc's function too, and they're not written to be executed on an 8k stack. We've reimplemented libc's printf() in terms of kernel sprintf() because it used 32K of stack. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 4/5] UML - Simplify helper stack handling
On giovedì 28 giugno 2007, Andrew Morton wrote: So I'm running the generic version of this on i386 with 8k stacks (below), with a quick LTP run. Holy cow, either we use a _lot_ of stack or these numbers are off: vmm:/home/akpm dmesg -s 100|grep 'bytes left' khelper used greatest stack depth: 7176 bytes left khelper used greatest stack depth: 7064 bytes left khelper used greatest stack depth: 6840 bytes left khelper used greatest stack depth: 6812 bytes left hostname used greatest stack depth: 6636 bytes left uname used greatest stack depth: 6592 bytes left uname used greatest stack depth: 6284 bytes left hotplug used greatest stack depth: 5568 bytes left rpc.nfsd used greatest stack depth: 5136 bytes left chown02 used greatest stack depth: 4956 bytes left fchown01 used greatest stack depth: 4892 bytes left That's the sum of process stack and interrupt stack, but I doubt if this little box is using much interrupt stack space. No wonder people are still getting stack overflows with 4k stacks... First, those numbers pretend to be _unused_ stack space. Well, UML tends to use more stack space than the rest of kernel. Apart it has a bit more layering (even if less than in the past), we must use libc's function too, and they're not written to be executed on an 8k stack. We've reimplemented libc's printf() in terms of kernel sprintf() because it used 32K of stack. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade signature.asc Description: This is a digitally signed message part.
Re: [uml-devel] [PATCH 2/2] UML - Add stack usage monitoring
On mercoledì 20 giugno 2007, Jeff Dike wrote: > On Wed, Jun 20, 2007 at 04:06:58PM +0200, Blaisorblade wrote: > > Oh, it's exactly what CONFIG_DEBUG_STACK_USAGE does for i386... (not sure > > if you were still wondering...). > > Where? The only usage in i386 that I see is thread_info.h zeroing stacks > as they are allocated. I only looked at docs. But Andrew Morton said: "Your new code should really be generic, utilising the stack-page-zeroing which CONFIG_DEBUG_STACK_USAGE enables." In fact, the other reference is in kernel/sched.c. You may (or may not) join the two stack walking (I would) and match a bit descriptions. Personally, I'd put the Kconfig option in lib/Kconfig.debug and have a Kconfig flag named DEBUG_STACK_USAGE_SUPPORT, much like LOCKDEP_SUPPORT (defined only by architectures supporting the option), but have no time right now. Bye -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/2] UML - Add stack usage monitoring
On martedì 19 giugno 2007, Andrew Morton wrote:
> On Tue, 19 Jun 2007 14:42:45 -0400
>
> Jeff Dike <[EMAIL PROTECTED]> wrote:
> > Add a machanism to see how much of a kernel stack is used. This
> > allocates zeroed stacks and sees where the lowest non-zero byte is on
> > process exit. It keeps track of the lowest value and logs values as
> > they get lower.
>
> remind us again why the generic code is unsuitable?
>
> > + for(p = stack; p < end; p++){
> > + if(*p != 0)
> > + if(left < lowest_to_date){
>
> Are there any plans to fix UML coding style?
In Italy we say "habits are hard to die"...
In an (unanswered) thread, titled "[RFC] Auto-fixups for CodingStyle against
major UML violations" from 31/3/2007, also CC'ed to you, Jeff and LKML, I
published a script (reattached here) which integrates with quilt and kbuild
to fix all sources for these violations. It is not indent based, consequently
it does not do any damages that indent would do.
Plus, with just a couple of tiny changes (for substitutions implying the use
of '^'), it can also be run on unified diffs.
The only problem is just coordinating to run it together on a source tree and
on the patch set applying on it. Otherwise the patchset manager would get
hard-to-fix rejects.
In the end: are you interested in this stuff? I'm busy right now but can work
to apply these changes after this thursday (i.e. tomorrow). I'd need to get
Jeff's patchset to fix it.
Please let me know.
Bye!
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
do-src-style-fix
Description: application/shellscript
Re: [uml-devel] [PATCH 2/2] UML - Add stack usage monitoring
On martedì 19 giugno 2007, Andrew Morton wrote: > On Tue, 19 Jun 2007 15:50:03 -0400 > > Jeff Dike <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 19, 2007 at 11:54:22AM -0700, Andrew Morton wrote: > > > On Tue, 19 Jun 2007 14:42:45 -0400 > > > > > > Jeff Dike <[EMAIL PROTECTED]> wrote: > > > > Add a machanism to see how much of a kernel stack is used. This > > > > allocates zeroed stacks and sees where the lowest non-zero byte is on > > > > process exit. It keeps track of the lowest value and logs values as > > > > they get lower. > > > > > > remind us again why the generic code is unsuitable? > > > > It does something different - it will tell you the greatest stack > > usage of any currently running process. What I want to be able to do > > is run a workload and come back a few days later and see how close > > anything came to running out of stack. > > > > wth? I'm _sure_ we used to have code in there which would, within > do_exit(), work out the maximum amount of kernel stack which a task had > used and if that was max-since-boot, drop a printk. > > Maybe I dreamed it, but I don't think so. > > I wonder where it went? Oh, it's exactly what CONFIG_DEBUG_STACK_USAGE does for i386... (not sure if you were still wondering...). > Oh well. Your new code should really be generic, utilising the > stack-page-zeroing which CONFIG_DEBUG_STACK_USAGE enables. There's nothing > UML-specific about it. > low_water_lock and lowest_to_date should be static to check_stack_usage(), > btw.. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/2] UML - Add stack usage monitoring
On martedì 19 giugno 2007, Andrew Morton wrote: On Tue, 19 Jun 2007 15:50:03 -0400 Jeff Dike [EMAIL PROTECTED] wrote: On Tue, Jun 19, 2007 at 11:54:22AM -0700, Andrew Morton wrote: On Tue, 19 Jun 2007 14:42:45 -0400 Jeff Dike [EMAIL PROTECTED] wrote: Add a machanism to see how much of a kernel stack is used. This allocates zeroed stacks and sees where the lowest non-zero byte is on process exit. It keeps track of the lowest value and logs values as they get lower. remind us again why the generic code is unsuitable? It does something different - it will tell you the greatest stack usage of any currently running process. What I want to be able to do is run a workload and come back a few days later and see how close anything came to running out of stack. looks wth? I'm _sure_ we used to have code in there which would, within do_exit(), work out the maximum amount of kernel stack which a task had used and if that was max-since-boot, drop a printk. Maybe I dreamed it, but I don't think so. I wonder where it went? Oh, it's exactly what CONFIG_DEBUG_STACK_USAGE does for i386... (not sure if you were still wondering...). Oh well. Your new code should really be generic, utilising the stack-page-zeroing which CONFIG_DEBUG_STACK_USAGE enables. There's nothing UML-specific about it. low_water_lock and lowest_to_date should be static to check_stack_usage(), btw.. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/2] UML - Add stack usage monitoring
On martedì 19 giugno 2007, Andrew Morton wrote:
On Tue, 19 Jun 2007 14:42:45 -0400
Jeff Dike [EMAIL PROTECTED] wrote:
Add a machanism to see how much of a kernel stack is used. This
allocates zeroed stacks and sees where the lowest non-zero byte is on
process exit. It keeps track of the lowest value and logs values as
they get lower.
remind us again why the generic code is unsuitable?
+ for(p = stack; p end; p++){
+ if(*p != 0)
+ if(left lowest_to_date){
Are there any plans to fix UML coding style?
In Italy we say habits are hard to die...
In an (unanswered) thread, titled [RFC] Auto-fixups for CodingStyle against
major UML violations from 31/3/2007, also CC'ed to you, Jeff and LKML, I
published a script (reattached here) which integrates with quilt and kbuild
to fix all sources for these violations. It is not indent based, consequently
it does not do any damages that indent would do.
Plus, with just a couple of tiny changes (for substitutions implying the use
of '^'), it can also be run on unified diffs.
The only problem is just coordinating to run it together on a source tree and
on the patch set applying on it. Otherwise the patchset manager would get
hard-to-fix rejects.
In the end: are you interested in this stuff? I'm busy right now but can work
to apply these changes after this thursday (i.e. tomorrow). I'd need to get
Jeff's patchset to fix it.
Please let me know.
Bye!
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
do-src-style-fix
Description: application/shellscript
Re: [uml-devel] [PATCH 2/2] UML - Add stack usage monitoring
On mercoledì 20 giugno 2007, Jeff Dike wrote: On Wed, Jun 20, 2007 at 04:06:58PM +0200, Blaisorblade wrote: Oh, it's exactly what CONFIG_DEBUG_STACK_USAGE does for i386... (not sure if you were still wondering...). Where? The only usage in i386 that I see is thread_info.h zeroing stacks as they are allocated. I only looked at docs. But Andrew Morton said: Your new code should really be generic, utilising the stack-page-zeroing which CONFIG_DEBUG_STACK_USAGE enables. In fact, the other reference is in kernel/sched.c. You may (or may not) join the two stack walking (I would) and match a bit descriptions. Personally, I'd put the Kconfig option in lib/Kconfig.debug and have a Kconfig flag named DEBUG_STACK_USAGE_SUPPORT, much like LOCKDEP_SUPPORT (defined only by architectures supporting the option), but have no time right now. Bye -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] UML - Network and pcap cleanup
On martedì 1 maggio 2007, Jeff Dike wrote: > [ Paolo - could you eyeball the globally valid MAC piece of this and > see if you think it's OK? ] Done, the patch can be accepted (I've not looked at the PCAP part). I've a note on the other fix there (the additional return). > Some network device cleanup. > > When setup_etheraddr found a globally valid MAC being assigned to an > interface, it went ahead and used it rather than assigning a random > MAC like the other cases do. This isn't really an error like the > others, but it seems consistent to make it behave the same. Fine, agreed. For this, you can add my Acked-by. Probably at that time MAC randomization wasn't implemented. > We were getting some duplicate kfree() in the error case in > eth_configure because platform_device_unregister frees buffers that > the error cases following tried to free again. This is due to patch: "uml: drivers get release methods" this could be useful to check whether other such changes are needed, by grepping for platform_device_unregister in exit paths, also for ubd driver. That patch only fixed net_remove() and ubd_remove(). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] UML - Network and pcap cleanup
On martedì 1 maggio 2007, Jeff Dike wrote: [ Paolo - could you eyeball the globally valid MAC piece of this and see if you think it's OK? ] Done, the patch can be accepted (I've not looked at the PCAP part). I've a note on the other fix there (the additional return). Some network device cleanup. When setup_etheraddr found a globally valid MAC being assigned to an interface, it went ahead and used it rather than assigning a random MAC like the other cases do. This isn't really an error like the others, but it seems consistent to make it behave the same. Fine, agreed. For this, you can add my Acked-by. Probably at that time MAC randomization wasn't implemented. We were getting some duplicate kfree() in the error case in eth_configure because platform_device_unregister frees buffers that the error cases following tried to free again. This is due to patch: uml: drivers get release methods this could be useful to check whether other such changes are needed, by grepping for platform_device_unregister in exit paths, also for ubd driver. That patch only fixed net_remove() and ubd_remove(). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/4] UML - tidy process.c
On lunedì 2 aprile 2007, Jeff Dike wrote: > Clean up arch/um/kernel/process.c - > lots of return(x); -> return x; conversions > a number of the small functions are either unused, in which > case they are gone, along any declarations in a header, or could be > made static. > current_pid is ifdefed on CONFIG_MODE_TT and its declaration > is ifdefed on both CONFIG_MODE_TT and UML_CONFIG_MODE_TT because we > don't know whether it's being used in a userspace or kernel file. Please, simply include uml-config.h and use just UML_CONFIG_MODE_TT. > Index: linux-2.6.21-mm/arch/um/include/kern_util.h > === > --- linux-2.6.21-mm.orig/arch/um/include/kern_util.h 2007-03-30 > 16:01:21.0 -0400 +++ > linux-2.6.21-mm/arch/um/include/kern_util.h 2007-04-02 12:07:48.0 > -0400 @@ -33,7 +33,9 @@ extern int nsyscalls; > UML_ROUND_DOWN(((unsigned long) addr) + PAGE_SIZE - 1) > > extern int kernel_fork(unsigned long flags, int (*fn)(void *), void * > arg); +#if defined(CONFIG_MODE_TT) || defined(UML_CONFIG_MODE_TT) > extern unsigned long stack_sp(unsigned long page); > +#endif > extern int kernel_thread_proc(void *data); > extern void syscall_segv(int sig); > extern int current_pid(void); -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [RFC] UML kernel & rootfs bundle with every kernel release ?
On lunedì 2 aprile 2007, Antoine Martin wrote: > Jeff Dike wrote: > > On Sun, Apr 01, 2007 at 08:58:45PM +0100, Antoine Martin wrote: > >> I reckon that one critical thing which could drastically increase the > >> user base would be to have a working virtual framebuffer implementation. > > > > Why? I've never understood what a framebuffer gives you that you > > don't have now. > > Just like the network auto-configuration via dhcp, Hmm... for that to be completely plug-and-play you need to make sure a dhcp server on the host exists. Vmware runs a separate DHCP server exactly for this, even if we should avoid that as much as possible. > it would allow users > to download images+kernel and run them like appliances without > understanding anything about X or UML, just click and run. > We are all capable of setting up Xvfb here, but most users are not, > which is why they download ready-made images. What about installing and pre-configuring Xnest on the image? With a suitable script calling xhost on the host, it just works. This project did it: http://umlbuilder.sourceforge.net/ although it stopped working for me ages ago (probably for some UML bug). I built a Mandrake image (that I now lost) with Xnest configured. With a script on the host which passes the host IP and that calls xhost, it should work easily. And btw, we need a standard startup script anyway. > It would also make it a lot easier to focus on writing a management UI, > hell if there isn't one shortly after, I'll do one myself! Why not one management UI running from the host, a-la vmware? Possibly, with as much code as possible in scripting languages, for better transparency. > Think of a UML browser image (running IE via wine in a limited image > with just X + wine + IE - I would much prefer that to having wine+IE > installed locally), testing framebuffer apps like gtk-fb/cairo-fb > without risking your dev environment, etc... > > Antoine -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [RFC] UML kernel rootfs bundle with every kernel release ?
On lunedì 2 aprile 2007, Antoine Martin wrote: Jeff Dike wrote: On Sun, Apr 01, 2007 at 08:58:45PM +0100, Antoine Martin wrote: I reckon that one critical thing which could drastically increase the user base would be to have a working virtual framebuffer implementation. Why? I've never understood what a framebuffer gives you that you don't have now. Just like the network auto-configuration via dhcp, Hmm... for that to be completely plug-and-play you need to make sure a dhcp server on the host exists. Vmware runs a separate DHCP server exactly for this, even if we should avoid that as much as possible. it would allow users to download images+kernel and run them like appliances without understanding anything about X or UML, just click and run. We are all capable of setting up Xvfb here, but most users are not, which is why they download ready-made images. What about installing and pre-configuring Xnest on the image? With a suitable script calling xhost on the host, it just works. This project did it: http://umlbuilder.sourceforge.net/ although it stopped working for me ages ago (probably for some UML bug). I built a Mandrake image (that I now lost) with Xnest configured. With a script on the host which passes the host IP and that calls xhost, it should work easily. And btw, we need a standard startup script anyway. It would also make it a lot easier to focus on writing a management UI, hell if there isn't one shortly after, I'll do one myself! Why not one management UI running from the host, a-la vmware? Possibly, with as much code as possible in scripting languages, for better transparency. Think of a UML browser image (running IE via wine in a limited image with just X + wine + IE - I would much prefer that to having wine+IE installed locally), testing framebuffer apps like gtk-fb/cairo-fb without risking your dev environment, etc... Antoine -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/4] UML - tidy process.c
On lunedì 2 aprile 2007, Jeff Dike wrote: Clean up arch/um/kernel/process.c - lots of return(x); - return x; conversions a number of the small functions are either unused, in which case they are gone, along any declarations in a header, or could be made static. current_pid is ifdefed on CONFIG_MODE_TT and its declaration is ifdefed on both CONFIG_MODE_TT and UML_CONFIG_MODE_TT because we don't know whether it's being used in a userspace or kernel file. Please, simply include uml-config.h and use just UML_CONFIG_MODE_TT. Index: linux-2.6.21-mm/arch/um/include/kern_util.h === --- linux-2.6.21-mm.orig/arch/um/include/kern_util.h 2007-03-30 16:01:21.0 -0400 +++ linux-2.6.21-mm/arch/um/include/kern_util.h 2007-04-02 12:07:48.0 -0400 @@ -33,7 +33,9 @@ extern int nsyscalls; UML_ROUND_DOWN(((unsigned long) addr) + PAGE_SIZE - 1) extern int kernel_fork(unsigned long flags, int (*fn)(void *), void * arg); +#if defined(CONFIG_MODE_TT) || defined(UML_CONFIG_MODE_TT) extern unsigned long stack_sp(unsigned long page); +#endif extern int kernel_thread_proc(void *data); extern void syscall_segv(int sig); extern int current_pid(void); -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] UML kernel & rootfs bundle with every kernel release ?
On domenica 1 aprile 2007, [EMAIL PROTECTED] wrote: > Hello ! > > i`m not very much into UML for the last months, but while playing around > with dm-loop i just got one idea i`d like to share. > > Whenever you want to test some new kernel (feature), you may put you main > system at risk, exactly know what you`re doing - or - use UserModeLinux. > > The "problem" with UML is: > > - you needs to compile an UML kernel first. > - you needs some "basic" knowlege about UML to get things running. > - you need to create an appropriate filesystem image for UML - or find some > for download > - you need to copy appropriate kernel modules inside Well, you just build usually monolithic kernels, so you skip this problem. And an idea that likely netkit uses is taking modules through an hostfs mount (or, it would be an easier setup). But you need modules to have uid 0... > - you need to put kernel sources inside, have compiler.. > - you may need appropriate modle-init-tools,initrd, kernel specific tools > (updated dmsetup, updatedwhatever) You found 2.4 images, but 2.6 ones do exist. > in short: > it`s quite some work to be done to have your uml 2.6.21 with root-fs up and > running and working cleanly. whenever i search the net for some appropriate > UML fs image, those i find are very often old and outdated... Hmm... I'd think we need a wizard for configuration. Plus some distro-like work for some specific issues - if I want to deploy a VM with hostname x, network config y, and with Xnest running, I need an easier way to do that. You can add settings on kernel command line and parse them inside UML - we need standard packaged utilities for that (one of the rootfs builder installed such stuff). > is there a project/website which is offering such ready to run "UML > kernel+rootfs release bundles" for download (i.e. new kernel,generic > root-fs, modules inside, sources inside, compiler inside - in sync with the > latest stable vanilla) , or , would it make sense to establish such project > ? i.e. besides releasing the kernel, also releasing sort of a kernel > "runtime kit" and/or "devkit" ? The runtime kit is there on nagafix.co.uk. The devkit is a main idea - most of the work is to put something on the UML wiki and market well the idea - creating such an image would be easy. But I haven't clear what you're talking about - kernel development (why sources inside) or userspace development? Also integrating all possible debug stuff would be useful, but I don't know what's needed. > i think this could be very helpful for linux-kernel, because it could be > tested by more people more quickly, more easily and thus, more often. just > download, do few steps for setup, start up that virtual machine and there > you go testing, hacking into the sources, do all that things you never > would do on your main system, whatever > > it would probably also add benefit to UML itself. We need three things: a) more performance b) more users c) more developers a) leads to c), and b) too. > does this sound dumb? i don`t know, so please comment. No, it's not dumb. I'm even wanting to have a "Vmware-like" interface. Or at least standard scripts for guest management. > regards > roland > > PS: > ok, this would be some 500M to 1G download, but there`s lot`s of bandwidth > today - and P2P/Bittorrent. uml.nagafix.co.uk has some good kernels + images. With compression, they're even as little as 50 Mb. However, making UML easier to use, and marketing it for more application, is very important. Various project do exist but they're not integrated, and they do not try to (netkit is for network experimentation, but is also better as VM management tool). In short, we'd need somebody helping out really with the website (there is the wiki but you must request an account via email, and it's not the main website), with uml-utilities, and with new uml-utilities (you know dm-snapshot is a faster COW? Something to setup it automatically would be good). There would be more to say on this, but I can't right now (I've other stuff to do). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] UML kernel rootfs bundle with every kernel release ?
On domenica 1 aprile 2007, [EMAIL PROTECTED] wrote: Hello ! i`m not very much into UML for the last months, but while playing around with dm-loop i just got one idea i`d like to share. Whenever you want to test some new kernel (feature), you may put you main system at risk, exactly know what you`re doing - or - use UserModeLinux. The problem with UML is: - you needs to compile an UML kernel first. - you needs some basic knowlege about UML to get things running. - you need to create an appropriate filesystem image for UML - or find some for download - you need to copy appropriate kernel modules inside Well, you just build usually monolithic kernels, so you skip this problem. And an idea that likely netkit uses is taking modules through an hostfs mount (or, it would be an easier setup). But you need modules to have uid 0... - you need to put kernel sources inside, have compiler.. - you may need appropriate modle-init-tools,initrd, kernel specific tools (updated dmsetup, updatedwhatever) You found 2.4 images, but 2.6 ones do exist. in short: it`s quite some work to be done to have your uml 2.6.21 with root-fs up and running and working cleanly. whenever i search the net for some appropriate UML fs image, those i find are very often old and outdated... Hmm... I'd think we need a wizard for configuration. Plus some distro-like work for some specific issues - if I want to deploy a VM with hostname x, network config y, and with Xnest running, I need an easier way to do that. You can add settings on kernel command line and parse them inside UML - we need standard packaged utilities for that (one of the rootfs builder installed such stuff). is there a project/website which is offering such ready to run UML kernel+rootfs release bundles for download (i.e. new kernel,generic root-fs, modules inside, sources inside, compiler inside - in sync with the latest stable vanilla) , or , would it make sense to establish such project ? i.e. besides releasing the kernel, also releasing sort of a kernel runtime kit and/or devkit ? The runtime kit is there on nagafix.co.uk. The devkit is a main idea - most of the work is to put something on the UML wiki and market well the idea - creating such an image would be easy. But I haven't clear what you're talking about - kernel development (why sources inside) or userspace development? Also integrating all possible debug stuff would be useful, but I don't know what's needed. i think this could be very helpful for linux-kernel, because it could be tested by more people more quickly, more easily and thus, more often. just download, do few steps for setup, start up that virtual machine and there you go testing, hacking into the sources, do all that things you never would do on your main system, whatever it would probably also add benefit to UML itself. We need three things: a) more performance b) more users c) more developers a) leads to c), and b) too. does this sound dumb? i don`t know, so please comment. No, it's not dumb. I'm even wanting to have a Vmware-like interface. Or at least standard scripts for guest management. regards roland PS: ok, this would be some 500M to 1G download, but there`s lot`s of bandwidth today - and P2P/Bittorrent. uml.nagafix.co.uk has some good kernels + images. With compression, they're even as little as 50 Mb. However, making UML easier to use, and marketing it for more application, is very important. Various project do exist but they're not integrated, and they do not try to (netkit is for network experimentation, but is also better as VM management tool). In short, we'd need somebody helping out really with the website (there is the wiki but you must request an account via email, and it's not the main website), with uml-utilities, and with new uml-utilities (you know dm-snapshot is a faster COW? Something to setup it automatically would be good). There would be more to say on this, but I can't right now (I've other stuff to do). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Auto-fixups for CodingStyle against major UML violations
Have you got sick of fixing your sources CodingStyle by hand? Are you
reintroducing violations because you've always programmed in a certain style
and those kernel hacker have dictated an insane one which you'll never learn?
Stop that, the spamful company "BlaisorBlade Inc. " has the right solution for
you, and this spam letter is going to explain ;-) !
Without using lindent, and with just a few sed/vim substitutions, it fixes
most of the problems we keep having. I wrote most of it with vim, and I
discovered it has another advantage: most of the substitutions also work on
patches (well, not so straightforward, but anyway good).
Also, it calls quilt to create a patch for all this stuff, and can optionally
do binary comparison to verify substitutions are safe (this is only coded,
not tested).
The only exception is the one to move labels to the first column - a slightly
different sub would be needed:
sed -e 's/\(\(.*\))/return \1/' \
-e 's/\ \?(\(.*\)){/if (\1) {/' \
-e 's/\(\(.*\))/if (\1)/' \
-e 's/\ \?(\(.*\)){/for (\1) {/' \
-e 's/\(\(.*\))/for (\1)/' \
-e 's/\ \?(\(.*\)){/while (\1) {/' \
-e 's/\(\(.*\))/while (\1)/' \
-e 's/^ \([a-z_]*:\)/\1/' \
This:
-e 's/^ \([a-z_]*:\)/\1/'
would become this:
-e 's/^\([ +-]\) \([a-z_]*:\)/\1\2/'
To yet test well:
- spaces to tabs (easy)
- binary comparison
Missing features:
- break if (foo) bar(); on two lines (probably won't do this one)
- do the work on patches
- have a sane cmd line interface (most of config is inside it).
Results:
*) in less than 10 seconds (cache-hot) generates a 416k on arch/um and
include/asm-um:
$ diffstat $(quilt top)|tail -n 1
147 files changed, 2360 insertions(+), 2360 deletions(-)
*) doesn't clutter the source tree nor temp directories, if you have quilt
installed.
I attach this with no guarantee at all, however! Bye!
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
do-src-style-fix
Description: application/shellscript
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On giovedì 29 marzo 2007, Jeff Dike wrote: > On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote: > > > Sometimes you need to. I'd probably just remove the do_ubd check and > > > always recall the request function when handling completions, it's > > > easier and safe. > > If I'm understanding this correctly, this is what happens now. There > is still the flag check and return if the queue is being run, but I > don't see the advantage of removing that. Possibly he just didn't understood what do_ubd was for, maybe there's some technical reason. > That's a lot of mapping and unmapping though. I wonder if just > calling mmap would cause the COWed page to be dropped... Yes, it would. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On giovedì 29 marzo 2007, Jeff Dike wrote: On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote: Sometimes you need to. I'd probably just remove the do_ubd check and always recall the request function when handling completions, it's easier and safe. If I'm understanding this correctly, this is what happens now. There is still the flag check and return if the queue is being run, but I don't see the advantage of removing that. Possibly he just didn't understood what do_ubd was for, maybe there's some technical reason. That's a lot of mapping and unmapping though. I wonder if just calling mmap would cause the COWed page to be dropped... Yes, it would. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Auto-fixups for CodingStyle against major UML violations
Have you got sick of fixing your sources CodingStyle by hand? Are you
reintroducing violations because you've always programmed in a certain style
and those kernel hacker have dictated an insane one which you'll never learn?
Stop that, the spamful company BlaisorBlade Inc. has the right solution for
you, and this spam letter is going to explain ;-) !
Without using lindent, and with just a few sed/vim substitutions, it fixes
most of the problems we keep having. I wrote most of it with vim, and I
discovered it has another advantage: most of the substitutions also work on
patches (well, not so straightforward, but anyway good).
Also, it calls quilt to create a patch for all this stuff, and can optionally
do binary comparison to verify substitutions are safe (this is only coded,
not tested).
The only exception is the one to move labels to the first column - a slightly
different sub would be needed:
sed -e 's/\return\(\(.*\))/return \1/' \
-e 's/\if\ \?(\(.*\)){/if (\1) {/' \
-e 's/\if\(\(.*\))/if (\1)/' \
-e 's/\for\ \?(\(.*\)){/for (\1) {/' \
-e 's/\for\(\(.*\))/for (\1)/' \
-e 's/\while\ \?(\(.*\)){/while (\1) {/' \
-e 's/\while\(\(.*\))/while (\1)/' \
-e 's/^ \([a-z_]*:\)/\1/' \
This:
-e 's/^ \([a-z_]*:\)/\1/'
would become this:
-e 's/^\([ +-]\) \([a-z_]*:\)/\1\2/'
To yet test well:
- spaces to tabs (easy)
- binary comparison
Missing features:
- break if (foo) bar(); on two lines (probably won't do this one)
- do the work on patches
- have a sane cmd line interface (most of config is inside it).
Results:
*) in less than 10 seconds (cache-hot) generates a 416k on arch/um and
include/asm-um:
$ diffstat $(quilt top)|tail -n 1
147 files changed, 2360 insertions(+), 2360 deletions(-)
*) doesn't clutter the source tree nor temp directories, if you have quilt
installed.
I attach this with no guarantee at all, however! Bye!
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
do-src-style-fix
Description: application/shellscript
Re: [uml-devel] [patch 06/37] UML - Fix static linking
On venerdì 30 marzo 2007, Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
I have one objection, the fix has a typo! This is the additional fix
(note '.note' instead of 'note'):
--- linux-2.6.git.orig/include/asm-um/common.lds.S
+++ linux-2.6.git/include/asm-um/common.lds.S
@@ -15,7 +15,7 @@
PROVIDE (_unprotected_end = .);
. = ALIGN(4096);
- .note : { *(note.*) }
+ .note : { *(.note.*) }
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
With this, the fix should be merged - I just re-hit this bug and rechecked
everything, now it's ok.
> --
> From: Jeff Dike <[EMAIL PROTECTED]>
>
> During a static link, ld has started putting a .note section in the
> .uml.setup.init section. This has the result that the UML setups
> begin with 32 bytes of garbage and UML crashes immediately on boot.
>
> This patch creates a specific .note section for ld to drop this stuff
> into.
>
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
> ---
> include/asm-um/common.lds.S |1 +
> 1 file changed, 1 insertion(+)
>
> --- a/include/asm-um/common.lds.S
> +++ b/include/asm-um/common.lds.S
> @@ -15,6 +15,7 @@
>PROVIDE (_unprotected_end = .);
>
>. = ALIGN(4096);
> + .note : { *(note.*) }
>__start___ex_table = .;
>__ex_table : { *(__ex_table) }
>__stop___ex_table = .;
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [PATCH] uml: fix static linking for real
There was a typo in commit 7632fc8f809a97f9d82ce125e8e3e579390ce2e5, preventing
it from working - 32bit binaries crashed hopelessly before the below fix and
work perfectly now.
Merge for 2.6.21, please.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
include/asm-um/common.lds.S |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-um/common.lds.S b/include/asm-um/common.lds.S
index b16222b..f5de80c 100644
--- a/include/asm-um/common.lds.S
+++ b/include/asm-um/common.lds.S
@@ -15,7 +15,7 @@
PROVIDE (_unprotected_end = .);
. = ALIGN(4096);
- .note : { *(note.*) }
+ .note : { *(.note.*) }
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)
set_up_list3s is not __init and references initkmem_list3.
Also, kmem_cache_create calls setup_cpu_cache which calls set_up_list3s. The
state machine _may_ prevent the code from accessing this data after freeing
initdata (it makes sure it's used only up to boot), so this warning may be a
false positive.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
mm/slab.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 0934f8d..0772faf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -305,7 +305,7 @@ struct kmem_list3 {
* Need this for bootstrapping a per node allocator.
*/
#define NUM_INIT_LISTS (2 * MAX_NUMNODES + 1)
-struct kmem_list3 __initdata initkmem_list3[NUM_INIT_LISTS];
+struct kmem_list3 initkmem_list3[NUM_INIT_LISTS];
#defineCACHE_CACHE 0
#defineSIZE_AC 1
#defineSIZE_L3 (1 + MAX_NUMNODES)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] utrace - uml: make UML compile with utrace enabled
* The prototype of arch_ptrace doesn't match the one in include/linux/ptrace.h.
* utrace_um_native is referred to by utrace_native_view but never defined.
Cc: Jeff Dike <[EMAIL PROTECTED]>
Cc: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/kernel/ptrace.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
index f66d01c..a42caf3 100644
--- a/arch/um/kernel/ptrace.c
+++ b/arch/um/kernel/ptrace.c
@@ -16,7 +16,12 @@ void ptrace_disable(struct task_struct *child)
{
}
-long arch_ptrace(struct task_struct *child, long request, long addr, long data)
+const struct utrace_regset_view utrace_um_native;
+
+int arch_ptrace(long *request, struct task_struct *child,
+ struct utrace_attached_engine *engine,
+ unsigned long addr, unsigned long data,
+ long *retval)
{
return -ENOSYS;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 1/2] UML - Fix umid in xterm titles
On venerdì 30 marzo 2007, Jeff Dike wrote: > From: Davide Brini <[EMAIL PROTECTED]> > > Calls lines_init() *after* xterm_title is modified to include umid. > > Signed-off-by: Davide Brini <[EMAIL PROTECTED]> > Signed-off-by: Jeff Dike <[EMAIL PROTECTED]> Acked-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> > -- > arch/um/drivers/ssl.c |4 ++-- > arch/um/drivers/stdio_console.c |4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > Index: linux-2.6.21-mm/arch/um/drivers/ssl.c > === > --- linux-2.6.21-mm.orig/arch/um/drivers/ssl.c2007-03-30 > 10:11:01.0 -0400 +++ > linux-2.6.21-mm/arch/um/drivers/ssl.c 2007-03-30 10:28:51.0 -0400 > @@ -191,12 +191,12 @@ static int ssl_init(void) > ssl_driver = register_lines(, _ops, serial_lines, > ARRAY_SIZE(serial_lines)); > > - lines_init(serial_lines, ARRAY_SIZE(serial_lines), ); > - > new_title = add_xterm_umid(opts.xterm_title); > if (new_title != NULL) > opts.xterm_title = new_title; > > + lines_init(serial_lines, ARRAY_SIZE(serial_lines), ); > + > ssl_init_done = 1; > register_console(_cons); > return 0; > Index: linux-2.6.21-mm/arch/um/drivers/stdio_console.c > === > --- linux-2.6.21-mm.orig/arch/um/drivers/stdio_console.c 2007-03-30 > 10:11:01.0 -0400 +++ > linux-2.6.21-mm/arch/um/drivers/stdio_console.c 2007-03-30 > 10:28:51.0 -0400 @@ -166,12 +166,12 @@ int stdio_init(void) > return -1; > printk(KERN_INFO "Initialized stdio console driver\n"); > > - lines_init(vts, ARRAY_SIZE(vts), ); > - > new_title = add_xterm_umid(opts.xterm_title); > if(new_title != NULL) > opts.xterm_title = new_title; > > + lines_init(vts, ARRAY_SIZE(vts), ); > + > con_init_done = 1; > register_console(); > return 0; > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php=sourceforge=DEVDEV > ___ > User-mode-linux-devel mailing list > User-mode-linux-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] sys_futex64-allows-64bit-futexes-workaround for uml
Copy sys_futex64-allows-64bit-futexes-workaround.patch to UML (to unbreak the
UML build). Note however that in include/asm-generic/futex.h we have:
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
{
return -ENOSYS;
}
Which is a better solution. Pierre Peiffer, please consider that.
Cc: Pierre Peiffer <[EMAIL PROTECTED]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
include/asm-um/futex.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/asm-um/futex.h b/include/asm-um/futex.h
index 6a332a9..e875d3e 100644
--- a/include/asm-um/futex.h
+++ b/include/asm-um/futex.h
@@ -3,4 +3,17 @@
#include
+static inline u64
+futex_atomic_cmpxchg_inatomic64(u64 __user *uaddr, u64 oldval, u64 newval)
+{
+ return 0;
+}
+
+static inline int
+futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
+{
+ return 0;
+}
+
+
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] mm-only patches
Patch-arounds for mm-only compile errors/warnings, got on 2.6.21-rc5-mm2, still apply on 2.6.21-rc5-mm3. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/2] UML - Speed up exec
On venerdì 30 marzo 2007, Jeff Dike wrote:
> flush_thread doesn't need to do a full page table walk in order to
> clear the address space. It knows what the end result needs to be, so
> it can call unmap directly.
>
> This results in a 10-20% speedup in an exec from bash.
Oh, yeah!
When porting part of Ingo's work, I realized that a similar thing can be done
for fork().
If the whole address space is unmapped in init_new_context_skas(), the first
fix_range_common() call won't need to call unmap at all. He did this with
remap_file_pages(), where init_new_context_skas() must "unmap" everything
anyway.
This is giving some speedup in lmbench (5% better in fork proc, 2% better in
exec proc), but the results are still controversial, there is one benchmark
with a 2% slowdown (called 'mmap latency').
In a loop, it maps, touches a byte per page and unmaps a region with growing
size (up to 32MB).
However, since results aren't yet stable for some other benchmark (context
switching benchmark is crazy), I'm still studying on this.
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> --
> arch/um/kernel/skas/exec.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-mm/arch/um/kernel/skas/exec.c
> ===
> --- linux-2.6.21-mm.orig/arch/um/kernel/skas/exec.c 2007-03-30
> 10:28:24.0 -0400 +++
> linux-2.6.21-mm/arch/um/kernel/skas/exec.c2007-03-30 10:30:15.0
> -0400 @@ -17,7 +17,17 @@
>
> void flush_thread_skas(void)
> {
> - force_flush_all();
> + void *data = NULL;
> + unsigned long end = proc_mm ? task_size : CONFIG_STUB_START;
> + int ret;
> +
> + ret = unmap(>mm->context.skas.id, 0, end, 1, );
> + if(ret){
> + printk("flush_thread_skas - clearing address space failed, "
> +"err = %d\n", ret);
> + force_sig(SIGKILL, current);
> + }
> +
> switch_mm_skas(>mm->context.skas.id);
> }
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Index: linux-2.6.git/arch/um/include/skas/mmu-skas.h
===
--- linux-2.6.git.orig/arch/um/include/skas/mmu-skas.h
+++ linux-2.6.git/arch/um/include/skas/mmu-skas.h
@@ -16,6 +16,7 @@ struct mmu_context_skas {
unsigned long last_pmd;
#endif
uml_ldt_t ldt;
+ int first_flush;
};
extern void switch_mm_skas(struct mm_id * mm_idp);
Index: linux-2.6.git/arch/um/kernel/skas/mmu.c
===
--- linux-2.6.git.orig/arch/um/kernel/skas/mmu.c
+++ linux-2.6.git/arch/um/kernel/skas/mmu.c
@@ -77,6 +77,7 @@ int init_new_context_skas(struct task_st
struct mmu_context_skas *to_mm = >context.skas;
unsigned long stack = 0;
int ret = -ENOMEM;
+ void *unused = NULL;
if(skas_needs_stub){
stack = get_zeroed_page(GFP_KERNEL);
@@ -121,6 +122,14 @@ int init_new_context_skas(struct task_st
else to_mm->id.u.pid = start_userspace(stack);
}
+ mm->context.skas.first_flush = 1;
+ ret = unmap(>context.skas.id, 0, TASK_SIZE, 1, );
+ if (ret < 0) {
+ printk("init_new_context_skas - unmap failed, "
+ "errno = %d; continuing\n", ret);
+ mm->context.skas.first_flush = 0;
+ }
+
ret = init_new_ldt(to_mm, from_mm);
if(ret < 0){
printk("init_new_context_skas - init_ldt"
Index: linux-2.6.git/arch/um/kernel/tlb.c
===
--- linux-2.6.git.orig/arch/um/kernel/tlb.c
+++ linux-2.6.git/arch/um/kernel/tlb.c
@@ -139,10 +139,17 @@ void fix_range_common(struct mm_struct *
void *flush = NULL;
int op_index = -1, last_op = ARRAY_SIZE(ops) - 1;
int ret = 0;
+ int first_flush;
if(mm == NULL)
return;
+ /* Nothing is mapped in this address space, so no call to add_munmap()
+ * must be done */
+ first_flush = mm->context.skas.first_flush;
+
+ mm->context.skas.first_flush = 0;
+
ops[0].type = NONE;
for(addr = start_addr; addr < end_addr && !ret;){
npgd = pgd_offset(mm, addr);
@@ -151,9 +158,10 @@ void fix_range_common(struct mm_struct *
if(end > end_addr)
end = end_addr;
if(force || pgd_newpage(*npgd)){
-ret = add_munmap(addr, end - addr, ops,
- _index, last_op, mmu,
- , do_ops);
+if (!first_flush)
+ ret = add_munmap(addr, end - addr, ops,
+ _index, last_op, mmu,
+ , do_ops);
pgd_mkuptodate(*npgd);
}
addr = end;
@@ -166,9 +174,10 @@ void fix_range_common(struct mm_struct *
if(end > end_addr)
end = end_addr;
if(force || pud_newpage(*npud)){
-ret = add_munmap(addr, end - addr, ops,
- _index, last_op
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On giovedì 29 marzo 2007, Jeff Dike wrote: > On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote: > > > Sometimes you need to. I'd probably just remove the do_ubd check and > > > always recall the request function when handling completions, it's > > > easier and safe. > > If I'm understanding this correctly, this is what happens now. There > is still the flag check and return if the queue is being run, but I > don't see the advantage of removing that. > > > Anyway, the main speedups to do on the UBD driver are: > > * implement write barriers (so much less fsync) - this is performance > > killer n.1 > > You mean preventing the upper layers from calling fsync? No. Since we don't know when the upper layers (including the journaling layer) wants to fsync, we call it everytime. But they pass this information. Chris Lightfoot implemented write barriers just before the API was changed, together with much of the other stuff I'm talking about. It's impressive to check his original mail - the scenario with create a 32M file + delete it, where delete takes a minute on vanilla and 1 second on his patched code. I've downloaded the patch for future reference, even if I don't know when I'll have time to look at it. > > * possibly to use the new 2.6 request layout with scatter/gather I/O, and > > vectorized I/O on the host > > Yeah, this is something I've thought about on occassion but never > done. > > > * while at vectorizing I/O using async I/O > > I have that, but haven't merged it since I see no performance benefit > for some reason. > > > * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes > > cpu-bound. > > Right - I cooked up a scheme a while ago that had the requests on a > list, being removed from one end and added to the other, with some > minimal number of bytes going across the pipe to ensure a wakeup if > the other side was possibly asleep. But I never implemented it. > > > * using futexes instead of pipes for synchronization (required for > > previous one). > > Yup - for this, we either need to test the host for futuxes and use > pipes as a fallback or give up on 2.4 as the host. > > > I forgot one thing: remember ubd=mmap? Something like that could have > > been done using MAP_PRIVATE, so that write had still to be called > > explicitly but unchanged data was shared with the host. > > > > Once a page gets dirty but is then cleaned, sharing it back is > > difficult - but even without that good savings could be > > achievable. That's to explore for the very future though. > > Interesting idea. That does avoid the formerly fatal mmap problem. > If you unmap it, the private copy goes away because it lost its last > reference, and if you map it again, you get the shared version. > > That's a lot of mapping and unmapping though. I wonder if just > calling mmap would cause the COWed page to be dropped... > > Jeff -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On giovedì 29 marzo 2007, Jeff Dike wrote: On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote: Sometimes you need to. I'd probably just remove the do_ubd check and always recall the request function when handling completions, it's easier and safe. If I'm understanding this correctly, this is what happens now. There is still the flag check and return if the queue is being run, but I don't see the advantage of removing that. Anyway, the main speedups to do on the UBD driver are: * implement write barriers (so much less fsync) - this is performance killer n.1 You mean preventing the upper layers from calling fsync? No. Since we don't know when the upper layers (including the journaling layer) wants to fsync, we call it everytime. But they pass this information. Chris Lightfoot implemented write barriers just before the API was changed, together with much of the other stuff I'm talking about. It's impressive to check his original mail - the scenario with create a 32M file + delete it, where delete takes a minute on vanilla and 1 second on his patched code. I've downloaded the patch for future reference, even if I don't know when I'll have time to look at it. * possibly to use the new 2.6 request layout with scatter/gather I/O, and vectorized I/O on the host Yeah, this is something I've thought about on occassion but never done. * while at vectorizing I/O using async I/O I have that, but haven't merged it since I see no performance benefit for some reason. * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes cpu-bound. Right - I cooked up a scheme a while ago that had the requests on a list, being removed from one end and added to the other, with some minimal number of bytes going across the pipe to ensure a wakeup if the other side was possibly asleep. But I never implemented it. * using futexes instead of pipes for synchronization (required for previous one). Yup - for this, we either need to test the host for futuxes and use pipes as a fallback or give up on 2.4 as the host. I forgot one thing: remember ubd=mmap? Something like that could have been done using MAP_PRIVATE, so that write had still to be called explicitly but unchanged data was shared with the host. Once a page gets dirty but is then cleaned, sharing it back is difficult - but even without that good savings could be achievable. That's to explore for the very future though. Interesting idea. That does avoid the formerly fatal mmap problem. If you unmap it, the private copy goes away because it lost its last reference, and if you map it again, you get the shared version. That's a lot of mapping and unmapping though. I wonder if just calling mmap would cause the COWed page to be dropped... Jeff -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 2/2] UML - Speed up exec
On venerdì 30 marzo 2007, Jeff Dike wrote:
flush_thread doesn't need to do a full page table walk in order to
clear the address space. It knows what the end result needs to be, so
it can call unmap directly.
This results in a 10-20% speedup in an exec from bash.
Oh, yeah!
When porting part of Ingo's work, I realized that a similar thing can be done
for fork().
If the whole address space is unmapped in init_new_context_skas(), the first
fix_range_common() call won't need to call unmap at all. He did this with
remap_file_pages(), where init_new_context_skas() must unmap everything
anyway.
This is giving some speedup in lmbench (5% better in fork proc, 2% better in
exec proc), but the results are still controversial, there is one benchmark
with a 2% slowdown (called 'mmap latency').
In a loop, it maps, touches a byte per page and unmaps a region with growing
size (up to 32MB).
However, since results aren't yet stable for some other benchmark (context
switching benchmark is crazy), I'm still studying on this.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
--
arch/um/kernel/skas/exec.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: linux-2.6.21-mm/arch/um/kernel/skas/exec.c
===
--- linux-2.6.21-mm.orig/arch/um/kernel/skas/exec.c 2007-03-30
10:28:24.0 -0400 +++
linux-2.6.21-mm/arch/um/kernel/skas/exec.c2007-03-30 10:30:15.0
-0400 @@ -17,7 +17,17 @@
void flush_thread_skas(void)
{
- force_flush_all();
+ void *data = NULL;
+ unsigned long end = proc_mm ? task_size : CONFIG_STUB_START;
+ int ret;
+
+ ret = unmap(current-mm-context.skas.id, 0, end, 1, data);
+ if(ret){
+ printk(flush_thread_skas - clearing address space failed,
+err = %d\n, ret);
+ force_sig(SIGKILL, current);
+ }
+
switch_mm_skas(current-mm-context.skas.id);
}
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Index: linux-2.6.git/arch/um/include/skas/mmu-skas.h
===
--- linux-2.6.git.orig/arch/um/include/skas/mmu-skas.h
+++ linux-2.6.git/arch/um/include/skas/mmu-skas.h
@@ -16,6 +16,7 @@ struct mmu_context_skas {
unsigned long last_pmd;
#endif
uml_ldt_t ldt;
+ int first_flush;
};
extern void switch_mm_skas(struct mm_id * mm_idp);
Index: linux-2.6.git/arch/um/kernel/skas/mmu.c
===
--- linux-2.6.git.orig/arch/um/kernel/skas/mmu.c
+++ linux-2.6.git/arch/um/kernel/skas/mmu.c
@@ -77,6 +77,7 @@ int init_new_context_skas(struct task_st
struct mmu_context_skas *to_mm = mm-context.skas;
unsigned long stack = 0;
int ret = -ENOMEM;
+ void *unused = NULL;
if(skas_needs_stub){
stack = get_zeroed_page(GFP_KERNEL);
@@ -121,6 +122,14 @@ int init_new_context_skas(struct task_st
else to_mm-id.u.pid = start_userspace(stack);
}
+ mm-context.skas.first_flush = 1;
+ ret = unmap(mm-context.skas.id, 0, TASK_SIZE, 1, unused);
+ if (ret 0) {
+ printk(init_new_context_skas - unmap failed,
+ errno = %d; continuing\n, ret);
+ mm-context.skas.first_flush = 0;
+ }
+
ret = init_new_ldt(to_mm, from_mm);
if(ret 0){
printk(init_new_context_skas - init_ldt
Index: linux-2.6.git/arch/um/kernel/tlb.c
===
--- linux-2.6.git.orig/arch/um/kernel/tlb.c
+++ linux-2.6.git/arch/um/kernel/tlb.c
@@ -139,10 +139,17 @@ void fix_range_common(struct mm_struct *
void *flush = NULL;
int op_index = -1, last_op = ARRAY_SIZE(ops) - 1;
int ret = 0;
+ int first_flush;
if(mm == NULL)
return;
+ /* Nothing is mapped in this address space, so no call to add_munmap()
+ * must be done */
+ first_flush = mm-context.skas.first_flush;
+
+ mm-context.skas.first_flush = 0;
+
ops[0].type = NONE;
for(addr = start_addr; addr end_addr !ret;){
npgd = pgd_offset(mm, addr);
@@ -151,9 +158,10 @@ void fix_range_common(struct mm_struct *
if(end end_addr)
end = end_addr;
if(force || pgd_newpage(*npgd)){
-ret = add_munmap(addr, end - addr, ops,
- op_index, last_op, mmu,
- flush, do_ops);
+if (!first_flush)
+ ret = add_munmap(addr, end - addr, ops,
+ op_index, last_op, mmu,
+ flush, do_ops);
pgd_mkuptodate(*npgd);
}
addr = end;
@@ -166,9 +174,10 @@ void fix_range_common(struct mm_struct *
if(end end_addr)
end = end_addr;
if(force || pud_newpage(*npud)){
-ret = add_munmap(addr, end - addr, ops,
- op_index, last_op, mmu,
- flush, do_ops);
+if (!first_flush)
+ ret = add_munmap(addr, end - addr, ops,
+ op_index, last_op, mmu,
+ flush, do_ops);
pud_mkuptodate(*npud);
}
addr = end;
@@ -181,9 +190,10 @@ void fix_range_common
[PATCH 2/3] sys_futex64-allows-64bit-futexes-workaround for uml
Copy sys_futex64-allows-64bit-futexes-workaround.patch to UML (to unbreak the
UML build). Note however that in include/asm-generic/futex.h we have:
static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
{
return -ENOSYS;
}
Which is a better solution. Pierre Peiffer, please consider that.
Cc: Pierre Peiffer [EMAIL PROTECTED]
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
include/asm-um/futex.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/asm-um/futex.h b/include/asm-um/futex.h
index 6a332a9..e875d3e 100644
--- a/include/asm-um/futex.h
+++ b/include/asm-um/futex.h
@@ -3,4 +3,17 @@
#include asm-generic/futex.h
+static inline u64
+futex_atomic_cmpxchg_inatomic64(u64 __user *uaddr, u64 oldval, u64 newval)
+{
+ return 0;
+}
+
+static inline int
+futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
+{
+ return 0;
+}
+
+
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] mm-only patches
Patch-arounds for mm-only compile errors/warnings, got on 2.6.21-rc5-mm2, still apply on 2.6.21-rc5-mm3. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)
set_up_list3s is not __init and references initkmem_list3.
Also, kmem_cache_create calls setup_cpu_cache which calls set_up_list3s. The
state machine _may_ prevent the code from accessing this data after freeing
initdata (it makes sure it's used only up to boot), so this warning may be a
false positive.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
mm/slab.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/slab.c b/mm/slab.c
index 0934f8d..0772faf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -305,7 +305,7 @@ struct kmem_list3 {
* Need this for bootstrapping a per node allocator.
*/
#define NUM_INIT_LISTS (2 * MAX_NUMNODES + 1)
-struct kmem_list3 __initdata initkmem_list3[NUM_INIT_LISTS];
+struct kmem_list3 initkmem_list3[NUM_INIT_LISTS];
#defineCACHE_CACHE 0
#defineSIZE_AC 1
#defineSIZE_L3 (1 + MAX_NUMNODES)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] utrace - uml: make UML compile with utrace enabled
* The prototype of arch_ptrace doesn't match the one in include/linux/ptrace.h.
* utrace_um_native is referred to by utrace_native_view but never defined.
Cc: Jeff Dike [EMAIL PROTECTED]
Cc: Roland McGrath [EMAIL PROTECTED]
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
arch/um/kernel/ptrace.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
index f66d01c..a42caf3 100644
--- a/arch/um/kernel/ptrace.c
+++ b/arch/um/kernel/ptrace.c
@@ -16,7 +16,12 @@ void ptrace_disable(struct task_struct *child)
{
}
-long arch_ptrace(struct task_struct *child, long request, long addr, long data)
+const struct utrace_regset_view utrace_um_native;
+
+int arch_ptrace(long *request, struct task_struct *child,
+ struct utrace_attached_engine *engine,
+ unsigned long addr, unsigned long data,
+ long *retval)
{
return -ENOSYS;
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 1/2] UML - Fix umid in xterm titles
On venerdì 30 marzo 2007, Jeff Dike wrote: From: Davide Brini [EMAIL PROTECTED] Calls lines_init() *after* xterm_title is modified to include umid. Signed-off-by: Davide Brini [EMAIL PROTECTED] Signed-off-by: Jeff Dike [EMAIL PROTECTED] Acked-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] -- arch/um/drivers/ssl.c |4 ++-- arch/um/drivers/stdio_console.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6.21-mm/arch/um/drivers/ssl.c === --- linux-2.6.21-mm.orig/arch/um/drivers/ssl.c2007-03-30 10:11:01.0 -0400 +++ linux-2.6.21-mm/arch/um/drivers/ssl.c 2007-03-30 10:28:51.0 -0400 @@ -191,12 +191,12 @@ static int ssl_init(void) ssl_driver = register_lines(driver, ssl_ops, serial_lines, ARRAY_SIZE(serial_lines)); - lines_init(serial_lines, ARRAY_SIZE(serial_lines), opts); - new_title = add_xterm_umid(opts.xterm_title); if (new_title != NULL) opts.xterm_title = new_title; + lines_init(serial_lines, ARRAY_SIZE(serial_lines), opts); + ssl_init_done = 1; register_console(ssl_cons); return 0; Index: linux-2.6.21-mm/arch/um/drivers/stdio_console.c === --- linux-2.6.21-mm.orig/arch/um/drivers/stdio_console.c 2007-03-30 10:11:01.0 -0400 +++ linux-2.6.21-mm/arch/um/drivers/stdio_console.c 2007-03-30 10:28:51.0 -0400 @@ -166,12 +166,12 @@ int stdio_init(void) return -1; printk(KERN_INFO Initialized stdio console driver\n); - lines_init(vts, ARRAY_SIZE(vts), opts); - new_title = add_xterm_umid(opts.xterm_title); if(new_title != NULL) opts.xterm_title = new_title; + lines_init(vts, ARRAY_SIZE(vts), opts); + con_init_done = 1; register_console(stdiocons); return 0; - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [patch 06/37] UML - Fix static linking
On venerdì 30 marzo 2007, Greg KH wrote:
-stable review patch. If anyone has any objections, please let us know.
I have one objection, the fix has a typo! This is the additional fix
(note '.note' instead of 'note'):
--- linux-2.6.git.orig/include/asm-um/common.lds.S
+++ linux-2.6.git/include/asm-um/common.lds.S
@@ -15,7 +15,7 @@
PROVIDE (_unprotected_end = .);
. = ALIGN(4096);
- .note : { *(note.*) }
+ .note : { *(.note.*) }
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
With this, the fix should be merged - I just re-hit this bug and rechecked
everything, now it's ok.
--
From: Jeff Dike [EMAIL PROTECTED]
During a static link, ld has started putting a .note section in the
.uml.setup.init section. This has the result that the UML setups
begin with 32 bytes of garbage and UML crashes immediately on boot.
This patch creates a specific .note section for ld to drop this stuff
into.
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
include/asm-um/common.lds.S |1 +
1 file changed, 1 insertion(+)
--- a/include/asm-um/common.lds.S
+++ b/include/asm-um/common.lds.S
@@ -15,6 +15,7 @@
PROVIDE (_unprotected_end = .);
. = ALIGN(4096);
+ .note : { *(note.*) }
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [PATCH] uml: fix static linking for real
There was a typo in commit 7632fc8f809a97f9d82ce125e8e3e579390ce2e5, preventing
it from working - 32bit binaries crashed hopelessly before the below fix and
work perfectly now.
Merge for 2.6.21, please.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
include/asm-um/common.lds.S |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-um/common.lds.S b/include/asm-um/common.lds.S
index b16222b..f5de80c 100644
--- a/include/asm-um/common.lds.S
+++ b/include/asm-um/common.lds.S
@@ -15,7 +15,7 @@
PROVIDE (_unprotected_end = .);
. = ALIGN(4096);
- .note : { *(note.*) }
+ .note : { *(.note.*) }
__start___ex_table = .;
__ex_table : { *(__ex_table) }
__stop___ex_table = .;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On giovedì 29 marzo 2007, Blaisorblade wrote: > On mercoledì 28 marzo 2007, Jeff Dike wrote: > > [ This patch needs to get into 2.6.21, as it fixes a serious bug > > introduced soon after 2.6.20 ] > > > > Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices > > queues and locks, which was fine as far as it went, but left in place > > a global which controlled access to submitting requests to the host. > > This should have been made per-device as well, since it causes I/O > > hangs when multiple block devices are in use. > > > > This patch fixes that by replacing the global with an activity flag in > > the device structure in order to tell whether the queue is currently > > being run. > > Finally that variable has a understandable name. However in a mail from > Jens Axboe, titled: > "Re: [uml-devel] [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup" , > with Date: Mon, 30 Oct 2006 09:26:48 +0100, he suggested removing this flag > > altogether, so we may explore this for the future: > > > Add some comments about requirements for ubd_io_lock and expand its > > > use. > > > > > > When an irq signals that the "controller" (i.e. another thread on the > > > host, which does the actual requests and is the only one blocked on I/O > > > on the host) has done some work, we call again the request function > > > ourselves (do_ubd_request). > > > We now do that with ubd_io_lock held - that's useful to protect against > > > concurrent calls to elv_next_request and so on. > > Not only useful, required, as I think I complained about a year or more > > ago :-) > > > XXX: Maybe we shouldn't call at all the request function. Input needed > > > on this. Are we supposed to plug and unplug the queue? That code > > > "indirectly" does that by setting a flag, called do_ubd, which makes > > > the request function return (it's a residual of 2.4 block layer > > > interface). > > Sometimes you need to. I'd probably just remove the do_ubd check and > > always recall the request function when handling completions, it's > > easier and safe. > Anyway, the main speedups to do on the UBD driver are: > * implement write barriers (so much less fsync) - this is performance > killer n.1 > * possibly to use the new 2.6 request layout with scatter/gather I/O, and > vectorized I/O on the host > * while at vectorizing I/O using async I/O > * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes > cpu-bound. > To make a different but related example, with a SpeedScale laptop, it's > interesting to double CPU frequency and observe tuntap speed double too. > (with 1GHz I get on TCP numbers like 150 Mbit/s - 100 Mbit/s, depending > whether UML trasmits or receives data; with 2GHz double rates). > Update: I now get 150Mbit / 200Mbit (Uml receives/Uml sends) at 1GHz, and > still the double at 2Ghz. > This is a different UML though. > * using futexes instead of pipes for synchronization (required for previous > one). I forgot one thing: remember ubd=mmap? Something like that could have been done using MAP_PRIVATE, so that write had still to be called explicitly but unchanged data was shared with the host. Once a page gets dirty but is then cleaned, sharing it back is difficult - but even without that good savings could be achievable. That's to explore for the very future though. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On mercoledì 28 marzo 2007, Jeff Dike wrote: > [ This patch needs to get into 2.6.21, as it fixes a serious bug > introduced soon after 2.6.20 ] > > Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices > queues and locks, which was fine as far as it went, but left in place > a global which controlled access to submitting requests to the host. > This should have been made per-device as well, since it causes I/O > hangs when multiple block devices are in use. > > This patch fixes that by replacing the global with an activity flag in > the device structure in order to tell whether the queue is currently > being run. Finally that variable has a understandable name. However in a mail from Jens Axboe, titled: "Re: [uml-devel] [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup" , with Date: Mon, 30 Oct 2006 09:26:48 +0100, he suggested removing this flag altogether, so we may explore this for the future: > > Add some comments about requirements for ubd_io_lock and expand its use. > > > > When an irq signals that the "controller" (i.e. another thread on the > > host, which does the actual requests and is the only one blocked on I/O > > on the host) has done some work, we call again the request function > > ourselves (do_ubd_request). > > > > We now do that with ubd_io_lock held - that's useful to protect against > > concurrent calls to elv_next_request and so on. > > Not only useful, required, as I think I complained about a year or more > ago :-) > > > XXX: Maybe we shouldn't call at all the request function. Input needed on > > this. Are we supposed to plug and unplug the queue? That code > > "indirectly" does that by setting a flag, called do_ubd, which makes the > > request function return (it's a residual of 2.4 block layer interface). > > Sometimes you need to. I'd probably just remove the do_ubd check and > always recall the request function when handling completions, it's > easier and safe. Anyway, the main speedups to do on the UBD driver are: * implement write barriers (so much less fsync) - this is performance killer n.1 * possibly to use the new 2.6 request layout with scatter/gather I/O, and vectorized I/O on the host * while at vectorizing I/O using async I/O * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes cpu-bound. To make a different but related example, with a SpeedScale laptop, it's interesting to double CPU frequency and observe tuntap speed double too. (with 1GHz I get on TCP numbers like 150 Mbit/s - 100 Mbit/s, depending whether UML trasmits or receives data; with 2GHz double rates). Update: I now get 150Mbit / 200Mbit (Uml receives/Uml sends) at 1GHz, and still the double at 2Ghz. This is a different UML though. * using futexes instead of pipes for synchronization (required for previous one). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.21] uml: fix unreasonably long udelay
Currently we have a confused udelay implementation.
* __const_udelay does not accept usecs but xloops in i386 and x86_64
* our implementation requires usecs as arg
* it gets a xloops count when called by asm/arch/delay.h
Bugs related to this (extremely long shutdown times) where reported by some
x86_64 users, especially using Device Mapper.
To hit this bug, a compile-time constant time parameter must be passed - that's
why UML seems to work most times.
Fix this with a simple udelay implementation.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/sys-i386/delay.c | 11 ---
arch/um/sys-x86_64/delay.c | 11 ---
include/asm-um/delay.h | 17 ++---
3 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/arch/um/sys-i386/delay.c b/arch/um/sys-i386/delay.c
index 2c11b97..d623e07 100644
--- a/arch/um/sys-i386/delay.c
+++ b/arch/um/sys-i386/delay.c
@@ -27,14 +27,3 @@ void __udelay(unsigned long usecs)
}
EXPORT_SYMBOL(__udelay);
-
-void __const_udelay(unsigned long usecs)
-{
- int i, n;
-
- n = (loops_per_jiffy * HZ * usecs) / MILLION;
-for(i=0;i 2) ? \
+ __bad_udelay() : __udelay(n))
+
+/* It appears that ndelay is not used at all for UML, and has never been
+ * implemented. */
+extern void __unimplemented_ndelay(void);
+#define ndelay(n) __unimplemented_ndelay()
+
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + uml-fix-pte-bit-collision.patch added to -mm tree
On martedì 27 marzo 2007, [EMAIL PROTECTED] wrote: > The patch titled > uml: fix pte bit collision > has been added to the -mm tree. Its filename is > uml-fix-pte-bit-collision.patch ACK from me: Acked-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> > *** Remember to use Documentation/SubmitChecklist when testing your code > *** > > See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find > out what to do about this > -- > Subject: uml: fix pte bit collision > From: Miklos Szeredi <[EMAIL PROTECTED]> > > _PAGE_PROTNONE conflicts with the lowest bit of pgoff. This causes all > sorts of weirdness when nonlinear mappings are used. Hmm, I had unit-tested to death the code with a custom test-program... The interesting thing is that I only tested my remap_file_pages changes (which are unaffected by this), not the existing code... -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + uml-fix-pte-bit-collision.patch added to -mm tree
On martedì 27 marzo 2007, [EMAIL PROTECTED] wrote: The patch titled uml: fix pte bit collision has been added to the -mm tree. Its filename is uml-fix-pte-bit-collision.patch ACK from me: Acked-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find out what to do about this -- Subject: uml: fix pte bit collision From: Miklos Szeredi [EMAIL PROTECTED] _PAGE_PROTNONE conflicts with the lowest bit of pgoff. This causes all sorts of weirdness when nonlinear mappings are used. Hmm, I had unit-tested to death the code with a custom test-program... The interesting thing is that I only tested my remap_file_pages changes (which are unaffected by this), not the existing code... -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][2.6.21] uml: fix unreasonably long udelay
Currently we have a confused udelay implementation.
* __const_udelay does not accept usecs but xloops in i386 and x86_64
* our implementation requires usecs as arg
* it gets a xloops count when called by asm/arch/delay.h
Bugs related to this (extremely long shutdown times) where reported by some
x86_64 users, especially using Device Mapper.
To hit this bug, a compile-time constant time parameter must be passed - that's
why UML seems to work most times.
Fix this with a simple udelay implementation.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
arch/um/sys-i386/delay.c | 11 ---
arch/um/sys-x86_64/delay.c | 11 ---
include/asm-um/delay.h | 17 ++---
3 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/arch/um/sys-i386/delay.c b/arch/um/sys-i386/delay.c
index 2c11b97..d623e07 100644
--- a/arch/um/sys-i386/delay.c
+++ b/arch/um/sys-i386/delay.c
@@ -27,14 +27,3 @@ void __udelay(unsigned long usecs)
}
EXPORT_SYMBOL(__udelay);
-
-void __const_udelay(unsigned long usecs)
-{
- int i, n;
-
- n = (loops_per_jiffy * HZ * usecs) / MILLION;
-for(i=0;in;i++)
-cpu_relax();
-}
-
-EXPORT_SYMBOL(__const_udelay);
diff --git a/arch/um/sys-x86_64/delay.c b/arch/um/sys-x86_64/delay.c
index 137f444..dee5be6 100644
--- a/arch/um/sys-x86_64/delay.c
+++ b/arch/um/sys-x86_64/delay.c
@@ -28,14 +28,3 @@ void __udelay(unsigned long usecs)
}
EXPORT_SYMBOL(__udelay);
-
-void __const_udelay(unsigned long usecs)
-{
- unsigned long i, n;
-
- n = (loops_per_jiffy * HZ * usecs) / MILLION;
-for(i=0;in;i++)
-cpu_relax();
-}
-
-EXPORT_SYMBOL(__const_udelay);
diff --git a/include/asm-um/delay.h b/include/asm-um/delay.h
index 0985bda..c71e32b 100644
--- a/include/asm-um/delay.h
+++ b/include/asm-um/delay.h
@@ -1,9 +1,20 @@
#ifndef __UM_DELAY_H
#define __UM_DELAY_H
-#include asm/arch/delay.h
-#include asm/archparam.h
-
#define MILLION 100
+/* Undefined on purpose */
+extern void __bad_udelay(void);
+
+extern void __udelay(unsigned long usecs);
+extern void __delay(unsigned long loops);
+
+#define udelay(n) ((__builtin_constant_p(n) (n) 2) ? \
+ __bad_udelay() : __udelay(n))
+
+/* It appears that ndelay is not used at all for UML, and has never been
+ * implemented. */
+extern void __unimplemented_ndelay(void);
+#define ndelay(n) __unimplemented_ndelay()
+
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On mercoledì 28 marzo 2007, Jeff Dike wrote: [ This patch needs to get into 2.6.21, as it fixes a serious bug introduced soon after 2.6.20 ] Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices queues and locks, which was fine as far as it went, but left in place a global which controlled access to submitting requests to the host. This should have been made per-device as well, since it causes I/O hangs when multiple block devices are in use. This patch fixes that by replacing the global with an activity flag in the device structure in order to tell whether the queue is currently being run. Finally that variable has a understandable name. However in a mail from Jens Axboe, titled: Re: [uml-devel] [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup , with Date: Mon, 30 Oct 2006 09:26:48 +0100, he suggested removing this flag altogether, so we may explore this for the future: Add some comments about requirements for ubd_io_lock and expand its use. When an irq signals that the controller (i.e. another thread on the host, which does the actual requests and is the only one blocked on I/O on the host) has done some work, we call again the request function ourselves (do_ubd_request). We now do that with ubd_io_lock held - that's useful to protect against concurrent calls to elv_next_request and so on. Not only useful, required, as I think I complained about a year or more ago :-) XXX: Maybe we shouldn't call at all the request function. Input needed on this. Are we supposed to plug and unplug the queue? That code indirectly does that by setting a flag, called do_ubd, which makes the request function return (it's a residual of 2.4 block layer interface). Sometimes you need to. I'd probably just remove the do_ubd check and always recall the request function when handling completions, it's easier and safe. Anyway, the main speedups to do on the UBD driver are: * implement write barriers (so much less fsync) - this is performance killer n.1 * possibly to use the new 2.6 request layout with scatter/gather I/O, and vectorized I/O on the host * while at vectorizing I/O using async I/O * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes cpu-bound. To make a different but related example, with a SpeedScale laptop, it's interesting to double CPU frequency and observe tuntap speed double too. (with 1GHz I get on TCP numbers like 150 Mbit/s - 100 Mbit/s, depending whether UML trasmits or receives data; with 2GHz double rates). Update: I now get 150Mbit / 200Mbit (Uml receives/Uml sends) at 1GHz, and still the double at 2Ghz. This is a different UML though. * using futexes instead of pipes for synchronization (required for previous one). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use
On giovedì 29 marzo 2007, Blaisorblade wrote: On mercoledì 28 marzo 2007, Jeff Dike wrote: [ This patch needs to get into 2.6.21, as it fixes a serious bug introduced soon after 2.6.20 ] Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices queues and locks, which was fine as far as it went, but left in place a global which controlled access to submitting requests to the host. This should have been made per-device as well, since it causes I/O hangs when multiple block devices are in use. This patch fixes that by replacing the global with an activity flag in the device structure in order to tell whether the queue is currently being run. Finally that variable has a understandable name. However in a mail from Jens Axboe, titled: Re: [uml-devel] [PATCH 06/11] uml ubd driver: ubd_io_lock usage fixup , with Date: Mon, 30 Oct 2006 09:26:48 +0100, he suggested removing this flag altogether, so we may explore this for the future: Add some comments about requirements for ubd_io_lock and expand its use. When an irq signals that the controller (i.e. another thread on the host, which does the actual requests and is the only one blocked on I/O on the host) has done some work, we call again the request function ourselves (do_ubd_request). We now do that with ubd_io_lock held - that's useful to protect against concurrent calls to elv_next_request and so on. Not only useful, required, as I think I complained about a year or more ago :-) XXX: Maybe we shouldn't call at all the request function. Input needed on this. Are we supposed to plug and unplug the queue? That code indirectly does that by setting a flag, called do_ubd, which makes the request function return (it's a residual of 2.4 block layer interface). Sometimes you need to. I'd probably just remove the do_ubd check and always recall the request function when handling completions, it's easier and safe. Anyway, the main speedups to do on the UBD driver are: * implement write barriers (so much less fsync) - this is performance killer n.1 * possibly to use the new 2.6 request layout with scatter/gather I/O, and vectorized I/O on the host * while at vectorizing I/O using async I/O * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes cpu-bound. To make a different but related example, with a SpeedScale laptop, it's interesting to double CPU frequency and observe tuntap speed double too. (with 1GHz I get on TCP numbers like 150 Mbit/s - 100 Mbit/s, depending whether UML trasmits or receives data; with 2GHz double rates). Update: I now get 150Mbit / 200Mbit (Uml receives/Uml sends) at 1GHz, and still the double at 2Ghz. This is a different UML though. * using futexes instead of pipes for synchronization (required for previous one). I forgot one thing: remember ubd=mmap? Something like that could have been done using MAP_PRIVATE, so that write had still to be called explicitly but unchanged data was shared with the host. Once a page gets dirty but is then cleaned, sharing it back is difficult - but even without that good savings could be achievable. That's to explore for the very future though. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + uml-create-archh.patch added to -mm tree
On Thursday 22 March 2007 22:44, [EMAIL PROTECTED] wrote: > The patch titled > uml: mreate arch.h ^ > has been added to the -mm tree. Its filename is > uml-create-archh.patch mreate? I've also seen this in all other patches of this batch (examples below), and both Jeff's original mails and patch filenames are correct. What are your scripts doing here? > The patch titled > uml: mreate as-layout.h ... > The patch titled > uml: memove user_util.h ... > The patch titled > uml: mdd missing __init declarations ... Bye -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [ PATCH 4/7 ] UML - create as-layout.h
On Thursday 22 March 2007 17:06, Jeff Dike wrote: > This patch moves all the the symbols defined in um_arch.c, which are > mostly boundaries between different parts of the UML kernel address > space, to a new header, as-layout.h. There are also a few things here > which aren't really related to address space layout, but which don't > really have a better place to go. Hey, I do like _these_ patches! A nice picture in that header could then be added (in the very future ;-) ), but at least one knows there are so much of them. And user_util.h is no more! ;-) Bye! -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + uml-create-archh.patch added to -mm tree
On Thursday 22 March 2007 22:44, [EMAIL PROTECTED] wrote: The patch titled uml: mreate arch.h ^ has been added to the -mm tree. Its filename is uml-create-archh.patch mreate? I've also seen this in all other patches of this batch (examples below), and both Jeff's original mails and patch filenames are correct. What are your scripts doing here? The patch titled uml: mreate as-layout.h ... The patch titled uml: memove user_util.h ... The patch titled uml: mdd missing __init declarations ... Bye -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [ PATCH 4/7 ] UML - create as-layout.h
On Thursday 22 March 2007 17:06, Jeff Dike wrote: This patch moves all the the symbols defined in um_arch.c, which are mostly boundaries between different parts of the UML kernel address space, to a new header, as-layout.h. There are also a few things here which aren't really related to address space layout, but which don't really have a better place to go. Hey, I do like _these_ patches! A nice picture in that header could then be added (in the very future ;-) ), but at least one knows there are so much of them. And user_util.h is no more! ;-) Bye! -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Tuesday 20 March 2007 07:00, Nick Piggin wrote: > On Mon, Mar 19, 2007 at 09:44:28PM +0100, Blaisorblade wrote: > > On Sunday 18 March 2007 03:50, Nick Piggin wrote: > > > > > Yes, I believe that is the case, however I wonder if that is going > > > > > to be a problem for you to distinguish between write faults for > > > > > clean writable ptes, and write faults for readonly ptes? > > > > I wouldn't be able to distinguish them, but am I going to get write > > > > faults for clean ptes when vma_wants_writenotify() is false (as seems > > > > to be for tmpfs)? I guess not. > > > > For tmpfs pages, clean writable PTEs are mapped as writable so they > > > > won't give any problem, since vma_wants_writenotify() is false for > > > > tmpfs. Correct? > > > Yes, that should be the case. So would this mean that nonlinear > > > protections don't work on regular files? > > They still work in most cases (including for UML), but if the initial > > mmap() specified PROT_WRITE, that is ignored, for pages which are not > > remapped via remap_file_pages(). UML uses PROT_NONE for the initial mmap, > > so that's no problem. > But how are you going to distinguish a write fault on a readonly pte for > dirty page accounting vs a read-only nonlinear protection? Hmm... I was only thinking to PTEs which hadn't been remapped via remap_file_pages, but just faulted in with initial mmap() protection. For the other PTEs, however, I overlooked that the current code ignores vma_wants_writenotify(), i.e. breaks dirty page accounting for them, and I refused to even consider this opportunity, even without knowing the purposes of dirty pages accounting (I found the commits explaining this however). > You can't store any more data in a present pte AFAIK, so you'd have to > have some out of band data. At which point, you may as well just forget > about vma_wants_writenotify vmas, considering that everybody is using > shmem/ramfs. I was going to do that anyway. I'd guess that I should just disallow in remap_file_pages() the VM_MANYPROTS (i.e. MAP_CHGPROT in flags) && vma_wants_writenotify() combination, right? Ok, trivial (shouldn't even have pointed this out). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Tuesday 20 March 2007 07:00, Nick Piggin wrote: On Mon, Mar 19, 2007 at 09:44:28PM +0100, Blaisorblade wrote: On Sunday 18 March 2007 03:50, Nick Piggin wrote: Yes, I believe that is the case, however I wonder if that is going to be a problem for you to distinguish between write faults for clean writable ptes, and write faults for readonly ptes? I wouldn't be able to distinguish them, but am I going to get write faults for clean ptes when vma_wants_writenotify() is false (as seems to be for tmpfs)? I guess not. For tmpfs pages, clean writable PTEs are mapped as writable so they won't give any problem, since vma_wants_writenotify() is false for tmpfs. Correct? Yes, that should be the case. So would this mean that nonlinear protections don't work on regular files? They still work in most cases (including for UML), but if the initial mmap() specified PROT_WRITE, that is ignored, for pages which are not remapped via remap_file_pages(). UML uses PROT_NONE for the initial mmap, so that's no problem. But how are you going to distinguish a write fault on a readonly pte for dirty page accounting vs a read-only nonlinear protection? Hmm... I was only thinking to PTEs which hadn't been remapped via remap_file_pages, but just faulted in with initial mmap() protection. For the other PTEs, however, I overlooked that the current code ignores vma_wants_writenotify(), i.e. breaks dirty page accounting for them, and I refused to even consider this opportunity, even without knowing the purposes of dirty pages accounting (I found the commits explaining this however). You can't store any more data in a present pte AFAIK, so you'd have to have some out of band data. At which point, you may as well just forget about vma_wants_writenotify vmas, considering that everybody is using shmem/ramfs. I was going to do that anyway. I'd guess that I should just disallow in remap_file_pages() the VM_MANYPROTS (i.e. MAP_CHGPROT in flags) vma_wants_writenotify() combination, right? Ok, trivial (shouldn't even have pointed this out). -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Sunday 18 March 2007 03:50, Nick Piggin wrote: > On Sat, Mar 17, 2007 at 01:17:00PM +0100, Blaisorblade wrote: > > On Tuesday 13 March 2007 02:19, Nick Piggin wrote: > > > On Tue, Mar 13, 2007 at 12:01:13AM +0100, Blaisorblade wrote: > > > > On Wednesday 07 March 2007 11:02, Nick Piggin wrote: > > > > > > Yeah, tmpfs/shm segs are what I was thinking about. If UML can > > > > > > live with that as well, then I think it might be a good option. > > > > > > > > > > Oh, hmm if you can truncate these things then you still need to > > > > > force unmap so you still need i_mmap_nonlinear. > > > > > > > > Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, > > > > which is way similar I guess. > > > > > > > > About the restriction to tmpfs, I have just discovered > > > > '[PATCH] mm: tracking shared dirty pages' (commit > > > > d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially > > > > conflicts with remap_file_pages for file-based mmaps (and that's > > > > fully fine, for now). > > > > > > > > Even if UML does not need it, till now if there is a VMA protection > > > > and a page hasn't been remapped with remap_file_pages, the VMA > > > > protection is used (just because it makes sense). > > > > > > > > However, it is only used when the PTE is first created - we can never > > > > change protections on a VMA - so it vma_wants_writenotify() is true > > > > (on all file-based and on no shmfs based mapping, right?), and we > > > > write-protect the VMA, it will always be write-protected. > > > > > > Yes, I believe that is the case, however I wonder if that is going to > > > be a problem for you to distinguish between write faults for clean > > > writable ptes, and write faults for readonly ptes? > > > > I wouldn't be able to distinguish them, but am I going to get write > > faults for clean ptes when vma_wants_writenotify() is false (as seems to > > be for tmpfs)? I guess not. > > > > For tmpfs pages, clean writable PTEs are mapped as writable so they won't > > give any problem, since vma_wants_writenotify() is false for tmpfs. > > Correct? > > Yes, that should be the case. So would this mean that nonlinear protections > don't work on regular files? They still work in most cases (including for UML), but if the initial mmap() specified PROT_WRITE, that is ignored, for pages which are not remapped via remap_file_pages(). UML uses PROT_NONE for the initial mmap, so that's no problem. > I guess that's OK if Oracle and UML both use > tmpfs/shm? -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Sunday 18 March 2007 03:50, Nick Piggin wrote: On Sat, Mar 17, 2007 at 01:17:00PM +0100, Blaisorblade wrote: On Tuesday 13 March 2007 02:19, Nick Piggin wrote: On Tue, Mar 13, 2007 at 12:01:13AM +0100, Blaisorblade wrote: On Wednesday 07 March 2007 11:02, Nick Piggin wrote: Yeah, tmpfs/shm segs are what I was thinking about. If UML can live with that as well, then I think it might be a good option. Oh, hmm if you can truncate these things then you still need to force unmap so you still need i_mmap_nonlinear. Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, which is way similar I guess. About the restriction to tmpfs, I have just discovered '[PATCH] mm: tracking shared dirty pages' (commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially conflicts with remap_file_pages for file-based mmaps (and that's fully fine, for now). Even if UML does not need it, till now if there is a VMA protection and a page hasn't been remapped with remap_file_pages, the VMA protection is used (just because it makes sense). However, it is only used when the PTE is first created - we can never change protections on a VMA - so it vma_wants_writenotify() is true (on all file-based and on no shmfs based mapping, right?), and we write-protect the VMA, it will always be write-protected. Yes, I believe that is the case, however I wonder if that is going to be a problem for you to distinguish between write faults for clean writable ptes, and write faults for readonly ptes? I wouldn't be able to distinguish them, but am I going to get write faults for clean ptes when vma_wants_writenotify() is false (as seems to be for tmpfs)? I guess not. For tmpfs pages, clean writable PTEs are mapped as writable so they won't give any problem, since vma_wants_writenotify() is false for tmpfs. Correct? Yes, that should be the case. So would this mean that nonlinear protections don't work on regular files? They still work in most cases (including for UML), but if the initial mmap() specified PROT_WRITE, that is ignored, for pages which are not remapped via remap_file_pages(). UML uses PROT_NONE for the initial mmap, so that's no problem. I guess that's OK if Oracle and UML both use tmpfs/shm? -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Tuesday 13 March 2007 02:19, Nick Piggin wrote: > On Tue, Mar 13, 2007 at 12:01:13AM +0100, Blaisorblade wrote: > > On Wednesday 07 March 2007 11:02, Nick Piggin wrote: > > > > Yeah, tmpfs/shm segs are what I was thinking about. If UML can live > > > > with that as well, then I think it might be a good option. > > > > > > Oh, hmm if you can truncate these things then you still need to > > > force unmap so you still need i_mmap_nonlinear. > > > > Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, > > which is way similar I guess. > > > > About the restriction to tmpfs, I have just discovered > > '[PATCH] mm: tracking shared dirty pages' (commit > > d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially > > conflicts with remap_file_pages for file-based mmaps (and that's fully > > fine, for now). > > > > Even if UML does not need it, till now if there is a VMA protection and a > > page hasn't been remapped with remap_file_pages, the VMA protection is > > used (just because it makes sense). > > > > However, it is only used when the PTE is first created - we can never > > change protections on a VMA - so it vma_wants_writenotify() is true (on > > all file-based and on no shmfs based mapping, right?), and we > > write-protect the VMA, it will always be write-protected. > > Yes, I believe that is the case, however I wonder if that is going to be > a problem for you to distinguish between write faults for clean writable > ptes, and write faults for readonly ptes? I wouldn't be able to distinguish them, but am I going to get write faults for clean ptes when vma_wants_writenotify() is false (as seems to be for tmpfs)? I guess not. For tmpfs pages, clean writable PTEs are mapped as writable so they won't give any problem, since vma_wants_writenotify() is false for tmpfs. Correct? > > Also, I'm curious. Since my patches are already changing > > remap_file_pages() code, should they be absolutely merged after yours? > > Is there a big clash? I don't think I did a great deal to fremap.c (mainly > just removing stuff)... Hopefully, we just both modify sys_remap_file_pages(), I'll see soon. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Tuesday 13 March 2007 02:19, Nick Piggin wrote: On Tue, Mar 13, 2007 at 12:01:13AM +0100, Blaisorblade wrote: On Wednesday 07 March 2007 11:02, Nick Piggin wrote: Yeah, tmpfs/shm segs are what I was thinking about. If UML can live with that as well, then I think it might be a good option. Oh, hmm if you can truncate these things then you still need to force unmap so you still need i_mmap_nonlinear. Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, which is way similar I guess. About the restriction to tmpfs, I have just discovered '[PATCH] mm: tracking shared dirty pages' (commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially conflicts with remap_file_pages for file-based mmaps (and that's fully fine, for now). Even if UML does not need it, till now if there is a VMA protection and a page hasn't been remapped with remap_file_pages, the VMA protection is used (just because it makes sense). However, it is only used when the PTE is first created - we can never change protections on a VMA - so it vma_wants_writenotify() is true (on all file-based and on no shmfs based mapping, right?), and we write-protect the VMA, it will always be write-protected. Yes, I believe that is the case, however I wonder if that is going to be a problem for you to distinguish between write faults for clean writable ptes, and write faults for readonly ptes? I wouldn't be able to distinguish them, but am I going to get write faults for clean ptes when vma_wants_writenotify() is false (as seems to be for tmpfs)? I guess not. For tmpfs pages, clean writable PTEs are mapped as writable so they won't give any problem, since vma_wants_writenotify() is false for tmpfs. Correct? Also, I'm curious. Since my patches are already changing remap_file_pages() code, should they be absolutely merged after yours? Is there a big clash? I don't think I did a great deal to fremap.c (mainly just removing stuff)... Hopefully, we just both modify sys_remap_file_pages(), I'll see soon. -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Wednesday 07 March 2007 11:02, Nick Piggin wrote: > On Wed, Mar 07, 2007 at 10:49:47AM +0100, Nick Piggin wrote: > > On Wed, Mar 07, 2007 at 01:44:20AM -0800, Bill Irwin wrote: > > > On Wed, Mar 07, 2007 at 10:28:21AM +0100, Nick Piggin wrote: > > > > Depending on whether anyone wants it, and what features they want, we > > > > could emulate the old syscall, and make a new restricted one which is > > > > much less intrusive. > > > > For example, if we can operate only on MAP_ANONYMOUS memory and > > > > specify that nonlinear mappings effectively mlock the pages, then we > > > > can get rid of all the objrmap and unmap_mapping_range handling, > > > > forget about the writeout and msync problems... > > > > > > Anonymous-only would make it a doorstop for Oracle, since its entire > > > motive for using it is to window into objects larger than user virtual > > > > Uh, duh yes I don't mean MAP_ANONYMOUS, I was just thinking of the shmem > > inode that sits behind MAP_ANONYMOUS|MAP_SHARED. Of course if you don't > > have a file descriptor to get a pgoff, then remap_file_pages is a > > doorstop for everyone ;) > > > > > address spaces (this likely also applies to UML, though they should > > > really chime in to confirm). Restrictions to tmpfs and/or ramfs would > > > likely be liveable, though I suspect some things might want to do it to > > > shm segments (I'll ask about that one). There's definitely no need for > > > a persistent backing store for the object to be remapped in Oracle's > > > case, in any event. It's largely the in-core destination and source of > > > IO, not something saved on-disk itself. > > > > Yeah, tmpfs/shm segs are what I was thinking about. If UML can live with > > that as well, then I think it might be a good option. > > Oh, hmm if you can truncate these things then you still need to > force unmap so you still need i_mmap_nonlinear. Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, which is way similar I guess. About the restriction to tmpfs, I have just discovered '[PATCH] mm: tracking shared dirty pages' (commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially conflicts with remap_file_pages for file-based mmaps (and that's fully fine, for now). Even if UML does not need it, till now if there is a VMA protection and a page hasn't been remapped with remap_file_pages, the VMA protection is used (just because it makes sense). However, it is only used when the PTE is first created - we can never change protections on a VMA - so it vma_wants_writenotify() is true (on all file-based and on no shmfs based mapping, right?), and we write-protect the VMA, it will always be write-protected. That's no problem for UML, but for any other user (I guess I'll have to prevent callers from trying such stuff - I started from a pretty generic patch). > But come to think of it, I still don't think nonlinear mappings are > too bad as they are ;) Btw, I really like removing ->populate and merging the common code together. filemap_populate and shmem_populate are so obnoxiously different that I already wanted to do that (after merging remap_file_pages() core). Also, I'm curious. Since my patches are already changing remap_file_pages() code, should they be absolutely merged after yours? -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Wednesday 07 March 2007 11:02, Nick Piggin wrote: On Wed, Mar 07, 2007 at 10:49:47AM +0100, Nick Piggin wrote: On Wed, Mar 07, 2007 at 01:44:20AM -0800, Bill Irwin wrote: On Wed, Mar 07, 2007 at 10:28:21AM +0100, Nick Piggin wrote: Depending on whether anyone wants it, and what features they want, we could emulate the old syscall, and make a new restricted one which is much less intrusive. For example, if we can operate only on MAP_ANONYMOUS memory and specify that nonlinear mappings effectively mlock the pages, then we can get rid of all the objrmap and unmap_mapping_range handling, forget about the writeout and msync problems... Anonymous-only would make it a doorstop for Oracle, since its entire motive for using it is to window into objects larger than user virtual Uh, duh yes I don't mean MAP_ANONYMOUS, I was just thinking of the shmem inode that sits behind MAP_ANONYMOUS|MAP_SHARED. Of course if you don't have a file descriptor to get a pgoff, then remap_file_pages is a doorstop for everyone ;) address spaces (this likely also applies to UML, though they should really chime in to confirm). Restrictions to tmpfs and/or ramfs would likely be liveable, though I suspect some things might want to do it to shm segments (I'll ask about that one). There's definitely no need for a persistent backing store for the object to be remapped in Oracle's case, in any event. It's largely the in-core destination and source of IO, not something saved on-disk itself. Yeah, tmpfs/shm segs are what I was thinking about. If UML can live with that as well, then I think it might be a good option. Oh, hmm if you can truncate these things then you still need to force unmap so you still need i_mmap_nonlinear. Well, we don't need truncate(), but MADV_REMOVE for memory hotunplug, which is way similar I guess. About the restriction to tmpfs, I have just discovered '[PATCH] mm: tracking shared dirty pages' (commit d08b3851da41d0ee60851f2c75b118e1f7a5fc89), which already partially conflicts with remap_file_pages for file-based mmaps (and that's fully fine, for now). Even if UML does not need it, till now if there is a VMA protection and a page hasn't been remapped with remap_file_pages, the VMA protection is used (just because it makes sense). However, it is only used when the PTE is first created - we can never change protections on a VMA - so it vma_wants_writenotify() is true (on all file-based and on no shmfs based mapping, right?), and we write-protect the VMA, it will always be write-protected. That's no problem for UML, but for any other user (I guess I'll have to prevent callers from trying such stuff - I started from a pretty generic patch). But come to think of it, I still don't think nonlinear mappings are too bad as they are ;) Btw, I really like removing -populate and merging the common code together. filemap_populate and shmem_populate are so obnoxiously different that I already wanted to do that (after merging remap_file_pages() core). Also, I'm curious. Since my patches are already changing remap_file_pages() code, should they be absolutely merged after yours? -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Lockdep report against pktcdvd
When booting my laptop with a 2.6.20.1 laptop with lockdep enabled to test my
code, I got a lockdep warning on pktcdvd on setup. It seems that do_open on a
pktcdvd device causes another do_open on the underlying device, and that
mutex_lock_nested is called with the same subclass (the for_part argument to
do_open). So this may be a false positive, after all, but I'll let you
decide.
I've installed and configured Ubuntu udftools so that pktcdvd0 is linked
to /dev/cdrw, i.e. /dev/sr0, on my system.
This is an extract from my /proc/config.gz - it shows that both LOCKDEP and
FRAME_POINTER are enabled, so the stack trace below out to be correct.
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_STACKOVERFLOW=y
~
[ 56.517353] pktcdvd: writer pktcdvd0 mapped to sr0
[ 56.525469]
[ 56.525471] =
[ 56.525476] [ INFO: possible recursive locking detected ]
[ 56.525479] 2.6.20.1-rfp+skas-v9-pre9+skas-dbg #3
[ 56.525498] -
[ 56.525501] vol_id/4536 is trying to acquire lock:
[ 56.525503] (>bd_mutex){--..}, at: []
do_open+0x7b/0x2c4
[ 56.525515]
[ 56.525521] but task is already holding lock:
[ 56.525536] (>bd_mutex){--..}, at: []
do_open+0x7b/0x2c4
[ 56.525560]
[ 56.525561] other info that might help us debug this:
[ 56.525579] 2 locks held by vol_id/4536:
[ 56.525593] #0: (>bd_mutex){--..}, at: []
do_open+0x7b/0x2c4
[ 56.525610] #1: (_mutex#2){--..}, at: []
mutex_lock+0x22/0x26
[ 56.525634]
[ 56.525634] stack backtrace:
[ 56.525646]
[ 56.525652] Call Trace:
[ 56.525666] [] __lock_acquire+0x137/0xa62
[ 56.525687] [] __mutex_unlock_slowpath+0x129/0x14f
[ 56.525712] [] lock_acquire+0x4d/0x69
[ 56.525732] [] do_open+0x7b/0x2c4
[ 56.525750] [] mutex_lock_nested+0x106/0x2cd
[ 56.525774] [] do_open+0x7b/0x2c4
[ 56.525795] [] __blkdev_get+0x7b/0x8d
[ 56.525830] [] blkdev_get+0xb/0xd
[ 56.525853] [] :pktcdvd:pkt_open+0xb5/0xd52
[ 56.525876] [] __d_lookup+0x116/0x142
[ 56.525897] [] debug_check_no_locks_freed+0x12b/0x13a
[ 56.525922] [] trace_hardirqs_on+0x11a/0x13e
[ 56.525944] [] lockdep_init_map+0xa6/0x326
[ 56.525968] [] __mutex_lock_slowpath+0x281/0x2b4
[ 56.525990] [] mark_held_locks+0x53/0x71
[ 56.526010] [] __mutex_lock_slowpath+0x281/0x2b4
[ 56.526034] [] __mutex_unlock_slowpath+0x129/0x14f
[ 56.526054] [] mutex_lock_nested+0x298/0x2cd
[ 56.526075] [] mark_held_locks+0x53/0x71
[ 56.526095] [] mutex_lock_nested+0x298/0x2cd
[ 56.526117] [] debug_mutex_free_waiter+0x58/0x5c
[ 56.526141] [] mutex_lock_nested+0x2be/0x2cd
[ 56.526165] [] do_open+0xae/0x2c4
[ 56.526184] [] _spin_unlock+0x2d/0x4b
[ 56.526205] [] blkdev_open+0x0/0x6b
[ 56.526225] [] blkdev_open+0x34/0x6b
[ 56.526247] [] __dentry_open+0x128/0x201
[ 56.526270] [] nameidata_to_filp+0x2a/0x3c
[ 56.526291] [] do_filp_open+0x3d/0x4f
[ 56.526315] [] _spin_unlock+0x2d/0x4b
[ 56.526335] [] get_unused_fd+0xfa/0x10b
[ 56.526356] [] do_sys_open+0x4d/0xd5
[ 56.526377] [] sys_open+0x1b/0x1d
[ 56.526396] [] system_call+0x7e/0x83
[ 56.526417]
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Lockdep report against pktcdvd
When booting my laptop with a 2.6.20.1 laptop with lockdep enabled to test my
code, I got a lockdep warning on pktcdvd on setup. It seems that do_open on a
pktcdvd device causes another do_open on the underlying device, and that
mutex_lock_nested is called with the same subclass (the for_part argument to
do_open). So this may be a false positive, after all, but I'll let you
decide.
I've installed and configured Ubuntu udftools so that pktcdvd0 is linked
to /dev/cdrw, i.e. /dev/sr0, on my system.
This is an extract from my /proc/config.gz - it shows that both LOCKDEP and
FRAME_POINTER are enabled, so the stack trace below out to be correct.
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_STACKOVERFLOW=y
~
[ 56.517353] pktcdvd: writer pktcdvd0 mapped to sr0
[ 56.525469]
[ 56.525471] =
[ 56.525476] [ INFO: possible recursive locking detected ]
[ 56.525479] 2.6.20.1-rfp+skas-v9-pre9+skas-dbg #3
[ 56.525498] -
[ 56.525501] vol_id/4536 is trying to acquire lock:
[ 56.525503] (bdev-bd_mutex){--..}, at: [810a2869]
do_open+0x7b/0x2c4
[ 56.525515]
[ 56.525521] but task is already holding lock:
[ 56.525536] (bdev-bd_mutex){--..}, at: [810a2869]
do_open+0x7b/0x2c4
[ 56.525560]
[ 56.525561] other info that might help us debug this:
[ 56.525579] 2 locks held by vol_id/4536:
[ 56.525593] #0: (bdev-bd_mutex){--..}, at: [810a2869]
do_open+0x7b/0x2c4
[ 56.525610] #1: (ctl_mutex#2){--..}, at: [8120d470]
mutex_lock+0x22/0x26
[ 56.525634]
[ 56.525634] stack backtrace:
[ 56.525646]
[ 56.525652] Call Trace:
[ 56.525666] [8104aa1e] __lock_acquire+0x137/0xa62
[ 56.525687] [8120ce13] __mutex_unlock_slowpath+0x129/0x14f
[ 56.525712] [8104b61c] lock_acquire+0x4d/0x69
[ 56.525732] [810a2869] do_open+0x7b/0x2c4
[ 56.525750] [8120d57a] mutex_lock_nested+0x106/0x2cd
[ 56.525774] [810a2869] do_open+0x7b/0x2c4
[ 56.525795] [810a2b98] __blkdev_get+0x7b/0x8d
[ 56.525830] [810a2bb5] blkdev_get+0xb/0xd
[ 56.525853] [8823bbf5] :pktcdvd:pkt_open+0xb5/0xd52
[ 56.525876] [8108f854] __d_lookup+0x116/0x142
[ 56.525897] [8104a8d8] debug_check_no_locks_freed+0x12b/0x13a
[ 56.525922] [8104a789] trace_hardirqs_on+0x11a/0x13e
[ 56.525944] [81049eef] lockdep_init_map+0xa6/0x326
[ 56.525968] [8120d41b] __mutex_lock_slowpath+0x281/0x2b4
[ 56.525990] [8104a5b7] mark_held_locks+0x53/0x71
[ 56.526010] [8120d41b] __mutex_lock_slowpath+0x281/0x2b4
[ 56.526034] [8120ce13] __mutex_unlock_slowpath+0x129/0x14f
[ 56.526054] [8120d70c] mutex_lock_nested+0x298/0x2cd
[ 56.526075] [8104a5b7] mark_held_locks+0x53/0x71
[ 56.526095] [8120d70c] mutex_lock_nested+0x298/0x2cd
[ 56.526117] [8104830f] debug_mutex_free_waiter+0x58/0x5c
[ 56.526141] [8120d732] mutex_lock_nested+0x2be/0x2cd
[ 56.526165] [810a289c] do_open+0xae/0x2c4
[ 56.526184] [8120eec6] _spin_unlock+0x2d/0x4b
[ 56.526205] [810a2ab2] blkdev_open+0x0/0x6b
[ 56.526225] [810a2ae6] blkdev_open+0x34/0x6b
[ 56.526247] [8107d664] __dentry_open+0x128/0x201
[ 56.526270] [8107d7ce] nameidata_to_filp+0x2a/0x3c
[ 56.526291] [8107d81d] do_filp_open+0x3d/0x4f
[ 56.526315] [8120eec6] _spin_unlock+0x2d/0x4b
[ 56.526335] [8107d1cf] get_unused_fd+0xfa/0x10b
[ 56.526356] [8107d87c] do_sys_open+0x4d/0xd5
[ 56.526377] [8107d92d] sys_open+0x1b/0x1d
[ 56.526396] [81009f6e] system_call+0x7e/0x83
[ 56.526417]
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Wednesday 07 March 2007 10:44, Bill Irwin wrote: > On Wed, Mar 07, 2007 at 10:28:21AM +0100, Nick Piggin wrote: > > Depending on whether anyone wants it, and what features they want, we > > could emulate the old syscall, and make a new restricted one which is > > much less intrusive. > > For example, if we can operate only on MAP_ANONYMOUS memory and specify > > that nonlinear mappings effectively mlock the pages, then we can get > > rid of all the objrmap and unmap_mapping_range handling, forget about > > the writeout and msync problems... > > Anonymous-only would make it a doorstop for Oracle, since its entire > motive for using it is to window into objects larger than user virtual > address spaces (this likely also applies to UML, though they should > really chime in to confirm). We need it for shared file mappings (for tmpfs only). Our scenario is: RAM is implemented through a shared mapped file, kept on tmpfs (except by dumb users); various processes share an fd for this file (it's opened and immediately deleted). We maintain page tables in x86 style, and TLB flush is implemented through mmap()/munmap()/mprotect(). Having a VMA per each 4K is not the intended VMA usage: for instance, the default /proc/sys/vm/max_map_count (64K) is saturated by a UML process with 64K * 4K = 256M of resident memory. > Restrictions to tmpfs and/or ramfs would > likely be liveable, though I suspect some things might want to do it to > shm segments (I'll ask about that one). > There's definitely no need for a > persistent backing store for the object to be remapped in Oracle's case, > in any event. It's largely the in-core destination and source of IO, not > something saved on-disk itself. > > > -- wli -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 027/101] Kconfig: FAULT_INJECTION can be selected only if LOCKDEP is enabled.
On Wednesday 07 March 2007 18:11, Greg KH wrote: > From: "Paolo 'Blaisorblade' Giarrusso" <[EMAIL PROTECTED]> > > There is no prompt for STACKTRACE, so it is enabled only when 'select'ed. > FAULT_INJECTION depends on it, while LOCKDEP selects it. So FAULT_INJECTION > becomes visible in Kconfig only when LOCKDEP is enabled. Please replace with the attached patch, sorry for being late (I thought it had been dropped). Otherwise a regression would be caused for archs like ia64 on allyesconfig; the change is needed, as discussed with Roman Zippel. > Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- > lib/Kconfig.debug |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-2.6.20.1.orig/lib/Kconfig.debug > +++ linux-2.6.20.1/lib/Kconfig.debug > @@ -400,7 +400,7 @@ config LKDTM > config FAULT_INJECTION > bool "Fault-injection framework" > depends on DEBUG_KERNEL > - depends on STACKTRACE > + select STACKTRACE > select FRAME_POINTER > help > Provide fault-injection framework. > > -- -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade [PATCH] Kconfig: FAULT_INJECTION can be selected only if LOCKDEP is enabled. There is no prompt for STACKTRACE, so it is enabled only when 'select'ed. FAULT_INJECTION depends on it, while LOCKDEP selects it. So FAULT_INJECTION becomes visible in Kconfig only when LOCKDEP is enabled. Update: fixed for architectures not supporting STACKTRACE_SUPPORT. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> Index: linux-2.6.git/lib/Kconfig.debug === --- linux-2.6.git.orig/lib/Kconfig.debug +++ linux-2.6.git/lib/Kconfig.debug @@ -399,8 +399,8 @@ config LKDTM config FAULT_INJECTION bool "Fault-injection framework" - depends on DEBUG_KERNEL - depends on STACKTRACE + depends on DEBUG_KERNEL && STACKTRACE_SUPPORT + select STACKTRACE select FRAME_POINTER help Provide fault-injection framework.
Re: [patch 027/101] Kconfig: FAULT_INJECTION can be selected only if LOCKDEP is enabled.
On Wednesday 07 March 2007 18:11, Greg KH wrote: From: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] There is no prompt for STACKTRACE, so it is enabled only when 'select'ed. FAULT_INJECTION depends on it, while LOCKDEP selects it. So FAULT_INJECTION becomes visible in Kconfig only when LOCKDEP is enabled. Please replace with the attached patch, sorry for being late (I thought it had been dropped). Otherwise a regression would be caused for archs like ia64 on allyesconfig; the change is needed, as discussed with Roman Zippel. Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- lib/Kconfig.debug |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.20.1.orig/lib/Kconfig.debug +++ linux-2.6.20.1/lib/Kconfig.debug @@ -400,7 +400,7 @@ config LKDTM config FAULT_INJECTION bool Fault-injection framework depends on DEBUG_KERNEL - depends on STACKTRACE + select STACKTRACE select FRAME_POINTER help Provide fault-injection framework. -- -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade [PATCH] Kconfig: FAULT_INJECTION can be selected only if LOCKDEP is enabled. There is no prompt for STACKTRACE, so it is enabled only when 'select'ed. FAULT_INJECTION depends on it, while LOCKDEP selects it. So FAULT_INJECTION becomes visible in Kconfig only when LOCKDEP is enabled. Update: fixed for architectures not supporting STACKTRACE_SUPPORT. Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED] Index: linux-2.6.git/lib/Kconfig.debug === --- linux-2.6.git.orig/lib/Kconfig.debug +++ linux-2.6.git/lib/Kconfig.debug @@ -399,8 +399,8 @@ config LKDTM config FAULT_INJECTION bool Fault-injection framework - depends on DEBUG_KERNEL - depends on STACKTRACE + depends on DEBUG_KERNEL STACKTRACE_SUPPORT + select STACKTRACE select FRAME_POINTER help Provide fault-injection framework.
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
On Wednesday 07 March 2007 10:44, Bill Irwin wrote: On Wed, Mar 07, 2007 at 10:28:21AM +0100, Nick Piggin wrote: Depending on whether anyone wants it, and what features they want, we could emulate the old syscall, and make a new restricted one which is much less intrusive. For example, if we can operate only on MAP_ANONYMOUS memory and specify that nonlinear mappings effectively mlock the pages, then we can get rid of all the objrmap and unmap_mapping_range handling, forget about the writeout and msync problems... Anonymous-only would make it a doorstop for Oracle, since its entire motive for using it is to window into objects larger than user virtual address spaces (this likely also applies to UML, though they should really chime in to confirm). We need it for shared file mappings (for tmpfs only). Our scenario is: RAM is implemented through a shared mapped file, kept on tmpfs (except by dumb users); various processes share an fd for this file (it's opened and immediately deleted). We maintain page tables in x86 style, and TLB flush is implemented through mmap()/munmap()/mprotect(). Having a VMA per each 4K is not the intended VMA usage: for instance, the default /proc/sys/vm/max_map_count (64K) is saturated by a UML process with 64K * 4K = 256M of resident memory. Restrictions to tmpfs and/or ramfs would likely be liveable, though I suspect some things might want to do it to shm segments (I'll ask about that one). There's definitely no need for a persistent backing store for the object to be remapped in Oracle's case, in any event. It's largely the in-core destination and source of IO, not something saved on-disk itself. -- wli -- Inform me of my mistakes, so I can add them to my list! Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 4/5] UML - driver formatting fixes
On Tuesday 06 March 2007 19:32, Jeff Dike wrote:
> Fix a bunch of formatting violations in the drivers:
> return(n) -> return n
> whitespace fixes
> emacs formatting comment removal
> breaking if(foo) return(n) into two lines
>
> There are also a couple of errno use bugs:
> using errno in a printk when the failure put errno into a local variable
> saving errno after a printk, which can change it
>
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> Index: test/arch/um/drivers/chan_user.c
> ===
> --- test.orig/arch/um/drivers/chan_user.c 2007-03-06 12:09:47.0
> -0500 +++ test/arch/um/drivers/chan_user.c2007-03-06 12:10:12.0
> -0500 @@ -158,7 +158,7 @@ static int winch_tramp(int fd, struct tt
>*/
> err = run_helper_thread(winch_thread, , CLONE_FILES, , 0);
> if(err < 0){
> - printk("fork of winch_thread failed - errno = %d\n", errno);
> + printk("fork of winch_thread failed - errno = %d\n", err);
> goto out_close;
> }
The second line should better say -err instead of err.
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 4/5] UML - driver formatting fixes
On Tuesday 06 March 2007 19:32, Jeff Dike wrote:
Fix a bunch of formatting violations in the drivers:
return(n) - return n
whitespace fixes
emacs formatting comment removal
breaking if(foo) return(n) into two lines
There are also a couple of errno use bugs:
using errno in a printk when the failure put errno into a local variable
saving errno after a printk, which can change it
Signed-off-by: Jeff Dike [EMAIL PROTECTED]
Index: test/arch/um/drivers/chan_user.c
===
--- test.orig/arch/um/drivers/chan_user.c 2007-03-06 12:09:47.0
-0500 +++ test/arch/um/drivers/chan_user.c2007-03-06 12:10:12.0
-0500 @@ -158,7 +158,7 @@ static int winch_tramp(int fd, struct tt
*/
err = run_helper_thread(winch_thread, data, CLONE_FILES, stack, 0);
if(err 0){
- printk(fork of winch_thread failed - errno = %d\n, errno);
+ printk(fork of winch_thread failed - errno = %d\n, err);
goto out_close;
}
The second line should better say -err instead of err.
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] uml: make sigio_lock() irq-safe
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
sigio_lock is taken both from process context and from interrupt context. So we
*must* use irqsave.
Then, remove irq disabling from update_thread(), as it's called with
sigio_lock() held (yes, set_signals(0) is local_irq_save).
In fact, I've seen this causing frequent hangs with spinlock debugging enabled
(I've verified well that the cause was an interrupt causing re-acquiring of
this lock); however, now it's causing hangs as interrupt disabling causes
some sleep-inside-spinlock checks to trigger - and then printk deadlocks.
I've tested this for a long time and it is stable.
I've also verified that nothing can sleep within this lock; to this purpose,
I've had to verify everything inside um_request_irq; since it calls again
write_sigio_workaround(), I've had to make atomic the allocation inside
setup_initial_poll.
HOWEVER, request_irq() can sleep, and in write_sigio_irq() thanks to
IRQF_SAMPLE_RANDOM it _does_ sleep. So a separate patch makes write_sigio_irq()
be called outside of sigio_lock().
Actually, I'm also quite dubious that an interrupt caused by other interrupts is
a reliable entropy source, but that is another thing completely.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/include/sigio.h |4 ++--
arch/um/kernel/sigio.c | 12
arch/um/os-Linux/sigio.c | 36
3 files changed, 30 insertions(+), 22 deletions(-)
diff --git a/arch/um/include/sigio.h b/arch/um/include/sigio.h
index 434f1a9..a58bc1d 100644
--- a/arch/um/include/sigio.h
+++ b/arch/um/include/sigio.h
@@ -8,7 +8,7 @@
extern int write_sigio_irq(int fd);
extern int register_sigio_fd(int fd);
-extern void sigio_lock(void);
-extern void sigio_unlock(void);
+extern unsigned long sigio_lock(void);
+extern void sigio_unlock(unsigned long flags);
#endif
diff --git a/arch/um/kernel/sigio.c b/arch/um/kernel/sigio.c
index 89f9866..cc54db7 100644
--- a/arch/um/kernel/sigio.c
+++ b/arch/um/kernel/sigio.c
@@ -45,12 +45,16 @@ int write_sigio_irq(int fd)
/* These are called from os-Linux/sigio.c to protect its pollfds arrays. */
static DEFINE_SPINLOCK(sigio_spinlock);
-void sigio_lock(void)
+unsigned long sigio_lock(void)
{
- spin_lock(_spinlock);
+ unsigned long flags;
+
+ spin_lock_irqsave(_spinlock, flags);
+
+ return flags;
}
-void sigio_unlock(void)
+void sigio_unlock(unsigned long flags)
{
- spin_unlock(_spinlock);
+ spin_unlock_irqrestore(_spinlock, flags);
}
diff --git a/arch/um/os-Linux/sigio.c b/arch/um/os-Linux/sigio.c
index 3fc43b3..88988fb 100644
--- a/arch/um/os-Linux/sigio.c
+++ b/arch/um/os-Linux/sigio.c
@@ -21,6 +21,10 @@
#include "os.h"
#include "um_malloc.h"
+/* Nothing in this file can sleep. I've verified each and every function. The
+ * only "exception" is write_sigio_thread, which runs in a host thread, so it
+ * has no chance of sleeping. */
+
/* Protected by sigio_lock(), also used by sigio_cleanup, which is an
* exitcall.
*/
@@ -121,11 +125,9 @@ static int need_poll(struct pollfds *polls, int n)
*/
static void update_thread(void)
{
- unsigned long flags;
int n;
char c;
- flags = set_signals(0);
n = os_write_file(sigio_private[0], , sizeof(c));
if(n != sizeof(c)){
printk("update_thread : write failed, err = %d\n", -n);
@@ -138,7 +140,6 @@ static void update_thread(void)
goto fail;
}
- set_signals(flags);
return;
fail:
/* Critical section start */
@@ -150,15 +151,15 @@ static void update_thread(void)
close(write_sigio_fds[0]);
close(write_sigio_fds[1]);
/* Critical section end */
- set_signals(flags);
}
int add_sigio_fd(int fd)
{
struct pollfd *p;
int err = 0, i, n;
+ unsigned long flags;
- sigio_lock();
+ flags = sigio_lock();
for(i = 0; i < all_sigio_fds.used; i++){
if(all_sigio_fds.poll[i].fd == fd)
break;
@@ -184,7 +185,7 @@ int add_sigio_fd(int fd)
next_poll.used = n + 1;
update_thread();
out:
- sigio_unlock();
+ sigio_unlock(flags);
return err;
}
@@ -192,6 +193,7 @@ int ignore_sigio_fd(int fd)
{
struct pollfd *p;
int err = 0, i, n = 0;
+ unsigned long flags;
/* This is called from exitcalls elsewhere in UML - if
* sigio_cleanup has already run, then update_thread will hang
@@ -200,7 +202,7 @@ int ignore_sigio_fd(int fd)
if(write_sigio_pid == -1)
return -EIO;
- sigio_lock();
+ flags = sigio_lock();
for(i = 0; i < current_poll.used; i++){
if(current_poll.poll[i].fd == fd) break;
}
@@ -220,7 +222,7 @@ int ignore_sigio_fd(int fd)
update_thread();
out:
- sigio
[PATCH 2/2] uml: avoid calling request_irq in atomic context
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
To avoid calling request_irq under a spinlock, and to simplify code around, code
a state machine to allow safely dropping and retaking sigio_lock during
initialization. The state variable is protected by a spinlock together with much
other stuff (so there's no reason to use atomic_t). See the long comment for
further details.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/os-Linux/sigio.c | 74 +-
1 files changed, 46 insertions(+), 28 deletions(-)
diff --git a/arch/um/os-Linux/sigio.c b/arch/um/os-Linux/sigio.c
index 88988fb..44a2d1f 100644
--- a/arch/um/os-Linux/sigio.c
+++ b/arch/um/os-Linux/sigio.c
@@ -29,6 +29,24 @@
* exitcall.
*/
static int write_sigio_pid = -1;
+/* State machine:
+ *
+ * write_sigio_workaround transitions from INACTIVE to STARTING; all methods
+ * exit when they detect the STARTING state, so it's effectively a lock without
+ * wait possibility. After initialization completes it goes to ACTIVE.
+ *
+ * Errors in initialization or in use (say the thread does not answer) move us
+ * to the BROKEN terminal state; this is a change (we went to INACTIVE), and it
+ * could be reverted so that we go back to INACTIVE, if this case is handled
+ * correctly without leaks.
+ *
+ * closing the device moves us to the CLOSED terminal state.
+ *
+ * The state must be read or written only with sigio_lock() held, even when we
+ * are in STARTING, to ensure global visibility across CPUs.
+ */
+enum {INACTIVE, STARTING, ACTIVE, BROKEN, CLOSED};
+static int write_sigio_state = INACTIVE;
/* These arrays are initialized before the sigio thread is started, and
* the descriptors closed after it is killed. So, it can't see them change.
@@ -121,7 +139,7 @@ static int need_poll(struct pollfds *polls, int n)
}
/* Must be called with sigio_lock held, because it's needed by the marked
- * critical section.
+ * critical section. The lock could be moved inside, but it is not needed.
*/
static void update_thread(void)
{
@@ -146,6 +164,9 @@ static void update_thread(void)
if(write_sigio_pid != -1)
os_kill_process(write_sigio_pid, 1);
write_sigio_pid = -1;
+ /* Since the deinit is not complete, we cannot move into INACTIVE state.
+* Or can we? */
+ write_sigio_state = BROKEN;
close(sigio_private[0]);
close(sigio_private[1]);
close(write_sigio_fds[0]);
@@ -199,7 +220,7 @@ int ignore_sigio_fd(int fd)
* sigio_cleanup has already run, then update_thread will hang
* or fail because the thread is no longer running.
*/
- if(write_sigio_pid == -1)
+ if(write_sigio_state != ACTIVE)
return -EIO;
flags = sigio_lock();
@@ -246,59 +267,53 @@ static void write_sigio_workaround(void)
unsigned long stack;
struct pollfd *p;
int err;
- int l_write_sigio_fds[2];
- int l_sigio_private[2];
- int l_write_sigio_pid;
unsigned long flags;
/* We call this *tons* of times - and most ones we must just fail. */
flags = sigio_lock();
- l_write_sigio_pid = write_sigio_pid;
- sigio_unlock(flags);
-
- if (l_write_sigio_pid != -1)
+ if (write_sigio_state != INACTIVE) {
+ sigio_unlock(flags);
return;
+ } else {
+ write_sigio_state = STARTING;
+ }
+ sigio_unlock(flags);
- err = os_pipe(l_write_sigio_fds, 1, 1);
+ err = os_pipe(write_sigio_fds, 1, 1);
if(err < 0){
printk("write_sigio_workaround - os_pipe 1 failed, "
"err = %d\n", -err);
return;
}
- err = os_pipe(l_sigio_private, 1, 1);
+ err = os_pipe(sigio_private, 1, 1);
if(err < 0){
printk("write_sigio_workaround - os_pipe 2 failed, "
"err = %d\n", -err);
goto out_close1;
}
- p = setup_initial_poll(l_sigio_private[1]);
+ p = setup_initial_poll(sigio_private[1]);
if(!p)
goto out_close2;
- flags = sigio_lock();
-
- /* Did we race? Don't try to optimize this, please, it's not so likely
-* to happen, and no more than once at the boot. */
- if(write_sigio_pid != -1)
- goto out_free;
+ if (current_poll.poll)
+ kfree(current_poll.poll);
current_poll = ((struct pollfds) { .poll= p,
.used= 1,
.size= 1 });
- if (write_sigio_irq(l_write_sigio_fds[0]))
+ if (write_sigio_irq(write_sigio_fds[0]))
goto out_clear_poll;
- memcpy(write_sigio_fds, l_write_sigio_fds, sizeof(l_write_sigio_fd
Re: [uml-devel] [PATCH 04/11] uml - hostfs: avoid possible escapes from hostfs=.
On Monday 05 March 2007 23:03, Jeff Dike wrote:
> On Mon, Mar 05, 2007 at 09:49:02PM +0100, Paolo 'Blaisorblade' Giarrusso
wrote:
> > From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> >
> > Avoid accepting things like -o .., -o dir/../../dir2, -o dir/../.. .
> > This may be considered useless, but YMMV. I consider that this has a
> > limited security value, exactly like disabling module support (in many
> > case it is useful).
>
> Two comments on this one:
> > + return strstr(path, "/../") != NULL ||
> > + strcmp(path, "..") == 0 ||
> > + strncmp(path, "../", strlen("../")) == 0 ||
> > + str_ends_with(path, "/..");
>
> Minor style point - I'd be happier with more parens:
>
> + return (strstr(path, "/../") != NULL) ||
> + (strcmp(path, "..") == 0) ||
> + (strncmp(path, "../", strlen("../")) == 0) ||
> + str_ends_with(path, "/..");
Hmm. Personally I prefer the earlier style, but I haven't the last word on
this.
> C gets operator precedence wrong in one or two cases, so I just put parens
> any place it might matter.
Indeed. For instance this patch is wrong, I did this once in a patch, and I
saw it another time in current Ubuntu kernels:
- a + b / 4
+ a + b >> 2
This is instead needed:
+ a + (b >> 2)
> Second, there is code in externfs which does the same thing without
> parsing paths which you might consider instead.
I must, indeed - your comment points out the symlink issue, which I didn't
think of, and which makes my patch moot.
> It sees whether the
> requested directory is outside the jail by cd-ing to it and then
> repeatedly cd .. until it either reaches / or the jail root.
>
> A copy is below for your reading pleasure.
I gave a look, and it's nice. Except that maybe "escapes_jail" would be a
clearer name (there's confusion about the subject of "escaping").
Also, what about concurrent UML threads caring about current directory? I know
that without SMP/preemption we can't have this problem, but when I see this I
count a future bug unless this is checked (I think I reason mathematically
about correctness, even if not formally).
And I haven't the time to check this - I think your version could be merged
anyway, but I'm not sure.
> Jeff
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/11] uml - hostfs: make hostfs= option work as a jail, as intended.
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
When a given host directory is specified to be mounted both in hostfs=path1 and
with mount option -o path2, we should give access to path1/path2, but this does
not happen. Fix that in the simpler way.
Also, root_ino can be the empty string, since we use %s/%s as format.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
fs/hostfs/hostfs_kern.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
index 6f10e43..9baf697 100644
--- a/fs/hostfs/hostfs_kern.c
+++ b/fs/hostfs/hostfs_kern.c
@@ -47,7 +47,7 @@ struct dentry_operations hostfs_dentry_ops = {
};
/* Changed in hostfs_args before the kernel starts running */
-static char *root_ino = "/";
+static char *root_ino = "";
static int append = 0;
#define HOSTFS_SUPER_MAGIC 0x00c0ffee
@@ -947,15 +947,17 @@ static int hostfs_fill_sb_common(struct super_block *sb,
void *d, int silent)
sb->s_magic = HOSTFS_SUPER_MAGIC;
sb->s_op = _sbops;
- if((data == NULL) || (*data == '\0'))
- data = root_ino;
+ /* NULL is printed as by sprintf: avoid that. */
+ if (data == NULL)
+ data = "";
err = -ENOMEM;
- name = kmalloc(strlen(data) + 1, GFP_KERNEL);
+ name = kmalloc(strlen(root_ino) + 1
+ + strlen(data) + 1, GFP_KERNEL);
if(name == NULL)
goto out;
- strcpy(name, data);
+ sprintf(name, "%s/%s", root_ino, data);
root_inode = iget(sb, 0);
if(root_inode == NULL)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/11] uml: mark both consoles as CON_ANYTIME
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Since both UML consoles do not use percpu variables, they may be called when the
cpu is still offline, and they may be marked CON_ANYTIME (this is documented in
kernel/printk.c, grep for CON_ANYTIME to find mentions of this).
Works well in testing done with lock debug enabled, should be safe but is
not needed for next release.
This would probably help also stderr_console.c, but this is yet to test.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/drivers/ssl.c |2 +-
arch/um/drivers/stdio_console.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/drivers/ssl.c b/arch/um/drivers/ssl.c
index fc22b9b..4b382a6 100644
--- a/arch/um/drivers/ssl.c
+++ b/arch/um/drivers/ssl.c
@@ -179,7 +179,7 @@ static struct console ssl_cons = {
.write = ssl_console_write,
.device = ssl_console_device,
.setup = ssl_console_setup,
- .flags = CON_PRINTBUFFER,
+ .flags = CON_PRINTBUFFER|CON_ANYTIME,
.index = -1,
};
diff --git a/arch/um/drivers/stdio_console.c b/arch/um/drivers/stdio_console.c
index 7ff0b0f..76d1f1c 100644
--- a/arch/um/drivers/stdio_console.c
+++ b/arch/um/drivers/stdio_console.c
@@ -153,7 +153,7 @@ static struct console stdiocons = {
.write = uml_console_write,
.device = uml_console_device,
.setup = uml_console_setup,
- .flags = CON_PRINTBUFFER,
+ .flags = CON_PRINTBUFFER|CON_ANYTIME,
.index = -1,
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/11] hostfs: rename some vars for clarity
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
* rename name to host_root_path
* rename data to req_root.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
fs/hostfs/hostfs_kern.c | 26 +-
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
index 0bcf7ac..b4e127b 100644
--- a/fs/hostfs/hostfs_kern.c
+++ b/fs/hostfs/hostfs_kern.c
@@ -961,7 +961,7 @@ static int contains_dotdot(const char* path)
static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent)
{
struct inode *root_inode;
- char *name, *data = d;
+ char *host_root_path, *req_root = d;
int err;
sb->s_blocksize = 1024;
@@ -970,20 +970,20 @@ static int hostfs_fill_sb_common(struct super_block *sb,
void *d, int silent)
sb->s_op = _sbops;
/* NULL is printed as by sprintf: avoid that. */
- if (data == NULL)
- data = "";
+ if (req_root == NULL)
+ req_root = "";
err = -EINVAL;
- if (unlikely(contains_dotdot(data)))
+ if (unlikely(contains_dotdot(req_root)))
goto out;
err = -ENOMEM;
- name = kmalloc(strlen(root_ino) + 1
- + strlen(data) + 1, GFP_KERNEL);
- if(name == NULL)
+ host_root_path = kmalloc(strlen(root_ino) + 1
+ + strlen(req_root) + 1, GFP_KERNEL);
+ if(host_root_path == NULL)
goto out;
- sprintf(name, "%s/%s", root_ino, data);
+ sprintf(host_root_path, "%s/%s", root_ino, req_root);
root_inode = iget(sb, 0);
if(root_inode == NULL)
@@ -993,10 +993,10 @@ static int hostfs_fill_sb_common(struct super_block *sb,
void *d, int silent)
if(err)
goto out_put;
- HOSTFS_I(root_inode)->host_filename = name;
- /* Avoid that in the error path, iput(root_inode) frees again name
through
-* hostfs_destroy_inode! */
- name = NULL;
+ HOSTFS_I(root_inode)->host_filename = host_root_path;
+ /* Avoid that in the error path, iput(root_inode) frees again
+* host_root_path through hostfs_destroy_inode! */
+ host_root_path = NULL;
err = -ENOMEM;
sb->s_root = d_alloc_root(root_inode);
@@ -1016,7 +1016,7 @@ static int hostfs_fill_sb_common(struct super_block *sb,
void *d, int silent)
out_put:
iput(root_inode);
out_free:
- kfree(name);
+ kfree(host_root_path);
out:
return(err);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] uml: fix errno usage
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Avoid reusing userspace errno twice - it can be cleared by libc code everywhere
(in particular printk() does clear it in my setup).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/drivers/daemon_user.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/um/drivers/daemon_user.c b/arch/um/drivers/daemon_user.c
index 310af0f..021b82c 100644
--- a/arch/um/drivers/daemon_user.c
+++ b/arch/um/drivers/daemon_user.c
@@ -56,30 +56,31 @@ static int connect_to_switch(struct daemon_data *pri)
pri->control = socket(AF_UNIX, SOCK_STREAM, 0);
if(pri->control < 0){
+ err = -errno;
printk("daemon_open : control socket failed, errno = %d\n",
- errno);
- return(-errno);
+ -err);
+ return err;
}
if(connect(pri->control, (struct sockaddr *) ctl_addr,
sizeof(*ctl_addr)) < 0){
- printk("daemon_open : control connect failed, errno = %d\n",
- errno);
err = -errno;
+ printk("daemon_open : control connect failed, errno = %d\n",
+ -err);
goto out;
}
fd = socket(AF_UNIX, SOCK_DGRAM, 0);
if(fd < 0){
- printk("daemon_open : data socket failed, errno = %d\n",
- errno);
err = -errno;
+ printk("daemon_open : data socket failed, errno = %d\n",
+ -err);
goto out;
}
if(bind(fd, (struct sockaddr *) local_addr, sizeof(*local_addr)) < 0){
- printk("daemon_open : data bind failed, errno = %d\n",
- errno);
err = -errno;
+ printk("daemon_open : data bind failed, errno = %d\n",
+ -err);
goto out_close;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/11] uml: remove dead code about os_usr1_signal() and os_usr1_process()
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
os_usr1_signal() is totally unused, os_usr1_process() is used only by TT mode.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/include/os.h |3 ++-
arch/um/os-Linux/process.c |3 +++
arch/um/os-Linux/signal.c |5 -
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/um/include/os.h b/arch/um/include/os.h
index 8629bd1..5c74da4 100644
--- a/arch/um/include/os.h
+++ b/arch/um/include/os.h
@@ -192,7 +192,9 @@ extern int os_process_parent(int pid);
extern void os_stop_process(int pid);
extern void os_kill_process(int pid, int reap_child);
extern void os_kill_ptraced_process(int pid, int reap_child);
+#ifdef UML_CONFIG_MODE_TT
extern void os_usr1_process(int pid);
+#endif
extern long os_ptrace_ldt(long pid, long addr, long data);
extern int os_getpid(void);
@@ -261,7 +263,6 @@ extern void block_signals(void);
extern void unblock_signals(void);
extern int get_signals(void);
extern int set_signals(int enable);
-extern void os_usr1_signal(int on);
/* trap.c */
extern void os_fill_handlinfo(struct kern_handlers h);
diff --git a/arch/um/os-Linux/process.c b/arch/um/os-Linux/process.c
index c692a19..76bdd67 100644
--- a/arch/um/os-Linux/process.c
+++ b/arch/um/os-Linux/process.c
@@ -21,6 +21,7 @@
#include "longjmp.h"
#include "skas_ptrace.h"
#include "kern_constants.h"
+#include "uml-config.h"
#define ARBITRARY_ADDR -1
#define FAILURE_PID-1
@@ -131,10 +132,12 @@ void os_kill_ptraced_process(int pid, int reap_child)
CATCH_EINTR(waitpid(pid, NULL, 0));
}
+#ifdef UML_CONFIG_MODE_TT
void os_usr1_process(int pid)
{
kill(pid, SIGUSR1);
}
+#endif
/* Don't use the glibc version, which caches the result in TLS. It misses some
* syscalls, and also breaks with clone(), which does not unshare the TLS.
diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
index b897e85..2667686 100644
--- a/arch/um/os-Linux/signal.c
+++ b/arch/um/os-Linux/signal.c
@@ -243,8 +243,3 @@ int set_signals(int enable)
return ret;
}
-
-void os_usr1_signal(int on)
-{
- change_sig(SIGUSR1, on);
-}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/11] Uml simple fixes
Some tested UML fixes - should be applied for 2.6.21. -- Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/11] uml: code convention cleanup of a file
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Fix coding conventions violations is arch/um/os-Linux/helper.c.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/os-Linux/helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/um/os-Linux/helper.c b/arch/um/os-Linux/helper.c
index c7ad630..7954357 100644
--- a/arch/um/os-Linux/helper.c
+++ b/arch/um/os-Linux/helper.c
@@ -38,7 +38,7 @@ static int helper_child(void *arg)
char **argv = data->argv;
int errval;
- if (helper_pause){
+ if (helper_pause) {
signal(SIGHUP, helper_hup);
pause();
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/11] uml - hostfs: avoid possible escapes from hostfs=.
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Avoid accepting things like -o .., -o dir/../../dir2, -o dir/../.. .
This may be considered useless, but YMMV. I consider that this has a limited
security value, exactly like disabling module support (in many case it is
useful).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
fs/hostfs/hostfs_kern.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
index 9baf697..0bcf7ac 100644
--- a/fs/hostfs/hostfs_kern.c
+++ b/fs/hostfs/hostfs_kern.c
@@ -936,6 +936,28 @@ static const struct address_space_operations
hostfs_link_aops = {
.readpage = hostfs_link_readpage,
};
+static inline int str_ends_with(const char * str, const char* suffix)
+{
+ size_t len = strlen(str), suffix_len = strlen(suffix);
+ return strcmp(str + len - suffix_len, suffix) == 0;
+}
+
+static int contains_dotdot(const char* path)
+{
+ /*
+* Prevent escaping from hostfs=folder, even if this is not useful to
+* jail the UML superuser.
+* Since foo..bar is a valid name, we must look for /../ in the string,
+* or for ../ at the beginning, /.. at the end, or check whether '..' is
+* the complete string.
+*/
+
+ return strstr(path, "/../") != NULL ||
+ strcmp(path, "..") == 0 ||
+ strncmp(path, "../", strlen("../")) == 0 ||
+ str_ends_with(path, "/..");
+}
+
static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent)
{
struct inode *root_inode;
@@ -951,6 +973,10 @@ static int hostfs_fill_sb_common(struct super_block *sb,
void *d, int silent)
if (data == NULL)
data = "";
+ err = -EINVAL;
+ if (unlikely(contains_dotdot(data)))
+ goto out;
+
err = -ENOMEM;
name = kmalloc(strlen(root_ino) + 1
+ strlen(data) + 1, GFP_KERNEL);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/11] uml: fix confusion irq early reenabling
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Fix confusion about call context - comments and code are inconsistent and plain
wrong, my fault.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/drivers/line.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index 01d4ab6..f75d7b0 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -370,10 +370,10 @@ static irqreturn_t line_write_interrupt(int irq, void
*data)
struct tty_struct *tty = line->tty;
int err;
- /* Interrupts are enabled here because we registered the interrupt with
+ /* Interrupts are disabled here because we registered the interrupt with
* IRQF_DISABLED (see line_setup_irq).*/
- spin_lock_irq(>lock);
+ spin_lock(>lock);
err = flush_buffer(line);
if (err == 0) {
return IRQ_NONE;
@@ -381,7 +381,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
line->head = line->buffer;
line->tail = line->buffer;
}
- spin_unlock_irq(>lock);
+ spin_unlock(>lock);
if(tty == NULL)
return IRQ_NONE;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/11] uml: fix a memory leak in the multicast driver
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Memory allocated by mcast_user_init must be freed in the matching mcast_remove.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/drivers/mcast_user.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/um/drivers/mcast_user.c b/arch/um/drivers/mcast_user.c
index 8138f5e..b827e82 100644
--- a/arch/um/drivers/mcast_user.c
+++ b/arch/um/drivers/mcast_user.c
@@ -50,6 +50,14 @@ static void mcast_user_init(void *data, void *dev)
pri->dev = dev;
}
+static void mcast_remove(void *data)
+{
+ struct mcast_data *pri = data;
+
+ kfree(pri->mcast_addr);
+ pri->mcast_addr = NULL;
+}
+
static int mcast_open(void *data)
{
struct mcast_data *pri = data;
@@ -157,7 +165,7 @@ const struct net_user_info mcast_user_info = {
.init = mcast_user_init,
.open = mcast_open,
.close = mcast_close,
- .remove = NULL,
+ .remove = mcast_remove,
.set_mtu= mcast_set_mtu,
.add_address= NULL,
.delete_address = NULL,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/11] uml - hostfs: fix double free
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> Fix double free in the error path - when name is assigned into root_inode we do not own it any more and we must not kfree() it - see patch for details. Thanks to William Stearns for the initial report. CC: William Stearns <[EMAIL PROTECTED]> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- fs/hostfs/hostfs_kern.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c index e965eb1..6f10e43 100644 --- a/fs/hostfs/hostfs_kern.c +++ b/fs/hostfs/hostfs_kern.c @@ -966,6 +966,9 @@ static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent) goto out_put; HOSTFS_I(root_inode)->host_filename = name; + /* Avoid that in the error path, iput(root_inode) frees again name through +* hostfs_destroy_inode! */ + name = NULL; err = -ENOMEM; sb->s_root = d_alloc_root(root_inode); @@ -977,7 +980,7 @@ static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent) /* No iput in this case because the dput does that for us */ dput(sb->s_root); sb->s_root = NULL; - goto out_free; + goto out; } return(0); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/11] uml - activate_fd: return ENOMEM only when appropriate
From: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
Avoid returning ENOMEM in case of a duplicate IRQ - ENOMEM was saved into err
earlier.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
---
arch/um/kernel/irq.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index 50a288b..dbf2f5b 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
@@ -142,6 +142,7 @@ int activate_fd(int irq, int fd, int type, void *dev_id)
.events= events,
.current_events= 0 } );
+ err = -EBUSY;
spin_lock_irqsave(_lock, flags);
for (irq_fd = active_fds; irq_fd != NULL; irq_fd = irq_fd->next) {
if ((irq_fd->fd == fd) && (irq_fd->type == type)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/11] uml - activate_fd: return ENOMEM only when appropriate
From: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
Avoid returning ENOMEM in case of a duplicate IRQ - ENOMEM was saved into err
earlier.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
---
arch/um/kernel/irq.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index 50a288b..dbf2f5b 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um/kernel/irq.c
@@ -142,6 +142,7 @@ int activate_fd(int irq, int fd, int type, void *dev_id)
.events= events,
.current_events= 0 } );
+ err = -EBUSY;
spin_lock_irqsave(irq_lock, flags);
for (irq_fd = active_fds; irq_fd != NULL; irq_fd = irq_fd-next) {
if ((irq_fd-fd == fd) (irq_fd-type == type)) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
