From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: s390 storage key inconsistency? [was Re: msync() behaviour broken for MS_ASYNC, revert patch?] From: "Stephen C. Tweedie" In-Reply-To: <20040401161949.GC25502@mail.shareable.org> References: <1080771361.1991.73.camel@sisko.scot.redhat.com> <1080776487.1991.113.camel@sisko.scot.redhat.com> <1080834032.2626.94.camel@sisko.scot.redhat.com> <20040401161949.GC25502@mail.shareable.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1080838581.2626.136.camel@sisko.scot.redhat.com> Mime-Version: 1.0 Date: 01 Apr 2004 17:56:22 +0100 Sender: owner-linux-mm@kvack.org Return-Path: To: Jamie Lokier , Linux on 390 Port Cc: Linus Torvalds , linux-mm , Andrew Morton , linux-kernel , Ulrich Drepper , Stephen Tweedie List-ID: Hi, On Thu, 2004-04-01 at 17:19, Jamie Lokier wrote: > Some documentation I'm looking at says MS_INVALIDATE updates the > mapped page to contain the current contents of the file. 2.6.4 seems > to do the reverse: update the file to contain the current content of > the mapped page. "man msync" agrees with the the latter. (I can't > look at SUS right now). btw, just looking at the filemap_sync_pte() code for MS_INVALIDATE, I noticed if (!PageReserved(page) && (ptep_clear_flush_dirty(vma, address, ptep) || page_test_and_clear_dirty(page))) set_page_dirty(page); I just happened to follow the function and noticed that on s390, page_test_and_clear_dirty() has the comment: * Test and clear dirty bit in storage key. * We can't clear the changed bit atomically. This is a potential * race against modification of the referenced bit. This function * should therefore only be called if it is not mapped in any * address space. but in this case the page is clearly mapped in the caller's address space, else we wouldn't have reached this. Is this a problem? --Stephen -- 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: aart@kvack.org