| 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: Thu, 05 Mar 2009 12:54:33 +0100 From: "Jorge Boncompte [DTI2]" <jorge@...2.net> To: npiggin@...e.de CC: ext-adrian.hunter@...ia.com, LKML <linux-kernel@...r.kernel.org> Subject: Re: Error testing ext3 on brd ramdisk Nick Piggin escribió: > On Thu, Mar 05, 2009 at 10:19:46AM +0100, Jorge Boncompte [DTI2] wrote: >> ----------- >> umount /etc (/etc is what is mounted from /dev/ram0) >> dd if=/dev/zero of=/dev/ram0 bs=1k count=1000 >> mount /dev/ram0 /etc -t minix -o rw >> ----------- >> ...succeds and mounts a corrupted filesystem with the old content. Doing >> the same with the all ramdisk driver fails on mount with "no filesystem >> found". >> >> If I do... >> ----------- >> umount /etc (/etc is what is mounted from /dev/ram0) >> echo 3 > /proc/sys/vm/drop_caches >> dd if=/dev/zero of=/dev/ram0 bs=1k count=1000 >> mount /dev/ram0 /etc -t minix -o rw >> ---------- >> ... then the mount fails with no filesystem found as it should. > > I can't reproduce this. Is the filesystem definitely being > unmounted and nothing else is holding the bdev inode open? I don't know about the bdev inode :-( but I am sure that in /proc/mounts does not appear as listed. > I can only imagine something like this happening if the fs > is still mounted, in which case it will write back some > superblock over the zeroed bdev, possibly allowing it to mount > again, or if the zeroed writes somehow get lost, which would > seem like a problem with the buffer cache. > > Actually, the 2nd scenario is more likely, because you wouldn't > see it with the old rd driver because it never allows the buffer > cache to be freed. > > Are you getting any errors in your dmesg or anything like that? No until I try to mount the filesystem again, then minix starts to complain. ----------------- minix_free_block (ram0:38): bit already cleared init_special_inode: bogus i_mode (0) init_special_inode: bogus i_mode (0) init_special_inode: bogus i_mode (0) init_special_inode: bogus i_mode (0) init_special_inode: bogus i_mode (0) ......... ----------------- > What happens when you run the following patch? Can you run the > test case then when you reproduce the problem, see if anything is > in dmesg? After a successful save ------------------ Mar 5 13:34:34 system: configuration save requested by user=root Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: killing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: truncated bdev Mar 5 13:34:34 kernel: killing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: truncated bdev Mar 5 13:34:34 kernel: killing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: truncated bdev Mar 5 13:34:34 kernel: killing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: truncated bdev Mar 5 13:34:34 kernel: killing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:34 kernel: truncated bdev Mar 5 13:34:34 kernel: killing bdev Mar 5 13:34:34 kernel: syncing bdev Mar 5 13:34:35 kernel: truncated bdev Mar 5 13:34:35 kernel: killing bdev Mar 5 13:34:35 kernel: syncing bdev Mar 5 13:34:35 kernel: truncated bdev Mar 5 13:34:35 kernel: killing bdev Mar 5 13:34:35 kernel: syncing bdev Mar 5 13:34:35 kernel: truncated bdev ------------------ rm -f <some archives> ------------------ Mar 5 13:35:00 system: configuration save requested by user=root Mar 5 13:35:00 kernel: syncing bdev Mar 5 13:35:00 kernel: syncing bdev Mar 5 13:35:00 kernel: syncing bdev Mar 5 13:35:00 kernel: syncing bdev ------------------ -- ============================================================== Jorge Boncompte - Ingenieria y Gestion de RED DTI2 - Desarrollo de la Tecnologia de las Comunicaciones -------------------------------------------------------------- C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN) Tlf: +34 957 761395 / FAX: +34 957 450380 ============================================================== - Sin pistachos no hay Rock & Roll... - Without wicker a basket cannot be made. ============================================================== -- 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