linux-kernel - Re: [PATCH 4.4 068/104] loop: Fold __loop_release into loop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190128133103.GD27972@quack2.suse.cz>
Date:   Mon, 28 Jan 2019 14:31:03 +0100
From:   Jan Kara <jack@...e.cz>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Jan Kara <jack@...e.cz>, Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH 4.4 068/104] loop: Fold __loop_release into loop_release

On Thu 24-01-19 20:19:57, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Jan Kara <jack@...e.cz>
> 
> commit 967d1dc144b50ad005e5eecdfadfbcfb399ffff6 upstream.
> 
> __loop_release() has a single call site. Fold it there. This is
> currently not a huge win but it will make following replacement of
> loop_index_mutex more obvious.
> 
> Signed-off-by: Jan Kara <jack@...e.cz>
> Signed-off-by: Jens Axboe <axboe@...nel.dk>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 

Hello Greg!

This and the following two (patches 69 & 70) loop patches are just
preparatory cleanups for commits 0da03cab87e632 "loop: Fix deadlock when
calling blkdev_reread_part()" and 1dded9acf6dc9a "loop: Avoid circular
locking dependency between loop_ctl_mutex and bd_mutex". As such they don't
fix anything and it doesn't make sense to carry them in stable unless
someone backports also the other patches in the series including the fixes
themselves (which honestly I don't think is worth it for stable).

								Honza

> ---
>  drivers/block/loop.c |   16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1586,12 +1586,15 @@ out:
>  	return err;
>  }
>  
> -static void __lo_release(struct loop_device *lo)
> +static void lo_release(struct gendisk *disk, fmode_t mode)
>  {
> +	struct loop_device *lo;
>  	int err;
>  
> +	mutex_lock(&loop_index_mutex);
> +	lo = disk->private_data;
>  	if (atomic_dec_return(&lo->lo_refcnt))
> -		return;
> +		goto unlock_index;
>  
>  	mutex_lock(&loop_ctl_mutex);
>  	if (lo->lo_flags & LO_FLAGS_AUTOCLEAR) {
> @@ -1601,7 +1604,7 @@ static void __lo_release(struct loop_dev
>  		 */
>  		err = loop_clr_fd(lo);
>  		if (!err)
> -			return;
> +			goto unlock_index;
>  	} else {
>  		/*
>  		 * Otherwise keep thread (if running) and config,
> @@ -1611,12 +1614,7 @@ static void __lo_release(struct loop_dev
>  	}
>  
>  	mutex_unlock(&loop_ctl_mutex);
> -}
> -
> -static void lo_release(struct gendisk *disk, fmode_t mode)
> -{
> -	mutex_lock(&loop_index_mutex);
> -	__lo_release(disk->private_data);
> +unlock_index:
>  	mutex_unlock(&loop_index_mutex);
>  }
>  
> 
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR