Bug 162094
| Summary: | read() with count > 0xffffffff panics kernel at fs/direct-io.c:886 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | David Milburn <dmilburn> | ||||||||||
| Component: | kernel | Assignee: | Peter Staubach <staubach> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 4.0 | CC: | jbaron, sct, tao | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | ia64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | RHSA-2006-0132 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2006-03-07 19:13:41 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: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 168429 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
David Milburn
2005-06-29 20:03:03 UTC
Created attachment 116144 [details]
Program to reproduce the bug
Created attachment 116145 [details]
Patch to fix
This situation occurs because an unsigned int is used to store the size of maximum contiguous number of blocks which can be transfered at once. When doing a direct-io read on a block device, the size of the transfer is set to the minimum of the size of the clock device or the requested number of bytes. In the test case, the program tries to read 4GB, 0x100000000. I used a 10G partition. Therefore, the code tried to store 0x100000000 in an unsigned int. This won't fit and ends up zeroing out the int. This situation can be addressed either by limiting the read count size, as the proposed patch does, or by handling the request as several smaller requests inside of the kernel. The advantage of this latter approach is that the system call semantics are maintained and the application does not need to be aware that it is dealing with a "file" with different characteristics and the file struct does not have to be modified. Created attachment 118154 [details]
Proposed patch
The proposed patch breaks up the original, single iovec into multiple smaller iovecs, each capable of being expressed using a 32 bit integer. This avoids the overflow that the current system suffers from. Created attachment 119775 [details]
Proposed patch
I don't understand the question. If it is about which symbol should be used at the user level, then I don't actually know and will have to defer to some one else with more experience in the kernel to user level symbol translation. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0132.html |