From: Jan Kara <jack@suse.cz>
To: Mark Fasheh <mark.fasheh@oracle.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] Handle i_size > s_maxbytes gracefully
Date: Wed, 19 Dec 2007 00:59:29 +0100 [thread overview]
Message-ID: <20071218235929.GA3569@duck.suse.cz> (raw)
In-Reply-To: <20071218225007.GE13821@ca-server1.us.oracle.com>
On Tue 18-12-07 14:50:07, Mark Fasheh wrote:
> On Tue, Dec 18, 2007 at 04:25:05PM +0100, Jan Kara wrote:
> > Although we don't allow writes over s_maxbytes, it can happen that a file's
> > size is larger than s_maxbytes. For example we can write the file from
> > a computer with a different architecture (which has larger s_maxbytes),
> > boot a kernel with a different set of config options (CONFIG_LBD...), etc.
> > Thus we have to make sure we don't crash / corrupt data when seeing such
> > file (page offset of the last page needn't fit into pgoff_t). Firstly, we
> > make read() and mmap() return error when user tries to access the file
> > above s_maxbytes, secondly we introduce a function i_size_read_trunc() which
> > returns min(i_size, s_maxbytes) and use it when determining maximal page
> > offset we are interested in.
>
> To give folks some more background on another case of this problem: If two
> nodes in a [Ocfs2, and likely Gfs2] cluster have mounted the same file
> system and have different s_maxbytes, you could get into a similar situation
> during runtime if the node with the larger s_maxbytes extends a file past
> what the lesser node can read.
>
> Generally, what we (Ocfs2) needs is just that the node with the lower
> s_maxbytes cleanly errors out instead of panicing or corrupting when it
> tries to do some operation at an offset past what it can support.
>
> Disallowing access past s_maxbytes up in the vfs should save us from some
> number of fs specific i_size versus s_maxbytes comparisons. It also has the
> nice property that it should help the case which Jan outlined above.
>
>
> > diff --git a/fs/buffer.c b/fs/buffer.c
> > index 7249e01..3861118 100644
> > --- a/fs/buffer.c
> > +++ b/fs/buffer.c
> > @@ -1623,7 +1623,7 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
> >
> > BUG_ON(!PageLocked(page));
> >
> > - last_block = (i_size_read(inode) - 1) >> inode->i_blkbits;
> > + last_block = (i_size_read_trunc(inode) - 1) >> inode->i_blkbits;
> >
> > if (!page_has_buffers(page)) {
> > create_empty_buffers(page, blocksize,
>
> I'm curious - how can we get to __block_write_full_page() if this condition
> is caught in mkwrite and write? That said, I'm not against defensive coding
> :)
We could still write to some offset below s_maxbytes and when i_size
happens to be larger than s_maxbytes, we have to handle that gracefully
(i.e., not overflow last_block in this case). But maybe I'm missing
something...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
prev parent reply other threads:[~2007-12-18 23:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-18 15:25 [PATCH] [RFC] Handle i_size > s_maxbytes gracefully Jan Kara
2007-12-18 22:50 ` Mark Fasheh
2007-12-18 23:59 ` Jan Kara [this message]
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=20071218235929.GA3569@duck.suse.cz \
--to=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.fasheh@oracle.com \
/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