Michael,
I tried your latest version, but my laptop freezes up as soon as I try
to write data into a file in the upper file system.
This procedure causes the freeze:
---------------------------------------
rm -rf $HOME/{a,b}
mkdir -p $HOME/{a,b}
mount -t ecryptfs /home/stefan/{a,b} \
-o cipher=aes,ecryptfs_key_bytes=32
cat << EOF > /home/stefan/b/testfile.txt
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
123456789-123456789-123456789-123456789-123456789-
EOF
-----------------------------------------
What is the best method to capture what is going wrong at the time of
the crash
Michael Halcrow wrote the following on 09/08/2007 04:10 PM:
On Sat, Sep 08, 2007 at 01:20:17PM -0700, Stefan Farestam wrote:
[drm] writeback test succeeded in 2 usecs
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
...
EIP: 0060:[<00000000>] Tainted: P VLI
You have a proprietary kernel module loaded (some Cisco IPSEC
thing). This may or may not have much to do with the problem you are
experiencing in your filesystem, but, in general, you will not get
much attention from the upstream folks (or most distro's) unless you
are running an untainted kernel.
EIP is at _stext+0x3feff000/0x14
...
Call Trace:
[<c013bf4c>] read_cache_page+0x83/0x120
[<f9b68bd7>] ecryptfs_do_readpage+0x36/0xce [ecryptfs]
...
Code: Bad EIP value.
EIP: [<00000000>] _stext+0x3feff000/0x14 SS:ESP 0068:f50ffdfc
I know that there are others out there running eCryptfs over their
home directories without any problems (or, at least, none that have
bothered to tell me if there was a problem). Try kernel version
2.6.22.6 from kernel.org, and do not load any proprietary kernel
modules. If you are still seeing this problem, give the newest
experimental version of eCryptfs (well, keep in mind that even the
upstream kernel module is still tagged ``EXPERIMENTAL'') that I just
released yesterday a try on your 2.6.21 kernel:
http://downloads.sourceforge.net/ecryptfs/ecryptfs-20070907.tar.bz2
I completely overhauled the I/O routines with the lower filesystem,
and this particular problem may simply go away for you. For instance,
the function ``ecryptfs_do_readpage'' does not even exist any more in
my new code base. The good thing about this is that the code to handle
I/O with the lower files is much less complex, and eCryptfs should no
longer blow up on the upcoming release of NFS (which doesn't implement
prepare_write() and commit_write() any more). Given the magnitude of
this change, I would bet that some other exotic problem will pop up
when you try to run it on your home directory, but if you have the
time and energy to try it out, I am curious to know how it works for
you. If you are even more adventurous, try to narrow down exactly
which application is causing the oops.
In the meantime, I will go ahead and install a copy of Feisty to see
if I can reproduce any of the bugs that you have experienced. It looks
like Trevor was able to reproduce the Apache bug, so it should be
interesting to see how Apache is managing to get to the lower file
address space.
Thanks,
Mike
--
Stefan Farestam
Mobile: +46 70 649 6838
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
eCryptfs-users mailing list
eCryptfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecryptfs-users
