| Message ID | 20230609125023.399942-1-jlayton@kernel.org |
|---|---|
| Headers | show |
| Series | fs: add some missing ctime updates | expand |
On Fri, Jun 09, 2023 at 08:50:16AM -0400, Jeff Layton wrote:
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
Sorry, but I can't take commits without any changelog text at all (nor
would you want me to...)
thanks,
greg k-h
On Fri, Jun 09, 2023 at 08:50:14AM -0400, Jeff Layton wrote: > While working on a patch series to change how we handle the ctime, I > found a number of places that update the mtime without a corresponding > ctime update. POSIX requires that when the mtime is updated that the > ctime also be updated. > > Note that these are largely untested other than for compilation, so > please review carefully. These are a preliminary set for the upcoming > rework of how we handle the ctime. > > None of these seem to be very crucial, but it would be nice if > various maintainers could pick these up for v6.5. Please let me know if > you do. > > Jeff Layton (9): > ibmvmc: update ctime in conjunction with mtime on write > usb: update the ctime as well when updating mtime after an ioctl > autofs: set ctime as well when mtime changes on a dir > bfs: update ctime in addition to mtime when adding entries > efivarfs: update ctime when mtime changes on a write > exfat: ensure that ctime is updated whenever the mtime is > gfs2: update ctime when quota is updated > apparmor: update ctime whenever the mtime changes on an inode > cifs: update the ctime on a partial page write > > drivers/misc/ibmvmc.c | 2 +- > drivers/usb/core/devio.c | 16 ++++++++-------- > fs/autofs/root.c | 6 +++--- > fs/bfs/dir.c | 2 +- > fs/efivarfs/file.c | 2 +- > fs/exfat/namei.c | 8 ++++---- > fs/gfs2/quota.c | 2 +- > fs/smb/client/file.c | 2 +- > security/apparmor/apparmorfs.c | 7 +++++-- > security/apparmor/policy_unpack.c | 11 +++++++---- > 10 files changed, 32 insertions(+), 26 deletions(-) > > -- > 2.40.1 > All of these need commit log messages, didn't checkpatch warn you about that? thanks, greg k-h
On Fri, 2023-06-09 at 15:10 +0200, Greg Kroah-Hartman wrote: > On Fri, Jun 09, 2023 at 08:50:14AM -0400, Jeff Layton wrote: > > While working on a patch series to change how we handle the ctime, I > > found a number of places that update the mtime without a corresponding > > ctime update. POSIX requires that when the mtime is updated that the > > ctime also be updated. > > > > Note that these are largely untested other than for compilation, so > > please review carefully. These are a preliminary set for the upcoming > > rework of how we handle the ctime. > > > > None of these seem to be very crucial, but it would be nice if > > various maintainers could pick these up for v6.5. Please let me know if > > you do. > > > > Jeff Layton (9): > > ibmvmc: update ctime in conjunction with mtime on write > > usb: update the ctime as well when updating mtime after an ioctl > > autofs: set ctime as well when mtime changes on a dir > > bfs: update ctime in addition to mtime when adding entries > > efivarfs: update ctime when mtime changes on a write > > exfat: ensure that ctime is updated whenever the mtime is > > gfs2: update ctime when quota is updated > > apparmor: update ctime whenever the mtime changes on an inode > > cifs: update the ctime on a partial page write > > > > drivers/misc/ibmvmc.c | 2 +- > > drivers/usb/core/devio.c | 16 ++++++++-------- > > fs/autofs/root.c | 6 +++--- > > fs/bfs/dir.c | 2 +- > > fs/efivarfs/file.c | 2 +- > > fs/exfat/namei.c | 8 ++++---- > > fs/gfs2/quota.c | 2 +- > > fs/smb/client/file.c | 2 +- > > security/apparmor/apparmorfs.c | 7 +++++-- > > security/apparmor/policy_unpack.c | 11 +++++++---- > > 10 files changed, 32 insertions(+), 26 deletions(-) > > > > -- > > 2.40.1 > > > > All of these need commit log messages, didn't checkpatch warn you about > that? It did, once I ran it. ;) I'll repost the set with more elaborate changelogs.
Jeff, On Fri, Jun 9, 2023 at 2:50 PM Jeff Layton <jlayton@kernel.org> wrote: > Signed-off-by: Jeff Layton <jlayton@kernel.org> > --- > fs/gfs2/quota.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c > index 1ed17226d9ed..6d283e071b90 100644 > --- a/fs/gfs2/quota.c > +++ b/fs/gfs2/quota.c > @@ -869,7 +869,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, > size = loc + sizeof(struct gfs2_quota); > if (size > inode->i_size) > i_size_write(inode, size); > - inode->i_mtime = inode->i_atime = current_time(inode); > + inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); I don't think we need to worry about the ctime of the quota inode as that inode is internal to the filesystem only. > mark_inode_dirty(inode); > set_bit(QDF_REFRESH, &qd->qd_flags); > } > -- > 2.40.1 > Thanks, Andreas
On Fri, 2023-06-09 at 18:44 +0200, Andreas Gruenbacher wrote: > Jeff, > > On Fri, Jun 9, 2023 at 2:50 PM Jeff Layton <jlayton@kernel.org> wrote: > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > > --- > > fs/gfs2/quota.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c > > index 1ed17226d9ed..6d283e071b90 100644 > > --- a/fs/gfs2/quota.c > > +++ b/fs/gfs2/quota.c > > @@ -869,7 +869,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, > > size = loc + sizeof(struct gfs2_quota); > > if (size > inode->i_size) > > i_size_write(inode, size); > > - inode->i_mtime = inode->i_atime = current_time(inode); > > + inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); > > I don't think we need to worry about the ctime of the quota inode as > that inode is internal to the filesystem only. > Thanks Andreas. I'll plan to drop this patch from the series for now. Does updating the mtime and atime here serve any purpose, or should those also be removed? If you plan to keep the a/mtime updates then I'd still suggest updating the ctime for consistency's sake. It shouldn't cost anything extra to do so since you're dirtying the inode below anyway. Thanks! > > mark_inode_dirty(inode); > > set_bit(QDF_REFRESH, &qd->qd_flags); > > } > > -- > > 2.40.1 > > > > Thanks, > Andreas >
On Mon, Jun 12, 2023 at 12:36 PM Jeff Layton <jlayton@kernel.org> wrote: > On Fri, 2023-06-09 at 18:44 +0200, Andreas Gruenbacher wrote: > > Jeff, > > > > On Fri, Jun 9, 2023 at 2:50 PM Jeff Layton <jlayton@kernel.org> wrote: > > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > > > --- > > > fs/gfs2/quota.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c > > > index 1ed17226d9ed..6d283e071b90 100644 > > > --- a/fs/gfs2/quota.c > > > +++ b/fs/gfs2/quota.c > > > @@ -869,7 +869,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, > > > size = loc + sizeof(struct gfs2_quota); > > > if (size > inode->i_size) > > > i_size_write(inode, size); > > > - inode->i_mtime = inode->i_atime = current_time(inode); > > > + inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); > > > > I don't think we need to worry about the ctime of the quota inode as > > that inode is internal to the filesystem only. > > > > Thanks Andreas. I'll plan to drop this patch from the series for now. > > Does updating the mtime and atime here serve any purpose, or should > those also be removed? If you plan to keep the a/mtime updates then I'd > still suggest updating the ctime for consistency's sake. It shouldn't > cost anything extra to do so since you're dirtying the inode below > anyway. Yes, good point actually, we should keep things consistent for simplicity. Would you add this back in if you do another posting? Thanks, Andreas > Thanks! > > > > mark_inode_dirty(inode); > > > set_bit(QDF_REFRESH, &qd->qd_flags); > > > } > > > -- > > > 2.40.1 > > > > > > > Thanks, > > Andreas > > > > -- > Jeff Layton <jlayton@kernel.org> >
On Wed, 2023-07-05 at 22:25 +0200, Andreas Gruenbacher wrote: > On Mon, Jun 12, 2023 at 12:36 PM Jeff Layton <jlayton@kernel.org> wrote: > > On Fri, 2023-06-09 at 18:44 +0200, Andreas Gruenbacher wrote: > > > Jeff, > > > > > > On Fri, Jun 9, 2023 at 2:50 PM Jeff Layton <jlayton@kernel.org> wrote: > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > > > > --- > > > > fs/gfs2/quota.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c > > > > index 1ed17226d9ed..6d283e071b90 100644 > > > > --- a/fs/gfs2/quota.c > > > > +++ b/fs/gfs2/quota.c > > > > @@ -869,7 +869,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, > > > > size = loc + sizeof(struct gfs2_quota); > > > > if (size > inode->i_size) > > > > i_size_write(inode, size); > > > > - inode->i_mtime = inode->i_atime = current_time(inode); > > > > + inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); > > > > > > I don't think we need to worry about the ctime of the quota inode as > > > that inode is internal to the filesystem only. > > > > > > > Thanks Andreas. I'll plan to drop this patch from the series for now. > > > > Does updating the mtime and atime here serve any purpose, or should > > those also be removed? If you plan to keep the a/mtime updates then I'd > > still suggest updating the ctime for consistency's sake. It shouldn't > > cost anything extra to do so since you're dirtying the inode below > > anyway. > > Yes, good point actually, we should keep things consistent for simplicity. > > Would you add this back in if you do another posting? > I just re-posted the other patches in this as part of the ctime accessor conversion. If I post again though, I can resurrect the gfs2 patch. If not, we can do a follow-on fix later. Since we're discussing it, it may be more correct to remove the atime update there. gfs2_adjust_quota sounds like a "modify" operation, not a "read", so I don't see a reason to update the atime. In general, the only time you only want to set the atime, ctime and mtime in lockstep is when the inode is brand new.
Am Mi., 5. Juli 2023 um 23:51 Uhr schrieb Jeff Layton <jlayton@kernel.org>: > > On Wed, 2023-07-05 at 22:25 +0200, Andreas Gruenbacher wrote: > > On Mon, Jun 12, 2023 at 12:36 PM Jeff Layton <jlayton@kernel.org> wrote: > > > On Fri, 2023-06-09 at 18:44 +0200, Andreas Gruenbacher wrote: > > > > Jeff, > > > > > > > > On Fri, Jun 9, 2023 at 2:50 PM Jeff Layton <jlayton@kernel.org> wrote: > > > > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > > > > > --- > > > > > fs/gfs2/quota.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c > > > > > index 1ed17226d9ed..6d283e071b90 100644 > > > > > --- a/fs/gfs2/quota.c > > > > > +++ b/fs/gfs2/quota.c > > > > > @@ -869,7 +869,7 @@ static int gfs2_adjust_quota(struct gfs2_inode *ip, loff_t loc, > > > > > size = loc + sizeof(struct gfs2_quota); > > > > > if (size > inode->i_size) > > > > > i_size_write(inode, size); > > > > > - inode->i_mtime = inode->i_atime = current_time(inode); > > > > > + inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); > > > > > > > > I don't think we need to worry about the ctime of the quota inode as > > > > that inode is internal to the filesystem only. > > > > > > > > > > Thanks Andreas. I'll plan to drop this patch from the series for now. > > > > > > Does updating the mtime and atime here serve any purpose, or should > > > those also be removed? If you plan to keep the a/mtime updates then I'd > > > still suggest updating the ctime for consistency's sake. It shouldn't > > > cost anything extra to do so since you're dirtying the inode below > > > anyway. > > > > Yes, good point actually, we should keep things consistent for simplicity. > > > > Would you add this back in if you do another posting? > > > > I just re-posted the other patches in this as part of the ctime accessor > conversion. If I post again though, I can resurrect the gfs2 patch. If > not, we can do a follow-on fix later. Sure, not a big deal. > Since we're discussing it, it may be more correct to remove the atime > update there. gfs2_adjust_quota sounds like a "modify" operation, not a > "read", so I don't see a reason to update the atime. > > In general, the only time you only want to set the atime, ctime and > mtime in lockstep is when the inode is brand new. Yes, that makes sense, too. Thanks, Andreas