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@xxxxxxxxxxx>
> Yunchuan Wen <wenyunchuan@xxxxxxxxxxxxxx>
>
> ---
>
> --- 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@xxxxxxxxxxxxx>
> >To："Cong Wang" <xiyou.wangcong@xxxxxxxxx>
> >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:
signature.asc
Description: Digital signature
