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);
On 11/23/21 5:38 PM, Stephen Rothwell wrote:
> 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.
Why does the tomoyo tree have loop commits is the question?
--
Jens Axboe
On 2021/11/24 11:06, Jens Axboe wrote:
>
> Why does the tomoyo tree have loop commits is the question?
>
I'm testing patches using my tree until maintainers respond.
On 11/23/21 7:25 PM, Tetsuo Handa wrote:
> On 2021/11/24 11:06, Jens Axboe wrote:
>>
>> Why does the tomoyo tree have loop commits is the question?
>>
>
> I'm testing patches using my tree until maintainers respond.
It's a week old, please don't put patches from an unrelated tree
into a different tree.
--
Jens Axboe