Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
tags 474648 +patch
thanks
On Mon, Apr 07, 2008, Sam Hocevar wrote:
Package: linux-image-2.6.24-1-amd64
Version: 2.6.24-5
Severity: important
CONFIG_SECCOMP was disabled for performance reasons, but it has always
been harmless.
Dear maintainers,
any news on this issue? I see that you have uploaded 8 new kernel
packages since my original report, but each time you inadvertently
forgot to fix the bug :-(
I am attaching a patch in order to help you in the task. It only
reactivates CONFIG_SECCOMP for the architectures used by cpushare in
order to reduce the induced bloat which I know you despise.
Yes, I am perfectly aware that the fix adds a massive 274-byte
overhead to most kernels. I agree this is not acceptable. But this
time I thought of everything before I abused your precious time for my
selfish deeds! Attached is an additional patch that crops the boot-time
logo to 72x80 instead of 80x80 in order to spare up to *640 bytes* per
kernel image!! I noticed that penguins were mostly vertical animals,
so the logo has all these extra black pixels on the sides that can be
removed in order to create smaller, more efficient kernels. I believe
this kind of optimisation could benefit all Debian users.
Let me know if I can be of further assistance, for instance by
preparing an NMU for you.
Best regards,
--
Sam.
diff -puriN linux-2.6-2.6.25/debian.old/config/amd64/config linux-2.6-2.6.25/debian/config/amd64/config
--- linux-2.6-2.6.25/debian.old/config/amd64/config 2008-07-23 11:28:10.0 +0200
+++ linux-2.6-2.6.25/debian/config/amd64/config 2008-07-23 11:34:33.0 +0200
@@ -28,7 +28,7 @@ CONFIG_X86_CPUID=m
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_MTRR=y
CONFIG_EFI=y
-# CONFIG_SECCOMP is not set
+CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
diff -puriN linux-2.6-2.6.25/debian.old/config/i386/config linux-2.6-2.6.25/debian/config/i386/config
--- linux-2.6-2.6.25/debian.old/config/i386/config 2008-07-23 11:28:10.0 +0200
+++ linux-2.6-2.6.25/debian/config/i386/config 2008-07-23 11:34:43.0 +0200
@@ -44,7 +44,7 @@ CONFIG_VMSPLIT_3G_OPT=y
CONFIG_MTRR=y
CONFIG_EFI=y
# CONFIG_IRQBALANCE is not set
-# CONFIG_SECCOMP is not set
+CONFIG_SECCOMP=y
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x10
diff -puriN linux-2.6-2.6.25/debian.old/config/powerpc/config linux-2.6-2.6.25/debian/config/powerpc/config
--- linux-2.6-2.6.25/debian.old/config/powerpc/config 2008-07-23 11:28:10.0 +0200
+++ linux-2.6-2.6.25/debian/config/powerpc/config 2008-07-23 11:35:00.0 +0200
@@ -11,7 +11,7 @@ CONFIG_KEXEC=y
CONFIG_PROC_DEVICETREE=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE=console=ttyS0,9600 console=tty0
-# CONFIG_SECCOMP is not set
+CONFIG_SECCOMP=y
CONFIG_PCI=y
# CONFIG_ADVANCED_OPTIONS is not set
diff -puriN linux-2.6-2.6.25-orig/scripts/pnmtologo.c linux-2.6-2.6.25/scripts/pnmtologo.c
--- linux-2.6-2.6.25-orig/scripts/pnmtologo.c 2008-04-17 04:49:44.0 +0200
+++ linux-2.6-2.6.25/scripts/pnmtologo.c 2008-07-23 14:54:43.0 +0200
@@ -246,7 +246,7 @@ static void write_footer(void)
fputs(\n};\n\n, out);
fprintf(out, struct linux_logo %s __initdata = {\n, logoname);
fprintf(out, .type\t= %s,\n, logo_types[logo_type]);
-fprintf(out, .width\t= %d,\n, logo_width);
+fprintf(out, .width\t= %d,\n, logo_width - 8);
fprintf(out, .height\t= %d,\n, logo_height);
if (logo_type == LINUX_LOGO_CLUT224) {
fprintf(out, .clutsize\t= %d,\n, logo_clutsize);
@@ -289,7 +289,7 @@ static void write_logo_mono(void)
/* write logo data */
for (i = 0; i logo_height; i++) {
- for (j = 0; j logo_width;) {
+ for (j = 4; j logo_width - 4;) {
for (val = 0, bit = 0x80; bit j logo_width; j++, bit = 1)
if (logo_data[i][j].red)
val |= bit;
@@ -323,7 +323,7 @@ static void write_logo_vga16(void)
/* write logo data */
for (i = 0; i logo_height; i++)
- for (j = 0; j logo_width; j++) {
+ for (j = 4; j logo_width - 4; j++) {
for (k = 0; k 16; k++)
if (is_equal(logo_data[i][j], clut_vga16[k]))
break;
@@ -365,7 +365,7 @@ static void write_logo_clut224(void)
/* write logo data */
for (i = 0; i logo_height; i++)
- for (j = 0; j logo_width; j++) {
+ for (j = 4; j logo_width - 4; j++) {
for (k = 0; k logo_clutsize; k++)
if (is_equal(logo_data[i][j], logo_clut[k]))
break;
@@ -402,7 +402,7 @@ static void write_logo_gray256(void)
/* write logo data */
for (i = 0; i logo_height; i++)
- for (j = 0; j logo_width; j++)
+ for (j = 4; j logo_width - 4; j++)
write_hex(logo_data[i][j].red);
/* write logo structure and file footer */
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
block 477674 by 474648 thanks On Mon, Apr 07, 2008, maximilian attems wrote: unless something substantial comes up that bug can be close right away. Wow, thanks for listening to the users. if it had users we already would have been notified. By the way, our first research paper using results computed using CPUShare will be presented at the International Conference on Image and Signal Processing 2008 (and published by Springer-Verlag in the ICISP proceedings as LNCS 5099-0038). We could not credit Debian. Cheers, -- Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
On Mon, Apr 07, 2008 at 12:47:56AM +0200, Sam Hocevar wrote: CONFIG_SECCOMP was disabled for performance reasons, but it has always been harmless. Quoting the author: | On x86-64 SECCOMP generates absoutely zero performance hit. | | The original seccomp patch for x86 also generated absolutely zero | performance hit, both pratically and theoretically too. _zero_ CPU | cycles of difference, zero cachelines. (From http://marc.info/?l=linux-kernelm=115235061904105) that's pretty wrong. it had a hit on each context switch. Please re-enable this feature. It is needed for CPUShare (see #417130). no. that is a commercial entity, no need to push that. unless something substantial comes up that bug can be close right away. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
On Mon, Apr 07, 2008 at 07:51:41AM +, maximilian attems wrote: that is a commercial entity, no need to push that. unless something substantial comes up that bug can be close right away. It seems that you're not really forced to use the commercial side. CPUShare may be use freely if you want to give CPU time for some free projects which need it. Is there some real-word benchmark about SECCOMP impact on performances? Cheers, -- Yves-Alexis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
On Mon, Apr 07, 2008, maximilian attems wrote: On Mon, Apr 07, 2008 at 11:21:24AM +0200, Sam Hocevar wrote: Okay, but I'm not asking for CONFIG_SECCOMP_DISABLE_TSC, just CONFIG_SECCOMP, which is completely harmless (unless you can tell me where the harm is). it adds useless bloat. It is not useless, I maintain a package that needs it. the SECCOMP_DISABLE_TSC is crazy, that is adding a couple of instructions to the hottest scheduler path. Again, I am not asking for SECCOMP_DISABLE_TSC. why would we diverge from upstream? what's that nonesense. each distribution is free to choose and adapt it's .config. I am not complaining about diverging from upstream, which is a perfectly natural thing to do. I am complaining about diverging from upstream for your own political agenda that you have no right to enforce using your Debian hat if it violates our social contract. if it had users we already would have been notified. Oh please. It's really depressing to spend so much time creating a proper package, and seeing that the people who have the power to help make it work do not wish to do so for obscure reasons. If you have a personal grudge against seccomp, maybe you can let someone else in the team activate it? Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
On Mon, Apr 07, 2008, maximilian attems wrote: On Mon, Apr 07, 2008 at 12:47:56AM +0200, Sam Hocevar wrote: CONFIG_SECCOMP was disabled for performance reasons, but it has always been harmless. Quoting the author: | On x86-64 SECCOMP generates absoutely zero performance hit. | | The original seccomp patch for x86 also generated absolutely zero | performance hit, both pratically and theoretically too. _zero_ CPU | cycles of difference, zero cachelines. (From http://marc.info/?l=linux-kernelm=115235061904105) that's pretty wrong. it had a hit on each context switch. Okay, but I'm not asking for CONFIG_SECCOMP_DISABLE_TSC, just CONFIG_SECCOMP, which is completely harmless (unless you can tell me where the harm is). Please re-enable this feature. It is needed for CPUShare (see #417130). no. that is a commercial entity, no need to push that. CPUShare is not a commercial entity, it is a piece of software I use and package and is unfortunately non-functional on Debian systems because CONFIG_SECCOMP is disabled. I see no reason for deliberately diverging from the upstream kernel for political reasons that have nothing to do with our social contract (and probably violate 4.). unless something substantial comes up that bug can be close right away. Wow, thanks for listening to the users. Regards, -- Sam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
On Mon, Apr 07, 2008 at 11:21:24AM +0200, Sam Hocevar wrote: Okay, but I'm not asking for CONFIG_SECCOMP_DISABLE_TSC, just CONFIG_SECCOMP, which is completely harmless (unless you can tell me where the harm is). it adds useless bloat. the SECCOMP_DISABLE_TSC is crazy, that is adding a couple of instructions to the hottest scheduler path. Please re-enable this feature. It is needed for CPUShare (see #417130). no. that is a commercial entity, no need to push that. CPUShare is not a commercial entity, it is a piece of software I use and package and is unfortunately non-functional on Debian systems because CONFIG_SECCOMP is disabled. why would we diverge from upstream? what's that nonesense. each distribution is free to choose and adapt it's .config. for political reasons that have nothing to do with our social contract (and probably violate 4.). unless something substantial comes up that bug can be close right away. Wow, thanks for listening to the users. if it had users we already would have been notified. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)
Package: linux-image-2.6.24-1-amd64 Version: 2.6.24-5 Severity: important CONFIG_SECCOMP was disabled for performance reasons, but it has always been harmless. Quoting the author: | On x86-64 SECCOMP generates absoutely zero performance hit. | | The original seccomp patch for x86 also generated absolutely zero | performance hit, both pratically and theoretically too. _zero_ CPU | cycles of difference, zero cachelines. (From http://marc.info/?l=linux-kernelm=115235061904105) Please re-enable this feature. It is needed for CPUShare (see #417130). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24.3 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
