linux-kernel - Re: [PATCH 2/4] fs: remove the never implemented aio

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Nov 2016 08:07:45 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Christoph Hellwig <hch@....de>
Cc:     Dave Chinner <david@...morbit.com>,
        Al Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
        Dmitry Monakhov <dmonakhov@...nvz.org>,
        Jeff Moyer <jmoyer@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-aio@...ck.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] fs: remove the never implemented aio_fsync file operation

On Tue, Nov 1, 2016 at 7:30 AM, Christoph Hellwig <hch@....de> wrote:
>
> sync_file_range is entirely different from fsync -

Absolutely.

And I think it's a shame. Particularly the fact that we don't have any
way to actually tie into the filesystem, and we just work on the page
cache level, which "mostly works" for writeback, but is really not
right. It's not like a filesystem even has to work on that level at
all..

> sync_file_range at the moment actually doesn't involve the fs, which
> has it's own set of problems.  So yes, maybe we need a full blown
> sync method unifying fsync, sync_file_range and which enables ranged
> data integrity fsync and asynchronous operations of all this.

I *think* we could just expand the existing filesystem "f_op->fsync()"
interface to take more than just the single-bit argument, and have the
full interface.

But being Linux-only, it sadly will never get much use. Even if the
other flags really are very useful for getting overlapping streaming
writes with minimal dirty state. It might be more productive to have
some easier-to-use interface to some generic writebehind logic, but..

> But to go back to Dave's argument - none of that can archived with that
> aio_fsync method added more than 10 years ago and never implemented.

Yeah, no, I actually agree with just removing that. I think we are
often much too slow to just say "nobody uses it, get rid of it". Even
if it were to ever be needed in the future, we could just resurrect
it, but it's not clear that it would ever be in that particular form.

               Linus