2.6.25-rc5-mm1 - Kernel

Tilman Schmidt wrote:
> Daniel Lezcano schrieb:
>
>> I was not able to reproduce it, but I think I didn't configured
>> postfix as I should had. What version do you use ?
>
> It's the one that comes with openSUSE 10.3:
>
> ts@xenon:~> rpm -q postfix
> postfix-2.4.5-20.2
>
>> If I may ask you, can you put your postfix configuration file and a
>> strace -f of your failing command ? on your website, that will help me
>> a lot to investigate.
>
> Sure, no problem. You may find them at
>
> http://gollum.phnxsoft.com/~ts/linux/main.cf
> http://gollum.phnxsoft.com/~ts/linux/strace.log

Thank you very much, I will try to reproduce it with a simple program.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Benjamin Thery schrieb:
> While googling for the error string, I found this link which report
> the same kind of
> error when Postfix is used with grsecurity (in 2006):
>
> http://blog.jensthebrain.de/archives...und-grsecurity
>
> I barely understand German so I'm not sure it is related to your problem.

The userspace failure described there is indeed the same as mine:
Postfix' sendmail command tries to open "/proc/net/if_inet6"
which fails with EACCES.

But I have never installed grsecurity on this machine, and the
problem appeared for me only with kernel 2.6.25-rc5-mm1, not when
running kernel 2.6.25-rc5 on the same machine, so I guess the
cause must be something different.

What's also strange is that I can "cat /proc/net/if_inet6" from
the command line as the same non-root user with no problem at all.
strace of "cat /proc/net/if_inet6" has:

open("/proc/net/if_inet6", O_RDONLY|O_LARGEFILE) = 3

strace of "/usr/sbin/sendmail", however:

open("/proc/net/if_inet6", O_RDONLY) = -1 EACCES (Permission denied)

Both run as

ts@xenon:~> id
uid=1000(ts) gid=100(users) groups=0(root),14(uucp),16(dialout),33(video),100( users),112(bacula)

HTH
T.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH3nO/Q3+did9BuFsRAhOsAJ9G/wD4GDJU+WiER81NXm0+9d8l2ACgigZ5
Nz+H3NZKTfD7Oize4qAnJBc=
=OZyI
-----END PGP SIGNATURE-----

I agree with Linus' decision to revert/disable this feature.
I think it is appropriate to muck with this in -mm, but not in -rc6
Kudos to Christoph, who recommended we revert it back at -rc2.

> > What's the problem with just loading a new DSDT later? Potentially as in
> > *much* later: including when user-space is all up-and-running?

I don't think re-loading the DSDT at run-time would be practical.

First, booting with the OEM DSDT may nullify the benefit
of overriding the OEM DSDT -- the damage may have already been done.

Secondly, unwinding everything that depends on the DSDT is on the
order of kexec or suspend/resume. We're talking about all the stuff
that PNP does at boot time, plus device discovery and driver binding.

The feature on the table here is an initrd DSDT override.
We already have the ability to statically compile a DSDT
override into the kernel image. That capability is sufficient
for kernel developers.

The initrd version of the DSDT override is really for one scenario.
Somebody who has a BIOS that even Windows can't deal with -- so
no amount of "Windows bug compatbility" will help Linux with it.
They must be capable eough to generate or acquire a modified DSDT.
They must be unwilling/unable to re-build their kenrel from scratch
each time they update it. Eg. following debian unstable updates etc.

I think that customer deserves support, particularly because they get
bragging rights that Linux works better on a box build for Windows
than Windows does:-)
However, I don't think there are enough customers like this to
justify a huge effort that would add risk to Linux.

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

> We used to have
> a different way but it was even uglier: append the DSDT after the
> initramfs, and then access it _directly_. This implies teaching
> populate_rootfs() to not panic when seeing DSDTs and loosing the benefit
> of the compression.

DSDT's are generally 4KB to 64KB, so I don't think compression
for a DSDT override is important.

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

> For things like DVD install images, you'd quite possibly want to have a
> few known-workaround DSDT images with the installer, and just say "ok, we
> want to fix up this ACPI crap in order to get working suspend/resume" kind
> of thing.

For a Linux distro to ship DSDT override images, they'd have to
have some licensing & support arrangement with the OEM
who actually owns that BIOS code.

While this wouldn't defy any laws of physics, it doesn't
look compatible with current industry business practices.

OEMs are more likely to simply ship a BIOS update ISO.

-Len

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

