Re: 2.6.29-git13: Reported regressions from 2.6.28

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Linus Torvalds]

On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
> 
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
> Subject		: /proc/<pid>/maps offset output broken in 2.6.29
> Submitter	: "Chris Friesen" <cfriesen@nortel.com>
> Date		: 2009-04-01 23:18 (6 days old)
> References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
> Handled-By	: Hugh Dickins <hugh@veritas.com>

I don't think that's a regression, nor really a bug. It looks cosmetic, 
and likely to be fixed, but not really worth worrying about.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13018
> Subject		: 2.6.29 on MacBook 2,1 fails to reboot
> Submitter	: Trenton Adams <trenton.d.adams@gmail.com>
> Date		: 2009-03-30 2:04 (8 days old)
> References	: http://marc.info/?l=linux-kernel&m=123837870307249&w=4
> Handled-By	: "Morten P.D. Stevens" <mstevens@win-professional.com>

This went through bisection, but looking at the email log, I tend to 
suspect that maybe Trenton marked some versions good even though they 
weren't (because they got versions numbers from v2.6.27), and didn't 
realize that that messes up bisection in a big way.

The bug _sounds_ like some deadlock due to lock problems - the shutdown 
path often triggers locks that no other path really cares about. And we 
had some lock problems in the sound subsystem that got fixed post-2.6.28, 
for example. 

And it looks like the problem is somewhere in sound shutdown:

12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>

So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss, 
fix locking typo") might explain it.

		Linus

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Rafael J. Wysocki]

On Monday 06 April 2009, Linus Torvalds wrote:
> 
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
> > 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
> > Subject		: /proc/<pid>/maps offset output broken in 2.6.29
> > Submitter	: "Chris Friesen" <cfriesen@nortel.com>
> > Date		: 2009-04-01 23:18 (6 days old)
> > References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
> > Handled-By	: Hugh Dickins <hugh@veritas.com>
> 
> I don't think that's a regression, nor really a bug. It looks cosmetic, 
> and likely to be fixed, but not really worth worrying about.

OK, I've dropped it from the list.

Thanks,
Rafael

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Mon, Apr 6, 2009 at 3:53 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>
>> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>> Subject               : 2.6.29 on MacBook 2,1 fails to reboot
>> Submitter     : Trenton Adams <trenton.d.adams@gmail.com>
>> Date          : 2009-03-30 2:04 (8 days old)
>> References    : http://marc.info/?l=linux-kernel&m=123837870307249&w=4
>> Handled-By    : "Morten P.D. Stevens" <mstevens@win-professional.com>
>
> This went through bisection, but looking at the email log, I tend to
> suspect that maybe Trenton marked some versions good even though they
> weren't (because they got versions numbers from v2.6.27), and didn't
> realize that that messes up bisection in a big way.

Is it appropriate for me to respond to these things?

I was wondering about that.  Someone had mentioned that I should trust
the bisect, even when it takes me into "other versions", and it was
taking me through 2.6.27, which I thought was just really weird.
Would you like me to try the bisect again with a little more
diligence, or do you think it can be found with the info given?  It
may take a week or so, due to being a bit busy.

Thanks

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Linus Torvalds]

On Mon, 6 Apr 2009, Trenton D. Adams wrote:
> >
> > This went through bisection, but looking at the email log, I tend to
> > suspect that maybe Trenton marked some versions good even though they
> > weren't (because they got versions numbers from v2.6.27), and didn't
> > realize that that messes up bisection in a big way.
> 
> Is it appropriate for me to respond to these things?

Yes. I added you to the cc exactly because it was hard for me to judge 
from the email discussion that is linked to in the regression list whether 
you actually _did_ mark some versions good because of confusion about the 
version numbering.

That would certainly explain why bisection didn't seem to work.

But it's not the _only_ reason bisection doesn't work. Sometimes you can 
be as careful as possible, but if it's a bug that is even _slightly_ flaky 
(timing-dependencies etc), and the bisection marked something good that 
shouldn't have been (or vice versa, but that's unusual), then the 
bisection end result won't be right.

So you may well have done everything right, and I'm not trying to blame 
you. I just was hoping that maybe that confusion would explain why the 
bisection didn't seem to pinpoint anything sane..

> I was wondering about that.  Someone had mentioned that I should trust
> the bisect, even when it takes me into "other versions", and it was
> taking me through 2.6.27, which I thought was just really weird.
> Would you like me to try the bisect again with a little more
> diligence, or do you think it can be found with the info given?  It
> may take a week or so, due to being a bit busy.

It would be good, especially if this bug doesn't end up being solved some 
other way... And slow results are better than no results at all ;)

			Linus

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Mon, Apr 6, 2009 at 10:07 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 6 Apr 2009, Trenton D. Adams wrote:
>> >
>> > This went through bisection, but looking at the email log, I tend to
>> > suspect that maybe Trenton marked some versions good even though they
>> > weren't (because they got versions numbers from v2.6.27), and didn't
>> > realize that that messes up bisection in a big way.
>>
>> Is it appropriate for me to respond to these things?
>
> Yes. I added you to the cc exactly because it was hard for me to judge
> from the email discussion that is linked to in the regression list whether
> you actually _did_ mark some versions good because of confusion about the
> version numbering.

Oh, didn't know you CC'd me.  I have just been searching for my name
to try and keep up to date on threads I participated in, because the
list volume is just too much.

> So you may well have done everything right, and I'm not trying to blame
> you. I just was hoping that maybe that confusion would explain why the
> bisection didn't seem to pinpoint anything sane..

This gave me a bit of a chuckle. ROFL.  I didn't think you were
_blaming_ me.  And even if you were, I'd just say "I'M HUMAN MAN". ;)

It is very well possible that I simply booted the wrong kernel, seeing
I had like 20 to choose from at the time, after doing all those
bisects.  This time, I will make the new kernels the default so that
it is impossible to happen again, assuming that is what happened.  I
will also stop and start alsa 2 or 3 times, in case it is a deadlock
timing issue as you mentioned.

I'm glad to know that I shouldn't be switching kernel versions though.
 I thought that was really crazy.

>
>
> It would be good, especially if this bug doesn't end up being solved some
> other way... And slow results are better than no results at all ;)
>
>                        Linus
>

Okay, I will try again.  Hopefully in a few days I'll have something
for the bug.

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Stefan Richter]

Linus Torvalds wrote:
> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13018
>> Subject		: 2.6.29 on MacBook 2,1 fails to reboot
>> Submitter	: Trenton Adams <trenton.d.adams@gmail.com>
>> Date		: 2009-03-30 2:04 (8 days old)
>> References	: http://marc.info/?l=linux-kernel&m=123837870307249&w=4
>> Handled-By	: "Morten P.D. Stevens" <mstevens@win-professional.com>
> 
> This went through bisection, but looking at the email log, I tend to 
> suspect that maybe Trenton marked some versions good even though they 
> weren't (because they got versions numbers from v2.6.27), and didn't 
> realize that that messes up bisection in a big way.
> 
> The bug _sounds_ like some deadlock due to lock problems - the shutdown 
> path often triggers locks that no other path really cares about. And we 
> had some lock problems in the sound subsystem that got fixed post-2.6.28, 
> for example. 
> 
> And it looks like the problem is somewhere in sound shutdown:
> 
> 12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>
> 
> So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss, 
> fix locking typo") might explain it.

Trenton,
could it be the same as this one?
http://bugzilla.kernel.org/show_bug.cgi?id=12321
"System hangs when unloading alsa modules"
http://bugs.gentoo.org/show_bug.cgi?id=253535
"System hangs when unloading alsa modules on Kernel >2.6.28"
-- 
Stefan Richter
-=====-==--= -=-- --===
http://arcgraph.de/sr/

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 10:16 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Linus Torvalds wrote:
>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>>> Subject              : 2.6.29 on MacBook 2,1 fails to reboot
>>> Submitter    : Trenton Adams <trenton.d.adams@gmail.com>
>>> Date         : 2009-03-30 2:04 (8 days old)
>>> References   : http://marc.info/?l=linux-kernel&m=123837870307249&w=4
>>> Handled-By   : "Morten P.D. Stevens" <mstevens@win-professional.com>
>>
>
> Trenton,
> could it be the same as this one?
> http://bugzilla.kernel.org/show_bug.cgi?id=12321
> "System hangs when unloading alsa modules"
> http://bugs.gentoo.org/show_bug.cgi?id=253535
> "System hangs when unloading alsa modules on Kernel >2.6.28"
> --
> Stefan Richter
> -=====-==--= -=-- --===
> http://arcgraph.de/sr/
>

The first one looks similar, if not identical.  The second one
doesn't, because my problem happens on 2.6.29 only, not 2.6.28.
Either way, the unload problem with the module didn't happen in
2.6.28.

2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Stefan Richter]

Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 10:16 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>> Linus Torvalds wrote:
>>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>>>> Subject              : 2.6.29 on MacBook 2,1 fails to reboot
...
>>> The bug _sounds_ like some deadlock due to lock problems - the shutdown 
>>> path often triggers locks that no other path really cares about. And we 
>>> had some lock problems in the sound subsystem that got fixed post-2.6.28, 
>>> for example. 
>>> 
>>> And it looks like the problem is somewhere in sound shutdown:
>>> 
>>> 12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>
>>> 
>>> So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss, 
>>> fix locking typo") might explain it.
...
>> could it be the same as this one?
>> http://bugzilla.kernel.org/show_bug.cgi?id=12321
>> "System hangs when unloading alsa modules"
>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>> "System hangs when unloading alsa modules on Kernel >2.6.28"
...
> The first one looks similar, if not identical.  The second one
> doesn't, because my problem happens on 2.6.29 only, not 2.6.28.

The Gentoo bug entry too is about a regression _after_ 2.6.28. :-)
I.e. 2.6.28.y. are unaffected.  It's actually just the downstream
duplicate of the kernel.org bug entry.

> Either way, the unload problem with the module didn't happen in
> 2.6.28.

Interdependencies between ALSA modules have changed.  The Gentoo init
scripts attempted to unload them in an order which deadlocked modprobe
due to dependencies.  The fix for Gentoo is to just not unload the
modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
this too; fixed by userland update.

(Added Cc to tiwai@suse.de)
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: 2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Justin Mattock]

On Tue, Apr 7, 2009 at 10:10 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Trenton D. Adams wrote:
>> On Tue, Apr 7, 2009 at 10:16 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>>> Linus Torvalds wrote:
>>>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>>>> Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=13018
>>>>> Subject              : 2.6.29 on MacBook 2,1 fails to reboot
> ...
>>>> The bug _sounds_ like some deadlock due to lock problems - the shutdown
>>>> path often triggers locks that no other path really cares about. And we
>>>> had some lock problems in the sound subsystem that got fixed post-2.6.28,
>>>> for example.
>>>>
>>>> And it looks like the problem is somewhere in sound shutdown:
>>>>
>>>> 12181 delete_module("snd_hda_codec", O_RDONLY|O_EXCL) = -1 EAGAIN (Resource temporarily unavailable) <0.000011>
>>>>
>>>> So commits like 91054598f794fb5d8a0b1e747ff8e2e8fc2115b3 ("ALSA: pcm_oss,
>>>> fix locking typo") might explain it.
> ...
>>> could it be the same as this one?
>>> http://bugzilla.kernel.org/show_bug.cgi?id=12321
>>> "System hangs when unloading alsa modules"
>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>>> "System hangs when unloading alsa modules on Kernel >2.6.28"
> ...
>> The first one looks similar, if not identical.  The second one
>> doesn't, because my problem happens on 2.6.29 only, not 2.6.28.
>
> The Gentoo bug entry too is about a regression _after_ 2.6.28. :-)
> I.e. 2.6.28.y. are unaffected.  It's actually just the downstream
> duplicate of the kernel.org bug entry.
>
>> Either way, the unload problem with the module didn't happen in
>> 2.6.28.
>
> Interdependencies between ALSA modules have changed.  The Gentoo init
> scripts attempted to unload them in an order which deadlocked modprobe
> due to dependencies.  The fix for Gentoo is to just not unload the
> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
> this too; fixed by userland update.
>
> (Added Cc to tiwai@suse.de)
> --
> Stefan Richter
> -=====-=-=== -=-= -==-=
> http://arcgraph.de/sr/
> --
> 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/
>

With the imac(kernel 2.6.29)
/sbin/shutdown -h now   (works)
but
/sbin/reboot
hangs

-- 
Justin P. Mattock

