W dniu 6 sierpnia 2011 14:41 użytkownik Michał Piotrowski <mkkp4x4@xxxxxxxxx> napisał: > W dniu 12 lipca 2011 22:45 użytkownik Michał Piotrowski > <mkkp4x4@xxxxxxxxx> napisał: >> I tested it, but it still corrupts data. On Thursday I'll do more >> tests. > > Sorry for the nearly month delay :) > > Today I tried to copy a file over samba to my encrypted dir and > operation still fails. > > When I tried to copy a file from other dir on the same machine to my > encrypted dir I get this oops This oops is apparently related to the lack of space on this partition. I must admit that this is an interesting way to show ENOSPC :) > > [41829.771957] ecryptfs_encrypt_page: Error attempting to write lower > page; rc = [-28] > [41829.772174] ecryptfs_writepage: Error encrypting page (upper index > [0x000000000003598f]) > [41829.772602] ------------[ cut here ]------------ > [41829.772701] kernel BUG at fs/ecryptfs/read_write.c:47! > [41829.772789] invalid opcode: 0000 [#1] SMP > [41829.772881] CPU 0 > [41829.772888] Modules linked in: ecryptfs smsc47m192 hwmon_vid > smsc47m1 coretemp serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support > r8169 mii sata_sil i915 drm_kms_helper drm i2c_algo_bit i2c_core video > [last unloaded: scsi_wait_scan] > [41829.773371] > [41829.773381] Pid: 10839, comm: flush-ecryptfs- Not tainted > 2.6.40-4.fc15.x86_64 #1 /D945GCLF2 > [41829.773381] RIP: 0010:[<ffffffffa013a218>] [<ffffffffa013a218>] > ecryptfs_write_lower+0x26/0x7d [ecryptfs] > [41829.773381] RSP: 0018:ffff88007b2059e0 EFLAGS: 00010246 > [41829.773381] RAX: 0000000000035990 RBX: ffff880079f14400 RCX: 0000000000001000 > [41829.773381] RDX: 0000000000001000 RSI: ffff880079e98000 RDI: ffff880079f14400 > [41829.773381] RBP: ffff88007b205a10 R08: 0000000000001000 R09: ffff88007b205990 > [41829.773381] R10: ffff880079c3b888 R11: ffff880079e98ff0 R12: 0000000000000000 > [41829.773381] R13: ffffea0001aab140 R14: ffffea0000829250 R15: ffff880079f14688 > [41829.773381] FS: 0000000000000000(0000) GS:ffff88007f200000(0000) > knlGS:0000000000000000 > [41829.773381] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > [41829.773381] CR2: 00007f52ddb57000 CR3: 0000000037a06000 CR4: 00000000000006f0 > [41829.773381] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [41829.773381] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [41829.773381] Process flush-ecryptfs- (pid: 10839, threadinfo > ffff88007b204000, task ffff88007b865cc0) > [41829.773381] Stack: > [41829.773381] ffff88007b2059f0 0000000035992000 0000000000000000 > ffff880079f14400 > [41829.773381] 0000000000000000 ffffea0001aab140 ffff88007b205a60 > ffffffffa013b5a1 > [41829.773381] ffffea0000829288 ffff880079e98000 ffff88007b205a80 > ffffea0000829250 > [41829.773381] Call Trace: > [41829.773381] [<ffffffffa013b5a1>] ecryptfs_encrypt_page+0xeb/0x151 [ecryptfs] > [41829.773381] [<ffffffffa0139b72>] ecryptfs_writepage+0x36/0x78 [ecryptfs] > [41829.773381] [<ffffffff810e353d>] __writepage+0x15/0x2e > [41829.773381] [<ffffffff810e3363>] write_cache_pages+0x203/0x33f > [41829.773381] [<ffffffff810e3528>] ? set_page_dirty_lock+0x33/0x33 > [41829.773381] [<ffffffff810e34df>] generic_writepages+0x40/0x56 > [41829.773381] [<ffffffff810e4066>] do_writepages+0x28/0x2a > [41829.773381] [<ffffffff8114488d>] writeback_single_inode+0xb2/0x1bc > [41829.773381] [<ffffffff81144bdc>] writeback_sb_inodes+0xcd/0x161 > [41829.773381] [<ffffffff81144fac>] writeback_inodes_wb+0x119/0x12b > [41829.773381] [<ffffffff811451a3>] wb_writeback+0x1e5/0x356 > [41829.773381] [<ffffffff810e391c>] ? global_dirty_limits+0x2b/0xd1 > [41829.773381] [<ffffffff8114548a>] wb_do_writeback+0x176/0x1a9 > [41829.773381] [<ffffffff814b6ffa>] ? _raw_spin_lock_irqsave+0x12/0x2f > [41829.773381] [<ffffffff81145538>] bdi_writeback_thread+0x7b/0x1f8 > [41829.773381] [<ffffffff811454bd>] ? wb_do_writeback+0x1a9/0x1a9 > [41829.773381] [<ffffffff8106fd0b>] kthread+0x84/0x8c > [41829.773381] [<ffffffff814be8e4>] kernel_thread_helper+0x4/0x10 > [41829.773381] [<ffffffff8106fc87>] ? kthread_worker_fn+0x148/0x148 > [41829.773381] [<ffffffff814be8e0>] ? gs_change+0x13/0x13 > [41829.773381] Code: 01 d8 5b 5d c3 55 48 89 e5 41 55 41 54 53 48 83 > ec 18 66 66 66 66 90 48 83 bf 80 02 00 00 00 48 89 55 d8 48 89 fb 48 > 89 ca 75 02 <0f> 0b 65 4c 8b 24 25 48 cd 00 00 4d 8b ac 24 48 e0 ff ff > 49 c7 > [41829.773381] RIP [<ffffffffa013a218>] > ecryptfs_write_lower+0x26/0x7d [ecryptfs] > [41829.773381] RSP <ffff88007b2059e0> > [41829.778779] ---[ end trace 32ff51ffa8acda79 ]--- > > I'm using > ecryptfs-utils-87-8.fc15.x86_64 > kernel-2.6.40-4.fc15.x86_64 > >> Data corruption does not happen always, so now I'm not too sure >> whether this has to do with eCryptfs itself. May simply not happened >> when I tested samba on not encrypted filesystem. >> > > > > -- > Best regards, > Michal > > http://eventhorizon.pl/ > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
