linux-kernel - Re: Block device cache issue

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]

Message-ID: <49DB2D14.5010603@redhat.com>
Date:	Tue, 07 Apr 2009 13:38:12 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Apollon Oikonomopoulos <ao-lkml@....grnet.gr>,
	linux-kernel@...r.kernel.org
Subject: Re: Block device cache issue

Andrew Morton wrote:
>
>> should it perhaps be the case that the partition's buffers somehow be 
>> linked with those of the containing device, or even be part of them? I 
>> don't even know if this is possible without significant overhead in the 
>> page cache (of which my understanding is very shallow), but keep in mind 
>> that this behaviour almost led to filesystem corruption (luckily we only 
>> changed a single file and hit a single inode).
>>     
>
> It would incur overhead.  We could perhaps fix it by having a single
> cache for /dev/sda and then just making /dev/sda1 access that cache
> with an offset.

The offset can be non PAGE_SIZE aligned (and usually isn't, 63 sectors 
difference with normal partitioning).

-- 
error compiling committee.c: too many arguments to function

--
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/