Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp791639pxj; Thu, 13 May 2021 17:41:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWTRK2RLwrSwkk4In2q1VoUgnz52DYnCzNLaFV4jE08yzORirrolLBeKjRvVMqqMYQ9Tm1 X-Received: by 2002:a02:a88f:: with SMTP id l15mr41646670jam.86.1620952915021; Thu, 13 May 2021 17:41:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620952915; cv=none; d=google.com; s=arc-20160816; b=Oo049O7sRnXdXpc80R0W87Wbv/3DxP3nHRHpHpxEvCs+8HRczIsjrHETK7OGAK8pL7 L6dblMqVp7cJqv/VUSHvoiIFKB7QkQ8btNOv1SK9VhhAna7wJyYIgX9HzbudUj6oVF7k SzUHOZHg0FDOCC89SGSp1Qlq28WZpoPC+IJeW9VaZpQQEu0DBebuth4Z1McUh7DQs5Am xD2xh6xW58quy68FvqugwKPy2eaJ+BGN2ZtJJRl+t3rtR9rUVf1b9B2lEa7d5OY0CdPU 9hvr3u0ABedWGcpQDA3v7ivfCn+TpeJQ+eWWw3jQL16s0dHaIRHyMpmSq9uAaP5LgNAk Onug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=yzxQymELG0KeNbwYlS8mC1jmfQ1Yd8uZ3NkI7DScLXg=; b=V/i5w0HSLR0M7OwIlLSFLZShDbam6dxO3gQqRkZrP9tdEYuwCSDrP9jJU5QKucri7L GNfPH2D3XkvltVwPnmVMVEmASfV7cPe6utIEgkfVcVFeoNjZMXyAZly96+XzRk0lc1gF ExTrVVYoJOMPsto4wrBP6vcPHCC9mrMAEF8g4WF8Y+Wij6RLE7kOkoRp+Y0X+UahJZt6 XyFK+oc6timyIFY0wNSHZuLK6ihPZ+twblLUHy0izt07tw6Jdjw5Q3ZVJkNyUSRkcBYs EMzC3908vNaj0ggYdrgE8ZV2eoQ9freYdDv8wxUzE8RcsbEif/syNW8f4aLkn+QasLV2 9asg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n4si5362291jap.69.2021.05.13.17.41.40; Thu, 13 May 2021 17:41:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233266AbhEMVGe (ORCPT + 99 others); Thu, 13 May 2021 17:06:34 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:35257 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S233247AbhEMVGd (ORCPT ); Thu, 13 May 2021 17:06:33 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 14DL5Kp2004827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 13 May 2021 17:05:21 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id A0D3D15C3C45; Thu, 13 May 2021 17:05:20 -0400 (EDT) Date: Thu, 13 May 2021 17:05:20 -0400 From: "Theodore Ts'o" To: Leah Rumancik Cc: linux-ext4@vger.kernel.org Subject: Re: [PATCH v4 2/3] ext4: add ioctl EXT4_IOC_CHECKPOINT Message-ID: References: <20210511180428.3358267-1-leah.rumancik@gmail.com> <20210511180428.3358267-2-leah.rumancik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210511180428.3358267-2-leah.rumancik@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, May 11, 2021 at 06:04:27PM +0000, Leah Rumancik wrote: > +static int ext4_ioctl_checkpoint(struct file *filp, unsigned long arg) > +{ > + int err = 0; > + unsigned long long flags = 0; > + struct super_block *sb = file_inode(filp)->i_sb; > + > + if (copy_from_user(&flags, (__u64 __user *)arg, > + sizeof(__u64))) > + return -EFAULT; > + > + if (flags & EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN) > + return 0; We should document exactly what "Dry run" means. Right now, it looks like it's used so we can tell whether the ioctl is support at all. It might be better to do all of the checks first, so that if EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN is set, and the ioctl returns success, we know that all of the ioctl would succeed. This would allow us to use DRY_RUN to check to see if a future flag bit is supported. > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + > + /* file argument is not the mount point */ > + if (file_dentry(filp) != sb->s_root) > + return -EINVAL; I'm not sure we need to require that EXT4_IOC_CHECKPOINT has to be called with the mount point, especially given that only process with root privs will be allowed to call the ioctl. SoI'd suggest removing the check above, and allowing a file descriptor opened on any file or directory on the file system to be sufficient to trigger the ioctl. > + /* filesystem is not backed by block device */ > + if (sb->s_bdev == NULL) > + return -ENODEV; This should never be the case for ext4.... > + > + /* check for invalid bits set */ > + if (flags & ~(EXT4_IOC_CHECKPOINT_FLAG_DISCARD | > + EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT)) > + return -EINVAL; > + > + /* both discard and zeroout cannot be set */ > + if (flags & EXT4_IOC_CHECKPOINT_FLAG_DISCARD & > + EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT) > + return -EINVAL; This check isn't correct; see a similar comment that I made on patch #1 of this series. > + > + if (flags & EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT) > + pr_info_ratelimited("warning: checkpointing journal with EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT can be slow"); > + > + if (!EXT4_SB(sb)->s_journal) > + return -ENODEV; So this is where I would actually move the DRY_RUN flag check (and then I'd move the pr_info_ratelimited check after the DRY_RUN check). Cheers, - Ted