From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1063C433F5 for ; Fri, 22 Apr 2022 01:40:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233182AbiDVBnN (ORCPT ); Thu, 21 Apr 2022 21:43:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39034 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232628AbiDVBnL (ORCPT ); Thu, 21 Apr 2022 21:43:11 -0400 Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 77CB11572C for ; Thu, 21 Apr 2022 18:40:20 -0700 (PDT) Received: from dread.disaster.area (pa49-181-115-138.pa.nsw.optusnet.com.au [49.181.115.138]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id CD7F610E5CA3; Fri, 22 Apr 2022 11:40:18 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1nhiHR-002zy2-38; Fri, 22 Apr 2022 11:40:17 +1000 Date: Fri, 22 Apr 2022 11:40:17 +1000 From: Dave Chinner To: Catherine Hoang Cc: linux-xfs@vger.kernel.org Subject: Re: [RFC PATCH v1 2/2] xfs: don't set warns on the id==0 dquot Message-ID: <20220422014017.GV1544202@dread.disaster.area> References: <20220421165815.87837-1-catherine.hoang@oracle.com> <20220421165815.87837-3-catherine.hoang@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220421165815.87837-3-catherine.hoang@oracle.com> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.4 cv=e9dl9Yl/ c=1 sm=1 tr=0 ts=62620782 a=/kVtbFzwtM2bJgxRVb+eeA==:117 a=/kVtbFzwtM2bJgxRVb+eeA==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=yPCof4ZbAAAA:8 a=7-415B0cAAAA:8 a=LMSRPKizwMK2ZEMeBN8A:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Thu, Apr 21, 2022 at 09:58:15AM -0700, Catherine Hoang wrote: > Quotas are not enforced on the id==0 dquot, so the quota code uses it > to store warning limits and timeouts. Having just dropped support for > warning limits, this field no longer has any meaning. Return -EINVAL > for this dquot id if the fieldmask has any of the QC_*_WARNS set. > > Signed-off-by: Catherine Hoang > --- > fs/xfs/xfs_qm_syscalls.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/fs/xfs/xfs_qm_syscalls.c b/fs/xfs/xfs_qm_syscalls.c > index e7f3ac60ebd9..bdbd5c83b08e 100644 > --- a/fs/xfs/xfs_qm_syscalls.c > +++ b/fs/xfs/xfs_qm_syscalls.c > @@ -290,6 +290,8 @@ xfs_qm_scall_setqlim( > return -EINVAL; > if ((newlim->d_fieldmask & XFS_QC_MASK) == 0) > return 0; > + if ((newlim->d_fieldmask & QC_WARNS_MASK) && id == 0) > + return -EINVAL; Why would we do this for only id == 0? This will still allow non-zero warning values to be written to dquots that have id != 0, but I'm not sure why we'd allow this given that the previous patch just removed all the warning limit checking? Which then makes me ask: why are we still reading the warning counts from on disk dquots and writing in-memory values back to dquots? Shouldn't xfs_dquot_to_disk() just write zeros to the warning fields now, and xfs_dquot_from_disk() elide reading the warning counts altogether? i.e. can we remove d_bwarns, d_iwarns and d_rtbwarns from the struct fs_disk_quota altogether now? Which then raises the question of whether copy_from_xfs_dqblk() and friends should still support warn counts up in fs/quota/quota.c...? Cheers, Dave. -- Dave Chinner david@fromorbit.com