From: "Anton Salikhmetov" <salikhmetov@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
peterz@infradead.org, linux-mm@kvack.org, jakob@unthought.net,
linux-kernel@vger.kernel.org, valdis.kletnieks@vt.edu,
riel@redhat.com, ksm@42.dk, staubach@redhat.com,
jesper.juhl@gmail.com, akpm@linux-foundation.org,
protasnb@gmail.com, r.e.wolff@bitwizard.nl,
hidave.darkstar@gmail.com, hch@infradead.org
Subject: Re: [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files
Date: Sat, 19 Jan 2008 01:04:50 +0300 [thread overview]
Message-ID: <4df4ef0c0801181404m186bb847sd556e031e908b0b6@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0801181325510.2957@woody.linux-foundation.org>
2008/1/19, Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Sat, 19 Jan 2008, Anton Salikhmetov wrote:
> >
> > Before using pte_wrprotect() the vma_wrprotect() routine uses the
> > pte_offset_map_lock() macro to get the PTE and to acquire the ptl
> > spinlock. Why did you say that this code was not SMP-safe? It should
> > be atomic, I think.
>
> It's atomic WITH RESPECT TO OTHER PEOPLE WHO GET THE LOCK.
>
> Guess how much another x86 CPU cares when it sets the accessed bit in
> hardware?
Thank you very much for taking part in this discussion. Personally,
it's very important to me. But I'm not sure that I understand which
bit can be lost.
Please let me explain.
The logic for my vma_wrprotect() routine was taken from the
page_check_address() function in mm/rmap.c. Here is a code snippet of
the latter function:
pgd = pgd_offset(mm, address);
if (!pgd_present(*pgd))
return NULL;
pud = pud_offset(pgd, address);
if (!pud_present(*pud))
return NULL;
pmd = pmd_offset(pud, address);
if (!pmd_present(*pmd))
return NULL;
pte = pte_offset_map(pmd, address);
/* Make a quick check before getting the lock */
if (!pte_present(*pte)) {
pte_unmap(pte);
return NULL;
}
ptl = pte_lockptr(mm, pmd);
spin_lock(ptl);
if (pte_present(*pte) && page_to_pfn(page) == pte_pfn(*pte)) {
*ptlp = ptl;
return pte;
}
pte_unmap_unlock(pte, ptl);
The page_check_address() function is called from the
page_mkclean_one() routine as follows:
pte = page_check_address(page, mm, address, &ptl);
if (!pte)
goto out;
if (pte_dirty(*pte) || pte_write(*pte)) {
pte_t entry;
flush_cache_page(vma, address, pte_pfn(*pte));
entry = ptep_clear_flush(vma, address, pte);
entry = pte_wrprotect(entry);
entry = pte_mkclean(entry);
set_pte_at(mm, address, pte, entry);
ret = 1;
}
pte_unmap_unlock(pte, ptl);
The write-protection of the PTE is done using the pte_wrprotect()
entity. I intended to do the same during msync() with MS_ASYNC. I
understand that I'm taking a risk of looking a complete idiot now,
however I don't see any difference between the two situations.
I presumed that the code in mm/rmap.c was absolutely correct, that's
why I basically reused the design.
>
> > The POSIX standard requires the ctime and mtime stamps to be updated
> > not later than at the second call to msync() with the MS_ASYNC flag.
>
> .. and that is no excuse for bad code.
>
> Linus
>
--
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>
next prev parent reply other threads:[~2008-01-18 22:04 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 22:31 [PATCH -v6 0/2] Fixing the issue with memory-mapped file times Anton Salikhmetov
2008-01-17 22:31 ` [PATCH -v6 1/2] Massive code cleanup of sys_msync() Anton Salikhmetov
2008-01-18 9:33 ` Miklos Szeredi
2008-01-18 10:30 ` Anton Salikhmetov
2008-01-17 22:31 ` [PATCH -v6 2/2] Updating ctime and mtime for memory-mapped files Anton Salikhmetov
2008-01-18 9:51 ` Miklos Szeredi
2008-01-18 10:15 ` Peter Zijlstra
2008-01-18 10:25 ` Peter Zijlstra
2008-01-18 10:39 ` Anton Salikhmetov
2008-01-18 17:58 ` Linus Torvalds
2008-01-18 18:11 ` Miklos Szeredi
2008-01-18 18:28 ` Rik van Riel
2008-01-18 18:51 ` Miklos Szeredi
2008-01-18 18:43 ` Linus Torvalds
2008-01-18 18:57 ` Miklos Szeredi
2008-01-18 19:08 ` Linus Torvalds
2008-01-18 19:22 ` Miklos Szeredi
2008-01-18 19:35 ` Linus Torvalds
2008-01-18 19:58 ` Anton Salikhmetov
2008-01-18 20:22 ` Linus Torvalds
2008-01-18 21:03 ` Anton Salikhmetov
2008-01-18 21:27 ` Linus Torvalds
2008-01-18 22:04 ` Anton Salikhmetov [this message]
2008-01-18 22:21 ` Linus Torvalds
2008-01-18 22:35 ` Anton Salikhmetov
2008-01-18 22:32 ` Ingo Oeser
2008-01-18 22:47 ` Linus Torvalds
2008-01-18 22:54 ` Rik van Riel
2008-01-19 0:50 ` Matt Mackall
2008-01-19 4:25 ` Rik van Riel
2008-01-19 10:22 ` Miklos Szeredi
2008-01-19 15:49 ` Matt Mackall
2008-01-21 14:25 ` Peter Staubach
2008-01-21 14:36 ` Anton Salikhmetov
2008-01-18 10:38 ` Miklos Szeredi
2008-01-18 11:00 ` Peter Zijlstra
2008-01-18 11:17 ` Miklos Szeredi
2008-01-18 11:23 ` Peter Zijlstra
2008-01-18 11:36 ` Miklos Szeredi
2008-01-18 9:40 ` [PATCH -v6 0/2] Fixing the issue with memory-mapped file times Miklos Szeredi
2008-01-18 10:31 ` Anton Salikhmetov
2008-01-18 19:48 ` Anton Salikhmetov
2008-01-19 10:45 ` 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=4df4ef0c0801181404m186bb847sd556e031e908b0b6@mail.gmail.com \
--to=salikhmetov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=hidave.darkstar@gmail.com \
--cc=jakob@unthought.net \
--cc=jesper.juhl@gmail.com \
--cc=ksm@42.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=peterz@infradead.org \
--cc=protasnb@gmail.com \
--cc=r.e.wolff@bitwizard.nl \
--cc=riel@redhat.com \
--cc=staubach@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=valdis.kletnieks@vt.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox