All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, hugh@veritas.com,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] update ctime and mtime for mmaped write
Date: Thu, 22 Feb 2007 15:50:03 -0500	[thread overview]
Message-ID: <45DE01FB.2010204@redhat.com> (raw)
In-Reply-To: <E1HKKmn-0006iw-00@dorka.pomaz.szeredi.hu>

Miklos Szeredi wrote:
>>> Take this example:
>>>
>>>     fd = open()
>>>     addr = mmap(.., fd)
>>>     write(fd, ...)
>>>     close(fd)
>>>     sleep(100)
>>>     msync(addr,...)
>>>     munmap(addr)
>>>
>>> The file times will be updated in write(), but with your patch, the
>>> bit in the mapping will also be set.
>>>
>>> Then in msync() the file times will be updated again, which is wrong,
>>> since the memory was _not_ modified through the mapping.
>>>       
>> This is correct.  I have updated my proposed patch to include the clearing
>> of AS_MCTIME in the routine which updates the mtime field.
>>     
>
> That doesn't really help.  Look at __generic_file_aio_write_nolock().
> file_update_time() is called before the data is written, so after the
> last write, there will be nothing to clear the flag.
>
> And even if fixed this case by moving the file_update_time() call to
> the end of the function, there's no guarantee, that some filesystem
> won't do something exotic and call set_page_dirty() indenpendently of
> write().  Good luck auditing all the set_page_dirty() calls ;)

Interesting.

No, I wouldn't want to get into worrying about set_page_dirty() calls.
Life is short and people have too much imagination...  :-)

    Thanx...

       ps


WARNING: multiple messages have this Message-ID (diff)
From: Peter Staubach <staubach@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, hugh@veritas.com,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] update ctime and mtime for mmaped write
Date: Thu, 22 Feb 2007 15:50:03 -0500	[thread overview]
Message-ID: <45DE01FB.2010204@redhat.com> (raw)
In-Reply-To: <E1HKKmn-0006iw-00@dorka.pomaz.szeredi.hu>

Miklos Szeredi wrote:
>>> Take this example:
>>>
>>>     fd = open()
>>>     addr = mmap(.., fd)
>>>     write(fd, ...)
>>>     close(fd)
>>>     sleep(100)
>>>     msync(addr,...)
>>>     munmap(addr)
>>>
>>> The file times will be updated in write(), but with your patch, the
>>> bit in the mapping will also be set.
>>>
>>> Then in msync() the file times will be updated again, which is wrong,
>>> since the memory was _not_ modified through the mapping.
>>>       
>> This is correct.  I have updated my proposed patch to include the clearing
>> of AS_MCTIME in the routine which updates the mtime field.
>>     
>
> That doesn't really help.  Look at __generic_file_aio_write_nolock().
> file_update_time() is called before the data is written, so after the
> last write, there will be nothing to clear the flag.
>
> And even if fixed this case by moving the file_update_time() call to
> the end of the function, there's no guarantee, that some filesystem
> won't do something exotic and call set_page_dirty() indenpendently of
> write().  Good luck auditing all the set_page_dirty() calls ;)

Interesting.

No, I wouldn't want to get into worrying about set_page_dirty() calls.
Life is short and people have too much imagination...  :-)

    Thanx...

       ps

--
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>

  reply	other threads:[~2007-02-22 20:50 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-21 17:51 [PATCH] update ctime and mtime for mmaped write Miklos Szeredi
2007-02-21 17:51 ` Miklos Szeredi, Miklos Szeredi
2007-02-21 18:07 ` Peter Staubach
2007-02-21 18:07   ` Peter Staubach
2007-02-21 18:23   ` Miklos Szeredi
2007-02-21 18:23     ` Miklos Szeredi
2007-02-21 18:54     ` Peter Staubach
2007-02-21 18:54       ` Peter Staubach
2007-02-21 19:07       ` Miklos Szeredi
2007-02-21 19:07         ` Miklos Szeredi
2007-02-22 17:36         ` Peter Staubach
2007-02-22 17:36           ` Peter Staubach
2007-02-22 18:16           ` Miklos Szeredi
2007-02-22 18:16             ` Miklos Szeredi
2007-02-22 20:11             ` Peter Staubach
2007-02-22 20:11               ` Peter Staubach
2007-02-22 20:43               ` Miklos Szeredi
2007-02-22 20:43                 ` Miklos Szeredi
2007-02-22 20:50                 ` Peter Staubach [this message]
2007-02-22 20:50                   ` Peter Staubach
2007-02-21 18:12 ` Trond Myklebust
2007-02-21 18:12   ` Trond Myklebust
2007-02-21 18:28   ` Miklos Szeredi
2007-02-21 18:28     ` Miklos Szeredi
2007-02-21 18:36     ` Trond Myklebust
2007-02-21 18:36       ` Trond Myklebust
2007-02-21 18:50       ` Miklos Szeredi
2007-02-21 18:50         ` Miklos Szeredi
2007-02-21 18:50       ` Peter Staubach
2007-02-21 18:50         ` Peter Staubach
2007-02-22  4:26 ` Andrew Morton
2007-02-22  4:26   ` Andrew Morton
2007-02-22  7:49   ` Miklos Szeredi
2007-02-22  7:49     ` Miklos Szeredi
2007-02-22 17:39     ` Peter Staubach
2007-02-22 17:39       ` Peter Staubach
2007-02-22 18:08       ` Miklos Szeredi
2007-02-22 18:08         ` Miklos Szeredi
2007-02-22 20:14         ` Peter Staubach
2007-02-22 20:14           ` Peter Staubach
2007-02-22 20:48           ` Miklos Szeredi
2007-02-22 20:48             ` Miklos Szeredi
2007-02-22 20:55             ` Peter Staubach
2007-02-22 20:55               ` Peter Staubach
2007-02-22 21:04             ` Trond Myklebust
2007-02-22 21:04               ` Trond Myklebust
2007-02-22 21:28               ` Miklos Szeredi
2007-02-22 21:28                 ` Miklos Szeredi
2007-02-22 21:52                 ` Peter Staubach
2007-02-22 21:52                   ` Peter Staubach
2007-02-22 22:08                   ` Miklos Szeredi
2007-02-22 22:08                     ` Miklos Szeredi

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=45DE01FB.2010204@redhat.com \
    --to=staubach@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hugh@veritas.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    /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.