| 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: <CADDb1s1pLQMMipe-zoHM6u4C_ZmUm_r4rsYxfft9mFQ56+Wgaw@mail.gmail.com> Date: Tue, 6 Sep 2011 22:56:41 +0530 From: Amit Sahrawat <amit.sahrawat83@...il.com> To: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org Subject: Issue with lazy umount and closing file descriptor in between We have observed below issues in busybox umount: 1. force umount (umount -f): it does not work as expected. 2. lazy umount(umount -l): it detaches the mount point but waits for current mount point users(processes) to finish. Corruption happens when we powerdown, while lazy umount is waiting for a process to finish. (e.g. #dd if=/dev/zero of=/mnt/test.txt ). What could be the ideal way so as to avoid file system corruption in above scenario? Is it fine to close all open file descriptors on umount system call before attempting umount? But this results in OOPS in certain situations like: 1. User app issue a write/read request 2. Write reaches in kernel space but sleeps for some time e.g. it is not available in dentry cache. 3. In the meanwhile, we issue umount. This will close open file descriptor, free file/dentry object and then umount. 4. Now write wakes up and finds NULL file/dentry object and triggers oops. Please offer some advice on this issue. Thanks & Regards, Amit Sahrawat -- 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