[PATCH]: xarray: Fix potential out of bounds access

Since the mark is used as an array index we should use preincrement to not access the XA_MARK_MAX index. Cc: Matthew Wilcox Signed-off-by: Cyrill Gorcunov --- Matthew, take a look please, I suspect we may access the mark index out of allocated one. Compile tested only. It comes from

[PATCH next]: xarray: Fix typo in comment

Seems copy and paste typo, not a big deal but still for consistency sake better to fix. Signed-off-by: Cyrill Gorcunov --- include/linux/xarray.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-next.git/include/linux/xarray.h

Re: [PATCH 01/12] x86_64: memset_user()

On Fri, Dec 21, 2018 at 01:07:21PM -0800, Matthew Wilcox wrote: > On Fri, Dec 21, 2018 at 11:46:16PM +0300, Cyrill Gorcunov wrote: > > Cast to unsigned char is needed in any case. And as far as I remember > > we've been using this multiplication trick for a really long time >

Re: [PATCH 01/12] x86_64: memset_user()

On Fri, Dec 21, 2018 at 12:29:46PM -0800, Matthew Wilcox wrote: > > > > > > That's inefficient. > > > > > > pattern = (unsigned char)c; > > > pattern |= pattern << 8; > > > pattern |= pattern << 16; > > > pattern |= pattern << 32; > > > > Won't > > > > pattern = 0x0101010101010101

Re: [PATCH v2] fs/proc: timers -- Test for potential index overflow

On Fri, Nov 09, 2018 at 02:31:53PM +0300, Cyrill Gorcunov wrote: > When showing timer's notify symbolic name make sure we never fetch a value > sitting outside of the names array. Though the former issue displaying > timer->it_sigev_notify has been fixed by Thomas in commit cef3

Re: [PATCH 01/12] x86_64: memset_user()

