linux-kernel - Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 7 Jan 2007 23:46:43 -0800 (PST)
From:	dean gaudet <dean@...tic.org>
To:	Andrew Morton <akpm@...l.org>
cc:	David Miller <davem@...emloft.net>, nickpiggin@...oo.com.au,
	torvalds@...l.org, gelma@...ma.net, linux-kernel@...r.kernel.org
Subject: Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback

On Wed, 3 Jan 2007, Andrew Morton wrote:

> On Wed, 03 Jan 2007 22:56:07 -0800 (PST)
> David Miller <davem@...emloft.net> wrote:
> 
> > Note that the original rtorrent debian bug report was against 2.6.18
> 
> I think that was 2.6.18+debian-added-dirty-page-tracking-patches.

i've seen it on a 2.6.18.4 box (no other patches) which was running 
rtorrent at 50mbps rates for a few days... i was only using the box to 
stress a new circuit before putting live traffic on it, so i didn't spend 
any time debugging the failures.

at least i'm assuming this is the same problem you've all just solved: 
rtorrent reports a sha1 miscompare after the download is finished when it 
rechecks the entire file before it enters seeding mode?

in this setup the rtorrent was uploading to ~3k clients simultaneously at 
50mbps... and downloading new torrents at a rate of ~2mbps (very gross 
average -- the download is a lot more bursty than that in practice).

the box has 2GiB of ram, and there were 5.3GB of torrents "live" at any 
time.  rtorrent is pretty bad at dealing with high bitrates for working 
sets larger than ram -- but the 10krpm scsi disk was only ~25% busy 
(unlike other setups i've tried at this bitrates where the disks become 
the bottleneck unless i back off on the torrent working set size).

btw if anyone has a fast pipe and wants to retest the conditions it should 
be easy to reproduce... just join the electricsheep bt swarm and you'll 
almost instantly fill your uplink.  the clients are very hungry ;)  none 
of this is pirated material -- it's basically a distributed render farm 
sharing animations via bt.  let me know if you want help setting such a 
test up.

i attached the .config in case there's anything of interest in it.

-dean
Download attachment "config-2.6.18.4.bz2" of type "APPLICATION/octet-stream" (12742 bytes)