[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29635.1363782649@warthog.procyon.org.uk>
Date: Wed, 20 Mar 2013 12:30:49 +0000
From: David Howells <dhowells@...hat.com>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: dhowells@...hat.com, Jan Kara <jack@...e.cz>,
Miklos Szeredi <miklos@...redi.hu>,
torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, hch@...radead.org,
akpm@...ux-foundation.org, apw@...onical.com, nbd@...nwrt.org,
neilb@...e.de, jordipujolp@...il.com, ezk@....cs.sunysb.edu,
sedat.dilek@...glemail.com, hooanon05@...oo.co.jp, mszeredi@...e.cz
Subject: Re: [PATCH 2/9] vfs: export do_splice_direct() to modules
Al Viro <viro@...IV.linux.org.uk> wrote:
> fs/cachefiles/rdwr.c:967: ret = file->f_op->write(
>
> cachefiles_write_page(); no fucking idea what locks might be held by caller
> and potentially that's a rather nasty source of PITA
The caller of cachefiles_write_page() (ie. fscache_write_op()) holds no locks
over the call.
__fscache_write_page() queues the pages for writing to the cache from the
netfs's read-side routines and returns immediately.
fscache_write_op() then picks them up in the background and passes them over
to the backend (eg. cachefiles_write_page()) which writes them out to the
cache.
So I think it should be safe to call file_start/end_write() or whatever around
the file->f_op->write() calls.
David
--
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