linux-kernel - Re: plain 2.6.21-rc5 (1) vs amanda (0)

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: <2c0942db0704010033r61f967c3y7d05e3ec0a9f6931@mail.gmail.com>
Date:	Sun, 1 Apr 2007 00:33:02 -0700
From:	"Ray Lee" <madrabbit@...il.com>
To:	"Gene Heskett" <gene.heskett@...izon.net>
Cc:	"Ingo Molnar" <mingo@...e.hu>, amanda-hackers@...nda.org,
	linux-kernel@...r.kernel.org, amanda-users@...nda.org
Subject: Re: plain 2.6.21-rc5 (1) vs amanda (0)

On 3/31/07, Gene Heskett <gene.heskett@...izon.net> wrote:
> This effect I have isolated down to something in the 31 patches from
> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in
> setting up the bisect to find it.  If indeed its a kernel problem.

First, set up a *small* test case, for your own sanity as well as
ours. (Set up a new backup job that does just part of your home
directory, for example. No, even better, just one file.) Then verify
that the small test case also fails the same was that you noticed your
big one does between 2.6.20.3 and 2.6.20.4.

Then, download everything in http://madrabbit.org/~ray/2.6.20.4 . That
has all the patches that Greg has in git, but your git is ancient so
let's just use the patches, hmm? It also has a control file (called
'series') that lists the order they should be applied in. Save
everything to the root of your 2.6.20.3 source tree. It'll be messy,
but it'll make things easier.

Once you have that, then go and apply the first half of the patches. (As in:
   head -n 16 series | xargs -n 1 patch -p1
at the base of the tree.

Compile and install that kernel, run your test case to see if the
problem is there. If it *is*, cut it in half again (Revert those 16
patches by adding a -R to the patch command (at the very end), then
redo the above command with an 8 instead of a 16.) If the problem
isn't there, cut the range [16,31] in half, giving you a 24 for the
next trial. Then repeat. Make sense?

Ray
-
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/