Re: Fw: Re: [PATCH] 2.6.16-rc-mm4 reiser4 calls try_to_unmap() with 1 arg -- now takes 2

Re: Fw: Re: [PATCH] 2.6.16-rc-mm4 reiser4 calls try_to_unmap() with 1 arg -- now takes 2

[Hans Reiser]

Umm, no, copy on capture needs to get enabled again as soon as we get
past issues outsiders care about, and start dealing again with improving
the code in the ways we think matter.  There are real problems that are
addressed by copy on capture.  That it has not been worked on since
2.6.5 just sadly indicates how successful folks have been in distracting
us for so long.

vs, open a bug report in bugzilla for copy on capture, and after we get
merged please make copy on capture work. 

Hans

Andrew Morton wrote:

>Hugh's right - quite worrying..
>
>Begin forwarded message:
>
>Date: Thu, 2 Feb 2006 20:46:07 +0000 (GMT)
>From: Hugh Dickins <hugh@veritas.com>
>To: Lee Schermerhorn <lee.schermerhorn@hp.com>
>Cc: linux-kernel <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org
>Subject: Re: [PATCH] 2.6.16-rc-mm4 reiser4 calls try_to_unmap() with 1 arg -- now takes 2
>
>
>On Thu, 2 Feb 2006, Lee Schermerhorn wrote:
>
>  
>
>>Apparent race between reiser4 and direct migration patches in 16-rc1-
>>mm4.
>>Direct migration added arg to rmap.c:try_to_unmap()--int ignore_refs--
>>and
>>fixed up existing refs.  reiser4 adds new call with single arg. 
>>
>>One doesn't see this when building mm4 w/ reiser4 because the ref under
>>an
>>"#if REISER4_COPY_ON_CAPTURE" that is apparently not enabled.  I  just
>>noticed
>>it while looking at direct migration patches.  So, this patch is
>>essentially
>>UNTESTED.  Supplied simply to illustrate the location of the single arg
>>    
>>
>
>That's worrying code to find down in a filesystem.  But never mind,
>it refers to pte_chain_lock(), which hasn't existed since 2.6.5.  So
>REISER4_COPY_ON_CAPTURE is long untested and should just be deleted.
>
>Hugh
>
>  
>
>>Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
>>
>>Index: linux-2.6.16-rc1-mm4/fs/reiser4/txnmgr.c
>>===================================================================
>>--- linux-2.6.16-rc1-mm4.orig/fs/reiser4/txnmgr.c	2006-01-31
>>16:51:39.000000000 -0500
>>+++ linux-2.6.16-rc1-mm4/fs/reiser4/txnmgr.c	2006-02-02
>>14:43:01.659744418 -0500
>>@@ -3693,7 +3693,7 @@ static int create_copy_and_replace(jnode
>> 		pte_chain_lock(page);
>> 
>> 		if (page_mapped(page)) {
>>-			result = try_to_unmap(page);
>>+			result = try_to_unmap(page, 0);
>> 			if (result == SWAP_AGAIN) {
>> 				result = RETERR(-E_REPEAT);
>>    
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>
>  
>

Re: Fw: Re: [PATCH] 2.6.16-rc-mm4 reiser4 calls try_to_unmap() with 1 arg -- now takes 2

[Andrew Morton]

Hans Reiser <reiser@namesys.com> wrote:
>
> Umm, no, copy on capture needs to get enabled again as soon as we get
>  past issues outsiders care about, and start dealing again with improving
>  the code in the ways we think matter.  There are real problems that are
>  addressed by copy on capture.  That it has not been worked on since
>  2.6.5 just sadly indicates how successful folks have been in distracting
>  us for so long.

Dinking with rmap internals from within a filesystem is a real problem. 
Whatever needs to be done there should be done within core MM if it's done
anywhere so it actually gets maintained by the people who are likely to
break it.

Something like
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/broken-out/add-page-becoming-writable-notification.patch
might be what you're after.

Re: Fw: Re: [PATCH] 2.6.16-rc-mm4 reiser4 calls try_to_unmap() with 1 arg -- now takes 2

[Hans Reiser]

Andrew Morton wrote:

>Hans Reiser <reiser@namesys.com> wrote:
>  
>
>>Umm, no, copy on capture needs to get enabled again as soon as we get
>> past issues outsiders care about, and start dealing again with improving
>> the code in the ways we think matter.  There are real problems that are
>> addressed by copy on capture.  That it has not been worked on since
>> 2.6.5 just sadly indicates how successful folks have been in distracting
>> us for so long.
>>    
>>
>
>Dinking with rmap internals from within a filesystem is a real problem. 
>Whatever needs to be done there should be done within core MM if it's done
>anywhere so it actually gets maintained by the people who are likely to
>break it.
>
>Something like
>http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/broken-out/add-page-becoming-writable-notification.patch
>might be what you're after.
>
>
>
>  
>
I don't actually care (at least I desire that I not have to care ;-) )
about the implementation of copy-on-capture so long as it works.  I am
sure vs will be happy to do it within core mm when we get to where he
can pay attention to it again.