[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110126023031.GA3160@elliptictech.com>
Date: Tue, 25 Jan 2011 21:30:31 -0500
From: Nick Bowler <nbowler@...iptictech.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, Evgeniy Dushistov <dushistov@...l.ru>
Subject: Re: [PATCH 15/20] ufs: remove the BKL
On 2011-01-25 23:17 +0100, Arnd Bergmann wrote:
> This introduces a new per-superblock mutex in UFS to replace
> the big kernel lock. I have been careful to avoid nested
> calls to lock_ufs and to get the lock order right with
> respect to other mutexes, in particular lock_super.
>
> The code is still only compile-tested, but it should
> at least be harmless on non-SMP systems, since the
> new mutex is not taken on those.
[...]
> +void lock_ufs(struct super_block *sb)
> +{
> +#if defined(CONFIG_SMP) || defined (CONFIG_PREEMPT)
> + struct ufs_sb_info *sbi = UFS_SB(sb);
> +
> + mutex_lock(&sbi->mutex);
> + sbi->mutex_owner = current;
> +#endif
> +}
> +
> +void unlock_ufs(struct super_block *sb)
> +{
> +#if defined(CONFIG_SMP) || defined (CONFIG_PREEMPT)
> + struct ufs_sb_info *sbi = UFS_SB(sb);
> +
> + sbi->mutex_owner = NULL;
> + mutex_unlock(&sbi->mutex);
> +#endif
> +}
The sbi->mutex lock used by these functions is never initialized, which
causes an insta-crash on mount. With a mutex_init call added to
ufs_fill_super, there are no obvious problems with my read-only
mounts after some (very light) testing.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
--
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