Re: 2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Trenton D. Adams wrote:
> Interdependencies between ALSA modules have changed.  The Gentoo init
> scripts attempted to unload them in an order which deadlocked modprobe
> due to dependencies.  The fix for Gentoo is to just not unload the
> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
> this too; fixed by userland update.
>

While that is interesting, I am not seeing that problem on my Gentoo
box (the macbook), which is completely up-to-date.  2.6.28 works, and
2.6.29 doesn't.  Same init scripts, different kernels.

And sure, I could put a comment on the rmmod, in the init script, but
IMO that would be a hack around a _bug_.  Which is fine for me.  But,
is it worth leaving the issue in the kernel?

Re: 2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Stefan Richter]

Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>> Interdependencies between ALSA modules have changed.  The Gentoo init
>> scripts attempted to unload them in an order which deadlocked modprobe
>> due to dependencies.  The fix for Gentoo is to just not unload the
>> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
>> this too; fixed by userland update.
>>
> 
> While that is interesting, I am not seeing that problem on my Gentoo
> box (the macbook), which is completely up-to-date.  2.6.28 works, and
> 2.6.29 doesn't.  Same init scripts, different kernels.

Note that the respective update changed /etc/conf.d/alsasound (a local
configuration file) to include
UNLOAD_ON_STOP="no"
KILLPROC_ON_STOP="no"
This change by update is not activated by a mere emerge; one needs to
incorporate that change with dispatch-conf or an equivalent method.
(Or simply edit the file to have these variables set to "no".)

> And sure, I could put a comment on the rmmod, in the init script, but
> IMO that would be a hack around a _bug_.  Which is fine for me.  But,
> is it worth leaving the issue in the kernel?

Is it a kernel issue if a script attempts to unload a busy module, then
fails to proceed?  I wouldn't think so.

But more importantly, is this init scripts related bug really what's
happening at your system?  Or do you actually experience an entirely
different bug?
-- 
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/

Re: 2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
<stefanr@s5r6.in-berlin.de> wrote:
> Trenton D. Adams wrote:
>> On Tue, Apr 7, 2009 at 11:10 AM, Stefan Richter
>> <stefanr@s5r6.in-berlin.de> wrote:
>>>>> http://bugs.gentoo.org/show_bug.cgi?id=253535
>>> Interdependencies between ALSA modules have changed.  The Gentoo init
>>> scripts attempted to unload them in an order which deadlocked modprobe
>>> due to dependencies.  The fix for Gentoo is to just not unload the
>>> modules on system shutdown.  My Gentoo/amd64 Mac mini was affected by
>>> this too; fixed by userland update.
>>>
>>
>> While that is interesting, I am not seeing that problem on my Gentoo
>> box (the macbook), which is completely up-to-date.  2.6.28 works, and
>> 2.6.29 doesn't.  Same init scripts, different kernels.
>
> Note that the respective update changed /etc/conf.d/alsasound (a local
> configuration file) to include
> UNLOAD_ON_STOP="no"
> KILLPROC_ON_STOP="no"
> This change by update is not activated by a mere emerge; one needs to
> incorporate that change with dispatch-conf or an equivalent method.
> (Or simply edit the file to have these variables set to "no".)

I run dispatch-conf every time I update.  It did not set it to no by
default.  I do see the option though.

>
>> And sure, I could put a comment on the rmmod, in the init script, but
>> IMO that would be a hack around a _bug_.  Which is fine for me.  But,
>> is it worth leaving the issue in the kernel?
>
> Is it a kernel issue if a script attempts to unload a busy module, then
> fails to proceed?  I wouldn't think so.

I don't know really.  It worked before, now it doesn't.  But, now I'm
recalling something you said earlier.  They are being done in the
wrong order.  The gentoo bug mentions the correct order.  I hadn't
realized that.

>
> But more importantly, is this init scripts related bug really what's
> happening at your system?  Or do you actually experience an entirely
> different bug?

It could be.  I will try it out when I get home from work, and get
back to you.  That would be cool if it was a simple init script
problem.  Cause then I don't have to do anymore git bisects. ;)

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

Re: 2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Trenton D. Adams]

On Tue, Apr 7, 2009 at 2:52 PM, Trenton D. Adams
<trenton.d.adams@gmail.com> wrote:
> On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
> <stefanr@s5r6.in-berlin.de> wrote:
>>
>> But more importantly, is this init scripts related bug really what's
>> happening at your system?  Or do you actually experience an entirely
>> different bug?
>
> It could be.  I will try it out when I get home from work, and get
> back to you.  That would be cool if it was a simple init script
> problem.  Cause then I don't have to do anymore git bisects. ;)

