linux-kernel - linux-next: manual merge of the tomoyo tree with the block tree

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-next>] [day] [month] [year] [list]

Date:   Wed, 24 Nov 2021 11:38:25 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Jens Axboe <axboe@...nel.dk>
Cc:     Christoph Hellwig <hch@....de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: linux-next: manual merge of the tomoyo tree with the block tree

Hi all,

Today's linux-next merge of the tomoyo tree got a conflict in:

  drivers/block/loop.c

between commit:

  3793b8e18186 ("block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART")

from the block tree and commits:

  dfb2cc3b7f7e ("loop: don't hold lo_mutex during __loop_clr_fd()")
  51d5ae114da8 ("loop: replace loop_validate_mutex with loop_validate_spinlock")

from the tomoyo tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/block/loop.c
index 0954ea8cf9e3,6ebfa156fd9b..000000000000
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@@ -1061,9 -1041,9 +1041,9 @@@ static int loop_configure(struct loop_d
  		lo->lo_flags |= LO_FLAGS_PARTSCAN;
  	partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
  	if (partscan)
 -		lo->lo_disk->flags &= ~GENHD_FL_NO_PART_SCAN;
 +		lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
  
- 	loop_global_unlock(lo, is_loop);
+ 	loop_update_state(lo, Lo_bound);
  	if (partscan)
  		loop_reread_partitions(lo);
  	if (!(mode & FMODE_EXCL))
@@@ -1181,19 -1142,14 +1142,14 @@@ static void __loop_clr_fd(struct loop_d
  
  	/*
  	 * lo->lo_state is set to Lo_unbound here after above partscan has
- 	 * finished.
- 	 *
- 	 * There cannot be anybody else entering __loop_clr_fd() as
- 	 * lo->lo_backing_file is already cleared and Lo_rundown state
- 	 * protects us from all the other places trying to change the 'lo'
- 	 * device.
+ 	 * finished. There cannot be anybody else entering __loop_clr_fd() as
+ 	 * Lo_rundown state protects us from all the other places trying to
+ 	 * change the 'lo' device.
  	 */
- 	mutex_lock(&lo->lo_mutex);
  	lo->lo_flags = 0;
  	if (!part_shift)
 -		lo->lo_disk->flags |= GENHD_FL_NO_PART_SCAN;
 +		lo->lo_disk->flags |= GENHD_FL_NO_PART;
- 	lo->lo_state = Lo_unbound;
- 	mutex_unlock(&lo->lo_mutex);
+ 	loop_update_state(lo, Lo_unbound);
  
  	/*
  	 * Need not hold lo_mutex to fput backing file. Calling fput holding
@@@ -2032,9 -1985,11 +1985,10 @@@ static int loop_add(int i
  	 * userspace tools. Parameters like this in general should be avoided.
  	 */
  	if (!part_shift)
 -		disk->flags |= GENHD_FL_NO_PART_SCAN;
 -	disk->flags |= GENHD_FL_EXT_DEVT;
 +		disk->flags |= GENHD_FL_NO_PART;
  	atomic_set(&lo->lo_refcnt, 0);
  	mutex_init(&lo->lo_mutex);
+ 	loop_update_state(lo, Lo_unbound);
  	lo->lo_number		= i;
  	spin_lock_init(&lo->lo_lock);
  	spin_lock_init(&lo->lo_work_lock);

Content of type "application/pgp-signature" skipped