Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-04 Thread Cyrill Gorcunov
On Wed, Apr 04, 2018 at 08:54:59AM -0700, Yang Shi wrote:
> > Yeah, let's just drop it and have the patch in linux-next (via mmotm)
> > for 2 release cycles and see whether somebody complains.
> 
> BTW, I will do my v3 on top of the patch (drop off prctl_set_mm).

Sorry for delay, will do in a couple of hours.


Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-04 Thread Cyrill Gorcunov
On Wed, Apr 04, 2018 at 08:54:59AM -0700, Yang Shi wrote:
> > Yeah, let's just drop it and have the patch in linux-next (via mmotm)
> > for 2 release cycles and see whether somebody complains.
> 
> BTW, I will do my v3 on top of the patch (drop off prctl_set_mm).

Sorry for delay, will do in a couple of hours.


Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-04 Thread Yang Shi



On 4/3/18 10:35 PM, Michal Hocko wrote:

On Tue 03-04-18 16:15:20, Yang Shi wrote:


On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:

An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.

Still old interface remains present for compatibility reason
though CRIU itself already switched to PR_SET_MM_MAP on its
own long ago.

Googling didn't reveal some other users of this operation
so I think it should be safe to issue deprecation warning
first time and get rid of this interface after a couple
of releases.

CC: Andrey Vagin 
CC: Andrew Morton 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Yang Shi 
CC: Michal Hocko 
Signed-off-by: Cyrill Gorcunov 
---
Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
and I would rather prefer to do that asap.

Thanks for making it deprecated. I'd prefer just drop it off if nobody
objects. The change will get soaked in linux-next for a while , we will know
if it breaks compatibility (it sounds very unlikely).

Yeah, let's just drop it and have the patch in linux-next (via mmotm)
for 2 release cycles and see whether somebody complains.


BTW, I will do my v3 on top of the patch (drop off prctl_set_mm).

Yang



You can add
Acked-by: Michal Hocko 
for such a patch.




Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-04 Thread Yang Shi



On 4/3/18 10:35 PM, Michal Hocko wrote:

On Tue 03-04-18 16:15:20, Yang Shi wrote:


On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:

An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.

Still old interface remains present for compatibility reason
though CRIU itself already switched to PR_SET_MM_MAP on its
own long ago.

Googling didn't reveal some other users of this operation
so I think it should be safe to issue deprecation warning
first time and get rid of this interface after a couple
of releases.

CC: Andrey Vagin 
CC: Andrew Morton 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Yang Shi 
CC: Michal Hocko 
Signed-off-by: Cyrill Gorcunov 
---
Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
and I would rather prefer to do that asap.

Thanks for making it deprecated. I'd prefer just drop it off if nobody
objects. The change will get soaked in linux-next for a while , we will know
if it breaks compatibility (it sounds very unlikely).

Yeah, let's just drop it and have the patch in linux-next (via mmotm)
for 2 release cycles and see whether somebody complains.


BTW, I will do my v3 on top of the patch (drop off prctl_set_mm).

Yang



You can add
Acked-by: Michal Hocko 
for such a patch.




Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-04 Thread Cyrill Gorcunov
On Wed, Apr 04, 2018 at 07:35:41AM +0200, Michal Hocko wrote:
> > > Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
> > > and I would rather prefer to do that asap.
> > 
> > Thanks for making it deprecated. I'd prefer just drop it off if nobody
> > objects. The change will get soaked in linux-next for a while , we will know
> > if it breaks compatibility (it sounds very unlikely).
> 
> Yeah, let's just drop it and have the patch in linux-next (via mmotm)
> for 2 release cycles and see whether somebody complains.
> 
> You can add
> Acked-by: Michal Hocko 
> for such a patch.

Sure. Thanks!


Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-04 Thread Cyrill Gorcunov
On Wed, Apr 04, 2018 at 07:35:41AM +0200, Michal Hocko wrote:
> > > Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
> > > and I would rather prefer to do that asap.
> > 
> > Thanks for making it deprecated. I'd prefer just drop it off if nobody
> > objects. The change will get soaked in linux-next for a while , we will know
> > if it breaks compatibility (it sounds very unlikely).
> 
> Yeah, let's just drop it and have the patch in linux-next (via mmotm)
> for 2 release cycles and see whether somebody complains.
> 
> You can add
> Acked-by: Michal Hocko 
> for such a patch.

