[RFC 0/6] Multi-thread per-cpu ksoftirqd

r...@redhat.com> Cc: Stanislaw Gruszka <sgrus...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Wanpeng Li <wanpeng...@hotmail.com> Dmitry Safonov (6): softirq: Add softirq_groups boot parameter softirq: Introduce mask for __do_softirq() softirq: Add reverse group-

[RFC 0/6] Multi-thread per-cpu ksoftirqd

)" Cc: Linus Torvalds Cc: Mauro Carvalho Chehab Cc: Mike Galbraith Cc: Paolo Abeni Cc: "Paul E. McKenney" Cc: Peter Zijlstra Cc: Radu Rendec Cc: Rik van Riel Cc: Stanislaw Gruszka Cc: Thomas Gleixner Cc: Wanpeng Li Dmitry Safonov (6): softirq: Add softirq_gr

Re: [RFC PATCH 0/5] softirq: Per vector threading v2

On Thu, 2018-01-18 at 05:09 +0100, Frederic Weisbecker wrote: > On Wed, Jan 17, 2018 at 07:09:39PM -0800, Linus Torvalds wrote: > > It should never trigger under any normal load, but I think it > > *should* > > trigger under the load that the networking people worry about. If > > you > > get a

Re: [RFC PATCH 0/5] softirq: Per vector threading v2

On Thu, 2018-01-18 at 05:09 +0100, Frederic Weisbecker wrote: > On Wed, Jan 17, 2018 at 07:09:39PM -0800, Linus Torvalds wrote: > > It should never trigger under any normal load, but I think it > > *should* > > trigger under the load that the networking people worry about. If > > you > > get a

Re: [PATCH 3/5] pktgen: Add behavior flag names array - pkt_flag_names

On Mon, 2018-01-15 at 13:09 -0500, David Miller wrote: > From: Dmitry Safonov <d...@arista.com> > Date: Tue, 9 Jan 2018 13:55:33 + > > > +#define pf(flag) __stringify(flag), > > +char *pkt_flag_names[] = { > > + PKT_FLAGS > > +}; &g

Re: [PATCH 3/5] pktgen: Add behavior flag names array - pkt_flag_names

On Mon, 2018-01-15 at 13:09 -0500, David Miller wrote: > From: Dmitry Safonov > Date: Tue, 9 Jan 2018 13:55:33 + > > > +#define pf(flag) __stringify(flag), > > +char *pkt_flag_names[] = { > > + PKT_FLAGS > > +}; > > +#undef pf > &

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:53 -0800, Eric Dumazet wrote: > On Thu, Jan 11, 2018 at 12:46 PM, Dmitry Safonov <d...@arista.com> > wrote: > > On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: > > > On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov <d...@

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:53 -0800, Eric Dumazet wrote: > On Thu, Jan 11, 2018 at 12:46 PM, Dmitry Safonov > wrote: > > On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: > > > On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov > > > > > > wrote: >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov <d...@arista.com> > wrote: > > > > I could try to write a PoC for that.. > > What should be the trigger to fall into workqueue? > > How to tell if th

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:40 -0800, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 12:34 PM, Dmitry Safonov > wrote: > > > > I could try to write a PoC for that.. > > What should be the trigger to fall into workqueue? > > How to tell if there're too many softir

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 12:16 PM, Eric Dumazet > wrote: > > > > Note that when I implemented TCP Small queues, I did experiments > > between > > using a work queue or a tasklet, and workqueues added unacceptable > >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 12:22 -0800, Linus Torvalds wrote: > On Thu, Jan 11, 2018 at 12:16 PM, Eric Dumazet > wrote: > > > > Note that when I implemented TCP Small queues, I did experiments > > between > > using a work queue or a tasklet, and workqueues added unacceptable > > P99 > > latencies,

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 05:44 +0100, Frederic Weisbecker wrote: > On Wed, Jan 10, 2018 at 08:19:49PM -0800, Linus Torvalds wrote: > > On Wed, Jan 10, 2018 at 7:22 PM, Frederic Weisbecker > > wrote: > > > > > > Makes sense, but I think you need to keep the TASK_RUNNING check. >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Thu, 2018-01-11 at 05:44 +0100, Frederic Weisbecker wrote: > On Wed, Jan 10, 2018 at 08:19:49PM -0800, Linus Torvalds wrote: > > On Wed, Jan 10, 2018 at 7:22 PM, Frederic Weisbecker > > wrote: > > > > > > Makes sense, but I think you need to keep the TASK_RUNNING check. > > > > Yes, good

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Tue, 2018-01-09 at 10:02 -0800, Eric Dumazet wrote: > On Tue, Jan 9, 2018 at 5:36 AM, Dmitry Safonov <d...@arista.com> > wrote: > > Warning: Not merge-ready > > > > I. Current workflow of ksoftirqd. > > Softirqs are processed in the context of ksoftirqd

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Tue, 2018-01-09 at 10:02 -0800, Eric Dumazet wrote: > On Tue, Jan 9, 2018 at 5:36 AM, Dmitry Safonov > wrote: > > Warning: Not merge-ready > > > > I. Current workflow of ksoftirqd. > > Softirqs are processed in the context of ksoftirqd iff they are > >

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Tue, 2018-01-09 at 17:03 +0100, Frederic Weisbecker wrote: > 2018-01-09 14:36 UTC+01:00, Dmitry Safonov <d...@arista.com>: > > Warning: Not merge-ready > > > > I. Current workflow of ksoftirqd. > > Softirqs are processed in the context of ksoftirqd iff

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On Tue, 2018-01-09 at 17:03 +0100, Frederic Weisbecker wrote: > 2018-01-09 14:36 UTC+01:00, Dmitry Safonov : > > Warning: Not merge-ready > > > > I. Current workflow of ksoftirqd. > > Softirqs are processed in the context of ksoftirqd iff they are > >