On Fri, Dec 21, 2018 at 10:25:16AM -0800, Matthew Wilcox wrote: > On Fri, Dec 21, 2018 at 08:14:12PM +0200, Igor Stoppa wrote: > > +unsigned long __memset_user(void __user *addr, int c, unsigned long size) > > +{ > > + long __d0; > > + unsigned long pattern = 0; > > + int i; > > + > > +

Re: [PATCH v3] ksm: React on changing "sleep_millisecs" parameter faster

ai > > v3: Do not use mutex: to acquire it may take much time in case long > list of ksm'able mm and pages. > v2: Use wait_event_interruptible_timeout() instead of unconditional > schedule_timeout(). Looks ok to me, thanks! Acked-by: Cyrill Gorcunov

Re: [PATCH v2] ksm: React on changing "sleep_millisecs" parameter faster

On Tue, Dec 11, 2018 at 03:22:42PM +0300, Kirill Tkhai wrote: > On 11.12.2018 14:13, Cyrill Gorcunov wrote: > > On Tue, Dec 11, 2018 at 01:26:59PM +0300, Kirill Tkhai wrote: > >> ksm thread unconditionally sleeps in ksm_scan_thread() > &g

Re: [PATCH v2] ksm: React on changing "sleep_millisecs" parameter faster

On Tue, Dec 11, 2018 at 01:26:59PM +0300, Kirill Tkhai wrote: > ksm thread unconditionally sleeps in ksm_scan_thread() > after each iteration: > > schedule_timeout_interruptible( > msecs_to_jiffies(ksm_thread_sleep_millisecs)) > > The timeout is configured in

Re: [PATCH] ksm: React on changing "sleep_millisecs" parameter faster

On Tue, Dec 11, 2018 at 12:23:11PM +0300, Kirill Tkhai wrote: ... > > Kirill, can we rather reuse @ksm_thread variable from ksm_init > > (by moving it to static file level variable). > > I've considered using it, but this is not looks good for me. > The problem is ksm thread may be parked, or it

Re: [PATCH] ksm: React on changing "sleep_millisecs" parameter faster

On Mon, Dec 10, 2018 at 07:06:18PM +0300, Kirill Tkhai wrote: > ksm thread unconditionally sleeps in ksm_scan_thread() > after each iteration: > > schedule_timeout_interruptible( > msecs_to_jiffies(ksm_thread_sleep_millisecs)) > > The timeout is configured in

Re: [PATCH v2] proc: fixup map_files test on arm

Tinoco > Signed-off-by: Alexey Dobriyan Acked-by: Cyrill Gorcunov Thank you!

Re: [PATCH v2] proc: fixup map_files test on arm

Tinoco > Signed-off-by: Alexey Dobriyan Acked-by: Cyrill Gorcunov Thank you!

Re: [PATCH] proc: fixup map_files test on arm

On Mon, Nov 12, 2018 at 05:14:57PM +0300, Alexey Dobriyan wrote: ... > > > int main(void) > > > { > > > const unsigned int PAGE_SIZE = sysconf(_SC_PAGESIZE); > > > +#ifdef __arm__ > > > + unsigned long va = 2 * PAGE_SIZE; > > > +#else > > > + unsigned long va = 0; > > > +#endif ... > > > > I

Re: [PATCH] proc: fixup map_files test on arm

On Mon, Nov 12, 2018 at 05:14:57PM +0300, Alexey Dobriyan wrote: ... > > > int main(void) > > > { > > > const unsigned int PAGE_SIZE = sysconf(_SC_PAGESIZE); > > > +#ifdef __arm__ > > > + unsigned long va = 2 * PAGE_SIZE; > > > +#else > > > + unsigned long va = 0; > > > +#endif ... > > > > I

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 04:48:49PM -0200, Rafael David Tinoco wrote: > > let me see if I got this right.. the premise for this test is to have *at > least* > 2 vmas, so we can check if the symlink for the mem range, describing the > mapped > area, is correct in procfs files, correct ? if yes,

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 04:48:49PM -0200, Rafael David Tinoco wrote: > > let me see if I got this right.. the premise for this test is to have *at > least* > 2 vmas, so we can check if the symlink for the mem range, describing the > mapped > area, is correct in procfs files, correct ? if yes,

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 10:01:13AM -0200, Rafael David Tinoco wrote: > > Alright, I'm fixing membarrier_test before, so.. I guess we have a > competition.. =o) Rafael, Alexey, what about simply wrap the test code with x86 and extend later with all archs which support zero address mapping? ---

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 10:01:13AM -0200, Rafael David Tinoco wrote: > > Alright, I'm fixing membarrier_test before, so.. I guess we have a > competition.. =o) Rafael, Alexey, what about simply wrap the test code with x86 and extend later with all archs which support zero address mapping? ---

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 09:45:36AM -0200, Rafael David Tinoco wrote: ... > > today evening or tomorrow. I think this way everybody will be > > happy: procfs get passed on arm32 and x86 will still have first > > page testing. > > Ohh, my understanding was that this was going to be addressed in

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 09:45:36AM -0200, Rafael David Tinoco wrote: ... > > today evening or tomorrow. I think this way everybody will be > > happy: procfs get passed on arm32 and x86 will still have first > > page testing. > > Ohh, my understanding was that this was going to be addressed in

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 09:30:36AM -0200, Rafael David Tinoco wrote: > Merge proc-self-map-files tests into one since this test should focus in > testing readlink in /proc/self/map_files/* only, and not trying to test > mapping virtual address 0. > > Lowest virtual address for user space mapping

Re: [PATCH] proc: fix and merge proc-self-map-file tests

On Fri, Nov 09, 2018 at 09:30:36AM -0200, Rafael David Tinoco wrote: > Merge proc-self-map-files tests into one since this test should focus in > testing readlink in /proc/self/map_files/* only, and not trying to test > mapping virtual address 0. > > Lowest virtual address for user space mapping

[PATCH v2] fs/proc: timers -- Test for potential index overflow

Use explicit index overflow test (by tglx@). Since it should never happen add warn-once to notify. Cc: Andrey Vagin Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Signed-off-by: Cyrill Gorcunov --- fs/proc/base.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-ml.git

[PATCH v2] fs/proc: timers -- Test for potential index overflow

Use explicit index overflow test (by tglx@). Since it should never happen add warn-once to notify. Cc: Andrey Vagin Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Signed-off-by: Cyrill Gorcunov --- fs/proc/base.c |6 ++ 1 file changed, 6 insertions(+) Index: linux-ml.git

Re: [PATCH] posix-timers: Use array safe helper when fetching notification symbolic name

On Fri, Nov 09, 2018 at 10:18:25AM +0100, Thomas Gleixner wrote: > > + nidx = array_index_nospec(notify & ~SIGEV_THREAD_ID, ARRAY_SIZE(nstr)); > > I completely understand your intention, but this is misleading. The above > is really not a speculation gadget. > > I'd rather do an open coded

Re: [PATCH] posix-timers: Use array safe helper when fetching notification symbolic name

On Fri, Nov 09, 2018 at 10:18:25AM +0100, Thomas Gleixner wrote: > > + nidx = array_index_nospec(notify & ~SIGEV_THREAD_ID, ARRAY_SIZE(nstr)); > > I completely understand your intention, but this is misleading. The above > is really not a speculation gadget. > > I'd rather do an open coded

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Thu, Nov 08, 2018 at 08:41:46AM -0200, Rafael David Tinoco wrote: > > > > As to me -- yes, I would move zero page testing to a separate memory > > testcase. > > But since Alexey is the former author of the tests better wait for his > > opinion. > > Alexey, > > would you care if we turn

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Thu, Nov 08, 2018 at 08:41:46AM -0200, Rafael David Tinoco wrote: > > > > As to me -- yes, I would move zero page testing to a separate memory > > testcase. > > But since Alexey is the former author of the tests better wait for his > > opinion. > > Alexey, > > would you care if we turn

[PATCH] posix-timers: Use array safe helper when fetching notification symbolic name

Cc: Andrey Vagin Cc: Thomas Gleixner Signed-off-by: Cyrill Gorcunov --- fs/proc/base.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-ml.git/fs/proc/base.c === --- linux-ml.git.orig/fs/proc/base.c +++ li

[PATCH] posix-timers: Use array safe helper when fetching notification symbolic name

Cc: Andrey Vagin Cc: Thomas Gleixner Signed-off-by: Cyrill Gorcunov --- fs/proc/base.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: linux-ml.git/fs/proc/base.c === --- linux-ml.git.orig/fs/proc/base.c +++ li

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Mon, Oct 15, 2018 at 01:55:14PM -0300, Rafael David Tinoco wrote: > That is what I also had in mind, thus the patch. I just realized we had > another issue on LKFT (our functional tests tool) for > proc-self-map-files-001.c. Test 001 does pretty much the same as 002, but > without the MAP_FIXED

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Mon, Oct 15, 2018 at 01:55:14PM -0300, Rafael David Tinoco wrote: > That is what I also had in mind, thus the patch. I just realized we had > another issue on LKFT (our functional tests tool) for > proc-self-map-files-001.c. Test 001 does pretty much the same as 002, but > without the MAP_FIXED

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Fri, Oct 12, 2018 at 12:30:06AM +0300, Alexey Dobriyan wrote: > On Fri, Oct 12, 2018 at 12:02:56AM +0300, Cyrill Gorcunov wrote: > > On Thu, Oct 11, 2018 at 11:56:01PM +0300, Alexey Dobriyan wrote: > > > > > > As the comment in the beginning says this test is specifi

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Fri, Oct 12, 2018 at 12:30:06AM +0300, Alexey Dobriyan wrote: > On Fri, Oct 12, 2018 at 12:02:56AM +0300, Cyrill Gorcunov wrote: > > On Thu, Oct 11, 2018 at 11:56:01PM +0300, Alexey Dobriyan wrote: > > > > > > As the comment in the beginning says this test is specifi

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Thu, Oct 11, 2018 at 11:56:01PM +0300, Alexey Dobriyan wrote: > > As the comment in the beginning says this test is specifically for addresss 0. > Maybe it should be ifdeffed with __arm__ then. Is there some other reason than allocating non-mergable VMA?

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

On Thu, Oct 11, 2018 at 11:56:01PM +0300, Alexey Dobriyan wrote: > > As the comment in the beginning says this test is specifically for addresss 0. > Maybe it should be ifdeffed with __arm__ then. Is there some other reason than allocating non-mergable VMA?

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

with another vmas. Fore sure most of x86 standart application won't be using 8K address as well, so should do the trick I think. (Strictlly speaking the test should be rather parsing own maps first and find unused address instead but whatever :) Reviewed-by: Cyrill Gorcunov

Re: [PATCH] proc: fix proc-self-map-files selftest for arm

with another vmas. Fore sure most of x86 standart application won't be using 8K address as well, so should do the trick I think. (Strictlly speaking the test should be rather parsing own maps first and find unused address instead but whatever :) Reviewed-by: Cyrill Gorcunov

Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()

On Fri, Sep 28, 2018 at 02:15:09PM -0700, Andrew Morton wrote: > What did he report? Was it code inspection? Did the kernel explode? > etcetera. I'm thinking that the fix should be backported but to > determine that, we need to understand the end-user runtime effects, as > always. Please.

Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()

On Fri, Sep 28, 2018 at 02:15:09PM -0700, Andrew Morton wrote: > What did he report? Was it code inspection? Did the kernel explode? > etcetera. I'm thinking that the fix should be backported but to > determine that, we need to understand the end-user runtime effects, as > always. Please.

Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()

f objects returned by do_shrink_slab() > may be interpreted as SHRINK_EMPTY, if low bytes of > their value are equal to 0xfffe. Fix that > by declaration ret as unsigned long in these functions. > > Reported-by: Cyrill Gorcunov > Signed-off-by: Kirill Tkhai Acked-by: Cyrill Gorcunov Thank you!

Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()

f objects returned by do_shrink_slab() > may be interpreted as SHRINK_EMPTY, if low bytes of > their value are equal to 0xfffe. Fix that > by declaration ret as unsigned long in these functions. > > Reported-by: Cyrill Gorcunov > Signed-off-by: Kirill Tkhai Acked-by: Cyrill Gorcunov Thank you!

Re: [linux-next] BUG triggered in ptraceme

On Thu, Sep 27, 2018 at 05:35:10PM +0200, Jann Horn wrote: ... > > > > Lets wait for fs people opinions. > > No reply yet - I guess I should just fix up the traceme case for now. Yes please.

Re: [linux-next] BUG triggered in ptraceme

On Thu, Sep 27, 2018 at 05:35:10PM +0200, Jann Horn wrote: ... > > > > Lets wait for fs people opinions. > > No reply yet - I guess I should just fix up the traceme case for now. Yes please.

Re: different capability from different namespace required for prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 07:37:14PM -0400, TongZhang wrote: > I can see there are two problems, > > First: In kernel/sys.c:2117 capable(CAP_SYS_RESOURCE), seems that ns_capable > should > be used to check capability against user namespace, instead of init_user_ns. > Because a > process in a

Re: different capability from different namespace required for prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 07:37:14PM -0400, TongZhang wrote: > I can see there are two problems, > > First: In kernel/sys.c:2117 capable(CAP_SYS_RESOURCE), seems that ns_capable > should > be used to check capability against user namespace, instead of init_user_ns. > Because a > process in a

Re: different capability from different namespace required for prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 08:40:54PM +0200, Greg KH wrote: > > > > It is done this way on purpose. The prctl_set_mm_map is a complex call > > which carries a bunch of parameters and allowed if you're inside user-ns > > admin, > > in turn prctl_set_mm allows to modify settings one by one. So no, it

Re: different capability from different namespace required for prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 08:40:54PM +0200, Greg KH wrote: > > > > It is done this way on purpose. The prctl_set_mm_map is a complex call > > which carries a bunch of parameters and allowed if you're inside user-ns > > admin, > > in turn prctl_set_mm allows to modify settings one by one. So no, it

Re: Leaking path for set_task_comm

On Tue, Sep 25, 2018 at 01:27:08PM -0400, Tong Zhang wrote: > Kernel Version: 4.18.5 > > Problem Description: > > When using prctl(PR_SET_NAME) to set the thread name, it is checked by > security_task_prctl. > > We discovered a leaking path that can also use method implemented in >

Re: Leaking path for set_task_comm

On Tue, Sep 25, 2018 at 01:27:08PM -0400, Tong Zhang wrote: > Kernel Version: 4.18.5 > > Problem Description: > > When using prctl(PR_SET_NAME) to set the thread name, it is checked by > security_task_prctl. > > We discovered a leaking path that can also use method implemented in >

Re: different capability from different namespace required for prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 07:37:45PM +0200, Greg KH wrote: > On Tue, Sep 25, 2018 at 01:26:55PM -0400, Tong Zhang wrote: > > Kernel Version: 4.18.5 > > > > Problem Description: > > > > We discovered inconsistent check when using prctl_set_mm_exe_file(), which > > is used to setup exe file link. >

Re: different capability from different namespace required for prctl_set_mm_exe_file

On Tue, Sep 25, 2018 at 07:37:45PM +0200, Greg KH wrote: > On Tue, Sep 25, 2018 at 01:26:55PM -0400, Tong Zhang wrote: > > Kernel Version: 4.18.5 > > > > Problem Description: > > > > We discovered inconsistent check when using prctl_set_mm_exe_file(), which > > is used to setup exe file link. >

Re: [RFC 02/20] timens: Add timens_offsets

On Thu, Sep 20, 2018 at 09:45:10PM +0300, Cyrill Gorcunov wrote: > On Wed, Sep 19, 2018 at 09:50:19PM +0100, Dmitry Safonov wrote: > > From: Andrei Vagin > > > > Introduce offsets for time namespace. They will contain adjustment > > needed to convert clocks to/from ho

Re: [RFC 02/20] timens: Add timens_offsets

On Thu, Sep 20, 2018 at 09:45:10PM +0300, Cyrill Gorcunov wrote: > On Wed, Sep 19, 2018 at 09:50:19PM +0100, Dmitry Safonov wrote: > > From: Andrei Vagin > > > > Introduce offsets for time namespace. They will contain adjustment > > needed to convert clocks to/from ho

Re: [RFC 02/20] timens: Add timens_offsets

On Wed, Sep 19, 2018 at 09:50:19PM +0100, Dmitry Safonov wrote: > From: Andrei Vagin > > Introduce offsets for time namespace. They will contain adjustment > needed to convert clocks to/from host's. > > Allocate one page for each time namespace that will be premapped into > userspace with vvar

Re: [RFC 02/20] timens: Add timens_offsets

On Wed, Sep 19, 2018 at 09:50:19PM +0100, Dmitry Safonov wrote: > From: Andrei Vagin > > Introduce offsets for time namespace. They will contain adjustment > needed to convert clocks to/from host's. > > Allocate one page for each time namespace that will be premapped into > userspace with vvar

Re: [linux-next] BUG triggered in ptraceme

On Wed, Sep 19, 2018 at 04:16:50PM +0200, Jann Horn wrote: ... > > > > Heh, actually not :) It is due to commit > > > > commit 1f8266ff58840d698a1e96d2274189de1bdf7969 > > Author: Jann Horn > > Date: Thu Sep 13 18:12:09 2018 +0200 > > > > which introduced might_sleep. Seems it is bad idea to

Re: [linux-next] BUG triggered in ptraceme

On Wed, Sep 19, 2018 at 04:16:50PM +0200, Jann Horn wrote: ... > > > > Heh, actually not :) It is due to commit > > > > commit 1f8266ff58840d698a1e96d2274189de1bdf7969 > > Author: Jann Horn > > Date: Thu Sep 13 18:12:09 2018 +0200 > > > > which introduced might_sleep. Seems it is bad idea to

Re: [linux-next] BUG triggered in ptraceme

On Wed, Sep 19, 2018 at 10:07:37AM +0300, Cyrill Gorcunov wrote: > Hi Oleg! While been testing criu with linux-next we've triggered a BUG. > https://api.travis-ci.org/v3/job/430308998/log.txt > > [2.461618] BUG: sleeping function called from invalid context at > security/a

Re: [linux-next] BUG triggered in ptraceme

On Wed, Sep 19, 2018 at 10:07:37AM +0300, Cyrill Gorcunov wrote: > Hi Oleg! While been testing criu with linux-next we've triggered a BUG. > https://api.travis-ci.org/v3/job/430308998/log.txt > > [2.461618] BUG: sleeping function called from invalid context at > security/a

[linux-next] BUG triggered in ptraceme

Hi Oleg! While been testing criu with linux-next we've triggered a BUG. https://api.travis-ci.org/v3/job/430308998/log.txt [2.461618] BUG: sleeping function called from invalid context at security/apparmor/include/cred.h:154 [2.461794] in_atomic(): 1, irqs_disabled(): 1, pid: 152, name:

[linux-next] BUG triggered in ptraceme

Hi Oleg! While been testing criu with linux-next we've triggered a BUG. https://api.travis-ci.org/v3/job/430308998/log.txt [2.461618] BUG: sleeping function called from invalid context at security/apparmor/include/cred.h:154 [2.461794] in_atomic(): 1, irqs_disabled(): 1, pid: 152, name:

Re: [linux-next] Kernel panic while tetsing criu

On Thu, Aug 16, 2018 at 09:51:36AM -0500, Eric W. Biederman wrote: ... > > That patch is incorrect as it misses the rcu_read_unlock. > > > > p.s. Andrew noticed the problem and asked me to notify, > > also he has been testing this oneliner patch. I'm out > > of sources at the moment but I think

Re: [linux-next] Kernel panic while tetsing criu

On Thu, Aug 16, 2018 at 09:51:36AM -0500, Eric W. Biederman wrote: ... > > That patch is incorrect as it misses the rcu_read_unlock. > > > > p.s. Andrew noticed the problem and asked me to notify, > > also he has been testing this oneliner patch. I'm out > > of sources at the moment but I think

[linux-next] Kernel panic while tetsing criu

Hi Eric! We're regularly running criu on linux-next and today kernel get panicing. --- [ 753.478579] BUG: unable to handle kernel NULL pointer dereference at 06a8 [ 753.479674] PGD 80011215f067 P4D 80011215f067 PUD 1134a8067 PMD 0 [ 753.480590] Oops: [#1] SMP PTI [

[linux-next] Kernel panic while tetsing criu

Hi Eric! We're regularly running criu on linux-next and today kernel get panicing. --- [ 753.478579] BUG: unable to handle kernel NULL pointer dereference at 06a8 [ 753.479674] PGD 80011215f067 P4D 80011215f067 PUD 1134a8067 PMD 0 [ 753.480590] Oops: [#1] SMP PTI [

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote: > Josh Triplett writes: > > > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > >> For a config option that no one has come forward with an actual real > >> world use case for disabling, that cost seems much

Re: [PATCH] kconfig: remove EXPERT from CHECKPOINT_RESTORE

On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote: > Josh Triplett writes: > > > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote: > >> For a config option that no one has come forward with an actual real > >> world use case for disabling, that cost seems much

Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes

On Fri, Jun 08, 2018 at 05:27:10PM +0300, Konstantin Khorenko wrote: > The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid > and use fs-specific l_pid for remote locks") > and now /proc/$PID/fdinfo/$FD does not show the info about the lock > * if the flock owner process is

Re: [PATCH 0/2] fs/lock: show locks info owned by dead/invisible processes

On Fri, Jun 08, 2018 at 05:27:10PM +0300, Konstantin Khorenko wrote: > The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid > and use fs-specific l_pid for remote locks") > and now /proc/$PID/fdinfo/$FD does not show the info about the lock > * if the flock owner process is

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

openvz.org> > Cc: Dmitry Safonov <0x7f454...@gmail.com> > Cc: "H. Peter Anvin" <h...@zytor.com> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: "Kirill A. Shutemov" <kirill.shute...@linux.intel.com> > Cc: Thomas Gleixner <t...@linutronix.de

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

ASE: 0x7f63b8309000 > AT_BASE: 0x7faec143c000 > AT_BASE: 0x7fbdb25fa000 > > $ gcc -m32 wrap.c -o wrap32 > $ LD_SHOW_AUXV=1 ./wrap32 ./wrap true |& grep AT_BASE > AT_BASE: 0xf7eff000 > AT_BASE: 0xf7cee000 > AT_BASE: 0x7f8b9774e000

[rfc linux-next 3/3] [RFC] prctl: prctl_set_mm -- Bring back handling of PR_SET_MM_x

ibaba.com> CC: Michal Hocko <mho...@kernel.org> Signed-off-by: Cyrill Gorcunov <gorcu...@gmail.com> --- kernel/sys.c | 65 +++ 1 file changed, 57 insertions(+), 8 dele

[rfc linux-next 3/3] [RFC] prctl: prctl_set_mm -- Bring back handling of PR_SET_MM_x

to continue utilizing the interface. CC: Jonathan de Boyne Pollard CC: Andrey Vagin CC: Andrew Morton CC: Michael Kerrisk CC: Yang Shi CC: Michal Hocko Signed-off-by: Cyrill Gorcunov --- kernel/sys.c | 65 +++ 1 file changed, 57

[rfc linux-next 0/3] prctl: prctl_set_mm -- Bring back handling of PR_SET_MM_x

Hi! Yesterday I've been pointed out that we unfortunatelly can't drop off PR_SET_MM_x operations. So here is a series which bring them back but instead of plain revert I tried to simplify the code and make it as minimum as possible. WARN: the series is compile-tested only for a while, I wanted to

[rfc linux-next 0/3] prctl: prctl_set_mm -- Bring back handling of PR_SET_MM_x

Hi! Yesterday I've been pointed out that we unfortunatelly can't drop off PR_SET_MM_x operations. So here is a series which bring them back but instead of plain revert I tried to simplify the code and make it as minimum as possible. WARN: the series is compile-tested only for a while, I wanted to

[rfc linux-next 1/3] [RFC] prctl: prctl_set_mm -- Move PR_SET_MM_MAP_SIZE out of prctl_set_mm_map

gt; CC: Andrey Vagin <ava...@openvz.org> CC: Andrew Morton <a...@linuxfoundation.org> CC: Michael Kerrisk <mtk.manpa...@gmail.com> CC: Yang Shi <yang@linux.alibaba.com> CC: Michal Hocko <mho...@kernel.org> Signed-off-by: Cyrill Gorcunov <gorcu...@gmail.com> -

[rfc linux-next 2/3] [RFC] prctl: prctl_set_mm -- Make prctl_set_mm_map to accept map as an argument

gro...@ntlworld.com> CC: Andrey Vagin <ava...@openvz.org> CC: Andrew Morton <a...@linuxfoundation.org> CC: Michael Kerrisk <mtk.manpa...@gmail.com> CC: Yang Shi <yang@linux.alibaba.com> CC: Michal Hocko <mho...@kernel.org> Signed-off-by: Cyrill Gorcunov <gorcu

[rfc linux-next 1/3] [RFC] prctl: prctl_set_mm -- Move PR_SET_MM_MAP_SIZE out of prctl_set_mm_map

Kerrisk CC: Yang Shi CC: Michal Hocko Signed-off-by: Cyrill Gorcunov --- kernel/sys.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Index: linux-ml.git/kernel/sys.c === --- linux-ml.git.orig/kernel/sys.c

[rfc linux-next 2/3] [RFC] prctl: prctl_set_mm -- Make prctl_set_mm_map to accept map as an argument

Morton CC: Michael Kerrisk CC: Yang Shi CC: Michal Hocko Signed-off-by: Cyrill Gorcunov --- kernel/sys.c | 59 +++ 1 file changed, 31 insertions(+), 28 deletions(-) Index: linux-ml.git/kernel/sys.c

Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

On Sun, May 06, 2018 at 12:01:44PM +0100, Jonathan de Boyne Pollard wrote: > 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. > > Please do not do that, because PR_SET_MM_MAP really does

Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

On Sun, May 06, 2018 at 12:01:44PM +0100, Jonathan de Boyne Pollard wrote: > 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. > > Please do not do that, because PR_SET_MM_MAP really does

Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

On Sun, May 06, 2018 at 12:01:44PM +0100, Jonathan de Boyne Pollard wrote: ... > > Incidentally, it is a welcome change to see the idea that unprivileged > processes may alter these things being introduced, as is already the case on > (say) FreeBSD. > > (I am not subscribed to linux-kernel.)

Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

On Sun, May 06, 2018 at 12:01:44PM +0100, Jonathan de Boyne Pollard wrote: ... > > Incidentally, it is a welcome change to see the idea that unprivileged > processes may alter these things being introduced, as is already the case on > (say) FreeBSD. > > (I am not subscribed to linux-kernel.)

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

CKPOINT_RESTORE is the only user of validate_prctl_map() > and prctl_set_mm_exe_file(), so we can move those two under > CONFIG_CHECKPOINT_RESTORE. > > Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com> Acked-by: Cyrill Gorcunov <gorcu...@openvz.org> Thanks a lot, Sergey!

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

prctl_map() > and prctl_set_mm_exe_file(), so we can move those two under > CONFIG_CHECKPOINT_RESTORE. > > Signed-off-by: Sergey Senozhatsky Acked-by: Cyrill Gorcunov Thanks a lot, Sergey!

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

On Fri, Apr 20, 2018 at 11:38:09AM +0900, Sergey Senozhatsky wrote: > On (04/05/18 21:26), Cyrill Gorcunov wrote: > [..] > > - > > #ifdef CONFIG_CHECKPOINT_RESTORE > > if (opt == PR_SET_MM_MAP || opt == PR_SET_MM_MAP_SIZE) > > return prctl_set_mm_map(

Re: [v2] prctl: Deprecate non PR_SET_MM_MAP operations

On Fri, Apr 20, 2018 at 11:38:09AM +0900, Sergey Senozhatsky wrote: > On (04/05/18 21:26), Cyrill Gorcunov wrote: > [..] > > - > > #ifdef CONFIG_CHECKPOINT_RESTORE > > if (opt == PR_SET_MM_MAP || opt == PR_SET_MM_MAP_SIZE) > > return prctl_set_mm_map(

Re: [PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 18, 2018 at 03:28:20PM -0700, Andrew Morton wrote: > On Thu, 5 Apr 2018 21:26:51 +0300 Cyrill Gorcunov <gorcu...@gmail.com> wrote: > > > Subject: [PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations > > s/Deprecate/remove/ ! Thanks! > > > &g

Re: [PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations

On Wed, Apr 18, 2018 at 03:28:20PM -0700, Andrew Morton wrote: > On Thu, 5 Apr 2018 21:26:51 +0300 Cyrill Gorcunov wrote: > > > Subject: [PATCH v2] prctl: Deprecate non PR_SET_MM_MAP operations > > s/Deprecate/remove/ ! Thanks! > > > > Googling

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Wed, Apr 18, 2018 at 11:03:14AM +0200, Michal Hocko wrote: > > > > > > What about something like the following? > > > " > > > arg_lock protects concurent updates but we still need mmap_sem for read > > > to exclude races with do_brk. > > > " > > > Acked-by: Michal Hocko > >

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Wed, Apr 18, 2018 at 11:03:14AM +0200, Michal Hocko wrote: > > > > > > What about something like the following? > > > " > > > arg_lock protects concurent updates but we still need mmap_sem for read > > > to exclude races with do_brk. > > > " > > > Acked-by: Michal Hocko > > > > Yes, thanks!

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Wed, Apr 18, 2018 at 10:05:55AM +0200, Michal Hocko wrote: > > Yes, looks good to me. As mentioned in other emails prctl_set_mm_map > really deserves a comment explaining why we are doing the down_read > > What about something like the following? > " > arg_lock protects concurent updates but

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Wed, Apr 18, 2018 at 10:05:55AM +0200, Michal Hocko wrote: > > Yes, looks good to me. As mentioned in other emails prctl_set_mm_map > really deserves a comment explaining why we are doing the down_read > > What about something like the following? > " > arg_lock protects concurent updates but

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 17, 2018 at 11:29:57AM -0700, Andrew Morton wrote: > On Sun, 15 Apr 2018 02:24:51 +0800 Yang Shi > wrote: > > > mmap_sem is on the hot path of kernel, and it very contended, but it is > > abused too. It is used to protect arg_start|end and evn_start|end

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 17, 2018 at 11:29:57AM -0700, Andrew Morton wrote: > On Sun, 15 Apr 2018 02:24:51 +0800 Yang Shi > wrote: > > > mmap_sem is on the hot path of kernel, and it very contended, but it is > > abused too. It is used to protect arg_start|end and evn_start|end when > > reading

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

e the later access_remote_vm() call > needs acquire mmap_sem. The mmap_sem scalability issue will be solved in the > future. > > Signed-off-by: Yang Shi <yang@linux.alibaba.com> > Cc: Alexey Dobriyan <adobri...@gmail.com> > Cc: Michal Hocko <mho...@kernel.o

Re: [v4 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

e the later access_remote_vm() call > needs acquire mmap_sem. The mmap_sem scalability issue will be solved in the > future. > > Signed-off-by: Yang Shi > Cc: Alexey Dobriyan > Cc: Michal Hocko > Cc: Matthew Wilcox > Cc: Mateusz Guzik > Cc: Cyrill Gorcunov > --- Looks ok to me, thanks! Reviewed-by: Cyrill Gorcunov

Re: [v3 PATCH] mm: introduce arg_lock to protect arg_start|end and env_start|end in mm_struct

On Tue, Apr 10, 2018 at 12:33:35PM -0700, Yang Shi wrote: ... > > The race condition is just valid when protecting start_brk, brk, start_data > and end_data with the new lock, but keep using mmap_sem in brk path. > > So, we should just need make a little tweak to have mmap_sem protect >

<    1   2   3   4   5   6   7   8   9   10   >