From: Evgeniy Dushistov <dushistov@mail.ru>
To: Andrew Morton <akpm@osdl.org>
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 19:24:50 +0400 [thread overview]
Message-ID: <20060628152450.GA16996@rain.homenetwork> (raw)
In-Reply-To: <20060628045029.bc10d333.akpm@osdl.org>
On Wed, Jun 28, 2006 at 04:50:29AM -0700, Andrew Morton wrote:
> On Wed, 28 Jun 2006 13:38:51 +0400
> > + 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.
>
I suppose this is possible because of
a)page may be mapped to hole
b)sys_msync doesn't use i_mutex
c)in case of block allocation we can call ufs_get_locked_page
> But if it _is_ possible, it can be simply fixed by doing
>
But you added such check "!page->mapping" into ufs_get_locked_page,
is it not enough?
> 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...
--
/Evgeniy
next prev parent reply other threads:[~2006-06-28 15:18 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
2006-06-28 15:24 ` Evgeniy Dushistov [this message]
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=20060628152450.GA16996@rain.homenetwork \
--to=dushistov@mail.ru \
--cc=akpm@osdl.org \
--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.