| 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: Wed, 4 Jan 2012 13:50:20 +1100 From: Dave Chinner <david@...morbit.com> To: Al Viro <viro@...IV.linux.org.uk> Cc: Jan Kara <jack@...e.cz>, Stephen Rothwell <sfr@...b.auug.org.au>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, Mikulas Patocka <mpatocka@...hat.com>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: linux-next: build failure after merge of the vfs tree On Wed, Jan 04, 2012 at 02:17:54AM +0000, Al Viro wrote: > I'm still not > sure about ->statfs(), BTW - any input on that would be welcome. Can > it end up blocked on a frozen fs until said fs is thawed? I don't see why this should ever happen - ->statfs has to work on read-only filesystems so shoul dnot be modifying state, and hence should never need to care about the frozen state of the superblock. So from a ->statfs POV, a frozen filesystem should look just like a read-only filesystem. If frozen filesystems are holding locks that ->statfs can block on until the filesystem us thawed, then I'd consider that a bug in the filesystem freeze implementation.... > to convert ustat(2) to "wait for thaw" semantics (should be interruptible, > BTW) or document that ->statfs() is not allowed to wait for thawing. > It's far too subtle to leave undocumented... The latter, IMO. Cheers, Dave. -- Dave Chinner david@...morbit.com -- 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