[PATCH 1/5] Documentation/pktgen: Clearify how-to use pktgen samples

to `source functions.sh`. o Document how-to unset a behaviour flag, note about history expansion. o Fix pgset spi parameter value. Cc: Jonathan Corbet <cor...@lwn.net> Cc: linux-...@vger.kernel.org Signed-off-by: Dmitry Safonov <d...@arista.com> --- Documentation/networking/pkt

[PATCH 1/5] Documentation/pktgen: Clearify how-to use pktgen samples

to `source functions.sh`. o Document how-to unset a behaviour flag, note about history expansion. o Fix pgset spi parameter value. Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Signed-off-by: Dmitry Safonov --- Documentation/networking/pktgen.txt | 19 ++- 1 file changed, 14

[PATCH 3/5] pktgen: Add behavior flag names array - pkt_flag_names

The array will be used to simplify the code that prints/reads pkg flags. Sorted the array in order of printing the flags in pktgen_if_show() Note: Renamed IPSEC_ON => IPSEC for simplicity. No visible behavior change expected. Signed-off-by: Dmitry Safonov <d...@arista.com> --- net/core

[PATCH 3/5] pktgen: Add behavior flag names array - pkt_flag_names

The array will be used to simplify the code that prints/reads pkg flags. Sorted the array in order of printing the flags in pktgen_if_show() Note: Renamed IPSEC_ON => IPSEC for simplicity. No visible behavior change expected. Signed-off-by: Dmitry Safonov --- net/core/pktgen.c |

[PATCH 0/5] pktgen: Behavior flags fixes

t;eduma...@google.com> Cc: Ingo Molnar <mi...@kernel.org> Cc: Johannes Berg <johannes.b...@intel.com> Cc: Mark Rutland <mark.rutl...@arm.com> Cc: Radu Rendec <rren...@arista.com> Cc: "Reshetova, Elena" <elena.reshet...@intel.com> Cc: net...@vger.kernel.org Dmit

[PATCH 0/5] pktgen: Behavior flags fixes

"Reshetova, Elena" Cc: net...@vger.kernel.org Dmitry Safonov (5): Documentation/pktgen: Clearify how-to use pktgen samples pktgen: Add missing !flag parameters pktgen: Add behavior flag names array - pkt_flag_names pktgen: Remove brute-force printing of flags pktgen: Clean read use

[PATCH 4/5] pktgen: Remove brute-force printing of flags

Like, we can do it using index. Signed-off-by: Dmitry Safonov <d...@arista.com> --- net/core/pktgen.c | 71 ++- 1 file changed, 13 insertions(+), 58 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index 51f273

[PATCH 4/5] pktgen: Remove brute-force printing of flags

Like, we can do it using index. Signed-off-by: Dmitry Safonov --- net/core/pktgen.c | 71 ++- 1 file changed, 13 insertions(+), 58 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index 51f273319baf..e320f0cbfd62 100644

[PATCH 2/5] pktgen: Add missing !flag parameters

o FLOW_SEQ now can be disabled with pgset "flag !FLOW_SEQ" o FLOW_SEQ and FLOW_RND are antonyms, as it's shown by pktgen_if_show() o IPSEC now may be disabled Note, that IPV6 is enabled with dst6/src6 parameters, not with a flag parameter. Signed-off-by: Dmitry Safonov <d...@arista.

[PATCH 2/5] pktgen: Add missing !flag parameters

o FLOW_SEQ now can be disabled with pgset "flag !FLOW_SEQ" o FLOW_SEQ and FLOW_RND are antonyms, as it's shown by pktgen_if_show() o IPSEC now may be disabled Note, that IPV6 is enabled with dst6/src6 parameters, not with a flag parameter. Signed-off-by: Dmitry Safonov --- net/cor

[PATCH 5/5] pktgen: Clean read user supplied flag mess

Don't use error-prone-brute-force way. Signed-off-by: Dmitry Safonov <d...@arista.com> --- net/core/pktgen.c | 144 +++--- 1 file changed, 39 insertions(+), 105 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index e320f0

[PATCH 5/5] pktgen: Clean read user supplied flag mess

Don't use error-prone-brute-force way. Signed-off-by: Dmitry Safonov --- net/core/pktgen.c | 144 +++--- 1 file changed, 39 insertions(+), 105 deletions(-) diff --git a/net/core/pktgen.c b/net/core/pktgen.c index e320f0cbfd62..a3862e500643 100644

[RFC 0/2] Net softirq deferring to ksoftirqd

u Rendec <rren...@arista.com> Cc: Rik van Riel <r...@redhat.com> Cc: Stanislaw Gruszka <sgrus...@redhat.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Wanpeng Li <wanpeng...@hotmail.com> Dmitry Safonov (2): softirq: Defer net rx/tx processing to ksoftirqd context

[RFC 0/2] Net softirq deferring to ksoftirqd

tanislaw Gruszka Cc: Thomas Gleixner Cc: Wanpeng Li Dmitry Safonov (2): softirq: Defer net rx/tx processing to ksoftirqd context softirq: Introduce mask for __do_softirq() include/linux/interrupt.h | 8 kernel/softirq.c | 48 ++--

[RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

ave qualms if my test's results are correct. V. References: [1] 4cd13c21b207 ("softirq: Let ksoftirqd do its job") [2] https://github.com/netoptimizer/network-testing/blob/master/src/udp_sink.c Signed-off-by: Dmitry Safonov <d...@arista.com> --- kernel/softirq.c | 29 +++

[RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

ave qualms if my test's results are correct. V. References: [1] 4cd13c21b207 ("softirq: Let ksoftirqd do its job") [2] https://github.com/netoptimizer/network-testing/blob/master/src/udp_sink.c Signed-off-by: Dmitry Safonov --- kernel/softirq.c | 29 -

[RFC 2/2] softirq: Introduce mask for __do_softirq()

Warning: Not merge-ready, tested only on x86_64 & arm32. For the reason of deferring net-softirqs till ksoftirqd run, __do_softirq() needs to process softirqs with mask, depending if it's called from ksoftirqd thread or on the context of some task. Signed-off-by: Dmitry Safonov <d...@ari

[RFC 2/2] softirq: Introduce mask for __do_softirq()

Warning: Not merge-ready, tested only on x86_64 & arm32. For the reason of deferring net-softirqs till ksoftirqd run, __do_softirq() needs to process softirqs with mask, depending if it's called from ksoftirqd thread or on the context of some task. Signed-off-by: Dmitry Safonov --- inc

Re: [PATCH v2 02/17] mm: Exempt special mappings from mlock(), mprotect() and madvise()

Hi, sorry for the late reply, 2017-12-14 17:36 GMT+00:00 Peter Zijlstra : > On Thu, Dec 14, 2017 at 08:19:36AM -0800, Andy Lutomirski wrote: >> On Thu, Dec 14, 2017 at 3:27 AM, Peter Zijlstra wrote: >> > It makes no sense to ever prod at special

Re: [PATCH v2 02/17] mm: Exempt special mappings from mlock(), mprotect() and madvise()

Hi, sorry for the late reply, 2017-12-14 17:36 GMT+00:00 Peter Zijlstra : > On Thu, Dec 14, 2017 at 08:19:36AM -0800, Andy Lutomirski wrote: >> On Thu, Dec 14, 2017 at 3:27 AM, Peter Zijlstra wrote: >> > It makes no sense to ever prod at special mappings with any of these >> > syscalls. >> > >>

Re: [PATCH AUTOSEL for 4.9 04/52] x86/selftests: Add clobbers for int80 on x86_64

- as people in userspace can reuse this code and think it's good and will just work after copy-paste (which is not the case). So, this patch doesn't look urgent to include it in -stable kernel. Thanks, Dmitry 2017-11-29 17:21 GMT+00:00 <alexander.le...@verizon.com>: > From: Dmitr

Re: [PATCH AUTOSEL for 4.9 04/52] x86/selftests: Add clobbers for int80 on x86_64

- as people in userspace can reuse this code and think it's good and will just work after copy-paste (which is not the case). So, this patch doesn't look urgent to include it in -stable kernel. Thanks, Dmitry 2017-11-29 17:21 GMT+00:00 : > From: Dmitry Safonov > > [ Upstre

Re: BUG: Sporadic crashes with current Linus tree

Hi Tglx, Andy, Sorry for old-posting, 2017-09-15 8:09 GMT+01:00 Thomas Gleixner : > On Thu, 14 Sep 2017, Andy Lutomirski wrote: >> On Thu, Sep 14, 2017 at 9:00 AM, Thomas Gleixner wrote: >> > On Thu, 14 Sep 2017, Andy Lutomirski wrote: >> >> On Thu, Sep

Re: BUG: Sporadic crashes with current Linus tree

Hi Tglx, Andy, Sorry for old-posting, 2017-09-15 8:09 GMT+01:00 Thomas Gleixner : > On Thu, 14 Sep 2017, Andy Lutomirski wrote: >> On Thu, Sep 14, 2017 at 9:00 AM, Thomas Gleixner wrote: >> > On Thu, 14 Sep 2017, Andy Lutomirski wrote: >> >> On Thu, Sep 14, 2017 at 12:38 AM, Thomas Gleixner

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-08-08 12:44 GMT+03:00 Will Deacon <will.dea...@arm.com>: > On Tue, Aug 08, 2017 at 12:29:50PM +0300, Dmitry Safonov wrote: >> 2017-08-02 19:04 GMT+03:00 Will Deacon <will.dea...@arm.com>: >> > On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: &g

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-08-08 12:44 GMT+03:00 Will Deacon : > On Tue, Aug 08, 2017 at 12:29:50PM +0300, Dmitry Safonov wrote: >> 2017-08-02 19:04 GMT+03:00 Will Deacon : >> > On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: >> >> 2017-07-28 19:48 GMT+03:00 Will Deacon

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-08-02 19:04 GMT+03:00 Will Deacon <will.dea...@arm.com>: > On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: >> 2017-07-28 19:48 GMT+03:00 Will Deacon <will.dea...@arm.com>: >> > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: &

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-08-02 19:04 GMT+03:00 Will Deacon : > On Fri, Jul 28, 2017 at 10:06:20PM +0300, Dmitry Safonov wrote: >> 2017-07-28 19:48 GMT+03:00 Will Deacon : >> > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: >> >> vDSO VMA address is saved in mm_co

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-07-28 19:48 GMT+03:00 Will Deacon <will.dea...@arm.com>: > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: >> vDSO VMA address is saved in mm_context for the purpose of using >> restorer from vDSO page to return to userspace after signal handling. >&g

Re: [PATCH] arm64/vdso: Support mremap() for vDSO

2017-07-28 19:48 GMT+03:00 Will Deacon : > On Wed, Jul 26, 2017 at 08:07:37PM +0300, Dmitry Safonov wrote: >> vDSO VMA address is saved in mm_context for the purpose of using >> restorer from vDSO page to return to userspace after signal handling. >> >> In Checkpoint

[PATCH] arm64/vdso: Support mremap() for vDSO

...@virtuozzo.com> Cc: Christopher Covington <c...@codeaurora.org> Signed-off-by: Dmitry Safonov <dsafo...@virtuozzo.com> --- arch/arm64/kernel/vdso.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c index e8f759f764f2..2d419

[PATCH] arm64/vdso: Support mremap() for vDSO

or sigpage/vDSO"). Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: Cyrill Gorcunov Cc: Pavel Emelyanov Cc: Christopher Covington Signed-off-by: Dmitry Safonov --- arch/arm64/kernel/vdso.c | 15 +++ 1 file changed, 15 insertions(+

Re: [BUG]: NULL ptr dereference in unix_stream_sendmsg+0x1c1/0x380

Sorry, I've forgot to change the subject as the first time it fired at xlog_cil_push(), but all reproductions fire on unix_stream_sendmsg(). On 07/13/2017 06:16 PM, Dmitry Safonov wrote: Hello, We run CRIU tests on linux-next tree and today we found this issue. CRIU tests are the set of small

Re: [BUG]: NULL ptr dereference in unix_stream_sendmsg+0x1c1/0x380

Sorry, I've forgot to change the subject as the first time it fired at xlog_cil_push(), but all reproductions fire on unix_stream_sendmsg(). On 07/13/2017 06:16 PM, Dmitry Safonov wrote: Hello, We run CRIU tests on linux-next tree and today we found this issue. CRIU tests are the set of small

[BUG]: NULL ptr dereference in xlog_cil_push+0x274/0x430

Hello, We run CRIU tests on linux-next tree and today we found this issue. CRIU tests are the set of small programs to check checkpoint/restore of different primitives (files, sockets, signals, pipes, etc). https://github.com/xemul/criu/tree/master/test Each test is executed three times:

[BUG]: NULL ptr dereference in xlog_cil_push+0x274/0x430

Hello, We run CRIU tests on linux-next tree and today we found this issue. CRIU tests are the set of small programs to check checkpoint/restore of different primitives (files, sockets, signals, pipes, etc). https://github.com/xemul/criu/tree/master/test Each test is executed three times:

Re: [PATCH 2/2] x86/elf: remove the unnecessary ADDR_NO_RANDOMIZE checks in stack_maxrandom_size() and randomize_stack_top()

On 07/10/2017 02:14 PM, Oleg Nesterov wrote: PF_RANDOMIZE is set by load_elf_binary() only if ADDR_NO_RANDOMIZE is not set, no need to re-check after that.that.that.that.that.that.that.that. Signed-off-by: Oleg Nesterov <o...@redhat.com> Reviewed-by: Dmitry Safonov <dsafo...@virt

Re: [PATCH 2/2] x86/elf: remove the unnecessary ADDR_NO_RANDOMIZE checks in stack_maxrandom_size() and randomize_stack_top()

On 07/10/2017 02:14 PM, Oleg Nesterov wrote: PF_RANDOMIZE is set by load_elf_binary() only if ADDR_NO_RANDOMIZE is not set, no need to re-check after that.that.that.that.that.that.that.that. Signed-off-by: Oleg Nesterov Reviewed-by: Dmitry Safonov --- arch/x86/mm/mmap.c | 3 +-- fs

Re: [PATCH 1/2] x86: fix norandmaps

sed to randomize mm->mmap_base returns a random value unconditionally. Shift the PF_RANDOMIZE check from arch_mmap_rnd() to arch_rnd(). Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()") Signed-off-by: Oleg Nesterov <o...@redhat.com> Thanks, Oleg, Reviewed-by:

Re: [PATCH 1/2] x86: fix norandmaps

sed to randomize mm->mmap_base returns a random value unconditionally. Shift the PF_RANDOMIZE check from arch_mmap_rnd() to arch_rnd(). Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()") Signed-off-by: Oleg Nesterov Thanks, Oleg, Reviewed-by: Dmitry Safonov -

Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c

On 06/22/2017 04:07 AM, Hugh Dickins wrote: On Wed, 21 Jun 2017, Linus Torvalds wrote: On Wed, Jun 21, 2017 at 1:56 PM, Oleg Nesterov wrote: I understand. My point is that this check was invalidated by stack-guard-page a long ago, and this means that we add the user-visible

Re: [lkp-robot] [mm] 1be7107fbe: kernel_BUG_at_mm/mmap.c

On 06/22/2017 04:07 AM, Hugh Dickins wrote: On Wed, 21 Jun 2017, Linus Torvalds wrote: On Wed, Jun 21, 2017 at 1:56 PM, Oleg Nesterov wrote: I understand. My point is that this check was invalidated by stack-guard-page a long ago, and this means that we add the user-visible change now.

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:31 PM, Oleg Nesterov wrote: On 06/21, Dmitry Safonov wrote: The only question I have - how is it connected to guard page? Because with stack guard page do_page_fault() almost never needs to call expand_stack(), thus this check was almost never tested, I guess. Probably

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:31 PM, Oleg Nesterov wrote: On 06/21, Dmitry Safonov wrote: The only question I have - how is it connected to guard page? Because with stack guard page do_page_fault() almost never needs to call expand_stack(), thus this check was almost never tested, I guess. Probably

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:31 PM, Oleg Nesterov wrote: On 06/21, Dmitry Safonov wrote: The only question I have - how is it connected to guard page? Because with stack guard page do_page_fault() almost never needs to call expand_stack(), thus this check was almost never tested, I guess. Probably

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:31 PM, Oleg Nesterov wrote: On 06/21, Dmitry Safonov wrote: The only question I have - how is it connected to guard page? Because with stack guard page do_page_fault() almost never needs to call expand_stack(), thus this check was almost never tested, I guess. Probably

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:15 PM, Dmitry Safonov wrote: On 06/21/2017 08:01 PM, Oleg Nesterov wrote: On 06/21, Cyrill Gorcunov wrote: On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: p = fake_grow_down; *p-- = 'c'; I guess this works? I mean, *p-- = 'c' should not fail

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:15 PM, Dmitry Safonov wrote: On 06/21/2017 08:01 PM, Oleg Nesterov wrote: On 06/21, Cyrill Gorcunov wrote: On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: p = fake_grow_down; *p-- = 'c'; I guess this works? I mean, *p-- = 'c' should not fail

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:01 PM, Oleg Nesterov wrote: On 06/21, Cyrill Gorcunov wrote: On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: p = fake_grow_down; *p-- = 'c'; I guess this works? I mean, *p-- = 'c' should not fail... It fails. Hmm. Impossible ;) could you

Re: [criu] 1M guard page ruined restore

On 06/21/2017 08:01 PM, Oleg Nesterov wrote: On 06/21, Cyrill Gorcunov wrote: On Wed, Jun 21, 2017 at 05:57:30PM +0200, Oleg Nesterov wrote: p = fake_grow_down; *p-- = 'c'; I guess this works? I mean, *p-- = 'c' should not fail... It fails. Hmm. Impossible ;) could you

Re: [PATCH] binder: Drop needless locking in binder_mmap()

On 05/24/2017 05:51 PM, Dmitry Safonov wrote: binder_mmap() protected proc->buffer from concurrent changes. It was introduced with commit bd1eff9741af ("Staging: android: binder: Fix crashes when sharing a binder file between processes"). The commit fixed such races alike: t

Re: [PATCH] binder: Drop needless locking in binder_mmap()

On 05/24/2017 05:51 PM, Dmitry Safonov wrote: binder_mmap() protected proc->buffer from concurrent changes. It was introduced with commit bd1eff9741af ("Staging: android: binder: Fix crashes when sharing a binder file between processes"). The commit fixed such races alike: t

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 05/24/2017 07:44 PM, Andy Lutomirski wrote: On Wed, May 24, 2017 at 3:09 AM, Dmitry Safonov <dsafo...@virtuozzo.com> wrote: + Adding back to CC x86 guys - as I've removed in ping messages. On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote: On Thu, May 18, 2017 at 02:13:29PM

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 05/24/2017 07:44 PM, Andy Lutomirski wrote: On Wed, May 24, 2017 at 3:09 AM, Dmitry Safonov wrote: + Adding back to CC x86 guys - as I've removed in ping messages. On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote: On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote

[PATCH] binder: remove unused BINDER_SMALL_BUF_SIZE define

It was never used since addition of binder to linux mainstream tree. Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: "Arve Hjønnevåg" <a...@android.com> Cc: Riley Andrews <riandr...@android.com> Cc: de...@driverdev.osuosl.org Signed-off-by: Dmitry Saf

[PATCH] binder: remove unused BINDER_SMALL_BUF_SIZE define

It was never used since addition of binder to linux mainstream tree. Cc: Greg Kroah-Hartman Cc: "Arve Hjønnevåg" Cc: Riley Andrews Cc: de...@driverdev.osuosl.org Signed-off-by: Dmitry Safonov --- drivers/android/binder.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drive

[PATCH] binder: Drop needless locking in binder_mmap()

y Andrews <riandr...@android.com> Cc: de...@driverdev.osuosl.org Cc: Android Kernel Team <kernel-t...@android.com> Signed-off-by: Dmitry Safonov <dsafo...@virtuozzo.com> --- drivers/android/binder.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/android/binder.c b/d

[PATCH] binder: Drop needless locking in binder_mmap()

. That commit prohibited mmap'ing of fd, that was opened by some other task. That restriction has made locking in binder_mmap() unnecessary. Cc: Al Viro Cc: "Arve Hjønnevåg" Cc: Greg Kroah-Hartman Cc: Riley Andrews Cc: de...@driverdev.osuosl.org Cc: Android Kernel Team Signed-off-by: Dmitry Sa

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

+ Adding back to CC x86 guys - as I've removed in ping messages. On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote: On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote: On 04/25/2017 08:18 PM, Dmitry Safonov wrote: On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

+ Adding back to CC x86 guys - as I've removed in ping messages. On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote: On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote: On 04/25/2017 08:18 PM, Dmitry Safonov wrote: On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/25/2017 08:35 PM, Russell King - ARM Linux wrote: On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/25/2017 08:35 PM, Russell King - ARM Linux wrote: On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 04/25/2017 08:18 PM, Dmitry Safonov wrote: On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores application mappings on the same place where they were before Checkpoint. That means, that we need to move vDSO and sigpage during restore on exactly the same place where they were before C

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 04/25/2017 08:18 PM, Dmitry Safonov wrote: On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores application mappings on the same place where they were before Checkpoint. That means, that we need to move vDSO and sigpage during restore on exactly the same place where they were before C

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/25/2017 08:35 PM, Russell King - ARM Linux wrote: On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/25/2017 08:35 PM, Russell King - ARM Linux wrote: On Tue, Apr 25, 2017 at 08:19:21PM +0300, Dmitry Safonov wrote: On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical address, then changes made to one of the alias might be lost or they can overwrite each other. To overcome aliasing issues

Re: [PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

On 04/14/2017 01:09 PM, Dmitry Safonov wrote: On ARMv6 CPUs with VIPT caches there are aliasing issues: if two different cache line indexes correspond to the same physical address, then changes made to one of the alias might be lost or they can overwrite each other. To overcome aliasing issues

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores application mappings on the same place where they were before Checkpoint. That means, that we need to move vDSO and sigpage during restore on exactly the same place where they were before C/R. Make mremap() code update mm->cont

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

On 04/14/2017 04:25 PM, Dmitry Safonov wrote: CRIU restores application mappings on the same place where they were before Checkpoint. That means, that we need to move vDSO and sigpage during restore on exactly the same place where they were before C/R. Make mremap() code update mm->cont

[PATCHv2] ARM32: Support mremap() for sigpage/vDSO

c: Thomas Gleixner <t...@linutronix.de> Cc: Cyrill Gorcunov <gorcu...@openvz.org> Cc: Pavel Emelyanov <xe...@virtuozzo.com> Cc: Christopher Covington <c...@codeaurora.org> Signed-off-by: Dmitry Safonov <dsafo...@virtuozzo.com> --- v2: (buildbot) Fix (unsinged long) to (vo

[PATCHv2] ARM32: Support mremap() for sigpage/vDSO

ton Signed-off-by: Dmitry Safonov --- v2: (buildbot) Fix (unsinged long) to (void*) cast warning. arch/arm/kernel/process.c | 8 arch/arm/kernel/vdso.c| 18 ++ arch/x86/entry/vdso/vma.c | 3 --- mm/mmap.c | 4 4 files changed, 30 insertions(+)

[PATCH] ARM32: Support mremap() for sigpage/vDSO

y Lutomirski <l...@amacapital.net> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Cyrill Gorcunov <gorcu...@openvz.org> Cc: Pavel Emelyanov <xe...@virtuozzo.com> Cc: Christopher Covington <c...@codeaurora.org> Signed-off-by: Dmitry Safonov <dsafo...@virtuozzo.com> --- arch/

[PATCH] ARM32: Support mremap() for sigpage/vDSO

vel Emelyanov Cc: Christopher Covington Signed-off-by: Dmitry Safonov --- arch/arm/kernel/process.c | 8 arch/arm/kernel/vdso.c| 18 ++ arch/x86/entry/vdso/vma.c | 3 --- mm/mmap.c | 4 4 files changed, 30 insertions(+), 3 deletions(-) diff --

[PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

Deacon <will.dea...@arm.com> Cc: Russell King <rmk+ker...@armlinux.org.uk> Cc: Christopher Covington <c...@codeaurora.org> Cc: Cyrill Gorcunov <gorcu...@openvz.org> Cc: Pavel Emelyanov <xe...@virtuozzo.com> Suggested-by: Russell King <rmk+ker...@armlinux.org.u

[PATCH] ARM/shmem: Drop page coloring align for non-VIPT CPUs

: Christopher Covington Cc: Cyrill Gorcunov Cc: Pavel Emelyanov Suggested-by: Russell King Signed-off-by: Dmitry Safonov --- arch/arm/include/asm/shmparam.h | 8 arch/arm/mm/copypage-v6.c | 5 + 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/arm/include/asm

Re: [PATCHv3 8/8] x86/mm: Allow to have userspace mappings above 47-bits

and forbid creating such VMAs once MPX is enabled. Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> Cc: Dmitry Safonov <dsafo...@virtuozzo.com> LGTM, Reviewed-by: Dmitry Safonov <dsafo...@virtuozzo.com> Thou, I'm not very excited about TASK_SIZE_LOW naming

Re: [PATCHv3 8/8] x86/mm: Allow to have userspace mappings above 47-bits

and forbid creating such VMAs once MPX is enabled. Signed-off-by: Kirill A. Shutemov Cc: Dmitry Safonov LGTM, Reviewed-by: Dmitry Safonov Thou, I'm not very excited about TASK_SIZE_LOW naming, but I'm not good at naming either, so maybe tglx will help. Anyway, I don't see any problems with code's

Re: [PATCHv2 8/8] x86/mm: Allow to have userspace mappings above 47-bits

and forbid creating such VMAs once MPX is enabled. Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> Cc: Dmitry Safonov <dsafo...@virtuozzo.com> --- arch/x86/include/asm/elf.h | 2 +- arch/x86/include/asm/mpx.h | 9 + arch/x86/include/asm/proc

Re: [PATCHv2 8/8] x86/mm: Allow to have userspace mappings above 47-bits

and forbid creating such VMAs once MPX is enabled. Signed-off-by: Kirill A. Shutemov Cc: Dmitry Safonov --- arch/x86/include/asm/elf.h | 2 +- arch/x86/include/asm/mpx.h | 9 + arch/x86/include/asm/processor.h | 10 +++--- arch/x86/kernel/sys_x86_64.c | 28

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On 04/07/2017 02:21 AM, Kirill A. Shutemov wrote: On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: On 04/06/2017 09:43 PM, Dmitry Safonov wrote: Hi Kirill, On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: On x86, 5-level paging enables 56-bit userspace virtual address space

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On 04/07/2017 02:21 AM, Kirill A. Shutemov wrote: On Thu, Apr 06, 2017 at 10:15:47PM +0300, Dmitry Safonov wrote: On 04/06/2017 09:43 PM, Dmitry Safonov wrote: Hi Kirill, On 04/06/2017 05:01 PM, Kirill A. Shutemov wrote: On x86, 5-level paging enables 56-bit userspace virtual address space

<    4   5   6   7   8   9   10   11   12   13   >