cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
* [Cluster-devel] [PATCH GFS2] gfs2_stuffed_write_end modifying source buffer?
       [not found] <652851863.523171253742277925.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
@ 2009-09-23 21:48 ` Bob Peterson
  2009-10-01 12:41   ` [Cluster-devel] " Steven Whitehouse
  0 siblings, 1 reply; 2+ messages in thread
From: Bob Peterson @ 2009-09-23 21:48 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi,

Maybe I'm wrong, but this looks like a bug to me: It looks like
GFS2's function gfs2_stuffed_write_end is zeroing out portions
of the source buffer.  So if I create a character array and
filled it with "X" then wrote only one byte to a very
small file, all the other X's in my buffer would get nuked.
Just a theory at this point but perhaps Steve Whitehouse can tell.

Regards,

Bob Peterson
Red Hat File Systems
--
 fs/gfs2/aops.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/fs/gfs2/aops.c b/fs/gfs2/aops.c
index 7ebae9a..6a23ba2 100644
--- a/fs/gfs2/aops.c
+++ b/fs/gfs2/aops.c
@@ -801,7 +801,6 @@ static int gfs2_stuffed_write_end(struct inode *inode, struct buffer_head *dibh,
 	BUG_ON((pos + len) > (dibh->b_size - sizeof(struct gfs2_dinode)));
 	kaddr = kmap_atomic(page, KM_USER0);
 	memcpy(buf + pos, kaddr + pos, copied);
-	memset(kaddr + pos + copied, 0, len - copied);
 	flush_dcache_page(page);
 	kunmap_atomic(kaddr, KM_USER0);
 



^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [Cluster-devel] Re: [PATCH GFS2] gfs2_stuffed_write_end modifying source buffer?
  2009-09-23 21:48 ` [Cluster-devel] [PATCH GFS2] gfs2_stuffed_write_end modifying source buffer? Bob Peterson
@ 2009-10-01 12:41   ` Steven Whitehouse
  0 siblings, 0 replies; 2+ messages in thread
From: Steven Whitehouse @ 2009-10-01 12:41 UTC (permalink / raw)
  To: cluster-devel.redhat.com

Hi,

I'm not convinced there is a bug here...

On Wed, 2009-09-23 at 17:48 -0400, Bob Peterson wrote:
> Hi,
> 
> Maybe I'm wrong, but this looks like a bug to me: It looks like
> GFS2's function gfs2_stuffed_write_end is zeroing out portions
> of the source buffer.  So if I create a character array and
> filled it with "X" then wrote only one byte to a very
> small file, all the other X's in my buffer would get nuked.
> Just a theory at this point but perhaps Steve Whitehouse can tell.
> 
> Regards,
> 
> Bob Peterson
> Red Hat File Systems
> --
>  fs/gfs2/aops.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/gfs2/aops.c b/fs/gfs2/aops.c
> index 7ebae9a..6a23ba2 100644
> --- a/fs/gfs2/aops.c
> +++ b/fs/gfs2/aops.c
> @@ -801,7 +801,6 @@ static int gfs2_stuffed_write_end(struct inode *inode, struct buffer_head *dibh,
>  	BUG_ON((pos + len) > (dibh->b_size - sizeof(struct gfs2_dinode)));
>  	kaddr = kmap_atomic(page, KM_USER0);
>  	memcpy(buf + pos, kaddr + pos, copied);
> -	memset(kaddr + pos + copied, 0, len - copied);
pos is the current file offset (which since its stuffed is also a byte
offset into this (first) page of the file)
copied is the number of bytes that were copied
len is the number of bytes that we wanted to copy (so for a successful
copy, its equal to copied and thus the memset() is a no-op

>  	flush_dcache_page(page);
>  	kunmap_atomic(kaddr, KM_USER0);
>  
The purpose of that memset() is to deal with the situation where the
copy has failed part way though (source page inaccessible) and thus we
couldn't complete the operation. If the write was not an extending
write, we cannot truncate off the bit which wasn't copied, so it gets
zeroed out instead.

Steve.




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-10-01 12:41 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <652851863.523171253742277925.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com>
2009-09-23 21:48 ` [Cluster-devel] [PATCH GFS2] gfs2_stuffed_write_end modifying source buffer? Bob Peterson
2009-10-01 12:41   ` [Cluster-devel] " Steven Whitehouse

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).