On Thu, Mar 26 2009, Chris Mason wrote: > On Thu, 2009-03-26 at 15:39 +0100, Jens Axboe wrote: > > On Thu, Mar 26 2009, Dan Carpenter wrote: > > > kzalloc() already initialized ->error to zero. > > > > > > regards, > > > dan carpenter > > > > > > Signed-off-by: Dan Carpenter <[email protected]> > > > > > > --- orig/fs/btrfs/volumes.c 2009-03-26 17:14:13.000000000 +0300 > > > +++ devel/fs/btrfs/volumes.c 2009-03-26 17:14:55.000000000 +0300 > > > @@ -2422,10 +2422,8 @@ > > > multi = kzalloc(btrfs_multi_bio_size(stripes_allocated), > > > GFP_NOFS); > > > if (!multi) > > > return -ENOMEM; > > > - > > > - atomic_set(&multi->error, 0); > > > } > > > > > > spin_lock(&em_tree->lock); > > > em = lookup_extent_mapping(em_tree, logical, *length); > > > > Careful, some archs require a barrier there. It's dangerous to makes > > assumptions about the underlying implementation of such things, I'd > > leave that one alone. > > > Yeah, I'm not so much worried about the barrier as I am that assuming a > memset can init an atomic in general.
Right, it was more a generic comment. As to the memset(), if someone decided to add a magic to atomic_t or something for debug purposes, it would break. That's the bigger problem here :-) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
