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:	Fri, 3 Apr 2009 03:47:20 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	David Howells <dhowells@...hat.com>, viro@...iv.linux.org.uk,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 22/43] CacheFiles: Add a hook to write a single page of data to an inode [ver #46]

On Friday 03 April 2009 03:37:12 Christoph Hellwig wrote:
> On Fri, Apr 03, 2009 at 02:32:58AM +1100, Nick Piggin wrote:
> > Hmm, I guess not all filesystems define write_begin/write_end. But if you
> > only need to use ones that do define them?
> 
> No.  write_begin/write_end are simply callbacks for the write helpers,
> and locking for them is entirely filesystem-defined.  E.g. xfs and the
> cluster filesystems require additional locks taken first, and some
> network filesystems require inode revalidations first.

Well they now are quite well filesystem defined. We no longer take
the page lock before calling them. Not saying it's perfect, but if
the backing fs is just using a known subset of ones that work
(like loop does).


> They really should be taken out of the address_space_operations and
> passed as callbacks to generic_file_aio_write & co.

Probably yes. But it seems like it should have more discussion IMO
(unless it has already been had and I missed it).

I don't think "write_one_page" sounds like a particularly good new
API addition.

In the meantime, I would prefer cachefs use writebegin/end and it can
be converted to a new API with everyone else rather than having to
rush a new API in with it.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