From: Oleg Drokin <green@linuxhacker.ru>
To: akpm@osdl.org
Cc: aia21@cantab.net, blaisorblade@yahoo.it, dhowells@redhat.com,
dwmw2@infradead.org, hch@lst.de, jdike@addtoit.com,
linux-fsdevel@vger.kernel.org, miklos@szeredi.hu,
neilb@cse.unsw.edu.au, reiserfs-dev@namesys.com,
rmk@arm.linux.org.uk, trond.myklebust@fys.uio.no,
zippel@linux-m68k.org, mm-commits@vger.kernel.org
Subject: Re: + fix-possible-page_cache_shift-overflows.patch added to -mm tree
Date: Thu, 24 Nov 2005 13:24:30 +0200 [thread overview]
Message-ID: <20051124112430.GM5297@linuxhacker.ru> (raw)
In-Reply-To: <200511232121.jANLLo7J024428@shell0.pdx.osdl.net>
Hello!
On Wed, Nov 23, 2005 at 01:22:16PM -0800, akpm@osdl.org wrote:
> - reiserfs map_block_for_writepage() takes an unsigned long for the block -
> it should take sector_t. (It'll fail for huge filesystems with
> blocksize<PAGE_CACHE_SIZE)
reiserfs is almost never used with blocksize other than 4k (And support
for block size smaller than 4k appeared only around 3 years ago).
And the only supported architectures that have PAGE_CACHE_SIZE bigger
than 4k are 64bit ones, so they are safe still.
Also sector_t is not very suitable for the job, because it is still 32 bit
with common config settings (no large block devices support).
So before proposing, even cosmetic, patch here, I want to understand - do we
allow files to be bigger than (u64)((sector_t)-1)*fs_block_size?
If we do, then we are in trouble even with sector_t. (And I do not see
what would prevent us to have a file that is bigger than 4T on ext2 with
512 byte blocksize, for example).
Also thanks to Andrews, I now see another overflow in reiserfs that should
lead to data corruptions with files that are bigger than 4G under certain
circumstances when using mmap.
In map_block_for_writepage():
loff_t byte_offset = (block << inode->i_sb->s_blocksize_bits) + 1;
Please consider patch below:
--- linux-2.6.14/fs/reiserfs/inode.c.orig 2005-11-24 13:26:26.000000000 +0200
+++ linux-2.6.14/fs/reiserfs/inode.c 2005-11-24 13:28:35.000000000 +0200
@@ -2194,7 +2194,7 @@ static int map_block_for_writepage(struc
INITIALIZE_PATH(path);
int pos_in_item;
int jbegin_count = JOURNAL_PER_BALANCE_CNT;
- loff_t byte_offset = (block << inode->i_sb->s_blocksize_bits) + 1;
+ loff_t byte_offset = ((loff_t)block << inode->i_sb->s_blocksize_bits)+1;
int retval;
int use_get_block = 0;
int bytes_copied = 0;
Bye,
Oleg
next prev parent reply other threads:[~2005-11-24 11:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-23 21:22 + fix-possible-page_cache_shift-overflows.patch added to -mm tree akpm
2005-11-23 22:01 ` ntfs - was: " Anton Altaparmakov
2005-11-24 1:00 ` Blaisorblade
2005-11-24 1:09 ` Andrew Morton
2005-11-24 1:37 ` Blaisorblade
2005-11-24 10:02 ` Christoph Hellwig
2005-11-24 7:05 ` Miklos Szeredi
2005-11-24 7:46 ` David Woodhouse
2005-11-24 11:24 ` Oleg Drokin [this message]
2005-11-26 0:54 ` Hans Reiser
2005-11-24 21:08 ` Roman Zippel
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=20051124112430.GM5297@linuxhacker.ru \
--to=green@linuxhacker.ru \
--cc=aia21@cantab.net \
--cc=akpm@osdl.org \
--cc=blaisorblade@yahoo.it \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=hch@lst.de \
--cc=jdike@addtoit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mm-commits@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=reiserfs-dev@namesys.com \
--cc=rmk@arm.linux.org.uk \
--cc=trond.myklebust@fys.uio.no \
--cc=zippel@linux-m68k.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;
as well as URLs for NNTP newsgroup(s).