[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100708095156.GB23392@mail.oracle.com>
Date: Thu, 8 Jul 2010 02:51:56 -0700
From: Joel Becker <Joel.Becker@...cle.com>
To: Tao Ma <tao.ma@...cle.com>
Cc: Dave Chinner <david@...morbit.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
ocfs2-devel@....oracle.com, Dave Chinner <dchinner@...hat.com>,
Christoph Hellwig <hch@....de>, Mark Fasheh <mfasheh@...e.com>
Subject: Re: [PATCH 1/3] ocfs2: When zero extending, do it by page.
On Thu, Jul 08, 2010 at 11:44:59AM +0800, Tao Ma wrote:
> On 07/07/2010 07:16 PM, Joel Becker wrote:
> >+ BUG_ON(abs_to> ((index + 1)<< PAGE_CACHE_SHIFT));
> Sorry for not noticing this yesterday night. This can't work and
> will overflow and bug out. I met with a similar bug in reflink test.
> See commit d622b89.
Good catch. It's obvious, now that you mention it.
> >+ /* We know that zero_from is block aligned */
> >+ for (block_start = zero_from;
> >+ (block_start< PAGE_CACHE_SIZE)&& (block_start< zero_to);
> >+ block_start = block_end) {
> Do we really need to check block_start < PAGE_CACHE_SIZE? I think
> just check block_start < zero_to is enough since you have limit
> zero_to with PAGE_CACHE_SIZE. What's more, it looks more natural(see
> below), does it?
>
> for (block_start = zero_form; block_start < zero_to; block_start =
> block_end) {
Yup. The code looked different halfway through, so I didn't
realize I was checking the same thing twice.
Joel
--
"Depend on the rabbit's foot if you will, but remember, it didn't
help the rabbit."
- R. E. Shay
Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists