On Sun, 1 Feb 2015 12:36:57 +0100 Fabian Frederick <[email protected]> wrote:
> Let locking subsystem decide on mutex management.
>
> ...
>
> --- a/fs/ufs/super.c
> +++ b/fs/ufs/super.c
> @@ -95,22 +95,18 @@
>
> 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
> }
Good heavens.
This patch is a bugfix. lock_ufs() is assuming that on non-preempt
uniprocessor, the calling code will run atomically up to the matching
unlock_ufs().
But that isn't true. The very first site I looked at (ufs_frag_map)
does sb_bread() under lock_ufs(. And sb_bread() will call schedule(),
very commonly.
The ->mutex_owner stuff is a bit hacky but should work OK.
Care to resend the patch with a more alarming changelog?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
