linux-kernel - Re: miniroot ramdisk corruption during intense memory usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 28 Mar 2007 10:50:18 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Peter Bier <peter_bier@....de>
CC:	linux-kernel@...r.kernel.org
Subject: Re: miniroot ramdisk corruption during intense memory usage

Peter Bier wrote:
> The following sympthom occured in a variant of the Knoppix-like linux appliance.
> 
> I get a corrupted miniroot ramdisk filesystem under kernel version 2.6.19.1 under intense memory usage during early startup of the system. 
> 
> In the course of a lengthy investigation of this behavior, I found out that the memory pages containing the miniroot ramdisk are freed during the initial installation 
> 
> process due to a memory shortage. It turned out, that shrink_active_list() calls pagevec_strip(), which in turn calls try_to_release_page() which finally calls try_to_free_buffers() which drops the corresponding buffers; if this succeeds, it seems to cause the page to become freed later. 
> 
> This causes pointers of indirect blocks of the filesystem of the miniroot ramdisk to be replaced by zero-filled pages later in the the system's history.
> 
> I fixed this by adding a new flag PG_ramdisk in the include file page-flags.h, setting the flag during ramdisk loading in ramdisk_commit_write() and checking for the flag in try_to_free_buffers() and retruning 0 as result immediately without freeing the buffers. 
> 
> I am not aware if that is the adequate way to solve the problem or if there is a solution that requires fewer and more localized changes of the system, avoiding to give the ramdisk pages a specific treatment
> 
>  
> 
>  
> 
> I did not observe this problem prior to kernel version 2.6.19.1, but I'm not sure whether ths was simply caused by coincidental circumstances during startup. 



The ramdisk driver already marks the pages as "do not discard".  Maybe 
you should investigate why that is no longer being respected?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/