On Saturday 15 March 2008, Éric Piel wrote:
> 15/03/08 20:21, Linus Torvalds wrote/a écrit:
> >
> > I've reverted the whole thing. Or rather, since there were various small
> > fixup commits over time, and a simple revert doesn't really work, I ended
> > up just removing the option and the code that was conditional on it - that
> > way, if we really want to fight this out some time (after 2.6.25 is out)
> > or some vendor wants to use a known-broken option anyway, there's a simple
> > and fairly clean commit to revert the revert.
> >
> > It's commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47, see
> >
> > http://git.kernel.org/?p=linux/kerne...cca4913e7fcd47
> >
> > for details if you aren't a git person.

> It's a pity, I had just nearly finished a new approach. Instead of
> relying on populate_rootfs() and the filesystem infrastructure, the new
> approach directly finds the file in the initramfs. With
> unpack_to_rootfs(), it turned out to be rather straightforward. Attached
> is a half-tested version of the patch (it boots and works but I haven't
> compiled without the option yet). Just in case you would like to change
> your mind ;-)

I recommend that you make a new proposal for 2.6.26
that applies on top of Linus' top-of-tree and that we
include lkml in hashing it out rather than just linux-acpi.

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

Tilman,

I've finally managed to reproduce your problem with Postfix on one of
my victims.

Earlier, in the afternoon, I wrote a piece of code that triggered a
similar behaviour,
but I wasn't sure it was exactly the problem you found. So, I've
rebuilt Postfix, added
some traces and, voila, same issue as yours.
(The version of Postfix originally installed on my machine seems to
have IPv6 disabled)

I bisected the problem to the commit "[NET]: Make /proc/net a symlink
on /proc/self/net (v3)"

Here is what happens:

- Recently /proc/net has been moved to /proc/self/net, and
/proc/self/net is a symlink
on this directory.
- Before that everybody could access /proc/net and read /proc/net/if_inet6:
dr-xr-xr-x 6 root root 0 2008-03-05 15:23 /proc/net

- Now, /proc/self/net has a more restrictive access mode and ony the
owner of the
process can enter the directory:
dr-xr--r-- 5 toto toto 0 Mar 19 17:30 net

This is not a problem in most of the cases, but it becomes annoying
when a process
decides to change its UID or GID. It may loose access to its own
/proc/self/net entries.

- What happens in the Postfix case is the 'sendmail' process executes the
'/usr/sbin/postdrop' binary to enqueue the message, but unfortunately
'/usr/bin/postdrop' has the setgid bit set:
-rwxr-sr-x 1 root postdrop 479475 Mar 19 17:14 /usr/sbin/postdrop

The process egid changes and this seems to be problematic to access
/proc/self/net/if_inet6.

I've attached a tiny test program that can be used to reproduce the problem
without Postfix.
- Either execute it as root and give it an unprivileged uid in argument
./test-proc_net_if_inet6 1001

- Or change its ownership and access mode to: -rwxr-sr-x root postdrop
and execute it as a lambda user.
chown rootostdrop test-proc_net_if_inet6; chmod 2755 test-proc_net_if_inet6
./test-proc_net_if_inet6

