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 09:03:42 -0700 From: "Darrick J. Wong" <darrick.wong@...cle.com> 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:52:01PM +0100, Matthew Wilcox wrote: > On Tue, Jul 21, 2020 at 05:42:40PM +0200, Christoph Hellwig wrote: > > 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. > > ... that's why I'm suggesting that you delete the first one and rewrite > the second one. Because they aren't true. /* * We allow only three outcomes of a directio: (1) it succeeds * completely; (2) it fails with a negative error code; or (3) it * returns -ENOTBLK to signal that we should fall back to buffered IO. * * The third scenario should only happen if iomap refuses to perform the * direct IO, or the direct write request requires CoW but is not aligned * to the filesystem block size. */ ? --D
Powered by blists - more mailing lists