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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 21 Jul 2020 17:42:40 +0200 From: Christoph Hellwig <hch@....de> To: Matthew Wilcox <willy@...radead.org> Cc: Christoph Hellwig <hch@....de>, Goldwyn Rodrigues <rgoldwyn@...e.de>, Dave Chinner <david@...morbit.com>, Damien Le Moal <damien.lemoal@....com>, Naohiro Aota <naohiro.aota@....com>, Johannes Thumshirn <jth@...nel.org>, linux-btrfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, cluster-devel@...hat.com, linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org, Michael Kerrisk <mtk.manpages@...il.com>, linux-man@...r.kernel.org Subject: Re: RFC: iomap write invalidation On Tue, Jul 21, 2020 at 04:31:36PM +0100, Matthew Wilcox wrote: > > Umm, no. -ENOTBLK is internal - the file systems will retry using > > buffered I/O and the error shall never escape to userspace (or even the > > VFS for that matter). > > Ah, I made the mistake of believing the comments that I could see in > your patch instead of reading the code. > > Can I suggest deleting this comment: > > /* > * No fallback to buffered IO on errors for XFS, direct IO will either > * complete fully or fail. > */ > > and rewording this one: > > /* > * Allow a directio write to fall back to a buffered > * write *only* in the case that we're doing a reflink > * CoW. In all other directio scenarios we do not > * allow an operation to fall back to buffered mode. > */ > > as part of your revised patchset? That isn't actually true. In current mainline we only fallback on reflink RMW cases, but with this series we also fall back for invalidation failures.
Powered by blists - more mailing lists