I've found the cause but not the fix.
(Adding Pavel in cc

Regards,
Benjamin


On Thu, Mar 13, 2008 at 8:48 PM, Tilman Schmidt wrote:
> Am 11.03.2008 09:14 schrieb Andrew Morton:
> > ftp://ftp.kernel.org/pub/linux/kerne....6.25-rc5-mm1/
>
> I'm noticing a strange effect with this:
>
> On my openSUSE 10.3 development machine with SUSEs default MTA
> Postfix installed, I occasionally send a pre-formatted mail by
> feeding it directly into "/usr/sbin/sendmail -t". If I try that
> while running a 2.6.25-rc5-mm1 kernel, I get:
>
> ts@xenon:~/kernel> /usr/sbin/sendmail -t < patch-usb-reduce-syslog-clutter-v3
> postdrop: warning: can't open /proc/net/if_inet6 (Permission denied) - skipping IPv6 configuration
> postdrop: fatal: parameter inet_interfaces: no local interface found for::1
> sendmail: warning: command "/usr/sbin/postdrop -r" exited with status 1
> sendmail: fatal: ts(1000): unable to execute /usr/sbin/postdrop -r: Success
> ts@xenon:~/kernel>
>
> and unsurprisingly, the mail is not sent. If I do the same as root,
> everything works as usual, there is no console output from the
> sendmail command, and the mail goes out as it should. All other
> networking applications appear to be running normally.
>
> On a 2.6.25-rc5 (non-mm) kernel I do not need to run the sendmail
> command as root. It works just as well if I run it as myself.
>
> IPv6 is not in use on that machine. The Ethernet interface has
> just the link local IPv6 address. Possibly relevant information:
>
> ts@xenon:~> /sbin/ifconfig -a
> eth0 Protokoll:Ethernet Hardware Adresse 00:191:038:FF
> inet Adresse:192.168.59.102 Bcast:192.168.59.255 Maske:255.255.255.0
> inet6 Adresse: fe80::219:d1ff:fe03:d8ff/64 Gültigkeitsbereich:Verbindung
> UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:78 errors:0 dropped:0 overruns:0 frame:0
> TX packets:145 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 Sendewarteschlangenlänge:100
> RX bytes:9547 (9.3 Kb) TX bytes:17952 (17.5 Kb)
> Speicher:92c00000-92c20000
>
> lo Protokoll:Lokale Schleife
> inet Adresse:127.0.0.1 Maske:255.0.0.0
> inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 Sendewarteschlangenlänge:0
> RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)
>
> ts@xenon:~/kernel> ls -l /proc/net/if_inet6
> -r--r--r-- 1 root root 0 13. Mär 19:26 /proc/net/if_inet6
> ts@xenon:~> cat /proc/net/if_inet6
> fe800000000000000219d1fffe03d8ff 02 40 20 80 eth0
> 00000000000000000000000000000001 01 80 10 80 lo
> ts@xenon:~> uname -a
> Linux xenon 2.6.25-rc5-mm1-testing #1 SMP PREEMPT Tue Mar 11 14:34:49 CET 2008 i686 i686 i386 GNU/Linux
>
> As you see, I can cat /proc/net/if_inet6 as regular (non-root) user
> just fine, even though Postfix complains it cannot access it.
> The content of /proc/net/if_inet6 is identical if I cat it on
> kernel 2.6.25-rc5 mainline.
>
> CCing a selection of IPv6 networking related maintainer addresses.
> If you need more information or want me to test something, let me
> know.
>
> HTH
> T.
>
> --
> Tilman Schmidt E-Mail: tilman@imap.cc
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
>
>

On Wed, 19 Mar 2008 18:52:41 +0100
"Benjamin Thery" wrote:

