public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: LKML <linux-kernel@vger.kernel.org>
Cc: linux-ext4@vger.kernel.org
Subject: Two questions on VFS/mm
Date: Wed, 4 Jun 2008 18:34:12 +0200	[thread overview]
Message-ID: <20080604163412.GL16572@duck.suse.cz> (raw)

  Hi,

  could some kind soul knowledgable in VFS/mm help me with the following
two questions? I've spotted them when testing some ext4 for patches...
  1) In write_cache_pages() we do:
...
	lock_page(page);
	...
	if (!wbc->range_cyclic && page->index > end) {
                   done = 1;
                   unlock_page(page);
                   continue;
        }
	...
	ret = (*writepage)(page, wbc, data);

  Now the problem is that if range_cyclic is set, it can happen that the
page we give to the filesystem is beyond the current end of file (and can
be already processed by invalidatepage()). Is the filesystem supposed to
handle this (what would it be good for to give such a page to the fs?) or
is it just a bug in write_cache_pages()?

  2) I have the following problem with page_mkwrite() when blocksize <
pagesize. What we want to do is to fill in a potential hole under a page
somebody wants to write to. But consider following scenario with a
filesystem with 1k blocksize:
  truncate("file", 1024);
  ptr = mmap("file");
  *ptr = 'a'
     -> page_mkwrite() is called.
        but "file" is only 1k large and we cannot really allocate blocks
        beyond end of file. So we allocate just one 1k block.
  truncate("file", 4096);
  *(ptr + 2048) = 'a'
     - nothing is called and later during writepage() time we are surprised
       we have a dirty page which is not backed by a filesystem block.

  How to solve this? One idea I have here is that when we handle truncate(),
we mark the original last page (if it is partial) as read-only again so
that page_mkwrite() is called on the next write to it. Is something like
this possible? Pointers to code doing something similar are welcome, I don't
really know these things ;).

								Thanks
									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

             reply	other threads:[~2008-06-04 16:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 16:34 Jan Kara [this message]
2008-06-04 17:10 ` Two questions on VFS/mm Miklos Szeredi
2008-06-05  8:12   ` Jan Kara
2008-06-12  7:06 ` Neil Brown
2008-06-12  8:18   ` Jan Kara
2008-06-13  6:44     ` Neil Brown
2008-06-17 10:11       ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080604163412.GL16572@duck.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox