| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20070725123653.GP5357@knopper.net> Date: Wed, 25 Jul 2007 14:36:53 +0200 From: Klaus Knopper <cloop@...pper.net> To: linux-kernel@...r.kernel.org Subject: PROBLEM: kernel 2.6.22 do_generic_mapping_read() hangs for no apparent reason Hi, Sorry about the quite poor subject. I just got stuck in the debugging and cannot point to the exact location of the problem, though I am quite sure it's a kernel 2.6.22 problem, and not a "third-party-module" problem. cloop-2.06 (block device module similar to loop.c) uses do_generic_file_read(), which is translated to do_generic_mapping_read() in mm/filemap.c, which worked fine up to and including Kernel 2.6.21.6. In Kernel 2.6.22, do_generic_file_read() blocks indefinitely with no log message at all, whenever data is read from the file and the read_actor is NOT called (i.e. parts of the file-to-be-read are probably already cached somewhere). Unfortunately, apart from cloop, there seem to be not many drivers that still use do_generic_file_read, so maybe it's time for a rewrite anyways. If anybody would volunteer to help debugging or rewriting cloop to work with Kernels >= 2.6.22, a lot of people developing live CDs would be very happy (including me. ;-) cloop source code is at http://debian-knoppix.alioth.debian.org/sources/cloop_2.06-2.tar.gz (make cloop.ko KERNEL_DIR=/path/to/kernel/source) With kind regards -Klaus Knopper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists