All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org, marvin24@gmx.de, zooko@leastauthority.com
Subject: Re: [PATCH v3] btrfs-progs: fix page align issue for lzo compress in restore
Date: Mon, 22 Sep 2014 15:41:15 +0200	[thread overview]
Message-ID: <20140922134115.GP9715@twin.jikos.cz> (raw)
In-Reply-To: <1411376306-10228-1-git-send-email-guihc.fnst@cn.fujitsu.com>

On Mon, Sep 22, 2014 at 04:58:26PM +0800, Gui Hecheng wrote:
> So we check page alignment every time before we are going to
> fetch the next @len and after the former piece of data is decompressed.
> If the current page that we reach has less than 4 bytes left,
> then we should fetch the next @len at the start of next page.

Thanks for the fix.

> --- a/cmds-restore.c
> +++ b/cmds-restore.c
> @@ -57,6 +57,9 @@ static int dry_run = 0;
>  
>  #define LZO_LEN 4
>  #define PAGE_CACHE_SIZE 4096
> +#define PAGE_CACHE_MASK (~(PAGE_CACHE_SIZE - 1))
> +#define PAGE_CACHE_ALIGN(addr) (((addr) + PAGE_CACHE_SIZE - 1)	\
> +							& PAGE_CACHE_MASK)

This is not type-safe, the PAGE_CACHE_SIZE should be unsigned long.

>  #define lzo1x_worst_compress(x) ((x) + ((x) / 16) + 64 + 3)
>  
>  static int decompress_zlib(char *inbuf, char *outbuf, u64 compress_len,
> @@ -93,6 +96,28 @@ static inline size_t read_compress_length(unsigned char *buf)
>  	return le32_to_cpu(dlen);
>  }
>  
> +static void align_if_need(size_t *tot_in, size_t *in_len)
> +{
> +	int tot_in_aligned;
> +	int bytes_left;
> +
> +	tot_in_aligned = PAGE_CACHE_ALIGN(*tot_in);

size_t -> int, plus other tricks that happen inside the macro

> +	bytes_left = tot_in_aligned - *tot_in;

int = int - size_t

> +
> +	if (bytes_left >= LZO_LEN)
> +		return;
> +
> +	/*
> +	 * The LZO_LEN bytes is guaranteed to be
> +	 * in one page as a whole, so if a page
> +	 * has fewer than LZO_LEN bytes left,
> +	 * the LZO_LEN bytes should be fetched
> +	 * at the start of the next page
> +	 */

Nitpick, the comment can use the whole width of the line

	/*
	 * The LZO_LEN bytes is guaranteed to be in one page as a whole,
	 * so if a page has fewer than LZO_LEN bytes left, the LZO_LEN
	 * bytes should be fetched at the start of the next page
	 */

> +	*in_len += bytes_left;
> +	*tot_in = tot_in_aligned;
> +}

  reply	other threads:[~2014-09-22 13:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-22  8:58 [PATCH v3] btrfs-progs: fix page align issue for lzo compress in restore Gui Hecheng
2014-09-22 13:41 ` David Sterba [this message]
2014-09-23  1:26   ` Gui Hecheng
2014-09-23  2:25   ` [PATCH v4] " Gui Hecheng
2014-09-23  8:25     ` Gui Hecheng
2014-09-23  8:34   ` Gui Hecheng
2014-10-14  8:06     ` Marc Dietrich
2014-10-14  9:32       ` David Sterba
2014-11-27  3:02         ` Gui Hecheng
2015-01-02 15:09           ` David Sterba

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=20140922134115.GP9715@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=guihc.fnst@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marvin24@gmx.de \
    --cc=zooko@leastauthority.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.