On 08/15/2018 08:05 PM, Stephen Rothwell wrote: > Hi all, > > On Mon, 30 Jul 2018 19:02:10 +1000 Stephen Rothwell wrote: >> Today's linux-next merge of the akpm-current tree got a conflict in: >> >> drivers/xen/gntdev.c >> >> between commit: >> >> 1d3145675538 ("xen/gntdev: Make private routines/structures accessible") >> >> from the xen-tip tree and commit: >> >> aaefcabe9c25 ("mm, oom: distinguish blockable mode for mmu notifiers") >> >> from the akpm-current 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/xen/gntdev.c >> index c866a62f766d,55b4f0e3f4d6..000000000000 >> --- a/drivers/xen/gntdev.c >> +++ b/drivers/xen/gntdev.c >> @@@ -479,7 -441,20 +479,20 @@@ static const struct vm_operations_struc >> >> /* ------------------------------------------------------------------ */ >> >> -static bool in_range(struct grant_map *map, >> ++static bool in_range(struct gntdev_grant_map *map, >> + unsigned long start, unsigned long end) >> + { >> + if (!map->vma) >> + return false; >> + if (map->vma->vm_start >= end) >> + return false; >> + if (map->vma->vm_end <= start) >> + return false; >> + >> + return true; >> + } >> + >> -static void unmap_if_in_range(struct grant_map *map, >> +static void unmap_if_in_range(struct gntdev_grant_map *map, >> unsigned long start, unsigned long end) >> { >> unsigned long mstart, mend; >> @@@ -503,15 -472,26 +510,26 @@@ >> WARN_ON(err); >> } >> >> - static void mn_invl_range_start(struct mmu_notifier *mn, >> + static int mn_invl_range_start(struct mmu_notifier *mn, >> struct mm_struct *mm, >> - unsigned long start, unsigned long end) >> + unsigned long start, unsigned long end, >> + bool blockable) >> { >> struct gntdev_priv *priv = container_of(mn, struct gntdev_priv, mn); >> - struct grant_map *map; >> + struct gntdev_grant_map *map; >> + int ret = 0; >> + >> + /* TODO do we really need a mutex here? */ >> + if (blockable) >> + mutex_lock(&priv->lock); >> + else if (!mutex_trylock(&priv->lock)) >> + return -EAGAIN; >> >> - mutex_lock(&priv->lock); >> list_for_each_entry(map, &priv->maps, next) { >> + if (in_range(map, start, end)) { >> + ret = -EAGAIN; >> + goto out_unlock; >> + } >> unmap_if_in_range(map, start, end); I think I mentioned this earlier --- this doesn't look right. Not the conflict resolution but the original patch. Should I send a patch against -next? Or -mm? -boris