Yes, the order is what causes this, you can close the bug.

Sorry for wasting everyone's time.  I thought it was a kernel bug
because I had not needed to update my gentoo system to make it happen.

Thanks.

Re: 2.6.29 on MacBook 2, 1 fails to reboot (was Re: 2.6.29-git13: Reported regressions from 2.6.28)

[Rafael J. Wysocki]

On Wednesday 08 April 2009, Trenton D. Adams wrote:
> On Tue, Apr 7, 2009 at 2:52 PM, Trenton D. Adams
> <trenton.d.adams@gmail.com> wrote:
> > On Tue, Apr 7, 2009 at 1:23 PM, Stefan Richter
> > <stefanr@s5r6.in-berlin.de> wrote:
> >>
> >> But more importantly, is this init scripts related bug really what's
> >> happening at your system?  Or do you actually experience an entirely
> >> different bug?
> >
> > It could be.  I will try it out when I get home from work, and get
> > back to you.  That would be cool if it was a simple init script
> > problem.  Cause then I don't have to do anymore git bisects. ;)
> 
> Yes, the order is what causes this, you can close the bug.

Closed.

Thanks,
Rafael

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Chris Friesen]

Rafael J. Wysocki wrote:
> On Monday 06 April 2009, Linus Torvalds wrote:
>> On Mon, 6 Apr 2009, Rafael J. Wysocki wrote:
>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=13019
>>> Subject		: /proc/<pid>/maps offset output broken in 2.6.29
>>> Submitter	: "Chris Friesen" <cfriesen@nortel.com>
>>> Date		: 2009-04-01 23:18 (6 days old)
>>> References	: http://marc.info/?l=linuxppc-embedded&m=123862902916059&w=4
>>> Handled-By	: Hugh Dickins <hugh@veritas.com>
>> I don't think that's a regression, nor really a bug. It looks cosmetic, 
>> and likely to be fixed, but not really worth worrying about.
> 
> OK, I've dropped it from the list.

I'm okay with that.  The problem causes some backwards compatibility 
problems with existing apps that get confused by the large "offset" 
number.  The fix is going to cause problems too, but in a different way.

We'll work around it.

Chris

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Linus Torvalds]

On Thu, 16 Apr 2009, Chris Friesen wrote:
> 
> I'm okay with that.  The problem causes some backwards compatibility problems
> with existing apps that get confused by the large "offset" number.  The fix is
> going to cause problems too, but in a different way.
> 
> We'll work around it.

If you have actual apps that care, that's a different issue.

We do try to bend over backwards on ABI issues if it really is noticeable 
for applications. Now, in this case, if you can just fix your app to not 
care (because it really was badly written in the first place to even 
notice), then that is the _much_ superior solution.

But if you actually have binary-only commercial apps that break, we'll do 
a compatibility thing rather than the 0 that already got merged.

Although I don't really even see what we can sanely do except for the 0 
case. We could put the virtual address in there instead of zero (I forget 
what old kernels used to do - whatever magic value the anonymous mappings 
got, it wasn't really designed as an important value in its own right, it 
was designed to trigger the "we can merge these vma's" logic.

			Linus

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Chris Friesen]

Linus Torvalds wrote:
> 
> On Thu, 16 Apr 2009, Chris Friesen wrote:
>> I'm okay with that.  The problem causes some backwards compatibility problems
>> with existing apps that get confused by the large "offset" number.  The fix is
>> going to cause problems too, but in a different way.
>>
>> We'll work around it.
> 
> If you have actual apps that care, that's a different issue.
> 
> We do try to bend over backwards on ABI issues if it really is noticeable 
> for applications. Now, in this case, if you can just fix your app to not 
> care (because it really was badly written in the first place to even 
> notice), then that is the _much_ superior solution.

Yep, we can fix the app to ignore that field for anonymous mappings.

