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 n
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 b
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 p
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,
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 non-NIL
* 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
"i
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 wa
* 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 (fs/seq_fil
* 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 http://vger.kernel
* 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'
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 / r
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
19 matches
Mail list logo
