diff -urNp linux-2.6.16/arch/i386/Kconfig linux-2.6.16.new/arch/i386/Kconfig
--- linux-2.6.16/arch/i386/Kconfig 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/arch/i386/Kconfig 2006-04-14 01:35:06.000000000 +0300
@@ -644,6 +644,14 @@ config EFI
anything about EFI). However, even with this option, the resultant
kernel should continue to boot on existing non-EFI platforms.
+config COMMAND_LINE_SIZE
+ int "Maximum kernel command-line size"
+ range 256 4096
+ default 256
+ ---help---
+ This enables adjusting maximum command-line size. If you are unsure
+ specify 256.
+
config IRQBALANCE
bool "Enable kernel irq balancing"
depends on SMP && X86_IO_APIC
diff -urNp linux-2.6.16/arch/x86_64/Kconfig linux-2.6.16.new/arch/x86_64/Kconfig
--- linux-2.6.16/arch/x86_64/Kconfig 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/arch/x86_64/Kconfig 2006-04-14 01:35:30.000000000 +0300
@@ -445,6 +445,14 @@ config PHYSICAL_START
Don't change this unless you know what you are doing.
+config COMMAND_LINE_SIZE
+ int "Maximum kernel command-line size"
+ range 256 4096
+ default 256
+ ---help---
+ This enables adjusting maximum command-line size. If you are unsure
+ specify 256.
+
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
diff -urNp linux-2.6.16/include/asm-i386/param.h linux-2.6.16.new/include/asm-i386/param.h
--- linux-2.6.16/include/asm-i386/param.h 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/include/asm-i386/param.h 2006-04-14 02:00:45.000000000 +0300
@@ -19,6 +19,15 @@
#endif
#define MAXHOSTNAMELEN 64 /* max length of hostname */
+
+/*
+ * This COMMAND_LINE_SIZE definition was left here
+ * for compatability, its correct location is in setup.h.
+ * Boot loaders that use this parameters will continue
+ * to use 256 maximum command-line size.
+ */
+#ifndef CONFIG_COMMAND_LINE_SIZE
#define COMMAND_LINE_SIZE 256
+#endif
#endif
diff -urNp linux-2.6.16/include/asm-i386/setup.h linux-2.6.16.new/include/asm-i386/setup.h
--- linux-2.6.16/include/asm-i386/setup.h 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/include/asm-i386/setup.h 2006-04-14 01:32:16.000000000 +0300
@@ -17,7 +17,7 @@
#define MAX_NONPAE_PFN (1 << 20)
#define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
#define OLD_CL_MAGIC_ADDR 0x90020
#define OLD_CL_MAGIC 0xA33F
diff -urNp linux-2.6.16/include/asm-x86_64/setup.h linux-2.6.16.new/include/asm-x86_64/setup.h
--- linux-2.6.16/include/asm-x86_64/setup.h 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/include/asm-x86_64/setup.h 2006-04-14 01:33:27.000000000 +0300
@@ -1,6 +1,6 @@
#ifndef _x8664_SETUP_H
#define _x8664_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
#endif
Alon Bar-Lev wrote:
>
>> Revert "x86_64/i386: increase command line size" patch
>> It's a bootup dependancy, you can't just increase it
>> randomly, and it breaks booting with LILO.
>> Pointed out by Janos Farkas and Adrian Bunk.
>
Can we get the details, please, instead of a repeat of the same patch,
so we can figure out a proper solution?
-hpa
H. Peter Anvin wrote:
> Alon Bar-Lev wrote:
>>
>>> Revert "x86_64/i386: increase command line size" patch
>>> It's a bootup dependancy, you can't just increase it
>>> randomly, and it breaks booting with LILO.
>>> Pointed out by Janos Farkas and Adrian Bunk.
>>
>
> Can we get the details, please, instead of a repeat of the same patch,
> so we can figure out a proper solution?
>
> -hpa
>
Hello Peter,
I don't know any other way to get the details. I am truly
thank you for your responses. But the people that rejected
this patch gave no detailed reason! I've extended the CC
list this time in a hope that someone will reply.
I also specify the exact history for this issue... In order
to encourage relevant people to reply.
This should be a simple modification and I don't see why we
should fight on the LILO problem (if exists) when we have
the compile time config options alternative.
People who uses LILO may leave the default 256 value. Other
may migrate to a higher one.
I also don't understand why every architecture have a
different command line size... The compile time config
option may solve all this to a unified solution with
different default for every architecture.
I will be glad to learn of a better to push this matter
forward, without adding a LILO specific code into the
kernel, which I don't think is wise... I prefer to continue
patching my and others kernel and not mess up kernel with
LILO specific code.
If you think I should stop this effort, please say so... I
will drop it.
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev wrote:
>
> This should be a simple modification and I don't see why we
> should fight on the LILO problem (if exists) when we have
> the compile time config options alternative.
>
> People who uses LILO may leave the default 256 value. Other
> may migrate to a higher one.
>
This is cargo-cult programming, sorry. Let's find out what the problem
is and fix it right. If that involves fixing LILO and/or dealing with a
LILO bug, we have ways we can do that.
-hpa
It is probably fairly easy to increase the LILO command line to 512
bytes (including terminator). Beyond 512 there are complicating factors:
1. "lilo -R ..." -- the space reserved for the stored command line
is 1 sector.
2. configuration option "fallback" -- again 1 sector is the amount reserved.
There are 2 buffers used for the command line. Since these are
allocated on sector boundaries, 512 should present no serious problems.
--John
At 07:35 AM Friday 5/5/2006, H. Peter Anvin wrote:
>Alon Bar-Lev wrote:
>>This should be a simple modification and I don't see why we
>>should fight on the LILO problem (if exists) when we have
>>the compile time config options alternative.
>>People who uses LILO may leave the default 256 value. Other
>>may migrate to a higher one.
>
>This is cargo-cult programming, sorry. Let's find out what the
>problem is and fix it right. If that involves fixing LILO and/or
>dealing with a LILO bug, we have ways we can do that.
>
> -hpa
PGP KeyID: 6781C9C8 (good until 31-Dec-2008)
Keyserver at ldap://keyserver.pgp.com OR http://pgp.mit.edu
LILO links at http://freshmeat.net/projects/lilo
and Help link at http://lilo.go.dyndns.org
John Coffman wrote:
> It is probably fairly easy to increase the LILO command line to 512
> bytes (including terminator). Beyond 512 there are complicating factors:
>
> 1. "lilo -R ..." -- the space reserved for the stored command line is 1
> sector.
> 2. configuration option "fallback" -- again 1 sector is the amount
> reserved.
>
> There are 2 buffers used for the command line. Since these are
> allocated on sector boundaries, 512 should present no serious problems.
>
The problem isn't that LILO can't handle more than some number of characters; that's a
LILO issue and doesn't affect the kernel.
The problem is that some people have reported that the kernel crashes if booted with LILO
and the size limit is more than 255. They haven't so far commented on how they observed
that, and that's a major problem.
If the issue is that LILO doesn't null-terminate overlong command lines, then that's
pretty easy to deal with:
- If the kernel sees protocol version <= 2.01, limit is 255+null.
- If the kernel sees protocol version >= 2.02, but ID is 0x1X, limit is 255+null.
- Otherwise limit is higher.
When LILO is fixed, it has to bump the ID byte version number.
What ID byte values has LILO used?
-hpa
At 11:17 AM Friday 5/5/2006, you wrote:
>John Coffman wrote:
>The problem isn't that LILO can't handle more than some number of
>characters; that's a LILO issue and doesn't affect the kernel.
>
>The problem is that some people have reported that the kernel
>crashes if booted with LILO and the size limit is more than
>255. They haven't so far commented on how they observed that, and
>that's a major problem.
Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
from 256 to 512 will not work. A .bss area must be moved to avoid
clobbering the kernel header.
>If the issue is that LILO doesn't null-terminate overlong command
>lines, then that's pretty easy to deal with:
>
>- If the kernel sees protocol version <= 2.01, limit is 255+null.
>- If the kernel sees protocol version >= 2.02, but ID is 0x1X, limit
>is 255+null.
>- Otherwise limit is higher.
>
>When LILO is fixed, it has to bump the ID byte version number.
>
>What ID byte values has LILO used?
For the last 8 years LILO has used 0x02 as the loader ID.
If anyone wishes to test a version of LILO that is able to pass a 512
byte command line, then the "22.7.2-beta8" version in the "beta"
directory should be tried. It moves the offending ".bss" area to
avoid the header clobber. However, I have not yet changed the loader ID.
--John
PGP KeyID: 6781C9C8 (good until 31-Dec-2008)
Keyserver at ldap://keyserver.pgp.com OR http://pgp.mit.edu
LILO links at http://freshmeat.net/projects/lilo
and Help link at http://lilo.go.dyndns.org
John Coffman wrote:
>>
>> The problem is that some people have reported that the kernel crashes
>> if booted with LILO and the size limit is more than 255. They haven't
>> so far commented on how they observed that, and that's a major problem.
>
> Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
> from 256 to 512 will not work. A .bss area must be moved to avoid
> clobbering the kernel header.
>
Okay, let me ask this:
If the *kernel* limit is modified, but the LILO limit is not, what will happen? This is
the real crux of the matter.
-hpa
John Coffman wrote:
> Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
> from 256 to 512 will not work. A .bss area must be moved to avoid
> clobbering the kernel header.
Hello John,
The COMMAND_LINE_SIZE should be fixed 256 bytes for boot
protocol < 2.02.
For boot protocol >= 2.02 it can be null terminated 256 and up.
>From LILO code I can see that COMMAND_LINE_SIZE is defined
in lilo.h, so I don't understand how a change in the
COMMAND_LINE_SIZE of the kernel affect LILO.
What we want to achieve is a kernel capable of accepting
command line size greater than 256 bytes... It is OK if LILO
will still pass 256 byte buffer as it already does.
Can you think of a reason why LILO will not work if we do
that? (lilo.h keeps #define COMMAND_LINE_SIZE 256).
Best Regards,
Alon Bar-Lev.
At 02:57 PM Friday 5/5/2006, H. Peter Anvin wrote:
Okay, let me ask this:
>If the *kernel* limit is modified, but the LILO limit is not, what
>will happen? This is the real crux of the matter.
The length of the kernel command line will be limited by the size of
the boot loader buffer. LILO always inserts a NUL terminator.
--John
P.S. The LILO command line buffer has always been 1 sector (512
bytes); however, only the first half is actually used for the command
line. No kernel can do any harm by setting "boot_cmdline[511] = 0;"
for any version of LILO back to version 20 (and probably before).
PGP KeyID: 6781C9C8 (good until 31-Dec-2008)
Keyserver at ldap://keyserver.pgp.com OR http://pgp.mit.edu
LILO links at http://freshmeat.net/projects/lilo
and Help link at http://lilo.go.dyndns.org
John Coffman wrote:
> At 02:57 PM Friday 5/5/2006, H. Peter Anvin wrote:
> Okay, let me ask this:
>
>> If the *kernel* limit is modified, but the LILO limit is not, what
>> will happen? This is the real crux of the matter.
>
> The length of the kernel command line will be limited by the size of the
> boot loader buffer. LILO always inserts a NUL terminator.
>
> --John
>
> P.S. The LILO command line buffer has always been 1 sector (512 bytes);
> however, only the first half is actually used for the command line. No
> kernel can do any harm by setting "boot_cmdline[511] = 0;" for any
> version of LILO back to version 20 (and probably before).
>
Okay... **DOES ANYONE HAVE ANY ACTUAL EVIDENCE TO THE CONTRARY???**, and
if so, **WHAT ARE THE DETAILS**?
All I've heard so far is hearsay. "X said that Y had said..."
-hpa
diff -urNp linux-2.6.17-rc3/include/asm-i386/param.h linux-2.6.17-rc3.new/include/asm-i386/param.h
--- linux-2.6.17-rc3/include/asm-i386/param.h 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.17-rc3.new/include/asm-i386/param.h 2006-05-06 12:38:32.000000000 +0300
@@ -19,6 +19,5 @@
#endif
#define MAXHOSTNAMELEN 64 /* max length of hostname */
-#define COMMAND_LINE_SIZE 256
#endif
diff -urNp linux-2.6.17-rc3/include/asm-i386/setup.h linux-2.6.17-rc3.new/include/asm-i386/setup.h
--- linux-2.6.17-rc3/include/asm-i386/setup.h 2006-05-06 12:35:09.000000000 +0300
+++ linux-2.6.17-rc3.new/include/asm-i386/setup.h 2006-05-06 12:38:44.000000000 +0300
@@ -15,7 +15,7 @@
#define MAX_NONPAE_PFN (1 << 20)
#define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 2048
#define OLD_CL_MAGIC_ADDR 0x90020
#define OLD_CL_MAGIC 0xA33F
diff -urNp linux-2.6.17-rc3/include/asm-ia64/setup.h linux-2.6.17-rc3.new/include/asm-ia64/setup.h
--- linux-2.6.17-rc3/include/asm-ia64/setup.h 2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.17-rc3.new/include/asm-ia64/setup.h 2006-05-06 12:40:32.000000000 +0300
@@ -1,6 +1,6 @@
#ifndef __IA64_SETUP_H
#define __IA64_SETUP_H
-#define COMMAND_LINE_SIZE 512
+#define COMMAND_LINE_SIZE 2048
#endif