[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <13789.1363973875@jrobl>
Date: Sat, 23 Mar 2013 02:37:55 +0900
From: "J. R. Okajima" <hooanon05@...oo.co.jp>
To: David Howells <dhowells@...hat.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, jack@...e.cz,
viro@...IV.linux.org.uk, 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, mszeredi@...e.cz
Subject: Re: [PATCH 2/9] vfs: export do_splice_direct() to modules
David Howells:
> Now, looking at __sb_start_write(), I'm not entirely sure how the deadlock
> might operate, so it's possible that this is a false alarm. Maybe Jan Kara can
> illuminate further, so I've added him to the cc list.
It is related to the design of UnionMount, isn't it?
UnionMount is not a filesystem and doen't have its own superblock.
If it was a fs, then
- vfs_truncate() acquires sb_writers for the unioning-fs.
- the unioning-fs may call vfs_truncate() again for the underlying fs.
- this time, sb_writers is for the underlying fs which is a different
sb_writers object from the already acquired one.
So there would be no deadlock.
Still lockdep will produce the message since sb_writers doesn't have the
lockdep class. Of course, we can introduce the lock class for it, or call
lockdep_off()/on() simply in order to stop the message. But, as long as
the unioning feature is not implemented as a fs, the solution will not
be so easy. I am afraid UnionMount will need to introduce a new counter
(or a new flag) to indicate the task entered the union, and adjust the
lock class or decide to call lockdep_off() for sb_writers. I don't think
it is a good idea.
J. R. Okajima
--
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