On Fri, Jul 14, 2023 at 02:26:44PM +0200, Carlos Maiolino wrote: > > > > > > @@ -3736,6 +3853,18 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) > > > ctx->noswap = true; > > > ctx->seen |= SHMEM_SEEN_NOSWAP; > > > break; > > > + case Opt_quota: > > > + ctx->seen |= SHMEM_SEEN_QUOTA; > > > + ctx->quota_types |= (QTYPE_MASK_USR | QTYPE_MASK_GRP); > > > + break; > > > + case Opt_usrquota: > > > + ctx->seen |= SHMEM_SEEN_QUOTA; > > > + ctx->quota_types |= QTYPE_MASK_USR; > > > + break; > > > + case Opt_grpquota: > > > + ctx->seen |= SHMEM_SEEN_QUOTA; > > > + ctx->quota_types |= QTYPE_MASK_GRP; > > > + break; > > > } > > > return 0; > > > > I mentioned this in an earlier review; following the sequence: > > > > if (ctx->seen & SHMEM_SEEN_QUOTA) > > -> shmem_enable_quotas() > > -> dquot_load_quota_sb() > > > > to then figure out that in dquot_load_quota_sb() we fail if > > sb->s_user_ns != &init_user_ns is too subtle for a filesystem that's > > mountable by unprivileged users. Every few months someone will end up > > stumbling upon this code and wonder where it's blocked. There isn't even > > a comment in the code. > > I was just going to rebase these updated changes on top of linux-next, and I > realized the patches are already there. Wouldn't it be better if I send a > follow-up patch on top of linux-next, applying these changes, as a Fixes: tag? I would just resend and fold the fix into the patch. There's no good reason to make this a separate patch imho.
