On Sun, Sep 09, 2007 at 03:14:17PM -0700, Stefan Farestam wrote: > 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.
Just as a word of warning: this experimental release has no backwards compatibility for now; this segment of the Documentation/ecryptfs.txt documentation file in the kernel source is in full force: --- NOTES In the beta/experimental releases of eCryptfs, when you upgrade eCryptfs, you should copy the files to an unencrypted location and then copy the files back into the new eCryptfs mount to migrate the files. --- So far, I have run tests on the 20070907 ecryptfs-kernel release on 2.6.16.21 with reiserfs and gpfs as the lower filesystems in SLES 10 and on 2.6.21.7 with ext3 as the lower filesystems in RHEL 5 without any problems. I am building a Feisty test system at the moment. > What is the best method to capture what is going wrong at the time > of the crash I assume that nothing is getting out from your system logger. If that is the case, you will need to invasively debug the eCryptfs kernel module on your system. If you are interested in debugging this, I have found a virtual machine with snaphot/revert capability to be the most efficient approach. VMWare is a no-cost option that I have found works well, but there is also KVM, if you happen to have hardware that supports it. I will typically go through a cycle of: add printk's/tweak code, build, snapshot, insmod, mount, test, read the oops and/or printk's in the log, revert, add printk's/tweak code, build, etc. Using that technique, I can usually track down and fix problems faster than I would with anything like kgdb. For this particular issue, you have to follow the execution path from the point of the syscall that is failing (probably ecryptfs_create() or ecryptfs_open() in this case). Mike > 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
pgpNKJRGensYb.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