> Tilman,
>
> I've finally managed to reproduce your problem with Postfix on one of
> my victims.
>
> Earlier, in the afternoon, I wrote a piece of code that triggered a
> similar behaviour,
> but I wasn't sure it was exactly the problem you found. So, I've
> rebuilt Postfix, added
> some traces and, voila, same issue as yours.
> (The version of Postfix originally installed on my machine seems to
> have IPv6 disabled)
>
> I bisected the problem to the commit "[NET]: Make /proc/net a symlink
> on /proc/self/net (v3)"
>
> Here is what happens:
>
> - Recently /proc/net has been moved to /proc/self/net, and
> /proc/self/net is a symlink
> on this directory.
> - Before that everybody could access /proc/net and read /proc/net/if_inet6:
> dr-xr-xr-x 6 root root 0 2008-03-05 15:23 /proc/net
>
> - Now, /proc/self/net has a more restrictive access mode and ony the
> owner of the
> process can enter the directory:
> dr-xr--r-- 5 toto toto 0 Mar 19 17:30 net
>
> This is not a problem in most of the cases, but it becomes annoying
> when a process
> decides to change its UID or GID. It may loose access to its own
> /proc/self/net entries.
>
> - What happens in the Postfix case is the 'sendmail' process executes the
> '/usr/sbin/postdrop' binary to enqueue the message, but unfortunately
> '/usr/bin/postdrop' has the setgid bit set:
> -rwxr-sr-x 1 root postdrop 479475 Mar 19 17:14 /usr/sbin/postdrop
>
> The process egid changes and this seems to be problematic to access
> /proc/self/net/if_inet6.
>
> I've attached a tiny test program that can be used to reproduce the problem
> without Postfix.
> - Either execute it as root and give it an unprivileged uid in argument
> ./test-proc_net_if_inet6 1001
>
> - Or change its ownership and access mode to: -rwxr-sr-x root postdrop
> and execute it as a lambda user.
> chown rootostdrop test-proc_net_if_inet6; chmod 2755 test-proc_net_if_inet6
> ./test-proc_net_if_inet6
>
> I've found the cause but not the fix.
> (Adding Pavel in cc
>

Thanks for that - most useful.

Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
regression is also in mainline? 2.6.25-rc6?

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

On Wed, Mar 19, 2008 at 10:16 PM, Andrew Morton
wrote:
>
> On Wed, 19 Mar 2008 18:52:41 +0100
> "Benjamin Thery" wrote:
>
> > Tilman,
> >
> > I've finally managed to reproduce your problem with Postfix on one of
> > my victims.
> >
> > Earlier, in the afternoon, I wrote a piece of code that triggered a
> > similar behaviour,
> > but I wasn't sure it was exactly the problem you found. So, I've
> > rebuilt Postfix, added
> > some traces and, voila, same issue as yours.
> > (The version of Postfix originally installed on my machine seems to
> > have IPv6 disabled)
> >
> > I bisected the problem to the commit "[NET]: Make /proc/net a symlink
> > on /proc/self/net (v3)"
> >
> > Here is what happens:
> >
> > - Recently /proc/net has been moved to /proc/self/net, and
> > /proc/self/net is a symlink
> > on this directory.
> > - Before that everybody could access /proc/net and read /proc/net/if_inet6:
> > dr-xr-xr-x 6 root root 0 2008-03-05 15:23 /proc/net
> >
> > - Now, /proc/self/net has a more restrictive access mode and ony the
> > owner of the
> > process can enter the directory:
> > dr-xr--r-- 5 toto toto 0 Mar 19 17:30 net
> >
> > This is not a problem in most of the cases, but it becomes annoying
> > when a process
> > decides to change its UID or GID. It may loose access to its own
> > /proc/self/net entries.
> >
> > - What happens in the Postfix case is the 'sendmail' process executes the
> > '/usr/sbin/postdrop' binary to enqueue the message, but unfortunately
> > '/usr/bin/postdrop' has the setgid bit set:
> > -rwxr-sr-x 1 root postdrop 479475 Mar 19 17:14 /usr/sbin/postdrop
> >
> > The process egid changes and this seems to be problematic to access
> > /proc/self/net/if_inet6.
> >
> > I've attached a tiny test program that can be used to reproduce the problem
> > without Postfix.
> > - Either execute it as root and give it an unprivileged uid in argument
> > ./test-proc_net_if_inet6 1001
> >
> > - Or change its ownership and access mode to: -rwxr-sr-x root postdrop
> > and execute it as a lambda user.
> > chown rootostdrop test-proc_net_if_inet6; chmod 2755 test-proc_net_if_inet6
> > ./test-proc_net_if_inet6
> >
> > I've found the cause but not the fix.
> > (Adding Pavel in cc
> >
>
> Thanks for that - most useful.
>
> Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> regression is also in mainline? 2.6.25-rc6?

Yes, it is in mainline. I reproduced it on 2.6.25-rc5.

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

From: Andrew Morton
Date: Wed, 19 Mar 2008 14:16:08 -0700

> Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> regression is also in mainline? 2.6.25-rc6?

It is in 2.6.25-rc6, correct.

If Pavel or someone else doesn't produce a good fix soon
I'll revert the guilty change as this bug is worse than
the problem that changeset fixes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Am 19.03.2008 22:16 schrieb Andrew Morton:
> On Wed, 19 Mar 2008 18:52:41 +0100
> "Benjamin Thery" wrote:
>
>> I bisected the problem to the commit "[NET]: Make /proc/net a symlink
>> on /proc/self/net (v3)"
[...]
>> I've attached a tiny test program that can be used to reproduce the problem
>> without Postfix.

Thanks. Works great.

> Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> regression is also in mainline? 2.6.25-rc6?

My results:

up to 2.6.25-rc5 -- good
2.6.25-rc5-mm1 -- bad
2.6.25-rc6 -- bad

HTH
T.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3rc1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH4aJuMdB4Whm86/kRAoadAJsHwaecacSWR1blDaxJGkDI0ueeGQCZAfzO
V7ftNLgLj91v8NRfUwHHTp8=
=LaBb
-----END PGP SIGNATURE-----

Am 17.03.2008 13:23 schrieb Peter Zijlstra:
> On Sun, 2008-03-16 at 13:11 -0700, Dave Hansen wrote:
>
>>> ACPI: Core revision 20070126
>>> +INFO: trying to register non-static key.
>>> +the code is fine but needs lockdep annotation.
>>> +turning off the locking correctness validator.
>>> +Pid: 0, comm: swapper Not tainted 2.6.25-rc5-mm1-testing #3
>>> + [] __lock_acquire+0x144/0xb6e
>>> + [] ? native_sched_clock+0xe0/0xff
>>> + [] ? kmem_cache_alloc+0x89/0xc9
>>> + [] ? trace_hardirqs_on+0xe8/0x11d
>>> + [] lock_acquire+0x6a/0x90
>>> + [] ? down_trylock+0xc/0x27
>>> + [] _spin_lock_irqsave+0x42/0x72
>>> + [] ? down_trylock+0xc/0x27
>>> + [] down_trylock+0xc/0x27
>>> + [] acpi_os_wait_semaphore+0x67/0x13d
>>> + [] acpi_ut_acquire_mutex+0x65/0xcf
>>> + [] acpi_ns_root_initialize+0x1a/0x289
>>> + [] acpi_initialize_subsystem+0x47/0x6a
>>> + [] acpi_early_init+0x57/0xf8
>>> + [] start_kernel+0x34d/0x35a
>>> + [] i386_start_kernel+0x8/0xa
>>> + =======================
>>> ACPI: Checking initramfs for custom DSDT
[...]
> Looks like another of the semaphore thingies.. Does this go away once
> you apply the semaphore lockdep fixup from here:
>
> http://lkml.org/lkml/2008/3/12/63

Yes, it does. With that patch on top of Dave's, I see no stack
backtraces in dmesg anymore.

HTH
T.

--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3rc1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH4abKMdB4Whm86/kRApucAJ4iM0kk6tR52+iNAPS7g6dXsLA+1QCePpm1
OfDDZfS22n8WiK8Zh5PBNEk=
=NP1u
-----END PGP SIGNATURE-----

> > The initrd version of the DSDT override is really for one scenario.
> > Somebody who has a BIOS that even Windows can't deal with -- so
> > no amount of "Windows bug compatbility" will help Linux with it.

> No, this is for people getting involved in ACPI.
> Everybody thinks ACPI is that complicated..., but it's not.
> It's amazing how far people can debug ACPI bugs (yes, even people who
> "do not even know" how to compile a kernel) by simply analyzing the ASL
> BIOS code.

Thomas,
The justification above is what convinced me
that we should try to integrate this feature.
Further, although we failed in 2.6.25,
I think we should continue to try to get this capability integrated.

If you think it will be useful for additional purposes, that's great.
As you know, I'm somewhat skeptical, as I've seen huge mistakes such
as a database of modified BIOS images created and used when the users
have absolutely no idea what they're doing. But we don't have to
agree on this to move forward.

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

On Wed, Mar 19, 2008 at 11:49 PM, David Miller wrote:
> From: Andrew Morton
> Date: Wed, 19 Mar 2008 14:16:08 -0700
>
>
> > Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> > regression is also in mainline? 2.6.25-rc6?
>
> It is in 2.6.25-rc6, correct.
>
> If Pavel or someone else doesn't produce a good fix soon
> I'll revert the guilty change as this bug is worse than
> the problem that changeset fixes.

Andre Noll sent a patch to LKML, acked by Pavel:

"Fix permissions of /proc/net"
http://thread.gmane.org/gmane.linux.kernel/655148

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

On Thursday, 20 of March 2008, Benjamin Thery wrote:
> On Wed, Mar 19, 2008 at 11:49 PM, David Miller wrote:
> > From: Andrew Morton
> > Date: Wed, 19 Mar 2008 14:16:08 -0700
> >
> >
> > > Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> > > regression is also in mainline? 2.6.25-rc6?
> >
> > It is in 2.6.25-rc6, correct.
> >
> > If Pavel or someone else doesn't produce a good fix soon
> > I'll revert the guilty change as this bug is worse than
> > the problem that changeset fixes.
>
> Andre Noll sent a patch to LKML, acked by Pavel:
>
> "Fix permissions of /proc/net"
> http://thread.gmane.org/gmane.linux.kernel/655148

Have you tested that patch?

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

Rafael J. Wysocki wrote:
> On Thursday, 20 of March 2008, Benjamin Thery wrote:
>> On Wed, Mar 19, 2008 at 11:49 PM, David Miller wrote:
>>> From: Andrew Morton
>>> Date: Wed, 19 Mar 2008 14:16:08 -0700
>>>
>>>
>>> > Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
>>> > regression is also in mainline? 2.6.25-rc6?
>>>
>>> It is in 2.6.25-rc6, correct.
>>>
>>> If Pavel or someone else doesn't produce a good fix soon
>>> I'll revert the guilty change as this bug is worse than
>>> the problem that changeset fixes.
>> Andre Noll sent a patch to LKML, acked by Pavel:
>>
>> "Fix permissions of /proc/net"
>> http://thread.gmane.org/gmane.linux.kernel/655148
>
> Have you tested that patch?

I did - works OK, that's why I Acked it.

> Rafael
>

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

On Thu, Mar 20, 2008 at 1:52 PM, Pavel Emelyanov wrote:
>
> Rafael J. Wysocki wrote:
> > On Thursday, 20 of March 2008, Benjamin Thery wrote:
> >> On Wed, Mar 19, 2008 at 11:49 PM, David Miller wrote:
> >>> From: Andrew Morton
> >>> Date: Wed, 19 Mar 2008 14:16:08 -0700
> >>>
> >>>
> >>> > Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> >>> > regression is also in mainline? 2.6.25-rc6?
> >>>
> >>> It is in 2.6.25-rc6, correct.
> >>>
> >>> If Pavel or someone else doesn't produce a good fix soon
> >>> I'll revert the guilty change as this bug is worse than
> >>> the problem that changeset fixes.
> >> Andre Noll sent a patch to LKML, acked by Pavel:
> >>
> >> "Fix permissions of /proc/net"
> >> http://thread.gmane.org/gmane.linux.kernel/655148
> >
> > Have you tested that patch?
>
> I did - works OK, that's why I Acked it.

Also tested here. It fixes the regression.


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

On Tue, 2008-03-18 at 16:32 -0400, Len Brown wrote:
> > > The initrd version of the DSDT override is really for one scenario.
> > > Somebody who has a BIOS that even Windows can't deal with -- so
> > > no amount of "Windows bug compatbility" will help Linux with it.
>
> > No, this is for people getting involved in ACPI.
> > Everybody thinks ACPI is that complicated..., but it's not.
> > It's amazing how far people can debug ACPI bugs (yes, even people who
> > "do not even know" how to compile a kernel) by simply analyzing the ASL
> > BIOS code.
>
> Thomas,
> The justification above is what convinced me
> that we should try to integrate this feature.
> Further, although we failed in 2.6.25,
> I think we should continue to try to get this capability integrated.
>
> If you think it will be useful for additional purposes, that's great.
> As you know, I'm somewhat skeptical, as I've seen huge mistakes such
> as a database of modified BIOS images created and used when the users
> have absolutely no idea what they're doing.
But even here we now have the only existing database for some research.
-> very important IMO.
> But we don't have to
> agree on this to move forward.
I think we fully agree.
I don't mind to add a message in big letters: "Only override the DSDT
for debugging, please report any findings" or whatever, we can add this
ten times in a row, still it is an important feature which is worth
pushing (and getting populate_root_fs being able to be executed earlier
is a feature others also like to see AFAIK).