> Although I don't really even see what we can sanely do except for the 0 
> case. We could put the virtual address in there instead of zero (I forget 
> what old kernels used to do - whatever magic value the anonymous mappings 
> got, it wasn't really designed as an important value in its own right, it 
> was designed to trigger the "we can merge these vma's" logic.

For anonymous mappings, the older kernels put the starting address of 
the VMA (from the point of view of the app) as the offset.  Until the 
recent change, new kernels still did this for most VMAs, but the stack 
offset was a 64-bit value with no obvious relation to the VMA start address.

Chris

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Hugh Dickins]

On Mon, 20 Apr 2009, Chris Friesen wrote:
> Linus Torvalds wrote:
> > On Thu, 16 Apr 2009, Chris Friesen wrote:
> > > I'm okay with that.  The problem causes some backwards compatibility
> > > problems
> > > with existing apps that get confused by the large "offset" number.  The
> > > fix is
> > > going to cause problems too, but in a different way.
> > >
> > > We'll work around it.
> > 
> > If you have actual apps that care, that's a different issue.

Yes, that's what I told Chris too.
But asked for more info, suspecting his app was already broken.

> > 
> > We do try to bend over backwards on ABI issues if it really is noticeable
> > for applications. Now, in this case, if you can just fix your app to not
> > care (because it really was badly written in the first place to even
> > notice), then that is the _much_ superior solution.
> 
> Yep, we can fix the app to ignore that field for anonymous mappings.
> 
> > Although I don't really even see what we can sanely do except for the 0
> > case. We could put the virtual address in there instead of zero (I forget
> > what old kernels used to do - whatever magic value the anonymous mappings
> > got, it wasn't really designed as an important value in its own right, it
> > was designed to trigger the "we can merge these vma's" logic.
> 
> For anonymous mappings, the older kernels put the starting address of the VMA
> (from the point of view of the app) as the offset.  Until the recent change,
> new kernels still did this for most VMAs, but the stack offset was a 64-bit
> value with no obvious relation to the VMA start address.

No, what they put there was something that in most cases matched the
starting address of the VMA; but try moving that VMA with mremap (and
an old /proc/<pid>/maps!) and you'll see that the "offset" remained
unchanged even when the starting address of the VMA was changed.

(The offset remaining constant so that rmap can locate the VMA's pages
and unmap them, despite their being mapped at different virtual
addresses in parent and child after a move in one of them.)

... so I think your app was indeed already broken, wasn't it?

It's also unclear why you'd want to use the offset field for the
starting address of the VMA, when /proc/<pid>/maps already shows
the starting address of the VMA.  I think you've more to tell us!

Hugh

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Chris Friesen]

Hugh Dickins wrote:
> On Mon, 20 Apr 2009, Chris Friesen wrote:

>> For anonymous mappings, the older kernels put the starting address of the VMA
>> (from the point of view of the app) as the offset.  Until the recent change,
>> new kernels still did this for most VMAs, but the stack offset was a 64-bit
>> value with no obvious relation to the VMA start address.
> 
> No, what they put there was something that in most cases matched the
> starting address of the VMA; but try moving that VMA with mremap (and
> an old /proc/<pid>/maps!) and you'll see that the "offset" remained
> unchanged even when the starting address of the VMA was changed.
> 
> (The offset remaining constant so that rmap can locate the VMA's pages
> and unmap them, despite their being mapped at different virtual
> addresses in parent and child after a move in one of them.)
> 
> ... so I think your app was indeed already broken, wasn't it?
> 
> It's also unclear why you'd want to use the offset field for the
> starting address of the VMA, when /proc/<pid>/maps already shows
> the starting address of the VMA.  I think you've more to tell us!

Yeah, given the above the app was broken.  We just didn't run into any 
cases where the assumption caused any problems.

Also, it's not so much that we were relying on the offset value for 
anything, so much as we were parsing the file and had made some 
assumptions about valid offsets for anonymous memory.

Anyways, we'll fix it going forward to simply ignore the offset for 
anonymous memory.

Chris

Re: 2.6.29-git13: Reported regressions from 2.6.28

[Rolf Eike Beer]

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

Rafael J. Wysocki wrote:

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=12836
> Subject		: 2.6.29-rc breaks STD using Intel 945
> Submitter	: Rolf Eike Beer <eike-kernel@sf-tec.de>
> Date		: 2009-03-04 19:20 (34 days old)
> References	: http://marc.info/?l=linux-kernel&m=123619451406192&w=4

Looks like this is fixed since 2.6.30-rc1.

Eike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]