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
| ||
|
Date: Mon, 17 Dec 2007 14:56:44 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: Valdis.Kletnieks@...edu Cc: linux-kernel@...r.kernel.org Subject: Re: 2.6.24-rc5-mm1 - wonky disk cache and CDROM behavior... On Mon, 17 Dec 2007 17:44:11 -0500 Valdis.Kletnieks@...edu wrote: > On Thu, 13 Dec 2007 02:40:50 PST, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/ > > OK, so I'm trying to 'dd' a CD and the drive on the laptop is having issues > reading the disk. > > I try it once, and get an I/O error about 117M in - dd reports 1.7M/sec. > > I try it again, and it reports it died at the same exact place, but in about > 2 seconds flat, and reports 91M/sec transfer. OK, that's *weird*, I didn't > think that blocks read from /dev/cdrom would get cached, but OK. It'll remain cached if something is holding the device open. > So I try > the obviously stupid thing: > > # echo 1 >| /proc/sys/vm/drop_caches > > Alas, that hangs gloriously - 'echo t > /proc/sysrq-trigger' tells me: > > Dec 17 17:30:02 turing-police kernel: [20235.823201] bash D 0000000000000001 5288 15123 15085 > Dec 17 17:30:02 turing-police kernel: [20235.823206] ffff81007ba7de28 0000000000000086 0000000000000000 0000000000000000 > Dec 17 17:30:02 turing-police kernel: [20235.823210] ffff81007bbd9000 ffff81007d70e000 ffff81007bbd9248 00000001019e3e48 > Dec 17 17:30:02 turing-police kernel: [20235.823214] ffffe20000f36028 ffffe200012b9978 ffffe20000eece48 ffffe20001164188 > Dec 17 17:30:02 turing-police kernel: [20235.823218] Call Trace: > Dec 17 17:30:02 turing-police kernel: [20235.823224] [<ffffffff80523e20>] __down_read+0x87/0xa1 > Dec 17 17:30:02 turing-police kernel: [20235.823229] [<ffffffff8024bc13>] down_read+0x9/0xe > Dec 17 17:30:02 turing-police kernel: [20235.823232] [<ffffffff802abafe>] drop_pagecache+0x3a/0x8c > Dec 17 17:30:02 turing-police kernel: [20235.823235] [<ffffffff802abb72>] drop_caches_sysctl_handler+0x22/0x38 > Dec 17 17:30:02 turing-police kernel: [20235.823239] [<ffffffff802d2b70>] proc_sys_write+0x7e/0xa6 > Dec 17 17:30:02 turing-police kernel: [20235.823244] [<ffffffff8028e18c>] vfs_write+0xc7/0x170 > Dec 17 17:30:02 turing-police kernel: [20235.823248] [<ffffffff8028e772>] sys_write+0x47/0x70 > Dec 17 17:30:02 turing-police kernel: [20235.823251] [<ffffffff8020c34c>] tracesys+0xdc/0xe1 > Something's holding s_umount for writing I guess. Possibly busted error handling somewhere totally different. -- 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