[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070209111455.67a69783.akpm@linux-foundation.org>
Date: Fri, 9 Feb 2007 11:14:55 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Nick Piggin <npiggin@...e.de>
Cc: Linux Filesystems <linux-fsdevel@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [patch 3/3] ext2: use perform_write aop
On Thu, 8 Feb 2007 14:07:46 +0100 (CET) Nick Piggin <npiggin@...e.de> wrote:
> +void page_zero_new_buffers(struct page *page, unsigned from, unsigned to)
> +{
> + unsigned int block_start, block_end;
> + struct buffer_head *head, *bh;
> +
> + BUG_ON(!PageLocked(page));
> + if (!page_has_buffers(page))
> + return;
> +
> + bh = head = page_buffers(page);
> + block_start = 0;
> + do {
> + block_end = block_start + bh->b_size;
> +
> + if (buffer_new(bh)) {
> + if (block_end > from && block_start < to) {
> + if (!PageUptodate(page)) {
> + unsigned start, end;
> + void *kaddr;
> +
> + start = max(from, block_start);
> + end = min(to, block_end);
> +
> + kaddr = kmap_atomic(page, KM_USER0);
> + memset(kaddr+start, 0, block_end-end);
> + flush_dcache_page(page);
> + kunmap_atomic(kaddr, KM_USER0);
> + set_buffer_uptodate(bh);
> + }
I don't see how this differs from the previous attempts to solve the
deadlock via atomic copt_from_user(). Here we temporarily zero out the
pagecache page then block_perform_write() unlocks the page. So another
thread can come in, read the page and see the temporary zeroes?
If so, that might be preventable by leaving the buffer nonuptodate.
-
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/
Powered by blists - more mailing lists