Bug 47644 - При взаимодействии с reiserfs: "kernel BUG at fs/reiserfs/journal.c:3039!" или "unable to handle page fault for address"
Summary: При взаимодействии с reiserfs: "kernel BUG at fs/reiserfs/journal.c:3039!" ил...
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: fstransform (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: viy
QA Contact: qa-sisyphus
URL: https://github.com/cosmos72/fstransfo...
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-19 17:58 MSK by Artem Varaksa
Modified: 2023-09-26 13:42 MSK (History)
3 users (show)

See Also:


Attachments
inxi (un-def p10 hw) (8.80 KB, text/plain)
2023-09-19 17:58 MSK, Artem Varaksa
no flags Details
journalctl (un-def p10 hw) (354.71 KB, text/x-log)
2023-09-19 17:59 MSK, Artem Varaksa
no flags Details
journalctl (std-def sisyphus vm) (199.58 KB, text/x-log)
2023-09-19 17:59 MSK, Artem Varaksa
no flags Details
fstransform log (un-def p10 hw) (4.41 KB, text/x-log)
2023-09-19 17:59 MSK, Artem Varaksa
no flags Details
fstransform log (std-def sisyphus vm) (5.30 KB, text/x-log)
2023-09-19 18:00 MSK, Artem Varaksa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Artem Varaksa 2023-09-19 17:58:26 MSK
Created attachment 14474 [details]
inxi (un-def p10 hw)

Шаги
====

1. # apt-get install -y fstransform reiserfsprogs

Повторять:
2. Отформатировать любой свободный раздел в ext2 (достаточно 4 GB).
3. Примонтировать раздел.
4. Создать несколько случайных файлов:
# for i in `seq 1 2`; do head -c 1G /dev/urandom > "random_$i.txt"; done
5. # fstransform /path/to/partition reiserfs
6. # fstransform /path/to/partition ext2

Ошибка плавающая, поэтому необходимо повторять шаги до появления ошибки.

Фактический результат
=====================

fstransform завершает работу с ошибкой, т. к. вызванная им команда падает с надписью "Ошибка сегментирования" или "Убито":

> fstransform: starting version 0.9.4, checking environment
> fstransform: checking for which...         '/usr/bin/which'
> [...]
> 12:02:32 fstransform: environment check passed.
> 12:02:32 fstransform: saving output of this execution into /var/tmp/fstransform/fstransform.log.15019
> 12:02:32 fstransform: preparing to transform device '/dev/sdb1' to file-system type 'ext2'
> 12:02:32 fstransform: device is mounted at '/test-mount' with file-system type 'reiserfs'
> 12:02:32 fstransform: device raw size = 4292870144 bytes
> 12:02:32 fstransform: creating sparse loop file '/test-mount/.fstransform.loop.15019' inside device '/dev/sdb1'...
> Убито
> 
> 12:02:32 ERROR! fstransform: failed to create or truncate '/test-mount/.fstransform.loop.15019' to zero bytes
>                 maybe device '/dev/sdb1' is full or mounted read-only?

Завершать работу может и на других этапах процесса (см. вложения).



При этом в journalctl (во вложениях):

> kernel: BUG: unable to handle page fault for address: ffffffffd60b47cb
> kernel: #PF: supervisor read access in kernel mode
> kernel: #PF: error_code(0x0000) - not-present page

Или:

> kernel: kernel BUG at fs/reiserfs/journal.c:3039!
> kernel: invalid opcode: 0000 [#1] PREEMPT SMP PTI

Ожидаемый результат
===================

Нет падения fstransform и ошибок ядра в journalctl. Успешное завершение преобразования файловой системы fstransform.

Дополнительно
=============

Возможно, что ошибка воспроизводится и при использовании другой файловой системы вместо ext2.

Воспроизводимость
=================

В [sisyphus] воспроизводится на ядре 6.1.53-std-def-alt1, не воспроизводится на 6.4.16-un-def-alt1.

В [p10] пакета fstransform нет, поэтому проверялось в [p10 + 328426].
В [p10 + 328426] воспроизводится на 6.1.52-un-def-alt1, не воспроизводится на 5.10.194-std-def-alt1.

Т. е. воспроизводится на ядрах 6.1.



Подробнее:

Виртуальные машины:

[p10 + 328426] education-10.1-x86-64
6.1.52-un-def-alt1 (~3/10 раз)
5.10.194-std-def-alt1 (~0/30 раз)

[sisyphus] kworkstation-10.1-x86-64, education-10.1-x86-64, education-10.1-x86-64-kde
6.4.16-un-def-alt1 (в сумме ~0/36 раз)

[sisyphus] workstation-10.1-x86-64, server-10.1-x86-64
6.1.53-std-def-alt1 (в сумме ~2/2 раз)

Реальная машина (inxi - во вложении):

[p10 + 328426] education-10.1-x86-64
6.1.52-un-def-alt1 (~1/40 раз)
5.10.194-std-def-alt1 (~0/14 раз)



Версии пакетов:

[p10 + 328426]
fstransform-0.9.4-alt2_11.x86_64

libreiserfsprogs-3.6.27-alt1.x86_64
reiserfsprogs-3.6.27-alt1.x86_64
libprogsreiserfs-0.3.0.5-alt4.x86_64
libreiser4-1.2.1-alt2.x86_64


[sisyphus] 
fstransform-0.9.4-alt2_11.x86_64

libreiserfsprogs-3.6.27-alt1.x86_64
reiserfsprogs-3.6.27-alt1.x86_64

Воспроизводится вне зависимости от наличия:
libprogsreiserfs-0.3.0.5-alt5.x86_64
libreiser4-1.2.1-alt3.x86_64
Comment 1 Artem Varaksa 2023-09-19 17:59:01 MSK
Created attachment 14476 [details]
journalctl (un-def p10 hw)
Comment 2 Artem Varaksa 2023-09-19 17:59:29 MSK
Created attachment 14477 [details]
journalctl (std-def sisyphus vm)
Comment 3 Artem Varaksa 2023-09-19 17:59:55 MSK
Created attachment 14478 [details]
fstransform log (un-def p10 hw)
Comment 4 Artem Varaksa 2023-09-19 18:00:19 MSK
Created attachment 14479 [details]
fstransform log (std-def sisyphus vm)
Comment 5 Vitaly Chikunov 2023-09-20 05:08:29 MSK
Прога fstransform не выглядит надежной -- если испортить файловую систему, то ядро может падать - это нормальное поведение. Хоть в README и написано, что она "tested carefully" - признаков CI тестирования в репозитории нет. При сборке пакета тестирования нет (в том числе и в Федоре откуда он взят). Апстрим практически не обновлялся с 2019, а ядро продолжало развиваться. При этом, Reiserfs - заброшенная и плохо поддерживаемая ФС в Линукс - желательно прекратить её использовать.

  "Reiserfs is deprecated and scheduled to be removed from the kernel
   in 2025. If you are still using it, please migrate to another
   filesystem or tell us your usecase for reiserfs."


В любом случае, вы можете попробовать завести баг в апстриме.
https://github.com/cosmos72/fstransform

Мое предложение - удалить fstransform.
Comment 6 Artem Varaksa 2023-09-21 15:00:01 MSK
Завёл ошибку в upstream: https://github.com/cosmos72/fstransform/issues/54.
Comment 7 Artem Varaksa 2023-09-26 13:42:07 MSK
Ошибка в upstream была закрыта.

Кратко:

1. Скорее всего, это ошибка ядра или fsck, т. к. fstransform не пишет в монтированные файловые системы, только в не монтированные, и перед монтированием запускает fsck. На это указывает и то, что ошибка воспроизводилась только на некоторых ядрах (6.1).

2. Это не первый случай, когда fstransform вызывал ошибку в ядре. Например, мейнтейнер в upstream сталкивался с ошибкой ядра из-за того что fstransform использует *огромные* sparse-файлы и записывает в них случайном порядке.


Подробнее: https://github.com/cosmos72/fstransform/issues/54#issuecomment-1734194232