Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: ecryptfs-utils - Linux eCryptfs utilities https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218556 bugzilla@xxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|normal |medium kevin@xxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778, 177841 | nThis| | Flag| |fedora-review+ ------- Additional Comments From kevin@xxxxxxxxx 2007-04-18 23:32 EST ------- ok. I have done some testing here with the latest rawhide kernel and ecrypts-utils. - ppc32 works just fine. No oops. No issues. I can mount, read/write and unmount ok. - x86_64 works ok. There is a locking message when you first try and use the mount after mounting, but there is no ill effect. mount/read/write/umount all work ok. Here's the locking messages I see in dmesg: ============================================= [ INFO: possible recursive locking detected ] 2.6.20-1.3079.fc7 #1 --------------------------------------------- ls/23073 is trying to acquire lock: (&inode->i_mutex){--..}, at: [<ffffffff802622fe>] mutex_lock+0x2a/0x2e but task is already holding lock: (&inode->i_mutex){--..}, at: [<ffffffff802622fe>] mutex_lock+0x2a/0x2e other info that might help us debug this: 1 lock held by ls/23073: #0: (&inode->i_mutex){--..}, at: [<ffffffff802622fe>] mutex_lock+0x2a/0x2e stack backtrace: Call Trace: [<ffffffff802a2e62>] __lock_acquire+0x151/0xbd1 [<ffffffff883f2120>] :ecryptfs:ecryptfs_filldir+0x0/0x7d [<ffffffff802a3cd8>] lock_acquire+0x4c/0x65 [<ffffffff802622fe>] mutex_lock+0x2a/0x2e [<ffffffff8026213a>] __mutex_lock_slowpath+0xff/0x299 [<ffffffff802622bb>] __mutex_lock_slowpath+0x280/0x299 [<ffffffff802622fe>] mutex_lock+0x2a/0x2e [<ffffffff80235b75>] vfs_readdir+0x61/0xb1 [<ffffffff8022668a>] filldir+0x0/0xc5 [<ffffffff883f2384>] :ecryptfs:ecryptfs_readdir+0x6c/0xb2 [<ffffffff8022668a>] filldir+0x0/0xc5 [<ffffffff80235b90>] vfs_readdir+0x7c/0xb1 [<ffffffff80239340>] sys_getdents+0x7a/0xc4 [<ffffffff8025c11e>] system_call+0x7e/0x83 That looks like it's a cosmetic bug more than one that causes any real problems. So, since there are no more packaging issues, and things seem to work now, I will go ahead and APPROVE this package. Michael: You can continue the process at: http://fedoraproject.org/wiki/PackageMaintainers/Join#head-a601c13b0950a89568deafa65f505b4b58ee869b If you have any questions at all about the process, feel free to email me, or catch me on irc.freenode.net in #fedora-devel (nick: nirik). Oh, I see that -14 is out now. If you would like me to look over the updated package before you import it, I would be happy to do so. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review