linux-ext4 - Re: ext4_page_mkwrite and delalloc

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]

Message-ID: <20080616160906.GB14214@skywalker>
Date:	Mon, 16 Jun 2008 21:39:06 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Mingming Cao <cmm@...ibm.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: ext4_page_mkwrite and delalloc

On Mon, Jun 16, 2008 at 04:11:41PM +0200, Jan Kara wrote:
>   Hi Aneesh,
> 
> On Thu 12-06-08 23:44:07, Aneesh Kumar K.V wrote:
> > With delalloc we should not do writepage in ext4_page_mkwrite. The idea
> > with delalloc is to delay the block allocation and make sure we allocate
> > chunks of blocks together at writepages. So i guess we should update
> > ext4_page_mkwrite to use write_begin and write_end instead of writepage.
> > Taking i_alloc_sem should protect against parallel truncate and the page
> > lock should protect against parallel write_begin/write_end.
> > 
> > How about the patch below ?
>   In principle the patch looks fine, I would only like to see two things
> checked:
>   1) Did you do some stress testing of the patch - combining mmapped writes
> with ordinary writes to the same file and truncation so that we detect
> possible bugs in locking / data corruption due to some bad locking. This
> significantly changes when write_begin / write_end can be called in ext4
> (i.e., it is now called without i_mutex - BTW: that is probably worth a
> comment before these functions).
>   2) How does this change influence CPU load for mmapped accesses - I worry
> about write_begin / write_end path being significantly heavier than just
> calling writepage. Probably just mmap a large file, write single byte
> to every page and measure using oprofile whether accumulated time spent in
> page_mkwrite didn't change to much.
> 

We can actually get away with page_mkwrite if we agree that SIGBUS on
ENOSPC is not the right way. We can implement writepages for different
data mode, and allocate blocks in writepages. With those changes we don't
allocate blocks for mmap area maping holes upon write. Instead we
allocate block during writepages. Since we can start a transaction
during writepages we should be ok with respect to new locking.?

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html