In the kerneloops.org stats, a new oops is rapidly climbing the charts.
The oops is a page fault in the ext3 "do_slit" function, and the first
report of it was with 2.6.26-rc6-git3.
It happens with various applications; the backtraces are at:
http://www.kerneloops.org/search.php?search=do_split
but are generally of this pattern:
*do_split
ext3_add_entry
ext3_rename
vfs_rename
... <various paths into vfs_rename> ...
or
*do_split
? add_dirent_to_buf
ext3_add_entry
ext3_new_inode
ext3_add_nondir
ext3_create
vfs_create
....
did we change anything in ext
On Thu, Jun 19, 2008 at 3:36 PM, Arjan van de Ven <[email protected]> wrote:
> In the kerneloops.org stats, a new oops is rapidly climbing the charts.
> The oops is a page fault in the ext3 "do_slit" function, and the first
> report of it was with 2.6.26-rc6-git3.
>
> It happens with various applications; the backtraces are at:
>
> http://www.kerneloops.org/search.php?search=do_split
>
This is a bug in rawhide in gcc miscompiling something...
https://bugzilla.redhat.com/show_bug.cgi?id=451068
Dave.
Dave Airlie wrote:
> On Thu, Jun 19, 2008 at 3:36 PM, Arjan van de Ven <[email protected]> wrote:
>> In the kerneloops.org stats, a new oops is rapidly climbing the charts.
>> The oops is a page fault in the ext3 "do_slit" function, and the first
>> report of it was with 2.6.26-rc6-git3.
>>
>> It happens with various applications; the backtraces are at:
>>
>> http://www.kerneloops.org/search.php?search=do_split
>>
>
> This is a bug in rawhide in gcc miscompiling something...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=451068
>
thanks for letting us know so fast!
I've marked this one in the database as a fedora gcc bug
On Thu, 19 Jun 2008, Dave Airlie wrote:
>
> This is a bug in rawhide in gcc miscompiling something...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=451068
Gaah. I should read all my email instead of wasting my time trying to
match up the code with what I can reproduce..
Linus
Linus Torvalds wrote:
>
> On Thu, 19 Jun 2008, Dave Airlie wrote:
>> This is a bug in rawhide in gcc miscompiling something...
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=451068
>
> Gaah. I should read all my email instead of wasting my time trying to
> match up the code with what I can reproduce..
>
unfortunately, kerneloops.org didn't pick up the link to this bug (due to the fact
that the oops in the bug was a jpeg....)... maybe one day if I'm really bored
I'll implement OCR into it ;)
sorry about wasting your time
On Thu, Jun 19, 2008 at 03:42:34PM +1000, Dave Airlie wrote:
> On Thu, Jun 19, 2008 at 3:36 PM, Arjan van de Ven <[email protected]> wrote:
> > In the kerneloops.org stats, a new oops is rapidly climbing the charts.
> > The oops is a page fault in the ext3 "do_slit" function, and the first
> > report of it was with 2.6.26-rc6-git3.
> >
> > It happens with various applications; the backtraces are at:
> >
> > http://www.kerneloops.org/search.php?search=do_split
>
> This is a bug in rawhide in gcc miscompiling something...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=451068
If I understand it correctly that's a bug in upstream gcc 4.3.1
(but not in gcc 4.3.0)?
Expect a lot more of this to pop up in the future.
Should we #error for gcc 4.3.1?
> Dave.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk writes:
> On Thu, Jun 19, 2008 at 03:42:34PM +1000, Dave Airlie wrote:
> > On Thu, Jun 19, 2008 at 3:36 PM, Arjan van de Ven <[email protected]> wrote:
> > > In the kerneloops.org stats, a new oops is rapidly climbing the charts.
> > > The oops is a page fault in the ext3 "do_slit" function, and the first
> > > report of it was with 2.6.26-rc6-git3.
> > >
> > > It happens with various applications; the backtraces are at:
> > >
> > > http://www.kerneloops.org/search.php?search=do_split
> >
> > This is a bug in rawhide in gcc miscompiling something...
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=451068
>
> If I understand it correctly that's a bug in upstream gcc 4.3.1
> (but not in gcc 4.3.0)?
>
> Expect a lot more of this to pop up in the future.
> Should we #error for gcc 4.3.1?
There are other nasty bugs in gcc-4.3.0. I actually
had to completely ban 4.3.0 in a user-space project
I'm involved with (Erlang) due to gcc PR36339 (fixed
in 4.3.1).
What's the gcc bugzilla number for this new 4.3.1 bug?
On Thu, Jun 19, 2008 at 10:32:24AM +0200, Mikael Pettersson wrote:
>...
> What's the gcc bugzilla number for this new 4.3.1 bug?
#36533
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
>
> Expect a lot more of this to pop up in the future.
> Should we #error for gcc 4.3.1?
>
it/s better to find if the gcc guys made a testcase for this bug (they normally do) and
test based on that.
Arjan van de Ven wrote:
> In the kerneloops.org stats, a new oops is rapidly climbing the charts.
> The oops is a page fault in the ext3 "do_slit" function, and the first
> report of it was with 2.6.26-rc6-git3.
>
> It happens with various applications; the backtraces are at:
>
> http://www.kerneloops.org/search.php?search=do_split
Arjan, I was just looking at kerneloops last night, seeing the count for
this oops climb, and was wishing there were some way to annotate an oops
signature with more info. If I could have tagged this with the RH
bugzilla nr. it might have saved a lot of time for folks. Is this
feasible? Or is finding the oops text in bugzilla the only way?
Thanks,
-Eric
Eric Sandeen wrote:
> Arjan van de Ven wrote:
>> In the kerneloops.org stats, a new oops is rapidly climbing the charts.
>> The oops is a page fault in the ext3 "do_slit" function, and the first
>> report of it was with 2.6.26-rc6-git3.
>>
>> It happens with various applications; the backtraces are at:
>>
>> http://www.kerneloops.org/search.php?search=do_split
>
> Arjan, I was just looking at kerneloops last night, seeing the count for
> this oops climb, and was wishing there were some way to annotate an oops
> signature with more info. If I could have tagged this with the RH
> bugzilla nr. it might have saved a lot of time for folks. Is this
> feasible? Or is finding the oops text in bugzilla the only way?
>
there's a way to add a description to oopses (you might have seen some of these
descriptions already); however I've not implemented an account system yet so for
now it's only me who can add these.
Arjan van de Ven wrote:
> Eric Sandeen wrote:
>> Arjan van de Ven wrote:
>>> In the kerneloops.org stats, a new oops is rapidly climbing the charts.
>>> The oops is a page fault in the ext3 "do_slit" function, and the first
>>> report of it was with 2.6.26-rc6-git3.
>>>
>>> It happens with various applications; the backtraces are at:
>>>
>>> http://www.kerneloops.org/search.php?search=do_split
>> Arjan, I was just looking at kerneloops last night, seeing the count for
>> this oops climb, and was wishing there were some way to annotate an oops
>> signature with more info. If I could have tagged this with the RH
>> bugzilla nr. it might have saved a lot of time for folks. Is this
>> feasible? Or is finding the oops text in bugzilla the only way?
>>
>
> there's a way to add a description to oopses (you might have seen some of these
> descriptions already); however I've not implemented an account system yet so for
> now it's only me who can add these.
Ok, that was my guess. I'll shoot you an email next time. :)
Thanks,
-Eric
On Thu, Jun 19, 2008 at 06:40:05AM -0700, Arjan van de Ven wrote:
> Adrian Bunk wrote:
>>
>> Expect a lot more of this to pop up in the future.
>> Should we #error for gcc 4.3.1?
>
> it/s better to find if the gcc guys made a testcase for this bug (they normally do) and
> test based on that.
The gcc Bugzilla contains a testcase.
But how do you plan to integrate it into a kernel build?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Thu, Jun 19, 2008 at 06:40:05AM -0700, Arjan van de Ven wrote:
>> Adrian Bunk wrote:
>>> Expect a lot more of this to pop up in the future.
>>> Should we #error for gcc 4.3.1?
>> it/s better to find if the gcc guys made a testcase for this bug (they normally do) and
>> test based on that.
>
> The gcc Bugzilla contains a testcase.
>
> But how do you plan to integrate it into a kernel build?
we already have several of these.
Just look at scripts/gcc-x86_64-has-stack-protector.sh for an example of such a beast.
On Thu, Jun 19, 2008 at 08:18:39AM -0700, Arjan van de Ven wrote:
> Adrian Bunk wrote:
>> On Thu, Jun 19, 2008 at 06:40:05AM -0700, Arjan van de Ven wrote:
>>> Adrian Bunk wrote:
>>>> Expect a lot more of this to pop up in the future.
>>>> Should we #error for gcc 4.3.1?
>>> it/s better to find if the gcc guys made a testcase for this bug (they normally do) and
>>> test based on that.
>>
>> The gcc Bugzilla contains a testcase.
>>
>> But how do you plan to integrate it into a kernel build?
>
> we already have several of these.
> Just look at scripts/gcc-x86_64-has-stack-protector.sh for an example of such a beast.
Checking whether gcc supports some flags is easy.
But miscompilations are a different issue.
Especially since we also want to reject broken gcc versions for cross
compilations.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
> On Thu, Jun 19, 2008 at 08:18:39AM -0700, Arjan van de Ven wrote:
>> Adrian Bunk wrote:
>>> On Thu, Jun 19, 2008 at 06:40:05AM -0700, Arjan van de Ven wrote:
>>>> Adrian Bunk wrote:
>>>>> Expect a lot more of this to pop up in the future.
>>>>> Should we #error for gcc 4.3.1?
>>>> it/s better to find if the gcc guys made a testcase for this bug (they normally do) and
>>>> test based on that.
>>> The gcc Bugzilla contains a testcase.
>>>
>>> But how do you plan to integrate it into a kernel build?
>> we already have several of these.
>> Just look at scripts/gcc-x86_64-has-stack-protector.sh for an example of such a beast.
>
> Checking whether gcc supports some flags is easy.
have you actually looked at this script?
You didn't, since the script doesn't check if gcc supports some flag.
It checks very specifically for a code generation pattern...
Please go look at the script first before responding.
On Thu, Jun 19, 2008 at 08:27:48AM -0700, Arjan van de Ven wrote:
> Adrian Bunk wrote:
>> On Thu, Jun 19, 2008 at 08:18:39AM -0700, Arjan van de Ven wrote:
>>> Adrian Bunk wrote:
>>>> On Thu, Jun 19, 2008 at 06:40:05AM -0700, Arjan van de Ven wrote:
>>>>> Adrian Bunk wrote:
>>>>>> Expect a lot more of this to pop up in the future.
>>>>>> Should we #error for gcc 4.3.1?
>>>>> it/s better to find if the gcc guys made a testcase for this bug (they normally do) and
>>>>> test based on that.
>>>> The gcc Bugzilla contains a testcase.
>>>>
>>>> But how do you plan to integrate it into a kernel build?
>>> we already have several of these.
>>> Just look at scripts/gcc-x86_64-has-stack-protector.sh for an example of such a beast.
>>
>> Checking whether gcc supports some flags is easy.
>
> have you actually looked at this script?
> You didn't, since the script doesn't check if gcc supports some flag.
> It checks very specifically for a code generation pattern...
>
> Please go look at the script first before responding.
I did look, but I missed the last pipe...
Do we know for sure this bug can only trigger on 32bit x86?
Or is there anything else I miss in gcc-x86_64-has-stack-protector.sh
that allows to use this approach to check for wrong code generation
caused by platform independent gcc bugs?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed