[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101116214233.GB15180@quack.suse.cz>
Date: Tue, 16 Nov 2010 22:42:33 +0100
From: Jan Kara <jack@...e.cz>
To: Christoph Hellwig <hch@...radead.org>
Cc: Alessio Igor Bogani <abogani@...ware.it>, Jan Kara <jack@...e.cz>,
Arnd Bergmann <arnd@...db.de>, Tim Bird <tim.bird@...sony.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/3] udf: Replace bkl with the inode->i_alloc_sem for
protect udf_inode_info struct
On Tue 16-11-10 13:05:44, Christoph Hellwig wrote:
> On Tue, Nov 16, 2010 at 06:40:47PM +0100, Alessio Igor Bogani wrote:
> > Replace bkl with the inode->i_alloc_sem rw semaphore in udf_release_file(),
> > udf_symlink(), udf_symlink_filler(), udf_get_block() and udf_block_map().
> > Add protection in udf_evict_inode() using the same i_alloc_sem rw semaphore.
>
> I'd rather prefer not to introduce new users of i_alloc_sem. It's a
> quite nasty beast: the only rw_semaphore that is not released by the
> thread acquiring it. Thomas asked me if there's a way to get rid of it,
> and I've come up with some schemes that I need to prototype. Adding
> more uses that are unrelated to the original direct I/O use case are
> not very helpful in doing that.
OK, I didn't know this. It's no problem to replace i_alloc_sem with a
private rw_semaphore so I can do that. I just thought we might as well use
it when it's there and not waste more inode memory...
Honza
--
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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