From: Jan Kara <jack@suse.cz>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2 2/3] mm: Update file times when inodes are written after mmaped writes
Date: Thu, 3 Jan 2013 19:56:42 +0100 [thread overview]
Message-ID: <20130103185642.GA5699@quack.suse.cz> (raw)
In-Reply-To: <CALCETrUXVQooGt+10zDzK1HLoEOPc+1KH41mFewjxMjjUPNvMA@mail.gmail.com>
On Thu 03-01-13 09:49:37, Andy Lutomirski wrote:
> On Mon, Dec 31, 2012 at 8:11 AM, Jan Kara <jack@suse.cz> wrote:
> > On Sat 22-12-12 00:43:30, Andy Lutomirski wrote:
> >> On Sat, Dec 22, 2012 at 12:29 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >> > NAK, we went through great trouble to get rid of the nasty layering
> >> > violation where the VM called file_update_time directly just a short
> >> > while ago, reintroducing that is a massive step back.
> >> >
[...]
> >With the call from
> > remove_vma() it is more problematic (and the calling context there is
> > harder as well because we hold mmap_sem). We could maybe leave the call
> > upto filesystem's ->release callback (and provide generic ->release handler
> > which just calls mapping_flush_cmtime()). It won't be perfect because that
> > gets called only after the last file descriptor for that struct file is
> > closed (i.e., if a process forks and child inherits mappings, ->release gets
> > called only after both parent and the child unmap the file) but it should
> > catch 99% of the real world cases. Christoph, would the be OK with
> > you?
>
> I'm not sure that 99% is good enough -- I'd be nervous about breaking
> some build or versioning system.
>
> vm_ops->close is almost a good place for this, except that it's called
> on some failure paths and it will mess up is_mergeable_vma if lots of
> filesystems suddenly have a ->close operation. What about adding
> vm_ops->flush, which would be called in remove_vma and possibly
> msync(MS_ASYNC)? I think that all real filesystems (i.e. things that
> care about cmtime updates) have vm_operations.
Yeah, that could work. I'm still somewhat nervous about updating the time
stamp under mmap_sem but in ->page_mkwrite we were in the same situation so
I guess it's fine.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@infradead.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2 2/3] mm: Update file times when inodes are written after mmaped writes
Date: Thu, 3 Jan 2013 19:56:42 +0100 [thread overview]
Message-ID: <20130103185642.GA5699@quack.suse.cz> (raw)
In-Reply-To: <CALCETrUXVQooGt+10zDzK1HLoEOPc+1KH41mFewjxMjjUPNvMA@mail.gmail.com>
On Thu 03-01-13 09:49:37, Andy Lutomirski wrote:
> On Mon, Dec 31, 2012 at 8:11 AM, Jan Kara <jack@suse.cz> wrote:
> > On Sat 22-12-12 00:43:30, Andy Lutomirski wrote:
> >> On Sat, Dec 22, 2012 at 12:29 AM, Christoph Hellwig <hch@infradead.org> wrote:
> >> > NAK, we went through great trouble to get rid of the nasty layering
> >> > violation where the VM called file_update_time directly just a short
> >> > while ago, reintroducing that is a massive step back.
> >> >
[...]
> >With the call from
> > remove_vma() it is more problematic (and the calling context there is
> > harder as well because we hold mmap_sem). We could maybe leave the call
> > upto filesystem's ->release callback (and provide generic ->release handler
> > which just calls mapping_flush_cmtime()). It won't be perfect because that
> > gets called only after the last file descriptor for that struct file is
> > closed (i.e., if a process forks and child inherits mappings, ->release gets
> > called only after both parent and the child unmap the file) but it should
> > catch 99% of the real world cases. Christoph, would the be OK with
> > you?
>
> I'm not sure that 99% is good enough -- I'd be nervous about breaking
> some build or versioning system.
>
> vm_ops->close is almost a good place for this, except that it's called
> on some failure paths and it will mess up is_mergeable_vma if lots of
> filesystems suddenly have a ->close operation. What about adding
> vm_ops->flush, which would be called in remove_vma and possibly
> msync(MS_ASYNC)? I think that all real filesystems (i.e. things that
> care about cmtime updates) have vm_operations.
Yeah, that could work. I'm still somewhat nervous about updating the time
stamp under mmap_sem but in ->page_mkwrite we were in the same situation so
I guess it's fine.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2013-01-03 18:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 21:28 [PATCH v2 0/3] Rework mtime and ctime updates on mmaped writes Andy Lutomirski
2012-12-21 21:28 ` Andy Lutomirski
2012-12-21 21:28 ` [PATCH v2 1/3] mm: Explicitly track when the page dirty bit is transferred from a pte Andy Lutomirski
2012-12-21 21:28 ` Andy Lutomirski
2012-12-21 21:28 ` [PATCH v2 2/3] mm: Update file times when inodes are written after mmaped writes Andy Lutomirski
2012-12-21 21:28 ` Andy Lutomirski
2012-12-22 8:29 ` Christoph Hellwig
2012-12-22 8:29 ` Christoph Hellwig
2012-12-22 8:43 ` Andy Lutomirski
2012-12-22 8:43 ` Andy Lutomirski
2012-12-31 16:11 ` Jan Kara
2012-12-31 16:11 ` Jan Kara
2013-01-03 17:49 ` Andy Lutomirski
2013-01-03 17:49 ` Andy Lutomirski
2013-01-03 18:56 ` Jan Kara [this message]
2013-01-03 18:56 ` Jan Kara
2012-12-24 8:36 ` Zheng Liu
2012-12-24 8:36 ` Zheng Liu
2012-12-21 21:28 ` [PATCH v2 3/3] Remove file_update_time from all mkwrite paths Andy Lutomirski
2012-12-21 21:28 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130103185642.GA5699@quack.suse.cz \
--to=jack@suse.cz \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.