Sure. Thanks!


Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-03 Thread Michal Hocko
On Tue 03-04-18 16:15:20, Yang Shi wrote:
> 
> 
> On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:
> > An ability to manipulate mm_struct fields was introduced in
> > sake of CRIU in first place. Later we provide more suitable
> > and safe operation PR_SET_MM_MAP where all fields to be modifed
> > are passed in one structure which allows us to make more detailed
> > verification.
> > 
> > Still old interface remains present for compatibility reason
> > though CRIU itself already switched to PR_SET_MM_MAP on its
> > own long ago.
> > 
> > Googling didn't reveal some other users of this operation
> > so I think it should be safe to issue deprecation warning
> > first time and get rid of this interface after a couple
> > of releases.
> > 
> > CC: Andrey Vagin 
> > CC: Andrew Morton 
> > CC: Pavel Emelyanov 
> > CC: Michael Kerrisk 
> > CC: Yang Shi 
> > CC: Michal Hocko 
> > Signed-off-by: Cyrill Gorcunov 
> > ---
> > Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
> > and I would rather prefer to do that asap.
> 
> Thanks for making it deprecated. I'd prefer just drop it off if nobody
> objects. The change will get soaked in linux-next for a while , we will know
> if it breaks compatibility (it sounds very unlikely).

Yeah, let's just drop it and have the patch in linux-next (via mmotm)
for 2 release cycles and see whether somebody complains.

You can add
Acked-by: Michal Hocko 
for such a patch.
-- 
Michal Hocko
SUSE Labs


Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-03 Thread Michal Hocko
On Tue 03-04-18 16:15:20, Yang Shi wrote:
> 
> 
> On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:
> > An ability to manipulate mm_struct fields was introduced in
> > sake of CRIU in first place. Later we provide more suitable
> > and safe operation PR_SET_MM_MAP where all fields to be modifed
> > are passed in one structure which allows us to make more detailed
> > verification.
> > 
> > Still old interface remains present for compatibility reason
> > though CRIU itself already switched to PR_SET_MM_MAP on its
> > own long ago.
> > 
> > Googling didn't reveal some other users of this operation
> > so I think it should be safe to issue deprecation warning
> > first time and get rid of this interface after a couple
> > of releases.
> > 
> > CC: Andrey Vagin 
> > CC: Andrew Morton 
> > CC: Pavel Emelyanov 
> > CC: Michael Kerrisk 
> > CC: Yang Shi 
> > CC: Michal Hocko 
> > Signed-off-by: Cyrill Gorcunov 
> > ---
> > Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
> > and I would rather prefer to do that asap.
> 
> Thanks for making it deprecated. I'd prefer just drop it off if nobody
> objects. The change will get soaked in linux-next for a while , we will know
> if it breaks compatibility (it sounds very unlikely).

Yeah, let's just drop it and have the patch in linux-next (via mmotm)
for 2 release cycles and see whether somebody complains.

You can add
Acked-by: Michal Hocko 
for such a patch.
-- 
Michal Hocko
SUSE Labs


Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-03 Thread Yang Shi



On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:

An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.

Still old interface remains present for compatibility reason
though CRIU itself already switched to PR_SET_MM_MAP on its
own long ago.

Googling didn't reveal some other users of this operation
so I think it should be safe to issue deprecation warning
first time and get rid of this interface after a couple
of releases.

CC: Andrey Vagin 
CC: Andrew Morton 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Yang Shi 
CC: Michal Hocko 
Signed-off-by: Cyrill Gorcunov 
---
Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
and I would rather prefer to do that asap.


Thanks for making it deprecated. I'd prefer just drop it off if nobody 
objects. The change will get soaked in linux-next for a while , we will 
know if it breaks compatibility (it sounds very unlikely).


Yang



  kernel/sys.c |2 ++
  1 file changed, 2 insertions(+)

