| 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: Tue, 2 Aug 2011 01:47:00 +0200 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Josef Bacik <josef@...hat.com> Cc: LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Linux PM mailing list <linux-pm@...ts.linux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz> Subject: [Regression] Commit 02c24a82187d5a628c68edfe71ae60dc135cd178 breaks s2disk Hi, Unfortunately s2disk (which is a user space tool for saving hibernate images) doesn't work any more after your commit 02c24a82187d5a628c68edfe71ae60dc135cd178 (fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers). The symptom is that the s2disk's resume counterpart cannot find the image in the device even though s2disk considers it as successfully saved. What happens is that s2disk opens a block device (disk partition to be precise) directly and writes to it eventually calling fsync(). My interpretation of the failure is that before commit 02c24a82187d5a628c68ed, when s2disk called fsync() the VFS layer would run filemap_write_and_wait_range() that in turn would cause the data to go to the disk, but after that commit this doesn't happen any more. If I'm right, then not only s2disk, but any process writing directly to a block device will have a problem with fsync(). Thanks, Rafael -- 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