All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: adilger.kernel@dilger.ca, Maurizio Lombardi <mlombard@redhat.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] ext4: fix bug in ext4_mb_normalize_request()
Date: Thu, 6 Mar 2014 10:44:07 -0500	[thread overview]
Message-ID: <20140306154407.GA28226@thunk.org> (raw)
In-Reply-To: <1393855228-13592-3-git-send-email-mlombard@redhat.com>

On Mon, Mar 03, 2014 at 03:00:28PM +0100, Maurizio Lombardi wrote:
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 08ddfda..546575a 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -3059,6 +3059,21 @@ ext4_mb_normalize_request(struct ext4_allocation_context *ac,
>  		size	  = ac->ac_o_ex.fe_len << bsbits;
>  	}
>  	size = size >> bsbits;
> +
> +	/* In any case, the size cannot be greater than the number
> +	 * of maximum free blocks per group.
> +	 */
> +	if (size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb)) {
> +		int sz_log2;
> +
> +		size = EXT4_BLOCKS_PER_GROUP(ac->ac_sb);
> +
> +		/* Recalculate the start offset */
> +		sz_log2 = __fls(size << bsbits);
> +		start_off = ((loff_t) ac->ac_o_ex.fe_logical >>
> +					(sz_log2 - bsbits)) << sz_log2;
> +	}
> +
>  	start = start_off >> bsbits;
>  
>  	/* don't cover already allocated blocks in selected range */

This definitely fixes the bug.  However, there will be some cases
where if the blocks per group is sufficiently small, where for smaller
files, start_off would have been 0 instead of that complicated
expression.

Looking at ext4_mb_normalize_request(), exactly what this code is
trying to do is actually a bit opaque to me, and every time I look at
it I get a headache.

Andreas, can you take a look at this?  I think you may know this code
better --- and it's somewhere I've been waiting to do some cleanup, or
at least some improved code comments.

Thanks!!

					- Ted

  reply	other threads:[~2014-03-06 15:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-03 14:00 [PATCH 0/2] ext4: ext4_mb_normalize_request() fixes Maurizio Lombardi
2014-03-03 14:00 ` [PATCH 1/2] ext4: fix wrong assert in ext4_mb_normalize_request() Maurizio Lombardi
2014-05-26 16:42   ` Theodore Ts'o
2014-03-03 14:00 ` [PATCH 2/2] ext4: fix bug " Maurizio Lombardi
2014-03-06 15:44   ` Theodore Ts'o [this message]
2014-03-06 16:54     ` Maurizio Lombardi
2014-03-06 17:54       ` Lukáš Czerner
2014-03-06 18:32         ` Theodore Ts'o
2014-03-07 21:09           ` Andreas Dilger
2014-05-26 16:50         ` Theodore Ts'o
2014-06-03 18:43           ` Lukáš Czerner
2014-06-03 20:36             ` Theodore Ts'o
2014-06-06  7:09               ` Lukáš Czerner
2014-06-11  8:47               ` Maurizio Lombardi

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=20140306154407.GA28226@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mlombard@redhat.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 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.