Cc: Mark Rutland
Cc: Radu Rendec
Cc: "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 behaviour flags macro to generate flags/names
pktgen: Remove brute-for
Add macro generated pkt_flag_names array, with a little help of which
the flags can be printed by using an index.
Signed-off-by: Dmitry Safonov
---
net/core/pktgen.c | 77 ++-
1 file changed, 19 insertions(+), 58 deletions(-)
diff --git a/net
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 f9883139e311..e335daa40211 1
PKT_FALGS macro will be used to add package behavior names definitions
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: Dmi
On Thu, 2018-01-18 at 18:00 +0100, Mike Galbraith wrote:
> On Thu, 2018-01-18 at 16:12 +0000, Dmitry Safonov wrote:
> >
> > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> > index 2ea09896bd6e..17e1a04445fa 100644
> > --- a/include/linux/interrup
ted a per-cpu kthread which
will process deferred softirqs of the group.
The parameter will allow an admin define how many ksoftirqd threads
will be created on each cpu and which softirqs have the same
deferring group.
Signed-off-by: Dmitry Safonov
---
Documentation/admin-guide/kernel-parameter
to
serve incoming packages.
The time-based decision will work better than check of re-raised softirq
after processing previous one. Because the check might not work even
under softirq storm if softirqs are raised too slowly (e.g. because of hw).
Signed-off-by: Dmitry Safonov
---
include/linux
For faster operation with pending mask:
pending &= group_to_softirq[group_nr];
Signed-off-by: Dmitry Safonov
---
kernel/softirq.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index ca8c3db4570d..7de5791c08f9 100644
--- a/ke
lt softirq-group which includes all softirqs and running only one
ksoftirqd thread per-cpu.
Signed-off-by: Dmitry Safonov
---
include/linux/interrupt.h | 16 +++-
kernel/sched/cputime.c| 27 ---
kernel/softirq.c | 187 --
net/ipv4/tc
ime to decide if softirq needs to be served or deferred.
It's possible to tune this with ksoftirqd nice policy.
Signed-off-by: Dmitry Safonov
---
include/linux/interrupt.h | 1 +
kernel/sched/fair.c | 38 ++
kernel/sched/sched.h | 19
igned-off-by: Dmitry Safonov
---
include/linux/interrupt.h | 8
kernel/softirq.c | 27 ++-
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5bb6b435f0bb..2ea09896bd6e 100644
exander (Sasha Levin)"
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):
sof
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 floo
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
>
&
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:
>
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 soft
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, whe
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 poin
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
> >
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
> > bei
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
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 |
"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
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
--- a
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
---
ne
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 1
van Riel
Cc: Stanislaw 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 +
then with RFC.
By that reason I have 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/soft
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
---
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.
>> >
>> >
ion
reasons - 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 Sa
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
>>
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 :
&
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
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
mremap() for 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 in
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
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: withou
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
ch is used 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 Sa
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.
Yeah
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 it
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 it
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' sho
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 a
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
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:
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
t 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:
+ 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 res
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
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
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
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
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
istopher Covington
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, 3
orcunov
Cc: Pavel 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 deletion
ussell King
Cc: 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/
he boundary 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'
he boundary 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_x8
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
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.
Not all user space is ready to handle wide addresses. It's known that
at least some JIT compilers use higher bi
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 | 9 ++---
arch/x86/kernel/sys_x86_64.c | 28
Commit-ID: ada26481dfe698ac64b4aaf19a726e66eb8508c6
Gitweb: http://git.kernel.org/tip/ada26481dfe698ac64b4aaf19a726e66eb8508c6
Author: Dmitry Safonov
AuthorDate: Fri, 31 Mar 2017 14:11:37 +0300
Committer: Thomas Gleixner
CommitDate: Fri, 31 Mar 2017 16:53:02 +0200
x86/mm: Make
ter Anvin
Suggested-by: Thomas Gleixner
Signed-off-by: Dmitry Safonov
---
v5: Use generated unistd includes than defining syscall numbers by hands.
v4: Pretend that we've come from appropriate system call than only
setting/dropping x32 bit.
arch/x86/kernel/process_64.c | 70
On 03/31/2017 10:25 AM, Thomas Gleixner wrote:
On Thu, 30 Mar 2017, Dmitry Safonov wrote:
vim +/__NR_ia32_execve +541 arch/x86/kernel/process_64.c
535 set_thread_flag(TIF_IA32);
536 clear_thread_flag(TIF_X32);
537 if (current->mm)
On 03/30/2017 12:31 PM, kbuild test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/mm
head: 693bcce23a1f830d64480cad10f4004e520965fd
commit: 693bcce23a1f830d64480cad10f4004e520965fd [1/1] x86/mm: Make
in_compat_syscall() work during exec
config: x86_64
ter Anvin
Suggested-by: Thomas Gleixner
Signed-off-by: Dmitry Safonov
---
arch/x86/kernel/process_64.c | 67 ++--
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index ea1a6180bf3
On 03/28/2017 03:51 PM, Thomas Gleixner wrote:
On Tue, 28 Mar 2017, Dmitry Safonov wrote:
On 03/22/2017 01:21 AM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
v3:
- clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, this wants to
On 03/22/2017 01:21 AM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
v3:
- clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, this wants to be cleared in the IA32 path as
well. It's not causing any harm, but
I'll am
On 03/22/2017 01:34 AM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, h...@zytor.com wrote:
On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Dmitry Safonov wrote:
v3:
- clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
For correctness sake, t
2017-03-22 0:16 GMT+03:00 Adam Borowski :
> On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote:
>> After my changes to mmap(), its code now relies on the bitness of
>> performing syscall. According to that, it chooses the base of allocation:
>> mmap_base
On 03/21/2017 10:24 PM, Cyrill Gorcunov wrote:
On Tue, Mar 21, 2017 at 10:19:01PM +0300, Dmitry Safonov wrote:
indeed, thanks!
Also, even more simple-minded: for now we could just check binary magic
from /proc/.../exe, for now stopping on x32 binaries.
File may not exist and elfheader
On 03/21/2017 09:40 PM, Cyrill Gorcunov wrote:
On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote:
I guess the question comes from that we're releasing CRIU 3.0 with
32-bit C/R and some other cool stuff, but we don't support x32 yet.
As we don't want release a thing
On 03/21/2017 10:42 PM, Dmitry Safonov wrote:
On 03/21/2017 10:31 PM, Andy Lutomirski wrote:
On Tue, Mar 21, 2017 at 11:09 AM, Dmitry Safonov
wrote:
On 03/21/2017 08:45 PM, Andy Lutomirski wrote:
On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov
wrote:
On Tue, Mar 21, 2017 at 07:37:12PM
On 03/21/2017 10:31 PM, Andy Lutomirski wrote:
On Tue, Mar 21, 2017 at 11:09 AM, Dmitry Safonov wrote:
On 03/21/2017 08:45 PM, Andy Lutomirski wrote:
On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov
wrote:
On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
...
diff --git a
On 03/21/2017 08:45 PM, Andy Lutomirski wrote:
On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov wrote:
On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
...
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index d6b784a5520d..d3d4d9abcaf8 100644
--- a
kvack.org
Cc: Andrei Vagin
Cc: Cyrill Gorcunov
Cc: Borislav Petkov
Cc: "Kirill A. Shutemov"
Cc: x...@kernel.org
Cc: H. Peter Anvin
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Thomas Gleixner
Reported-by: Adam Borowski
Signed-off-by: Dmitry Safonov
---
v2:
- specifying mmap() allocati
On 03/21/2017 08:27 PM, h...@zytor.com wrote:
On March 21, 2017 9:37:12 AM PDT, Dmitry Safonov wrote:
After my changes to mmap(), its code now relies on the bitness of
performing syscall. According to that, it chooses the base of
allocation:
mmap_base for 64-bit mmap() and mmap_compat_base for
On 03/21/2017 03:50 PM, Dmitry Safonov wrote:
On 03/21/2017 03:49 PM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Adam Borowski wrote:
On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
* Andrei Vagin wrote:
# first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
Make
etkov
Cc: "Kirill A. Shutemov"
Cc: x...@kernel.org
Cc: H. Peter Anvin
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Thomas Gleixner
Reported-by: Adam Borowski
Signed-off-by: Dmitry Safonov
---
v2:
- specifying mmap() allocation path which failed during exec()
- fix comment style
arch
On 03/21/2017 06:55 PM, Dmitry Safonov wrote:
After my changes to mmap(), its code now relies on the bitness of
performing syscall. According to that, it chooses the base of allocation:
mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall.
It was done by:
commit 1b028f784e8c
84e8c ("x86/mm: Introduce mmap_compat_base() for
32-bit mmap()")
Cc: 0x7f454...@gmail.com
Cc: linux...@kvack.org
Cc: Cyrill Gorcunov
Cc: Borislav Petkov
Cc: "Kirill A. Shutemov"
Cc: x...@kernel.org
Cc: H. Peter Anvin
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Thomas Gleixner
Reported-by:
On 03/21/2017 03:49 PM, Thomas Gleixner wrote:
On Tue, 21 Mar 2017, Adam Borowski wrote:
On Tue, Mar 21, 2017 at 07:45:39AM +0100, Ingo Molnar wrote:
* Andrei Vagin wrote:
# first bad commit: [45fc8757d1d2128e342b4e7ef39adedf7752faac] x86:
Make the GDT remapping read-only on 64-bit
Just wo
Commit-ID: e13b73dd9c8003993b171173ba803363faf74238
Gitweb: http://git.kernel.org/tip/e13b73dd9c8003993b171173ba803363faf74238
Author: Dmitry Safonov
AuthorDate: Tue, 14 Mar 2017 14:41:26 +0300
Committer: Thomas Gleixner
CommitDate: Tue, 14 Mar 2017 16:29:16 +0100
x86/hugetlb: Adjust
Commit-ID: 7d5c038a03acfbedeb3ffef9da1814a47191f6f1
Gitweb: http://git.kernel.org/tip/7d5c038a03acfbedeb3ffef9da1814a47191f6f1
Author: Dmitry Safonov
AuthorDate: Tue, 14 Mar 2017 14:41:26 +0300
Committer: Thomas Gleixner
CommitDate: Tue, 14 Mar 2017 16:11:47 +0100
x86/hugetlb: Adjust
On 03/14/2017 02:41 PM, Dmitry Safonov wrote:
Commit:
1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit
mmap()")
introduced two mmap() bases for 32-bit syscalls and for 64-bit syscalls.
After that commit mm->mmap_base has address to base allocations for
64-bit sysca
: "Kirill A. Shutemov"
Cc: H. Peter Anvin
Cc: linux...@kvack.org
Cc: Andy Lutomirski
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: x...@kernel.org
Signed-off-by: Dmitry Safonov
---
Note: I've tested it on a simple hand-written test, will reply when
got libhugetlbfs tests running in
On 03/13/2017 05:03 PM, Thomas Gleixner wrote:
On Mon, 13 Mar 2017, Dmitry Safonov wrote:
On 03/13/2017 04:47 PM, Thomas Gleixner wrote:
On Mon, 13 Mar 2017, Dmitry Safonov wrote:
On 03/13/2017 12:39 PM, Thomas Gleixner wrote:
On Mon, 6 Mar 2017, Dmitry Safonov wrote:
Result of mmap
Commit-ID: 3e6ef9c80946f781fc25e8490c9875b1d2b61158
Gitweb: http://git.kernel.org/tip/3e6ef9c80946f781fc25e8490c9875b1d2b61158
Author: Dmitry Safonov
AuthorDate: Mon, 6 Mar 2017 17:17:20 +0300
Committer: Thomas Gleixner
CommitDate: Mon, 13 Mar 2017 14:59:23 +0100
x86/mm: Make mmap
Commit-ID: 6a0b41d1e23dd3318568461593ae5e36d966981e
Gitweb: http://git.kernel.org/tip/6a0b41d1e23dd3318568461593ae5e36d966981e
Author: Dmitry Safonov
AuthorDate: Mon, 6 Mar 2017 17:17:17 +0300
Committer: Thomas Gleixner
CommitDate: Mon, 13 Mar 2017 14:59:22 +0100
x86/mm: Introduce
Commit-ID: 1b028f784e8c341e762c264f70dc0ca1418c8b7a
Gitweb: http://git.kernel.org/tip/1b028f784e8c341e762c264f70dc0ca1418c8b7a
Author: Dmitry Safonov
AuthorDate: Mon, 6 Mar 2017 17:17:19 +0300
Committer: Thomas Gleixner
CommitDate: Mon, 13 Mar 2017 14:59:22 +0100
x86/mm: Introduce
Commit-ID: 8f3e474f3cea7b2470218a6ed6da47ff02147dce
Gitweb: http://git.kernel.org/tip/8f3e474f3cea7b2470218a6ed6da47ff02147dce
Author: Dmitry Safonov
AuthorDate: Mon, 6 Mar 2017 17:17:18 +0300
Committer: Thomas Gleixner
CommitDate: Mon, 13 Mar 2017 14:59:22 +0100
x86/mm: Add task_size
On 03/13/2017 04:47 PM, Thomas Gleixner wrote:
On Mon, 13 Mar 2017, Dmitry Safonov wrote:
On 03/13/2017 12:39 PM, Thomas Gleixner wrote:
On Mon, 6 Mar 2017, Dmitry Safonov wrote:
Result of mmap() calls with MAP_32BIT flag at this moment depends
on thread flag TIF_ADDR32, which is set during
On 03/13/2017 12:39 PM, Thomas Gleixner wrote:
On Mon, 6 Mar 2017, Dmitry Safonov wrote:
Result of mmap() calls with MAP_32BIT flag at this moment depends
on thread flag TIF_ADDR32, which is set during exec() for 32-bit apps.
It's broken as the behavior of mmap() shouldn't depend
_base
on two bases: for 64-bit syscall and for 32-bit syscalls.
Signed-off-by: Dmitry Safonov
---
arch/x86/include/asm/elf.h | 24 ++-
arch/x86/include/asm/processor.h | 4 +++-
arch/x86/mm/mmap.c | 50 +---
3 files change
d VMA [0x7f936f36a000, 0x7f936f76a000] in maps file, that was
allocated with compat syscall
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Dmitry Safonov
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/test_compat_mmap.c
ls it will be always ignored and for 64-bit syscalls it'll
always return 32-bit pointer restricted with 1Gb adress space,
independently of the binary's bitness of executed application.
Signed-off-by: Dmitry Safonov
---
arch/x86/kernel/sys_x86_64.c | 4 ++--
1 file changed, 2 insertions(+)
il first mmap()
call, but don't think it's worth.
Signed-off-by: Dmitry Safonov
---
arch/Kconfig | 7 +++
arch/x86/Kconfig | 1 +
arch/x86/include/asm/elf.h | 3 +++
arch/x86/kernel/sys_x86_64.c | 23 +++
arch/x86/mm/mma
of mmap_is_ia32().
Suggested-by: Thomas Gleixner
Signed-off-by: Dmitry Safonov
---
arch/x86/mm/mmap.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 7940166c799b..f31ed7097d0b 100644
--- a/arch/x86/mm
601 - 700 of 1001 matches
Mail list logo
