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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6c8024f4-bfea-4934-9120-b17ab0770a1f@asahilina.net>
Date: Fri, 8 Nov 2024 07:34:26 +0900
From: Asahi Lina <lina@...hilina.net>
To: Dan Williams <dan.j.williams@...el.com>, Jan Kara <jack@...e.cz>
Cc: Dave Chinner <david@...morbit.com>, Matthew Wilcox <willy@...radead.org>,
 Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Sergio Lopez Pascual
 <slp@...hat.com>, linux-fsdevel@...r.kernel.org, nvdimm@...ts.linux.dev,
 linux-kernel@...r.kernel.org, asahi@...ts.linux.dev
Subject: Re: [PATCH] dax: Allow block size > PAGE_SIZE



On 11/8/24 6:24 AM, Dan Williams wrote:
> Asahi Lina wrote:
> [..]
>> I don't think that's how it actually works, at least on arm64.
>> arch_wb_cache_pmem() calls dcache_clean_pop() which is either dc cvap or
>> dc cvac. Those are trapped by HCR_EL2<TPC>, and that is never set by KVM.
>>
>> There was some discussion of this here:
>> https://lore.kernel.org/all/20190702055937.3ffpwph7anvohmxu@US-160370MP2.local/
>>
>> But I'm not sure that all really made sense then.
>>
>> msync() and fsync() should already provide persistence. Those end up
>> calling vfs_fsync_range(), which becomes a FUSE fsync(), which fsyncs
>> (or fdatasyncs) the whole file. What I'm not so sure is whether there
>> are any other codepaths that also need to provide those guarantees which
>> *don't* end up calling fsync on the VFS. For example, the manpages kind
>> of imply munmap() syncs, though as far as I can tell that's not actually
>> the case. If there are missing sync paths, then I think those might just
>> be broken right now...
> 
> IIRC, from the pmem persistence dicussions, if userspace fails to call
> *sync then there is no obligation to flush on munmap() or close(). Some
> filesystems layer on those guarantees, but the behavior is
> implementation specific.

Then I think your patch should be fine then, since there's nothing to do
for writepages(). The syncing is handled via fsync() for FUSE/virtiofs
and I don't think the dax_writeback_mapping_range() is actually doing
anything in KVM anyway.

~~ Lina


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