OpenVZ Forum: Devel » [PATCH] incorrect error handling inside generic_file_direct

Home » Mailing lists » Devel » [PATCH] incorrect error handling inside generic_file_direct_write

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: [PATCH] incorrect error handling inside generic_file_direct_write [message #8969 is a reply to message #8968]

Tue, 12 December 2006 10:40

Andrew Morton
Messages: 127
Registered: December 2005

Senior Member

On Tue, 12 Dec 2006 16:18:32 +0300
Dmitriy Monakhov <dmonakhov@sw.ru> wrote:

> >> but according to filemaps locking rules: mm/filemap.c:77
> >> ..
> >> * ->i_mutex (generic_file_buffered_write)
> >> * ->mmap_sem (fault_in_pages_readable->do_page_fault)
> >> ..
> >> I'm confused a litle bit, where is the truth?
> >
> > xfs_write() calls generic_file_direct_write() without taking i_mutex for
> > O_DIRECT writes.
> Yes, but my quastion is about __generic_file_aio_write_nolock().
> As i understand _nolock sufix means that i_mutex was already locked
> by caller, am i right ?

Nope. It just means that __generic_file_aio_write_nolock() doesn't take
the lock. We don't assume or require that the caller took it. For example
the raw driver calls generic_file_aio_write_nolock() without taking
i_mutex. Raw isn't relevant to the problem (although ocfs2 might be). But
we cannot assume that all callers have taken i_mutex, I think.

I guess we can make that a rule (document it, add
BUG_ON(!mutex_is_locked(..)) if it isn't a blockdev) if needs be. After
really checking that this matches reality for all callers.

It's important, too - if we have an unprotected i_size_write() then the
seqlock can get out of sync due to a race and then i_size_read() locks up
the kernel.

Report message to a moderator

[Message index]

		[PATCH] incorrect error handling inside generic_file_direct_write By: Dmitriy Monakhov on Mon, 11 December 2006 10:34
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: dev on Mon, 11 December 2006 12:27
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Andrew Morton on Mon, 11 December 2006 20:40
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Dmitriy Monakhov on Tue, 12 December 2006 06:22
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Andrew Morton on Tue, 12 December 2006 06:36
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Dmitriy Monakhov on Tue, 12 December 2006 09:20
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Andrew Morton on Tue, 12 December 2006 09:52
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Dmitriy Monakhov on Tue, 12 December 2006 10:18
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Andrew Morton on Tue, 12 December 2006 10:40
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Dmitriy Monakhov on Tue, 12 December 2006 20:14
		RE: [PATCH] incorrect error handling inside generic_file_direct_write By: kenneth.w.chen on Wed, 13 December 2006 02:43
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Christoph Hellwig on Fri, 15 December 2006 10:43
		RE: [PATCH] incorrect error handling inside generic_file_direct_write By: kenneth.w.chen on Fri, 15 December 2006 18:53
		Re: [PATCH] incorrect error handling inside generic_file_direct_write By: Christoph Hellwig on Tue, 02 January 2007 11:17

Previous Topic:	[PATCH] xt_hashlimit.c: fix typo
Next Topic:	vzmigrate filesystem rsync correction

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Tue Jan 27 09:56:45 GMT 2026

Total time taken to generate the page: 0.49967 seconds