On Mon 13-05-13 12:04:23, Jan Kara wrote: > On Fri 10-05-13 17:24:33, Cong Wang wrote: > > From: Cong Wang <amwang@xxxxxxxxxx> > > > > There is a hole in struct fs_quota_stat, so we have to > > zero the struct on stack before copying it to user-space. > > > > Cc: Jan Kara <jack@xxxxxxx> > > Signed-off-by: Cong Wang <amwang@xxxxxxxxxx> > Good point. I've merged the patch. Ah, now I've noticed that XFS (the only user of the callback you are fixing) is zeroing the structure on its own (xfs_qm_scall_getqstat). So there's no real problem. I'm somewhat wondering whether clearing the field in the place where you did it isn't more future-proof but usually we don't pass in prezeroed buffers so I've decided to leave things as they are. Honza > BTW for XFS folks: The structure definition looks somewhat odd (unaligned > definition of qs_flags, qs_uquota starts only at 32-bit boundary although > it has 64-bit fields in it) and I wouldn't be surprised if it needed compat > wrapper for 32-bit apps on some architectures... > > Honza > > > > --- > > diff --git a/fs/quota/quota.c b/fs/quota/quota.c > > index c7314f1..2b0c182 100644 > > --- a/fs/quota/quota.c > > +++ b/fs/quota/quota.c > > @@ -211,6 +211,7 @@ static int quota_getxstate(struct super_block *sb, void __user *addr) > > > > if (!sb->s_qcop->get_xstate) > > return -ENOSYS; > > + memset(&fqs, 0, sizeof(fqs)); > > ret = sb->s_qcop->get_xstate(sb, &fqs); > > if (!ret && copy_to_user(addr, &fqs, sizeof(fqs))) > > return -EFAULT; > -- > Jan Kara <jack@xxxxxxx> > SUSE Labs, CR -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
