linux-kernel - Re: [PATCH 1/3] direct-io: only inc/dec inode->i_dio

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:	Wed, 15 Apr 2015 23:56:25 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dave Chinner <david@...morbit.com>
Cc:	Jens Axboe <axboe@...com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@....de>, Theodore Ts'o <tytso@....edu>,
	"Elliott, Robert (Server Storage)" <elliott@...com>
Subject: Re: [PATCH 1/3] direct-io: only inc/dec inode->i_dio_count for file
 systems

On Thu, Apr 16, 2015 at 08:36:20AM +1000, Dave Chinner wrote:

> Bikeshedding: I think this would be better suited to inode_dio_begin()
> and inode_dio_end() because now we are trying to say "this is where
> the DIO starts, and this is where it ends". It's not really
> "reference counting" interface, we're trying to annotate the
> boundaries of where DIO iis protected against truncate....

*nod*

And while we are at, inode_dio_begin() could be static inline just fine.

> And, realistically, if we are pushing this up into the filesystems
> again, we should push it up into *all* filesystems and get rid of it
> completely from the DIO layer. That way no new twisty passages in
> the direct IO code are needed.

Maybe...  FWIW, since the code *checking* ->i_dio_count is already
inside the individual filesystems (and right now I'm trying to verify
it), we might as well have the code changing it there as well.  AFAICS,
the main problem with that is the need to do it after the end of async
operation.  Sure, we do have callbacks, but we'd need something like
	* start protection
	* submit DIO
	* if that has failed synchronously, drop protection and fuck off
	* otherwise let the callback deal with dropping it.
What's more, we'd get not just a slew of boilerplate callbacks, but make
life interesting for branch predictor - indirect calls are not fun...
--
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/