Bug 61595
Summary: | Assertion failure in ext3_sync_file() at fsync.c:55: "ext3_journal_current_handle() == 0" | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Andrew Vasquez <andrew.vasquez> | ||||
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.2 | CC: | john_hull, sct | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2002-03-22 23:14:57 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Andrew Vasquez
2002-03-21 23:02:00 UTC
Does the 5.38.3 driver have the stackoverflow that was in 5.31 fixed ? Arjan, I'm looking at the changelog from the RH1 drop you had worked on. There are three places where you note 'buffer/stack overflow': * fix bufferoverflow from the /proc file * fix using stack variables to register IO ports and other resources (and bufferoverflow in the same code) I can see the problem in the code for these two (qla2100_proc_info, qla2100_register_with_Linux). But, for the third entry: * fix stack overflow that caused oopses and/or memory corruption I've scanned the diffs, but cannot seem to trace this down to a specific change beyond the following lines: - request_region(host->io_port, 0xff, drvname); + sprintf(ha->devname, "qla2x00#%02d", host->unique_id); + request_region(host->io_port, 0xff, ha->devname); - /* ER# 4368 */ - sprintf(drvname, "qla2x00#%02d", host->unique_id); Where drvname was originally defined char drvname[9] (bad!). Thanks! All that has happened here is that we've entered an ext3 function, and the "task->journal" entry in the task_struct is already set. That's the last item in the task struct, and the task struct is allocated just below the kernel stack, so if there is any chance there's a stack overflow involved, this is exactly where you'd expect to see it detected. We really need to eliminate that possibility if there is any question of such overflow in the driver. Created attachment 49724 [details]
simple shell script to check for stack abuse
I've attached a simple shell script to check a compiled driver for functions that have a big stack footprint. It will print a series of lines in the form of sub $0x19c,%esp where "0x19c" is the amount of stack use for the function in question, in (hex) bytes. It writes also a disassembled file called "d" where that line can be looked up to see which C function it corresponds with. Remember that the linux kernel stack that drivers etc can use is 3 Kb or so. (8Kb minus the task struct minus a room you need to keep for irq's to work) Since we think this is a bug in the driver you are loading, and not in our kernel, I'm closing this as NOTABUG. You can always re-open it if you determine that this is not the case. |