Thomas

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

On Thursday, 20 of March 2008, Benjamin Thery wrote:
> On Thu, Mar 20, 2008 at 1:52 PM, Pavel Emelyanov wrote:
> >
> > Rafael J. Wysocki wrote:
> > > On Thursday, 20 of March 2008, Benjamin Thery wrote:
> > >> On Wed, Mar 19, 2008 at 11:49 PM, David Miller wrote:
> > >>> From: Andrew Morton
> > >>> Date: Wed, 19 Mar 2008 14:16:08 -0700
> > >>>
> > >>>
> > >>> > Although this is advertised as a 2.6.25-rc5-mm1 problem, I assume the
> > >>> > regression is also in mainline? 2.6.25-rc6?
> > >>>
> > >>> It is in 2.6.25-rc6, correct.
> > >>>
> > >>> If Pavel or someone else doesn't produce a good fix soon
> > >>> I'll revert the guilty change as this bug is worse than
> > >>> the problem that changeset fixes.
> > >> Andre Noll sent a patch to LKML, acked by Pavel:
> > >>
> > >> "Fix permissions of /proc/net"
> > >> http://thread.gmane.org/gmane.linux.kernel/655148
> > >
> > > Have you tested that patch?
> >
> > I did - works OK, that's why I Acked it.
>
> Also tested here. It fixes the regression.

OK, thanks.

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

* Badari Pulavarty wrote:

> Yes. I found the following patch to be the culprit.
>
> sched: make sure jiffies is up to date before calling __update_rq_clock
> ()

thanks Badari, i've backed out this patch.

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