| Message ID | 1421260031-3355-2-git-send-email-jack@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jan 14, 2015 at 07:27:08PM +0100, Jan Kara wrote: > Currently, v2 quota format blindly stored flags from in-memory dqinfo on > disk, although there are no flags supported. Since it is stupid to store > flags which have no effect, just store 0 unconditionally and don't > bother loading it from disk. > > Note that userspace could have stored some flags there via Q_SETINFO > quotactl and then later read them (although flags have no effect) but > I'm pretty sure noone does that (most definitely quota-tools don't and > quota interface doesn't have too much other users). What about future proofing? Current kernels can store flags on disk, so the best is to reserve the currently (and possibly previously) assigned values, and mask them out when reading from disk.
On Thu 15-01-15 01:40:34, Christoph Hellwig wrote: > On Wed, Jan 14, 2015 at 07:27:08PM +0100, Jan Kara wrote: > > Currently, v2 quota format blindly stored flags from in-memory dqinfo on > > disk, although there are no flags supported. Since it is stupid to store > > flags which have no effect, just store 0 unconditionally and don't > > bother loading it from disk. > > > > Note that userspace could have stored some flags there via Q_SETINFO > > quotactl and then later read them (although flags have no effect) but > > I'm pretty sure noone does that (most definitely quota-tools don't and > > quota interface doesn't have too much other users). > > What about future proofing? Current kernels can store flags on disk, > so the best is to reserve the currently (and possibly previously) > assigned values, and mask them out when reading from disk. Hum, I'm not sure I follow you. Current kernels will store any 32-bit number user sets in flags field. So if we wanted to be 100% safe, we'd have to just ignore that field. Which isn't currently a problem since quota code doesn't use the field for anything (it was added just for future extensions). But since I'm pretty certain noone actually relies on values of that field, I though we could just get away with forcibly zeroing the field now and if there's a need to use the field in a few years, we could start using it. Honza
On Thu, Jan 15, 2015 at 11:13:10AM +0100, Jan Kara wrote: > Hum, I'm not sure I follow you. Current kernels will store any 32-bit > number user sets in flags field. So if we wanted to be 100% safe, we'd have > to just ignore that field. Which isn't currently a problem since quota code > doesn't use the field for anything (it was added just for future > extensions). But since I'm pretty certain noone actually relies on values > of that field, I though we could just get away with forcibly zeroing the > field now and if there's a need to use the field in a few years, we could > start using it. Oh, I misread the code and your description. I thought we would just store any potentially valid in-core flag on disk. I guess for now the best case would be to stop storing anything, and then just make an educated decision if/when we need a flags field.
On Mon 19-01-15 01:14:32, Christoph Hellwig wrote: > On Thu, Jan 15, 2015 at 11:13:10AM +0100, Jan Kara wrote: > > Hum, I'm not sure I follow you. Current kernels will store any 32-bit > > number user sets in flags field. So if we wanted to be 100% safe, we'd have > > to just ignore that field. Which isn't currently a problem since quota code > > doesn't use the field for anything (it was added just for future > > extensions). But since I'm pretty certain noone actually relies on values > > of that field, I though we could just get away with forcibly zeroing the > > field now and if there's a need to use the field in a few years, we could > > start using it. > > Oh, I misread the code and your description. I thought we would just > store any potentially valid in-core flag on disk. > > I guess for now the best case would be to stop storing anything, and > then just make an educated decision if/when we need a flags field. Yes, that's what I do in the patch. So we are in agreement here. Honza
diff --git a/fs/quota/quota_v2.c b/fs/quota/quota_v2.c index 02751ec695c5..b291602e1193 100644 --- a/fs/quota/quota_v2.c +++ b/fs/quota/quota_v2.c @@ -126,7 +126,8 @@ static int v2_read_file_info(struct super_block *sb, int type) } info->dqi_bgrace = le32_to_cpu(dinfo.dqi_bgrace); info->dqi_igrace = le32_to_cpu(dinfo.dqi_igrace); - info->dqi_flags = le32_to_cpu(dinfo.dqi_flags); + /* No flags currently supported */ + info->dqi_flags = le32_to_cpu(0); qinfo->dqi_sb = sb; qinfo->dqi_type = type; qinfo->dqi_blocks = le32_to_cpu(dinfo.dqi_blocks); @@ -157,7 +158,8 @@ static int v2_write_file_info(struct super_block *sb, int type) info->dqi_flags &= ~DQF_INFO_DIRTY; dinfo.dqi_bgrace = cpu_to_le32(info->dqi_bgrace); dinfo.dqi_igrace = cpu_to_le32(info->dqi_igrace); - dinfo.dqi_flags = cpu_to_le32(info->dqi_flags & DQF_MASK); + /* No flags currently supported */ + dinfo.dqi_flags = 0; spin_unlock(&dq_data_lock); dinfo.dqi_blocks = cpu_to_le32(qinfo->dqi_blocks); dinfo.dqi_free_blk = cpu_to_le32(qinfo->dqi_free_blk);
Currently, v2 quota format blindly stored flags from in-memory dqinfo on disk, although there are no flags supported. Since it is stupid to store flags which have no effect, just store 0 unconditionally and don't bother loading it from disk. Note that userspace could have stored some flags there via Q_SETINFO quotactl and then later read them (although flags have no effect) but I'm pretty sure noone does that (most definitely quota-tools don't and quota interface doesn't have too much other users). Signed-off-by: Jan Kara <jack@suse.cz> --- fs/quota/quota_v2.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)