From: Jari Ruusu <jariruusu@users.sourceforge.net>
To: Jan Rychter <jan@rychter.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Oopsing cryptoapi (or loop device?) on 2.6.*
Date: Sun, 15 Feb 2004 18:38:14 +0200 [thread overview]
Message-ID: <402FA076.7D6304C6@users.sourceforge.net> (raw)
In-Reply-To: 402F877C.C9B693C1@users.sourceforge.net
Jari Ruusu wrote:
> Jan Rychter wrote:
> > FWIW, I've just tried loop-AES with 2.4.24, after using cryptoapi for a
> > number of years. My machine froze dead in the midst of copying 2.8GB of
> > data onto my file-backed reiserfs encrypted loopback mount.
> >
> > Since the system didn't ever freeze on me before and since I've had zero
> > problems with cryptoapi, I attribute the freeze to loop-AES.
> >
> > Yes, I know this isn't a good bugreport...
>
> Is there any particular reason why you insist on using file backed loops?
>
> File backed loops have hard to fix re-entry problem: GFP_NOFS memory
> allocations that cause dirty pages to written out to file backed loop, will
> have to re-enter the file system anyway to complete the write. This causes
> deadlocks. Same deadlocks are there in mainline loop+cryptoloop combo.
>
> This is one of the reasons why this is in loop-AES README: "If you can
> choose between device backed and file backed, choose device backed even if
> it means that you have to re-partition your disks."
A quick grep of potential deadlock points:
armas:/usr/src/linux-2.4.24/fs/reiserfs # grep -r GFP_NOFS *
dir.c: local_buf = reiserfs_kmalloc(d_reclen, GFP_NOFS, inode->i_sb) ;
fix_node.c: buf = reiserfs_kmalloc(size, GFP_NOFS, tb->tb_sb);
journal.c: bn = reiserfs_kmalloc(sizeof(struct reiserfs_bitmap_node), GFP_NOFS, p_s_sb) ;
journal.c: bn->data = reiserfs_kmalloc(p_s_sb->s_blocksize, GFP_NOFS, p_s_sb) ;
journal.c: log_blocks = reiserfs_kmalloc(le32_to_cpu(desc->j_len) * sizeof(struct buffer_head *), GFP_NOFS, p_s_sb) ;
journal.c: real_blocks = reiserfs_kmalloc(le32_to_cpu(desc->j_len) * sizeof(struct buffer_head *), GFP_NOFS, p_s_sb) ;
journal.c: /* using GFP_NOFS, GFP_KERNEL could try to flush inodes, which will try
journal.c: ct = reiserfs_kmalloc(sizeof(struct reiserfs_journal_commit_task), GFP_NOFS, p_s_sb) ;
namei.c: buffer = reiserfs_kmalloc (buflen, GFP_NOFS, dir->i_sb);
namei.c: name = reiserfs_kmalloc (item_len, GFP_NOFS, parent_dir->i_sb);
armas:/usr/src/linux-2.4.24/fs/reiserfs #
Many potential deadlock points there in reiserfs.
armas:/usr/src/linux-2.4.24/fs/ext2 # grep -r GFP_NOFS *
armas:/usr/src/linux-2.4.24/fs/ext2 #
File backed loop to a file on ext2 may work.
armas:/usr/src/linux-2.4.24/fs/ext3 # grep -r GFP_NOFS *
inode.c: page = find_or_create_page(mapping, index, GFP_NOFS);
armas:/usr/src/linux-2.4.24/fs/ext3 #
Potential deadlock point there in ext3.
armas:/usr/src/linux-2.4.24/fs/nfs # grep -r GFP_NOFS *
armas:/usr/src/linux-2.4.24/fs/nfs #
File backed loop to a file on nfs may work.
armas:/usr/src/linux-2.4.24/fs/smbfs # grep -r GFP_NOFS *
armas:/usr/src/linux-2.4.24/fs/smbfs #
File backed loop to a file on smbfs may work.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
next prev parent reply other threads:[~2004-02-15 16:38 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-11 15:33 Oopsing cryptoapi (or loop device?) on 2.6.* Michal Kwolek
2004-02-11 18:41 ` Jari Ruusu
2004-02-15 2:35 ` Jan Rychter
2004-02-15 14:51 ` Jari Ruusu
2004-02-15 16:38 ` Jari Ruusu [this message]
2004-02-16 0:26 ` James Morris
2004-02-18 14:07 ` Bill Davidsen
2004-02-16 12:22 ` Jan Rychter
2004-02-17 14:09 ` Jari Ruusu
2004-02-17 19:14 ` Jan Rychter
2004-02-18 14:06 ` Jari Ruusu
2004-02-18 21:40 ` Jan Rychter
2004-02-19 13:34 ` Jari Ruusu
2004-02-11 22:54 ` bill davidsen
2004-02-15 17:34 ` Christophe Saout
2004-02-15 18:02 ` Christoph Hellwig
2004-02-15 18:42 ` Christophe Saout
2004-02-15 18:53 ` Christoph Hellwig
2004-02-15 19:36 ` Christophe Saout
2004-02-15 19:46 ` Christoph Hellwig
2004-02-15 20:24 ` kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Christophe Saout
2004-02-15 22:13 ` kthread vs. dm-daemon Mike Christie
2004-02-16 0:04 ` Christophe Saout
2004-02-16 1:04 ` Mike Christie
2004-02-16 1:29 ` Christophe Saout
2004-02-16 3:02 ` kthread vs. dm-daemon (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Rusty Russell
2004-02-16 13:27 ` Christophe Saout
2004-02-16 16:42 ` Christophe Saout
2004-02-16 13:48 ` Joe Thornber
2004-02-16 1:44 ` dm-crypt using kthread " Christophe Saout
2004-02-16 1:53 ` Andrew Morton
2004-02-16 2:07 ` Grzegorz Kulewski
2004-02-16 3:03 ` Christophe Saout
2004-02-16 3:22 ` Grzegorz Kulewski
2004-02-16 4:05 ` dm-crypt using kthread Jeff Garzik
2004-02-16 4:14 ` Grzegorz Kulewski
2004-02-16 10:15 ` Christophe Saout
2004-02-16 9:54 ` dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Christophe Saout
2004-03-01 22:18 ` Matthias Urlichs
2004-03-01 22:51 ` Christophe Saout
2004-03-01 23:22 ` Matthias Urlichs
2004-02-16 2:58 ` Christophe Saout
2004-02-16 7:28 ` David Wagner
2004-02-16 10:11 ` Christophe Saout
2004-02-18 14:15 ` dm-crypt using kthread Bill Davidsen
2004-02-16 2:07 ` dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Andrew Morton
2004-02-16 2:17 ` dm-crypt using kthread Jeff Garzik
2004-02-16 2:53 ` dm-crypt using kthread (was: Oopsing cryptoapi (or loop device?) on 2.6.*) Christophe Saout
2004-02-16 2:10 ` dm-crypt using kthread Jeff Garzik
2004-02-16 2:40 ` Christophe Saout
2004-02-16 2:58 ` Jeff Garzik
2004-02-16 3:10 ` Christophe Saout
2004-02-16 13:04 ` Christophe Saout
2004-02-16 19:09 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=402FA076.7D6304C6@users.sourceforge.net \
--to=jariruusu@users.sourceforge.net \
--cc=jan@rychter.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.