Index: linux-ml.git/kernel/sys.c
===
--- linux-ml.git.orig/kernel/sys.c
+++ linux-ml.git/kernel/sys.c
@@ -2052,6 +2052,8 @@ static int prctl_set_mm(int opt, unsigne
if (!capable(CAP_SYS_RESOURCE))
return -EPERM;
  
+	pr_warn_once("Non PR_SET_MM_MAP operations are deprecated\n");

+
if (opt == PR_SET_MM_EXE_FILE)
return prctl_set_mm_exe_file(mm, (unsigned int)addr);
  




Re: [RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-03 Thread Yang Shi



On 4/3/18 3:37 PM, Cyrill Gorcunov wrote:

An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.

Still old interface remains present for compatibility reason
though CRIU itself already switched to PR_SET_MM_MAP on its
own long ago.

Googling didn't reveal some other users of this operation
so I think it should be safe to issue deprecation warning
first time and get rid of this interface after a couple
of releases.

CC: Andrey Vagin 
CC: Andrew Morton 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Yang Shi 
CC: Michal Hocko 
Signed-off-by: Cyrill Gorcunov 
---
Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
and I would rather prefer to do that asap.


Thanks for making it deprecated. I'd prefer just drop it off if nobody 
objects. The change will get soaked in linux-next for a while , we will 
know if it breaks compatibility (it sounds very unlikely).


Yang



  kernel/sys.c |2 ++
  1 file changed, 2 insertions(+)

Index: linux-ml.git/kernel/sys.c
===
--- linux-ml.git.orig/kernel/sys.c
+++ linux-ml.git/kernel/sys.c
@@ -2052,6 +2052,8 @@ static int prctl_set_mm(int opt, unsigne
if (!capable(CAP_SYS_RESOURCE))
return -EPERM;
  
+	pr_warn_once("Non PR_SET_MM_MAP operations are deprecated\n");

+
if (opt == PR_SET_MM_EXE_FILE)
return prctl_set_mm_exe_file(mm, (unsigned int)addr);
  




[RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-03 Thread Cyrill Gorcunov
An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.

Still old interface remains present for compatibility reason
though CRIU itself already switched to PR_SET_MM_MAP on its
own long ago.

Googling didn't reveal some other users of this operation
so I think it should be safe to issue deprecation warning
first time and get rid of this interface after a couple
of releases.

CC: Andrey Vagin 
CC: Andrew Morton 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Yang Shi 
CC: Michal Hocko 
Signed-off-by: Cyrill Gorcunov 
---
Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
and I would rather prefer to do that asap.

 kernel/sys.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-ml.git/kernel/sys.c
===
--- linux-ml.git.orig/kernel/sys.c
+++ linux-ml.git/kernel/sys.c
@@ -2052,6 +2052,8 @@ static int prctl_set_mm(int opt, unsigne
if (!capable(CAP_SYS_RESOURCE))
return -EPERM;
 
+   pr_warn_once("Non PR_SET_MM_MAP operations are deprecated\n");
+
if (opt == PR_SET_MM_EXE_FILE)
return prctl_set_mm_exe_file(mm, (unsigned int)addr);
 


[RFC] prctl: Deprecate non PR_SET_MM_MAP operations

2018-04-03 Thread Cyrill Gorcunov
An ability to manipulate mm_struct fields was introduced in
sake of CRIU in first place. Later we provide more suitable
and safe operation PR_SET_MM_MAP where all fields to be modifed
are passed in one structure which allows us to make more detailed
verification.

Still old interface remains present for compatibility reason
though CRIU itself already switched to PR_SET_MM_MAP on its
own long ago.

Googling didn't reveal some other users of this operation
so I think it should be safe to issue deprecation warning
first time and get rid of this interface after a couple
of releases.

CC: Andrey Vagin 
CC: Andrew Morton 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Yang Shi 
CC: Michal Hocko 
Signed-off-by: Cyrill Gorcunov 
---
Or we can simply drop it off because PR_SET_MM_MAP covers all needs,
and I would rather prefer to do that asap.

 kernel/sys.c |2 ++
 1 file changed, 2 insertions(+)

Index: linux-ml.git/kernel/sys.c
===
--- linux-ml.git.orig/kernel/sys.c
+++ linux-ml.git/kernel/sys.c
@@ -2052,6 +2052,8 @@ static int prctl_set_mm(int opt, unsigne
if (!capable(CAP_SYS_RESOURCE))
return -EPERM;
 
+   pr_warn_once("Non PR_SET_MM_MAP operations are deprecated\n");
+
if (opt == PR_SET_MM_EXE_FILE)
return prctl_set_mm_exe_file(mm, (unsigned int)addr);