[d-kernel] Cryptoloop на usb

[d-kernel] Cryptoloop на usb

[Alex Yustasov]

[-- Attachment #1: Type: text/plain, Size: 1824 bytes --]

Здравствуйте!
У меня проблема с cryptoloop на USB устройстве.
На USB flash-ka. Попробовал

modprobe cryptoloop
losetup -e blowfish /dev/loop0 /dev/sda1
mkfs.ext3 /dev/loop0
mount /dev/loop0 /mnt/disk

Записываю данные. Размонтирую
umount /mnt/disk
losetup -d /dev/loop0
rmmod cryptoloop

В логах
kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal
kernel: EXT3-fs: mounted filesystem with ordered data mode.
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24688
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24689
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24752
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24753
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24816
kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24817
kernel: cryptoloop: unloaded

При следующем монтировании того-же один каталог оказывается
?<каталог> красного цвета. Иногда получается со второго раза
(монтирование, запись, размонтирование).
Если использовался usb-uhci (на другой машине usb-ohci), то при
перезагрузке oops при unload usb-uhci (в аттаче)
и заняты /usr /proc.
Если использовался uhci - перезагрузка проходит нормально.
При загрузке системы, если usb-uhci, то usb-storage загружается очень долго.
Первый раз случилось это на ядре с swsusp, проверил на std-up-2.4.22-alt7
тоже самое. Последний сизиф. 
В файл на flash-ke cryptoloop пишет нормально, пробовал сделать тоже
на раздел диска - все нормально.
Это у меня одного такое? Или я что-то делаю не так?

[-- Attachment #2: out2 --]
[-- Type: text/plain, Size: 3900 bytes --]

ksymoops 2.4.9 on i686 2.4.22-std-up-alt7.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.22-std-up-alt7/ (default)
     -m /boot/System.map-2.4.22-std-up-alt7 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Warning (compare_ksyms_lsmod): module ext3 is in lsmod but not in ksyms, probably no symbols exported
Unable to handle kernel paging request at virtual address d0c62010
c0155784
*pde = 01385067
Oops: 0002
CPU:    0
EIP:    0010:[proc_get_inode+196/320]    Not tainted
EIP:    0010:[<c0155784>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: d0c62000   ebx: cd38d860   ecx: 00000000   edx: 00000003
esi: ce9070e0   edi: cd38d860   ebp: ccb211cd   esp: c9445cb4
ds: 0018   es: 0018   ss: 0018
Process updfstab (pid: 2057, stackpage=c9445000)
Stack: ccb22e00 00000246 c0157515 ccb22da0 ce9070e0 ccb22889 ce907139 c0157540 
       cfdc4800 000011cd ce9070e0 ffffffea 00000000 cffb94e0 cc09200b 12f82eba 
       0000000d ccb22820 fffffff4 cd38d680 ccb22da0 c0140cef cd38d680 ccb22820 
Call Trace:    [proc_lookup+149/224] [proc_lookup+192/224] [real_lookup+79/192] [link_path_walk+1684/2432] [__alloc_pages+64/368]
Call Trace:    [<c0157515>] [<c0157540>] [<c0140cef>] [<c0141594>] [<c0131130>]
  [<c0127035>] [<c0127094>] [<c01272a8>] [<c0225227>] [<c0225227>] [<c012abdd>]
  [<c012ac0b>] [<c0127048>] [<c012ab20>] [<c01419fb>] [<c0141db7>] [<c011d9be>]
  [<c01156d9>] [<c0137114>] [<c0140a3f>] [<c0137454>] [<c0108933>]
Code: ff 40 10 8b 46 24 8b 50 14 83 ca 18 89 50 14 8b 46 18 85 c0 


>>EIP; c0155784 <proc_get_inode+c4/140>   <=====

>>eax; d0c62000 <[xfs]qm_dqtrxzone+187e8/2b848>
>>ebx; cd38d860 <_end+d085230/1080da30>
>>esi; ce9070e0 <_end+e5feab0/1080da30>
>>edi; cd38d860 <_end+d085230/1080da30>
>>ebp; ccb211cd <_end+c818b9d/1080da30>
>>esp; c9445cb4 <_end+913d684/1080da30>

Trace; c0157515 <proc_lookup+95/e0>
Trace; c0157540 <proc_lookup+c0/e0>
Trace; c0140cef <real_lookup+4f/c0>
Trace; c0141594 <link_path_walk+694/980>
Trace; c0131130 <__alloc_pages+40/170>
Trace; c0127035 <do_anonymous_page+115/140>
Trace; c0127094 <do_no_page+34/1f0>
Trace; c01272a8 <handle_mm_fault+58/c0>
Trace; c0225227 <vsnprintf+2b7/450>
Trace; c0225227 <vsnprintf+2b7/450>
Trace; c012abdd <filemap_nopage+bd/210>
Trace; c012ac0b <filemap_nopage+eb/210>
Trace; c0127048 <do_anonymous_page+128/140>
Trace; c012ab20 <filemap_nopage+0/210>
Trace; c01419fb <path_lookup+1b/30>
Trace; c0141db7 <open_namei+77/750>
Trace; c011d9be <parse_table+be/e0>
Trace; c01156d9 <do_page_fault+189/4cb>
Trace; c0137114 <filp_open+34/60>
Trace; c0140a3f <getname+5f/a0>
Trace; c0137454 <sys_open+34/80>
Trace; c0108933 <system_call+33/40>

Code;  c0155784 <proc_get_inode+c4/140>
00000000 <_EIP>:
Code;  c0155784 <proc_get_inode+c4/140>   <=====
   0:   ff 40 10                  incl   0x10(%eax)   <=====
Code;  c0155787 <proc_get_inode+c7/140>
   3:   8b 46 24                  mov    0x24(%esi),%eax
Code;  c015578a <proc_get_inode+ca/140>
   6:   8b 50 14                  mov    0x14(%eax),%edx
Code;  c015578d <proc_get_inode+cd/140>
   9:   83 ca 18                  or     $0x18,%edx
Code;  c0155790 <proc_get_inode+d0/140>
   c:   89 50 14                  mov    %edx,0x14(%eax)
Code;  c0155793 <proc_get_inode+d3/140>
   f:   8b 46 18                  mov    0x18(%esi),%eax
Code;  c0155796 <proc_get_inode+d6/140>
  12:   85 c0                     test   %eax,%eax


2 warnings issued.  Results may not be reliable.

[-- Attachment #3: Type: text/plain, Size: 81 bytes --]

Scanned by evaluation version of Dr.Web antivirus Daemon 
http://drweb.ru/unix/

Re: [d-kernel] Cryptoloop на usb

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

On Wed, Nov 05, 2003 at 04:08:41PM +0200, Alex Yustasov wrote:
> Здравствуйте!
> У меня проблема с cryptoloop на USB устройстве.
> На USB flash-ka. Попробовал
> 
> modprobe cryptoloop
> losetup -e blowfish /dev/loop0 /dev/sda1
> mkfs.ext3 /dev/loop0
> mount /dev/loop0 /mnt/disk
> 
> Записываю данные. Размонтирую
> umount /mnt/disk
> losetup -d /dev/loop0
> rmmod cryptoloop
> 
> В логах
> kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal
> kernel: EXT3-fs: mounted filesystem with ordered data mode.
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24688
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24689
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24752
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24753
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24816
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24817
> kernel: cryptoloop: unloaded
> 
> При следующем монтировании того-же один каталог оказывается
> ?<каталог> красного цвета. Иногда получается со второго раза
> (монтирование, запись, размонтирование).

А можно попробовать то же самое, но без шифрования (просто сделать
losetup /dev/loop0 /dev/sda1 и попробовать с ним поработать)?

Работа с loop на устройстве обрабатывается несколько по-другому, чем
при использовании файла - возможно, проблемы в этом.

> Если использовался usb-uhci (на другой машине usb-ohci), то при
> перезагрузке oops при unload usb-uhci (в аттаче)
> и заняты /usr /proc.
> Если использовался uhci - перезагрузка проходит нормально.

А порча файловой системы через cryptoloop наблюдается и с uhci, и
с usb-uhci?

> При загрузке системы, если usb-uhci, то usb-storage загружается очень долго.

От этого остаются какие-нибудь ругательства в dmesg?

> Первый раз случилось это на ядре с swsusp, проверил на std-up-2.4.22-alt7
> тоже самое. Последний сизиф. 
> В файл на flash-ke cryptoloop пишет нормально, пробовал сделать тоже
> на раздел диска - все нормально.
> Это у меня одного такое? Или я что-то делаю не так?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Cryptoloop на usb

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Alex Yustasov пишет:
> Здравствуйте!
> У меня проблема с cryptoloop на USB устройстве.
> На USB flash-ka. Попробовал
> 
> modprobe cryptoloop
> losetup -e blowfish /dev/loop0 /dev/sda1
> mkfs.ext3 /dev/loop0
> mount /dev/loop0 /mnt/disk
> 
> Записываю данные. Размонтирую
> umount /mnt/disk
> losetup -d /dev/loop0
> rmmod cryptoloop
> 
> В логах
> kernel: EXT3 FS 2.4-0.9.19, 19 August 2002 on loop(7,0), internal journal
> kernel: EXT3-fs: mounted filesystem with ordered data mode.
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24688
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24689
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24752
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24753
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24816
> kernel: EXT3-fs error (device loop(7,0)): ext3_new_block: Allocating block in system zone - block = 24817
> kernel: cryptoloop: unloaded
> 
> При следующем монтировании того-же один каталог оказывается
> ?<каталог> красного цвета. Иногда получается со второго раза
> (монтирование, запись, размонтирование).
> Если использовался usb-uhci (на другой машине usb-ohci), то при
> перезагрузке oops при unload usb-uhci (в аттаче)
> и заняты /usr /proc.
> Если использовался uhci - перезагрузка проходит нормально.
> При загрузке системы, если usb-uhci, то usb-storage загружается очень долго.
> Первый раз случилось это на ядре с swsusp, проверил на std-up-2.4.22-alt7
> тоже самое. Последний сизиф. 
> В файл на flash-ke cryptoloop пишет нормально, пробовал сделать тоже
> на раздел диска - все нормально.
> Это у меня одного такое? Или я что-то делаю не так?
> 

А флешка смонтирована с опцией sync ?

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Cryptoloop на usb

[Alex Yustasov]

On Wed, Nov 05, 2003 at 05:47:43PM +0300, Sergey Vlasov wrote:
> On Wed, Nov 05, 2003 at 04:08:41PM +0200, Alex Yustasov wrote:
> > Здравствуйте!
> > У меня проблема с cryptoloop на USB устройстве.
> > На USB flash-ka. Попробовал
> > 
> > modprobe cryptoloop
> > losetup -e blowfish /dev/loop0 /dev/sda1
> > mkfs.ext3 /dev/loop0
> > mount /dev/loop0 /mnt/disk
> > 
> > Записываю данные. Размонтирую
> > umount /mnt/disk
> > losetup -d /dev/loop0
> > rmmod cryptoloop
> > 
> > При следующем монтировании того-же один каталог оказывается
> > ?<каталог> красного цвета. Иногда получается со второго раза
> > (монтирование, запись, размонтирование).
> 
> А можно попробовать то же самое, но без шифрования (просто сделать
> losetup /dev/loop0 /dev/sda1 и попробовать с ним поработать)?

Попробую.

> 
> Работа с loop на устройстве обрабатывается несколько по-другому, чем
> при использовании файла - возможно, проблемы в этом.
> 
> > Если использовался usb-uhci (на другой машине usb-ohci), то при
> > перезагрузке oops при unload usb-uhci (в аттаче)
> > и заняты /usr /proc.
> > Если использовался uhci - перезагрузка проходит нормально.
> 
> А порча файловой системы через cryptoloop наблюдается и с uhci, и
> с usb-uhci?

Да.

> 
> > При загрузке системы, если usb-uhci, то usb-storage загружается очень долго.
> 
> От этого остаются какие-нибудь ругательства в dmesg?

Если usb-uhci, то usb-storage ждет пока подключится устройство. Потом загрузка
продолжается. При uhci устройство подключается позже, usb-storage его не ждет.

> 
> > Первый раз случилось это на ядре с swsusp, проверил на std-up-2.4.22-alt7
> > тоже самое. Последний сизиф. 
> > В файл на flash-ke cryptoloop пишет нормально, пробовал сделать тоже
> > на раздел диска - все нормально.
> > Это у меня одного такое? Или я что-то делаю не так?

Re: [d-kernel] Cryptoloop на usb

[Alex Yustasov]

К выше сказанноему.
ps ax показывает 15 процессов
/bin/bash /etc/hotplug/usb.agent и
/usr/sbin/updfstab