linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Li Wang <liwang@nudt.edu.cn>
Cc: ecryptfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Cong Wang <xiyou.wangcong@gmail.com>
Subject: Re: [PATCH] eCryptfs: infinite loop bug
Date: Thu, 19 Jan 2012 02:48:36 -0600	[thread overview]
Message-ID: <20120119084836.GA29477@boyd> (raw)
In-Reply-To: <12011909443668a7a65ff897afc93db177848236f08f@nudt.edu.cn>

[-- Attachment #1: Type: text/plain, Size: 3371 bytes --]

On 2012-01-19 09:44:36, Li Wang wrote:
> 
> 
> Hi,
>   Thanks Cong Wang for the kind reminding regarding the patch format.

The commit message still needs some work. But there's no need to drag
out the process for a fix like this, so I'll rewrite the commit message
and reply to this email with the cleaned up version. Let me know if you
have any problems with that. You'll still be credited as the author.

For future kernel patches, please see "15) The canonical patch format"
of Documentation/SubmittingPatches and "5.4: PATCH FORMATTING AND
CHANGELOGS" of Documentation/development-process/5.Posting for more
information on how the commit message should be written.

Also, your email came across in base64 encoding. I'm not sure of the
reason for that or how to fix it.

>   We did notice that the total_remaining_zeroes need be revised as well, 
> and the start_offset_in_page, num_bytes need not be revised (always smaller 

Yes, size_t will work fine, as Linus confirmed.

> than PAGE_CACHE_SIZE, even the huge page size is supported, 
> the 4G page size is not present in the current world?)
> but we forget to include the revision for total_remaining_zeroes, so here comes the patch.

I really appreciate the patch - thanks!

Tyler

> 
> Cheers,
> Li Wang
> 
> Signed-off-by: Li Wang <liwang@nudt.edu.cn>
>                Yunchuan Wen <wenyunchuan@kylinos.com.cn>
> 
> ---
> 
> --- a/fs/ecryptfs/read_write.c	2012-01-19 17:34:54.666940824 +0800
> +++ b/fs/ecryptfs/read_write.c	2012-01-19 17:35:16.257940840 +0800
> @@ -130,13 +130,13 @@ int ecryptfs_write(struct inode *ecryptf
>  		pgoff_t ecryptfs_page_idx = (pos >> PAGE_CACHE_SHIFT);
>  		size_t start_offset_in_page = (pos & ~PAGE_CACHE_MASK);
>  		size_t num_bytes = (PAGE_CACHE_SIZE - start_offset_in_page);
> -		size_t total_remaining_bytes = ((offset + size) - pos);
> +		loff_t total_remaining_bytes = ((offset + size) - pos);
>  
>  		if (num_bytes > total_remaining_bytes)
>  			num_bytes = total_remaining_bytes;
>  		if (pos < offset) {
>  			/* remaining zeros to write, up to destination offset */
> -			size_t total_remaining_zeros = (offset - pos);
> +			loff_t total_remaining_zeros = (offset - pos);
>  
>  			if (num_bytes > total_remaining_zeros)
>  				num_bytes = total_remaining_zeros;
> 
> 
> 
> 
> 
> ---------- Origin message ----------
> >From:"Tyler Hicks" <tyhicks@canonical.com>
> >To:"Cong Wang" <xiyou.wangcong@gmail.com>
> >Subject:Re: [PATCH] eCryptfs: infinite loop bug
> >Date:2012-01-19 05:40:51
> 
> On 2012-01-18 23:26:52, Cong Wang wrote:
> > On 01/18/2012 03:30 PM, Li Wang wrote:
> > >Hi,
> > > There is an infinite loop bug in eCryptfs, to make it present,
> > >just truncate to generate a huge file (>= 4G) on a 32-bit machine
> > >under the plain text foleder mounted with eCryptfs, a simple command
> > >'truncate -s 4G dummy' is enough. Note: 4GB is smaller than 4G,
> > >therefore the following command 'truncate -s 4GB dummy' will not trigger this bug.
> > >The bug comes from a data overflow, the patch below fixes it.
> > >
> > >
> >
> > Hi,
> >
> > Your patch is not correctly generated, you need to make the diff on
> > top of the source tree.
> >
> > Also, after reviewing the code, I think there are more places need
> > to fix. Can you try my patch below?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-01-19  8:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-18  7:30 [PATCH] eCryptfs: infinite loop bug Li Wang
2012-01-18 15:26 ` Cong Wang
2012-01-18 21:40   ` Tyler Hicks
2012-01-19  3:43     ` Linus Torvalds
     [not found]   ` <526922120.05125@eyou.net>
2012-01-19  1:44     ` Li Wang
2012-01-19  8:48       ` Tyler Hicks [this message]
2012-01-19 14:03         ` Dustin Kirkland
2012-01-19 15:08           ` Tyler Hicks
2012-01-19  9:13       ` [PATCH] eCryptfs: infinite loop due to overflow in ecryptfs_write() Tyler Hicks
2012-01-19 15:09         ` Cong Wang
     [not found] <7f1e961d.f528.134efaf8348.Coremail.dragonylffly@163.com>
2012-01-18 20:49 ` [PATCH] eCryptfs: infinite loop bug Linus Torvalds
2012-01-18 21:04   ` Tyler Hicks
2012-01-19 16:17   ` Dustin Kirkland

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=20120119084836.GA29477@boyd \
    --to=tyhicks@canonical.com \
    --cc=ecryptfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwang@nudt.edu.cn \
    --cc=xiyou.wangcong@gmail.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;
as well as URLs for NNTP newsgroup(s).