Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
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..
>> --- 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(>lock);
>> +else if (!mutex_trylock(>lock))
>> +return -EAGAIN;
>>
>> -mutex_lock(>lock);
>> list_for_each_entry(map, >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
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
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..
> --- 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(>lock);
> + else if (!mutex_trylock(>lock))
> + return -EAGAIN;
>
> - mutex_lock(>lock);
> list_for_each_entry(map, >maps, next) {
> + if (in_range(map, start, end)) {
> + ret = -EAGAIN;
> + goto out_unlock;
> + }
> unmap_if_in_range(map, start, end);
> }
> list_for_each_entry(map, >freeable_maps, next) {
This is now a conflict between Linus' tree and the akpm-current tree.
--
Cheers,
Stephen Rothwell
pgpVyemEAhotn.pgp
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
On 07/30/2018 01:02 PM, Boris Ostrovsky wrote:
> On 07/30/2018 05:02 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> 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.. --- 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(>lock); + else if (!mutex_trylock(>lock)) +
>> return -EAGAIN; - mutex_lock(>lock); list_for_each_entry(map,
>> >maps, next) { + if (in_range(map, start, end)) { + ret =
>> -EAGAIN; + goto out_unlock; + } unmap_if_in_range(map, start, end); }
>> list_for_each_entry(map, >freeable_maps, next) {
Ugh... That's some interesting whitespace optimization on part of
thundebird. Let me paste the relevant patch hunk here.
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index bd56653b9bbc..55b4f0e3f4d6 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -441,18 +441,25 @@ static const struct vm_operations_struct gntdev_vmops = {
/* -- */
+static bool in_range(struct 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,
unsigned long start, unsigned long end)
{
unsigned long mstart, mend;
int err;
- if (!map->vma)
- return;
- if (map->vma->vm_start >= end)
- return;
- if (map->vma->vm_end <= start)
- return;
mstart = max(start, map->vma->vm_start);
mend = min(end, map->vma->vm_end);
pr_debug("map %d+%d (%lx %lx), range %lx %lx, mrange %lx %lx\n",
@@ -465,21 +472,40 @@ static void unmap_if_in_range(struct grant_map *map,
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;
+ int ret = 0;
+
+ /* TODO do we really need a mutex here? */
+ if (blockable)
+ mutex_lock(>lock);
+ else if (!mutex_trylock(>lock))
+ return -EAGAIN;
- mutex_lock(>lock);
list_for_each_entry(map, >maps, next) {
+ if (in_range(map, start, end)) {
+ ret = -EAGAIN;
+ goto out_unlock;
+ }
unmap_if_in_range(map, start, end);
}
list_for_each_entry(map, >freeable_maps, next) {
+ if (in_range(map, start, end)) {
+
Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree
On 07/30/2018 05:02 AM, Stephen Rothwell wrote:
> Hi all,
>
> 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.. --- 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(>lock); + else if (!mutex_trylock(>lock)) +
> return -EAGAIN; - mutex_lock(>lock); list_for_each_entry(map,
> >maps, next) { + if (in_range(map, start, end)) { + ret =
> -EAGAIN; + goto out_unlock; + } unmap_if_in_range(map, start, end); }
> list_for_each_entry(map, >freeable_maps, next) {
I clearly missed this (aaefcabe9c25) patch but now that I am looking at
it I don't think I understand the logic for changes in
list_for_each_entry() loops.
Aren't we ending up never unmapping grant pages? Michal, can you explain
what you are trying to do here?
-boris
signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
