linux-kernel - Re: [patch 01/22] update ctime and mtime for mmaped write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1HMSy2-0008F6-00@dorka.pomaz.szeredi.hu>
Date:	Wed, 28 Feb 2007 18:51:54 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	staubach@...hat.com
CC:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [patch 01/22] update ctime and mtime for mmaped write

> While these entry points do not actually modify the file itself,
> as was pointed out, they are handy points at which the kernel gains
> control and could actually notice that the contents of the file are
> no longer the same as they were, ie. modified.
> 
>  From the operating system viewpoint, this is where the semantics of
> modification to file contents via mmap differs from the semantics of
> modification to file contents via write(2).
> 
> It is desirable for the file times to be updated as quickly as
> possible after the actual modification has occurred.

I disagree.

You don't worry about the timestamp being updated _during_ a large
write() call, even though the file is constantly being modified.

You think of write() as something instantaneous, while you think of
writing to a shared mapping, then doing msync() as something taking a
long time.  In actual fact both of these are basically equivalent
operations, the differences being, that you can easily modify
non-contiguous parts of a file with mmap, while you can't do that with
write.  The disadvantage from mmap comes from the cost of setting up
the page tables and handling the faults.

Think of it this way:

  shared mmap write + msync(MS_ASYNC)  ==  write()
  msync(MS_ASYNC) + fsync()  ==  msync(MS_SYNC)

> A better design for all of this would be to update the file times
> and mark the inode as needing to be written out when a page fault
> is taken for a page which either does not exist or needs to be made
> writable and that page is part of an appropriate style mapping.

I think this would just be a waste of CPU.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/