2.6.40 ecryptfs oops (Re: glibc 2.14-4 eats my data (Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)))

[Michał Piotrowski]

W dniu 6 sierpnia 2011 14:41 użytkownik Michał Piotrowski
<mkkp4x4 at gmail.com> napisał:
> W dniu 12 lipca 2011 22:45 użytkownik Michał Piotrowski
> <mkkp4x4 at gmail.com> 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/