Bug 220328

Summary: possible data corruption when using MAP_SHARED
Product: Red Hat Enterprise Linux 5 Reporter: Peter Zijlstra <pzijlstr>
Component: kernelAssignee: Peter Zijlstra <pzijlstr>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 5.0CC: dzickus, lwang
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-08 16:28:13 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 Flags
current proposed patch - (verified to fix the issue on x86_64) none

Description Peter Zijlstra 2006-12-20 14:11:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko)

Description of problem:
Data corruption was observed when using MAP_SHARED files on ext3 (not sure if 
limited to ext3) on various architectures (i686, x86_64, arm).

This error was traced back to the dirty page tracking for shared mappings 
patches.


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1.download a large (several times larger than machine memory) multi file 
torrent with rtorrent (version 0.7.0 with libtorrent 0.11.0) from mutliple 
peers.


Actual Results:
The hash check after the download completes indicates data corruption

Expected Results:
clean file

Additional info:
After a few days long bughunt on lkml it was found that page_mkclean_one() is 
racy.
A proposed patch is currently under discussion.

Start of thread:
 http://lkml.org/lkml/2006/12/16/164

current proposed patch:
 http://lkml.org/lkml/2006/12/20/112

Comment 1 Peter Zijlstra 2006-12-20 14:12:51 UTC
Created attachment 144099 [details]
current proposed patch - (verified to fix the issue on x86_64)

Comment 2 Eric Sandeen 2007-01-08 15:38:36 UTC
Sorry Peter, didn't know about this one - should it be dup'd to 220963 now?

Comment 3 Eric Sandeen 2007-01-08 16:28:13 UTC

*** This bug has been marked as a duplicate of 220963 ***