NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/46472: 5.1_STABLE/i386 panic after recent pull-ups



The following reply was made to PR kern/46472; it has been noted by GNATS.

From: buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow)
To: "J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>, 
gnats-bugs%NetBSD.org@localhost
Cc: jdbaker%mylinuxisp.com@localhost, buhrow%lothlorien.nfbcal.org@localhost
Subject: Re: kern/46472: 5.1_STABLE/i386 panic after recent pull-ups
Date: Mon, 21 May 2012 13:20:36 -0700

        hello.  I've been able to reproduce the panic on my test machine and
 can confirm that Hannken's patch fixes the problem.  Here's an explanation
 of what's going on.
        When patch patches a file, it creates a temporary file in /tmp and
 tries to link it with the file being patched.  (This is after it renames
 the original file to original.orig.)  If /tmp is on a different device from
 the file being patched, then rename will fail with EXDEV and patch will 
 copy the temporary file to the original file name and all will work as
 expected.  The missing goto caused rename to never return EXDEV, but rather
 to fall through the logic until the error was noticed at a critical moment
 and the panic ensued.  My guess is that the difference between the machine
 that worked and the one that didn't was that /tmp was on the same device as
 the source tree for the machine that worked  and /tmp was on a different
 device from the source tree on the machine that didn't.
        David is right that this was undoubtedly a merging error when I
 backported the original changes from -current.  I apologize for the error
 and am glad the fix is so simple.
        John, can you confirm that this patch fixes things for you?
 If it does, we'll get the patch  committed.
 
 -thanks
 -Brian
 
 [For the curious, here is a partial trace of patch doing its work.]
 I created:
 foo
 bar
 Rand:
 diff -u foo bar > foo.diff
 Then:
 patch < foo.diff
 (My /tmp is on a different device than the test filesystem I used for this
 test.)
 
 ... begin trace ...
 
    517      1 patch    CALL  rename(0xbb915098,0xbfbfe6d4)
    517      1 patch    NAMI  "foo"
    517      1 patch    NAMI  "foo.orig"
    517      1 patch    RET   rename 0
    517      1 patch    CALL  rename(0xbb903040,0xbb915098)
    517      1 patch    NAMI  "/tmp/patcho00000517aa"
    517      1 patch    NAMI  "foo"
    517      1 patch    RET   rename -1 errno 18 Cross-device link
    517      1 patch    CALL  open(0xbb915098,0x601,0x1b6)
    517      1 patch    NAMI  "foo"
    517      1 patch    RET   open 4
    517      1 patch    CALL  open(0xbb903040,0,0)
    517      1 patch    NAMI  "/tmp/patcho00000517aa"
    517      1 patch    RET   open 6
 
 
 . . . end trace . . .
 
        Before the patch, that second rename would have caused a panic.
 
 -Brian
 


Home | Main Index | Thread Index | Old Index