Here's a short list of showstoppers for 2.6.14 release, from the UML point of
view.
I and/or Jeff know about them, and Jeff might add some other ones. Also UML
users are welcome (please in this case, especially if you aren't sure if
you're experiencing a bug or a setup problem, don't CC directly Andrew
Morton, but instead give me and Jeff a chance to act as a filter).
I hope so to avoid the situation of 2.6.10 release, when a bunch of important
fixes was in -mm, targeted at 2.6.10, but was merged *after* 2.6.10. That has
not happened any more, but 2.6.14 has a shorter release cycle, so I'm
worried.
I initially read 2.6.14 ETA's was around October 7, when is it now?
However, here we go with the showstoppers (mostly regression):
1) I broke SKAS3 with the last merge. The fix is trivial, I just want to
stress-test it a bit more this time (and run the original LTP failing test
case, i.e. copy_from_user(dest, (void*) -1, n)).
2) problems with UBD (i.e. _the_ uml block driver): this is pretty dangerous
and untrivial to fix, even if the code exists.
DESCRIPTION:
with the UBD rewrite to use AIO merged before 2.6.14-rc1, the UBD driver does
GFP_KERNEL allocations under spinlocks and can have a deadlock (there's an
host IPC pipe, whose buffer can get filled causing the kernel to sleep). Jeff
Dike has the fixes for this, but they're not trivial, so he's working on
them. I think he could send them to Jens Axboe, when he feels them ready.
Agreed, Jeff?
3) I've a problem with KBUILD_OUTPUT, just fixed, recently introduced. Going
to properly test the fix and submit it.
4) Not a regression:
I have a bunch of fixes for HPPFS, which went under a review from Al Viro. I'm
incorporating his suggestions, but the patches are invasive, so probably it's
better to defer them to 2.6.15. I'm not sure, though.
Jeff, have you any further notes to add?
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
On Tue, Sep 27, 2005 at 06:46:50PM +0200, Blaisorblade wrote:
> Jeff, have you any further notes to add?
Agree.
I have one more to add - that UML/x86_64 doesn't run with CONFIG_FRAME_POINTER
disabled.
Jeff
On Tuesday 27 September 2005 21:30, Jeff Dike wrote:
> On Tue, Sep 27, 2005 at 06:46:50PM +0200, Blaisorblade wrote:
> > Jeff, have you any further notes to add?
>
> Agree.
>
> I have one more to add - that UML/x86_64 doesn't run with
> CONFIG_FRAME_POINTER disabled.
Do you know when this was introduced, and the last working UML version?
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
On Wed, Sep 28, 2005 at 02:15:18PM +0200, Blaisorblade wrote:
> Do you know when this was introduced, and the last working UML version?
It's always been broken, I think. It results from the stub having to
sigreturn by hand because it has no access to the libc restorer, and thus
needing to restore the stack pointer to where it was on entry. I did this
by popping the requisite number of times. Bodo fixed this for i386, and
I need to do something similar for x86_64.
Jeff
On Wednesday 28 September 2005 16:52, Jeff Dike wrote:
> On Wed, Sep 28, 2005 at 02:15:18PM +0200, Blaisorblade wrote:
> > Do you know when this was introduced, and the last working UML version?
> It's always been broken, I think.
Ah, but you're talking of SKAS0.
In this case (which seems strange, given the number of people using x86_64 and
not complaining - or maybe it's just me who didn't say "enable frame
pointers" to any of the various bug reports), if the patch is not trivial
enough (it seems to be), make sure to at least force frame pointers.
Even if I think, if I understood the thing correctly, that this workaround is
not even guaranteed to work.
> It results from the stub having to
> sigreturn by hand because it has no access to the libc restorer, and thus
> needing to restore the stack pointer to where it was on entry. I did this
> by popping the requisite number of times.
> Bodo fixed this for i386,
By restoring in sp the address of first param (or something like that), right?
> and
> I need to do something similar for x86_64.
The bug killing almost everybody testing 2.6.12-bb? In this case, it's SKAS0
specific.
But especially, couldn't this be triggered by another GCC version, changing
the stack layout?
> Jeff
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Messenger: chiamate gratuite in tutto il mondo
http://it.messenger.yahoo.com