On 10/4/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
> >...
> > and btw, there is no question what-so-ever about whether your compiler
> > might be doing a legal optimization - the compiler really is wrong, and is
> > total shit. You
On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
>...
> and btw, there is no question what-so-ever about whether your compiler
> might be doing a legal optimization - the compiler really is wrong, and is
> total shit. You need to make a gcc bug-report.
>...
Ingo can't send a gcc
On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
...
and btw, there is no question what-so-ever about whether your compiler
might be doing a legal optimization - the compiler really is wrong, and is
total shit. You need to make a gcc bug-report.
...
Ingo can't send a gcc
On 10/4/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 08:11:05AM -0700, Linus Torvalds wrote:
...
and btw, there is no question what-so-ever about whether your compiler
might be doing a legal optimization - the compiler really is wrong, and is
total shit. You need to
On Wed, 3 Oct 2007, Jan Engelhardt wrote:
>
> >When I'm ruler of the universe, it *will* be illegal. I'm just getting a
> >bit ahead of myself.
>
> Any time frame when that will happen?
I'm working on it, I'm working on it. I'm just as frustrated as you are.
It turns out to be a non-trivial
On Oct 3 2007 09:09, Linus Torvalds wrote:
>On Wed, 3 Oct 2007, Alan Cox wrote:
>>
>> > and btw, there is no question what-so-ever about whether your compiler
>> > might be doing a legal optimization - the compiler really is wrong, and is
>>
>> Pedant: valid. Almost all optimizations are
On Wed, 3 Oct 2007, Alan Cox wrote:
>
> > and btw, there is no question what-so-ever about whether your compiler
> > might be doing a legal optimization - the compiler really is wrong, and is
>
> Pedant: valid. Almost all optimizations are legal, nobody has yet written
> laws about compilers.
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > Your compiler generates
> >
> > movl-16(%ebp),%edx
> > movl(%edx),%edi /* this is _totally_ bogus! */
> > incl%edx
> > movl%edx,-16(%ebp)
> > movl
On Wed, 3 Oct 2007, Ingo Molnar wrote:
>
> > - and as a result you get an exception on the *next* page:
> >
> > BUG: unable to handle kernel paging request at virtual address f2a4
>
> Hm, are you sure? This is a CONFIG_DEBUG_PAGEALLOC=y kernel, so even a
> slight overrun of a
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Your compiler generates
>
> movl-16(%ebp),%edx
> movl(%edx),%edi /* this is _totally_ bogus! */
> incl%edx
> movl%edx,-16(%ebp)
> movl%edi,%ecx
> testb %cl,%cl
> je ...
On Wed, 3 Oct 2007, Linus Torvalds wrote:
>
> - the bug happens on this:
>
> char c = *p++;
>
> - which has been compiled into
>
> 8b 3a mov(%edx),%edi
Btw, this definitely doesn't happen for me, either on x86-64 or plain x86.
The x86 thing I tested was Fedora 8
> and btw, there is no question what-so-ever about whether your compiler
> might be doing a legal optimization - the compiler really is wrong, and is
Pedant: valid. Almost all optimizations are legal, nobody has yet written
laws about compilers. Sorry but I'm forever fixing misuse of the word
On Wed, 3 Oct 2007 15:26:01 +0100
Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
> > > Charming... So we get d_path() either returning junk or we get
> > > something that isn't NUL-terminated. Which one it is? I.e. what
> > > does p look like
On Wed, 3 Oct 2007, Ingo Molnar wrote:
>
> hm, i just triggered the procfs crash below with -rc9 on a testbox.
You have a terminally buggy piece of shit compiler.
Lookie here:
- the bug happens on this:
char c = *p++;
- which has been compiled into
8b 3a mov
On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
> > Charming... So we get d_path() either returning junk or we get
> > something that isn't NUL-terminated. Which one it is? I.e. what does
> > p look like and what's in s?
>
> could be use-after-free as well, as CONFIG_PAGEALLOC
* Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
> >
> > hm, i just triggered the procfs crash below with -rc9 on a testbox.
> > Config attached. It's easy to reproduce it via 'service sshd restart'.
> > The crash site is:
> >
> > (gdb) list
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
>
> hm, i just triggered the procfs crash below with -rc9 on a testbox.
> Config attached. It's easy to reproduce it via 'service sshd restart'.
> The crash site is:
>
> (gdb) list *0xc017599d
> 0xc017599d is in seq_path
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> -CONFIG_MAC80211_DEBUGFS=y
it's CONFIG_MAC80211_DEBUGFS=y causing the crash.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> nodev /debug debugfs rw 0 0
> ) = 290
> read(3, "", 4096) = 0
> close(3)= 0
>
> there's nothing particularly interesting in it. (perhaps debugfs)
disabling debugfs makes the crash go away so
update: occasionally the reading of /proc/mounts succeeds, and it's:
open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "rootfs / rootfs rw 0 0\n/dev/root"..., 4096) = 290
write(1, "rootfs / rootfs rw 0 0\n/dev/root"..., 290rootfs /
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
0xc017599d is in seq_path (fs/seq_file.c:354).
349 if (m->count < m->size) {
350
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
0xc017599d is in seq_path (fs/seq_file.c:354).
349 if (m-count m-size) {
350
update: occasionally the reading of /proc/mounts succeeds, and it's:
open(/proc/mounts, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, rootfs / rootfs rw 0 0\n/dev/root..., 4096) = 290
write(1, rootfs / rootfs rw 0 0\n/dev/root..., 290rootfs / rootfs
* Ingo Molnar [EMAIL PROTECTED] wrote:
nodev /debug debugfs rw 0 0
) = 290
read(3, , 4096) = 0
close(3)= 0
there's nothing particularly interesting in it. (perhaps debugfs)
disabling debugfs makes the crash go away so it's debugfs
* Ingo Molnar [EMAIL PROTECTED] wrote:
-CONFIG_MAC80211_DEBUGFS=y
it's CONFIG_MAC80211_DEBUGFS=y causing the crash.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
0xc017599d is in seq_path
* Al Viro [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 10:46:07AM +0200, Ingo Molnar wrote:
hm, i just triggered the procfs crash below with -rc9 on a testbox.
Config attached. It's easy to reproduce it via 'service sshd restart'.
The crash site is:
(gdb) list *0xc017599d
On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
Charming... So we get d_path() either returning junk or we get
something that isn't NUL-terminated. Which one it is? I.e. what does
p look like and what's in s?
could be use-after-free as well, as CONFIG_PAGEALLOC was
On Wed, 3 Oct 2007, Ingo Molnar wrote:
hm, i just triggered the procfs crash below with -rc9 on a testbox.
You have a terminally buggy piece of shit compiler.
Lookie here:
- the bug happens on this:
char c = *p++;
- which has been compiled into
8b 3a mov
On Wed, 3 Oct 2007 15:26:01 +0100
Al Viro [EMAIL PROTECTED] wrote:
On Wed, Oct 03, 2007 at 04:08:42PM +0200, Ingo Molnar wrote:
Charming... So we get d_path() either returning junk or we get
something that isn't NUL-terminated. Which one it is? I.e. what
does p look like and what's
and btw, there is no question what-so-ever about whether your compiler
might be doing a legal optimization - the compiler really is wrong, and is
Pedant: valid. Almost all optimizations are legal, nobody has yet written
laws about compilers. Sorry but I'm forever fixing misuse of the word
On Wed, 3 Oct 2007, Linus Torvalds wrote:
- the bug happens on this:
char c = *p++;
- which has been compiled into
8b 3a mov(%edx),%edi
Btw, this definitely doesn't happen for me, either on x86-64 or plain x86.
The x86 thing I tested was Fedora 8 testing
* Linus Torvalds [EMAIL PROTECTED] wrote:
Your compiler generates
movl-16(%ebp),%edx
movl(%edx),%edi /* this is _totally_ bogus! */
incl%edx
movl%edx,-16(%ebp)
movl%edi,%ecx
testb %cl,%cl
je ...
ah, ok.
On Wed, 3 Oct 2007, Ingo Molnar wrote:
- and as a result you get an exception on the *next* page:
BUG: unable to handle kernel paging request at virtual address f2a4
Hm, are you sure? This is a CONFIG_DEBUG_PAGEALLOC=y kernel, so even a
slight overrun of a non-NIL
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
Your compiler generates
movl-16(%ebp),%edx
movl(%edx),%edi /* this is _totally_ bogus! */
incl%edx
movl%edx,-16(%ebp)
movl%edi,%ecx
testb
On Wed, 3 Oct 2007, Alan Cox wrote:
and btw, there is no question what-so-ever about whether your compiler
might be doing a legal optimization - the compiler really is wrong, and is
Pedant: valid. Almost all optimizations are legal, nobody has yet written
laws about compilers. Sorry
On Oct 3 2007 09:09, Linus Torvalds wrote:
On Wed, 3 Oct 2007, Alan Cox wrote:
and btw, there is no question what-so-ever about whether your compiler
might be doing a legal optimization - the compiler really is wrong, and is
Pedant: valid. Almost all optimizations are legal, nobody has
On Wed, 3 Oct 2007, Jan Engelhardt wrote:
When I'm ruler of the universe, it *will* be illegal. I'm just getting a
bit ahead of myself.
Any time frame when that will happen?
I'm working on it, I'm working on it. I'm just as frustrated as you are.
It turns out to be a non-trivial
38 matches
Mail list logo
