From: Andrew Morton <akpm@osdl.org>
To: Evgeniy Dushistov <dushistov@mail.ru>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH]: ufs: truncate should allocate block for last byte
Date: Wed, 28 Jun 2006 04:50:29 -0700 [thread overview]
Message-ID: <20060628045029.bc10d333.akpm@osdl.org> (raw)
In-Reply-To: <20060628093851.GA1719@rain.homenetwork>
On Wed, 28 Jun 2006 13:38:51 +0400
Evgeniy Dushistov <dushistov@mail.ru> wrote:
> +struct page *ufs_get_locked_page(struct address_space *mapping,
> + pgoff_t index)
> +{
> + struct page *page;
> +
> +try_again:
> + page = find_lock_page(mapping, index);
> + if (!page) {
> + page = read_cache_page(mapping, index,
> + (filler_t*)mapping->a_ops->readpage,
> + NULL);
> + if (IS_ERR(page)) {
> + printk(KERN_ERR "ufs_change_blocknr: "
> + "read_cache_page error: ino %lu, index: %lu\n",
> + mapping->host->i_ino, index);
> + goto out;
> + }
> +
> + lock_page(page);
> +
> + if (!PageUptodate(page) || PageError(page)) {
> + unlock_page(page);
> + page_cache_release(page);
> +
> + printk(KERN_ERR "ufs_change_blocknr: "
> + "can not read page: ino %lu, index: %lu\n",
> + mapping->host->i_ino, index);
> +
> + page = ERR_PTR(-EIO);
> + goto out;
> + }
> + }
> +
> + if (unlikely(!page->mapping || !page_has_buffers(page))) {
> + unlock_page(page);
> + page_cache_release(page);
> + goto try_again;/*we really need these buffers*/
> + }
> +out:
> + return page;
> +}
I think there's a (preexisting) problem here. When one thread is executing
ufs_get_locked_page() while a second thread is running truncate().
If truncate got to the page first, truncate_complete_page() will mark the
page !uptodate and will later unlock it. Now this function gets the page
lock and emits a printk (bad) and assumes -EIO (worse).
That scenario might not be possible because of i_mutex coverage, dunno.
But if it _is_ possible, it can be simply fixed by doing
lock_page(page);
+ if (page->mapping == NULL) {
+ /* truncate() got there first */
+ page_cache_release(page);
+ goto try_again;
+ }
That's if it is appropriate to re-instantiate the page at a place which is
now outside i_size...
next prev parent reply other threads:[~2006-06-28 11:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 9:38 [PATCH]: ufs: truncate should allocate block for last byte Evgeniy Dushistov
2006-06-28 11:50 ` Andrew Morton [this message]
2006-06-28 15:24 ` Evgeniy Dushistov
2006-06-28 19:22 ` Andrew Morton
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=20060628045029.bc10d333.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dushistov@mail.ru \
--cc=linux-fsdevel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.